• In diesem Bereich findet ihr Tutorials und Reviews. Die Forenrechte zur Erstellung neuer Themen sind hier eingeschränkt, da Problemdiskussionen bitte in den übrigen Forenbereichen auf Apfeltalk zu führen sind. Wer ein Tutorial oder Review einstellen möchte, kann im Unterforum "Einreichung neuer Tutorials" ein neues Thema erstellen. Die Moderatoren verschieben den Beitrag dann in den passenden Bereich.
  • Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

[TUTORIAL] Terminal - Teil 4

  • Ersteller Hobbes_
  • Erstellt am

Hobbes_

Gast
Dies ist Teil 4 eines Tutorials zu Terminal

Inhalt
Teil 1
(0) Einleitung
(1) Das Programm
(2) Unix als System
(3) man
(4) Einige Befehle

Teil 2
(5) I/O-Redirection / Pipes und Wildcards / Regular Expressions
(6) Editoren vi/vim, Emacs und nano
(7) "Pimp my Terminal"

Teil 3
(7) "Pimp my Terminal" (Fortsetzung)
(8) User / Admin / Superuser

Teil 4
(8) User / Admin / Superuser (Fortsetzung)
(9) Wie komme ich zu UNIX-Programmen?

Teil 5
(9) Wie komme ich zu UNIX-Programmen? (Fortsetzung)

Teil 6
(10) Einige Unterschiede zwischen Darwin und anderen UNICES
(11) Weitere Informationen / Referenzen / Links
Dank

------

(8) User / Admin / Superuser (Fortsetzung)

(8.2) su - die Umkleidekabine der Boutique
su (substitute user identity; nicht etwa superuser...) erlaubt es uns, den Benutzer zu wechseln. Oftmals wird es benutzt, um eben direkt auf root zu wechseln (su ohne Parameter). Doch dies werden wir nicht tun!

Wir werden dieses Programm jedoch benutzen, um uns von einem normalen Benutzer mit eingeschränkten Rechten in einen Admin zu verwandeln, welcher dann elegant sudo benutzen kann (wie gesagt, es gäbe auch andere Wege, dies zu erreichen)...

Um dies besser nachvollziehen zu können, schauen wir zerst mal zu welchen Benutzergruppen wir so gehören (id), in welchem Verzeichnis wir sind (pwd), unter welchem Namen wir angemeldet sind (whoami) und wer sonst noch angemeldet ist (who). Zu Übungszwecken führen wir den Wechsel durch, während wir im Benutzerverzeichnis ~ sind:
$ cd ~
$ id
$ pwd
$ whoami
$ who


Wir benutzen su in einer speziellen Art, um auf den Admin zu wechseln
$ su -l beispielAdminName
Das Passwort dieses beispielAdminName wird verlangt. Beachte jeweils Gross- und Kleinschreibung.​

Erklärung: Tausche beispielAdminName mit dem bei Dir üblichen Admin-Kurznamen aus. Wir benutzen die Option -l (kleines L), um einen vollständigen Login-Vorgang zu simulieren. Wir machen dies, so dass auch die Umgebungsvariablen neu angelegt werden (wir wollen ja nicht allfällig korrupte Pfad-Angaben mit in den Admin-Bereich nehmen, nicht wahr?).

Wir sehen, dass sich der Prompt nun geändert hat. Links des $-Zeichens ersheint ein anderer Benutzername (nämlich unser Admin-Kurzname). Wir sehen dies auch deutlich mit
$ whoami

Wir sehen die Zugehörigkeit zu neuen Benutzergruppen (unter anderem admin) mit
$ id

Es ist wichtig zu erkennen, dass damit die ganzen Umgebungsvariablen der Shell neu eingerichtet wurden. so gelten unsere vorgängig für den Benutzer sorgfältig konfiguigurierten Einstellungen
~/.bash_profile
~/.bash_rc
~/.inputrc
hier nicht mehr. Dies ist auch logisch. Die Einstellungen sind im Benutzerverzeichnis ~gespeichert. Wir haben nun zwar wieder ein Benutzerverzeichnis, jedoch ist es jedes des Admin-Benutzers...

Dies sehen wir rasch mittels
$ pwd

Das Benutzerverzeichnis ~hat gewechselt.

So schlage ich vor, dass wir uns deshalb die obgenannten Konfigurationsdateien schnell von unserem anderen Verzeichnis kopieren. Wir können dies tun, da diese ja zum lesen für alle Benutzer freigegeben sind. Umgekehrt können wir Daten aus dem aktuellen Benutzerverzeichnis nicht so ohne weiteres ins Benutzerverzeichnes des anderen Accounts kopieren, da uns dazu das Schreibrecht fehlt (daneben müssten auch noch die Eigentumsrechte angepasst werden). Für diese Übung müssen wir wissen, dass
~ auf das Benutzerverzeichnes des aktiven Benutzers, und
~name auf das Benutzerverzeichnis des Benutzers name zeigt.

In folgendem Beispiel bitte also name mit dem Benutzername des vorher benutzten normalen User-Accounts austauschen:

$ cp –i ~name/.bash_profile ~name/.bashrc \
> ~name/.inputrc ~


Erklärung:
(1) Für diese längere Befehlszeile benutzen wir eine weitere Möglichkeit der Shell. Wir benutzen einen Backslash (\) am Ende der ersten Zeile und drücken den Zeilenvorschub. Eine zweite Zeile mit dem neuen Prompt > gibt uns genügend Platz zum weiterschreiben.
(2) Wir benutzen cp um gleich mehrere Dateien aus dem anderen Benutzerverzeichnis (~name) ins eigene (~) zu kopieren. Die Option –i warnt uns vor allfälligem Überschreiben bestehender Dateien.

Schauen wir uns die kopierten Dateien an:
$ ls –law

Alles da, sogar der Eigentümer wurde angepasst. Doch leider sind diese Konfigurationen noch nicht aktiv. Diese Dateien werden erst gelesen, wenn die Shell neu gestartet wird. Also:

$ exit

Wir sehen: Zurück kann man immer ohne Passwort. Wir sind wieder zurück in unserer ursprünglichen Shell mit dem normalen Benutzer. Dann wechseln wir nochmals in den anderen Account.

$ su –l beispielAdminName

Wieder erfolgt eine Passworteingabe. Jetzt sollten auch unsere lieb gewonnenen Anpassungen da sein (zB. alias-Definitionen). Wir erkennen übrigens: Es ist wichtig, dass uns der Prompt angibt, unter welchem Benutzernamen wir angemeldet sind. Erst so erkennen wir, welche Rechte uns zustehen. Selbstverständlich kann der Prompt in unserer Konfigurationsdatei .bash_profile auch modifiziert werden, so dass admin-Accounts noch besser auffallen (zB. spezielle Farbe -> siehe Kapitel 7.3.1 in Teil 2).


(8.3) Werde ein Superuser!
Wir haben uns nun also sicher in einen Admin "umgezogen" (wir sind sozusagen Clark Kent geworden, jedoch noch nicht Superman). Nun kommt das geniale Element von sudo zu tragen. Wir können nun Befehle, welche root Rechte benötigen nun problemlos aus diesem Admin account starten, ohne ein root Passwort zu kennen.

Beispiel: Probieren wir mal die folgende Datei zu lesen:
$ less /etc/sudoers

Es kommt die Fehlermeldung /etc/sudoers: Permission denied. Wir haben also keine Rechte, diese Datei anzusehen. Wir können dies auch gut nachvollziehen:
$ ls –law /etc/sudoers

-r--r----- 1 root wheel 629 13 Jan 2006 /etc/sudoers

Die Datei gehört root. Sie kann von root selbst und der Benutzergruppe wheel gelesen werden. Alle anderen können sie nicht lesen. Wir sehen, die Datei ist recht geschützt. Sogar root selbst kann sie in der aktuellen Form nur lesen.

Schauen wir sie uns also trotzdem an. Schliesslich wollen wir ja mal superuser werden :)
$ sudo less /etc/sudoers

Erklärung: Wir benutzen denselben Befehl wie oben bereits. Nur stellen wir den Befehl sudo davor. That's it! sudo verlangt ein Passwort (das aktuelle Passwort unseres Admin-Accounts mit dem wir uns ja mittels su –l angemeldet haben). Erst bei korrektem Passwort führt es den Befehl aus. Dies dann jedoch mit Superuser-Privilegien! Passen wir also auf diese Datei auf. Es ist eine wichtige...

sudo merkt sich übrigens eine korrekte Passworteingabe einige Minuten (selbstverständlich einstellbar...). So können folgende sudo Befehle ausgefüht werden, auch ohne dass das Passwort explizit erneut eingegeben werden muss. Es kann also auch plötzlich schnell gehen :)


Gratulation! Der erste Befehl als root – und dies sogar ohne dass wir uns als root hätten anmelden müssen.

Nebenbei: Wir haben uns soeben die Datei angeschaut, welche die Zugriffsrechte reguliert, welche Benutzer welche Befehle mittels sudo ausführen dürfen. So ist eine differenzierte Vergabe von Rechten an Unter-Administratoren möglich, die beispielsweise nur Teilaspekte des ganzen Systems administrieren sollen.
Auch kann so grundsätzlich einzelnen normalen Benutzeraccounts erlaubt werden, sudo zu benutzen. Davon sehen wir im Moment ab. Dazu empfehle ich erst etwas mehr Erfahrung zu sammeln. Diese doppelte Sicherheit (erst Wechsel in einen Admin-Account) macht es einem besser bewusst, dass man nun etwas potentiell riskantes unternimmt.

Nachdem wir nun unseren ersten Superuser-Job mit Bravour abgeschlossen haben, verlassen wir auch den Admin-Account wieder mittels
$ exit

Wir sind nun wieder in der normalen Shell. Man soll auch nur so kurz wie möglich im Admin-Bereich bleiben. Wir werden dann sudo noch einige male benutzen, wenn wir dann eigentliche UNIX-Programme installieren werden...

Nebenbei: Zur Anpassung dieser Datei sudoers braucht es v.a. auch Erfahrung mit der Benutzung des vim (wir erinnern uns: Der mit den Schweisstropfen). Diese Konfigurationsdatei sollte übrigens auch nicht direkt mittels eines Editors verändert werden. Man soll dies nur mit dem Programm visudo machen (das eben auf vim aufbaut). visudo kontrolliert dabei beispielsweise, dass die Datei nicht von mehreren Administratoren gleichzeitig geöffnet wird (wir erinnern uns: UNIX ist ein Multiuser-System, auch wenn wir alleine am Computer sitzen und so die Wahrscheinlichkeit sehr klein ist, dass sich im Hintergrund ein anderer Admin eingelogt hat). Auch prüft visudo die Syntax der Datei auf Korrektheit vor dem Speichern. Wir wollen ja nicht plötzlich nicht mehr auf root zugreifen können...

Ich empfehle mal:
$ man visudo
$ man vim
(bzw. die früher erwähnte Online-Dokumentation)
$ vimtutor (interaktives Tutorial, mit den aktuellen Konfigurationen wählt es automatisch deutsch als Lernsprache)


(9) Wie komme ich zu UNIX-Programmen?
Einer der ganz grossen Vorteile, ein POSIX kompatibles UNIX zu haben besteht darin, dass man auf eine riesige Bibliothek kostenloser Programme zurückgreifen kann (Freeware / Open Source). Gerade mit dem Erfolg des Linux kommen immer weitere Programme ins Netz, welche dann mit kleinerem oder grösserem adaptivem Aufwand auch auf dem Mac laufen.

Es gibt eine praktische Sammlungen von Programmpaketen (insbesondere Fink und MacPorts), welche vorbereitet sind auf Mac OS X zu laufen. Beide haben Vor- und Nachteile.
Fink ist ein Paralleluniversum und greift in die Apple Installation soweit wie möglich nicht ein. MacPorts integriert sich direkter mit entsprechenden potentiellen Schwierigkeiten, insbesondere wenn etwas nicht funktionieren sollte. Andererseits hat MacPorts den Vorteil, dass diese Pakete oft aktueller sind oder schneller upgedatet werden. Einige Pakete finden sich nur in MacPorts, andere nur in Fink. Es spricht nichts dagegen, auch beide Paketsammlungen parallel auf dem Computer zu verwenden, insofern man ausreichend Platz dafür auf der Platte hat.

(9.1) Fink
Als erstes schauen wir uns Fink an, da es gerade für uns Einsteiger einfacher zu benutzen ist und aufgrund seiner Trennung vom übrigen OS eher eine gewisse Fehlertoleranz aufweist. Das ganze Paketmanagement wurde von Debian GNU/Linux übernommen. Kenner dieses System werden sich also sofort heimisch fühlen.
Einige Pakete werden bereits kompiliert (passend für OS Version und Prozessor) angeboten. Andere werden einfach als Quellcode angeboten, wobei das ganze kompilieren bei erfolgreicher Installation völlig automatisch läuft...

(9.1.1) Fink installieren
Ich empfehle, mal die Dokumentation (englisch) und vor allem die Schritt-für-Schritt-Anleitung (deutsch / englisch kleine Unterschiede) zu lesen bevor Du auch nur irgend etwas installierst. Es sind doch einige Bedienungsschritte notwendig, die korrekt ausgeführt werden müssen. Es ist zwar alles gut erklärt. Doch gibt es immer einige Fehlerquellen.

Tip: Damit die Installation nachher problemlos geht, empfehle ich bereits vorgängig zwei Pakete zu installieren.
  • X11 (für alle UNIX-Programme notwendig, die eine X-GUI haben): Installation von der originalen Mac-DVD und nachfolgend mittels Software-Aktualisierung schauen, ob es nicht eine neue Version gibt. Wichtig: Insbesondere unter Tiger darf nicht die online für ältere OS-Versionen erhältliche Version installiert werden.
  • Entwicklungsumgebung Xcode: Diese kanst Du zwar ebenso von der originalen Installations-DVD installieren. Besser jedoch holst Du Dir diese (genügend schnelles Internet vorausgesetzt) online direkt von Apple Developer Connection (ADC). Du kannst Xcode und auch zahlreiche andere Tools erst nach Registration downloaden. Es gibt jedoch eine kostenlose Registrationsmöglichkeit.

Die eigentliche Installation von Fink funktioniert wirklich ausserordentlich einfach. Am besten wirklich genau analog der Online-Anleitung vorgehen. Hier deshalb nur ein paar Ergänzungen.
  1. Download und Installation des Fink Installers (dabei wird man während der Installation wie gewohnt nach einem Admin-Namen und dessen Passwort gefragt; andererseits hatte ich bei meiner Installation als User eine Fehlermeldung, die dann nicht mehr auftrat, als ich das Paket als Admin lud und installierte [siehe auch hier]. So ist meine Empfehlung im Moment, den Download und die Installation als Admin durchzuführen).
  2. Durch die Installation sollte automatisch ein Script pathsetup.command (siehe deutsche Version) bzw. pathsetup.sh (siehe englische Version) aufgerufen werden (Frage erfolgt, ob OK). Dieses Programm installiert in die Konfigurationsdatei der Shell eine Ergänzung des Suchpfades für Dateien. Um eine Verwechslung mit anderen Programmen / Paketen auszuschliessen, installiert Fink seine sämtlichen Programme in das Verzeichnis /sw (als Shell-Profi-User kannst Du Dir das ja mal mit ls detailliert ansehen gehen :) )
  3. Wichtig: Dieses pathsetup.command bzw. pathsetup.sh muss in Terminal wie auf der Website angegeben auch für jeden anderen Benutzer auf dem Computer ausgeführt werden (jeweils kurz entsprechend in die Shell einloggen). Dazu braucht es keine Admin-Rechte. Damit wird die Datei ~/.profile um die Pfadangaben der Programme in /sw ergänzt, so dass auch fink und die damit installierten Programme einfach ausgeführt werden können.
  4. Shell schliessen --> alles funktioniert erst nach neuem Start der Shell

Für die Installation der Fink-Programme empfiehlt es sich, wenn die Shell (Terminal) vom Admin-Account geöffnet wurde. Alternativ kann natürlich auch der in Kapitel 8 gewählte Wechsel mittels su –l beispielAdminName benutzt werden. Dies ist notwendig, da von sudo Gebrauch gemacht wird.

Fink kann letztlich über ein Programm Fink-Commander oder in der Shell via den apt-get Paket-Manager (gleich wie Debian GNU/Linux) für bereits compilierte Programme bzw. noch komfortabler via das Programm fink (für compilierte Programme und source-codes) bedient werden.

Die einfachste Variante ist die direkte Benutzung von fink im Terminal, das dann (indirekt auf apt-get zurückgreift).

$ man apt-get
$ man fink

(kennen wir ja :) )

Sowohl für die Anwendung von apt-get als auch von fink muss man in der Shell eines Admins sein, da beide von sudo Gebrauch machen. Bei apt-get benutzt man es selbst; fink ruft es von sich aus intern auf.

Ach ja: fink ist letztlich ein Perl-Programm
Wir finden es mittels
$ which fink
--> das zeigt uns den Ort des Programms: /sw/bin/fink

$ less /sw/bin/fink
zeigt uns einen Blick hinein.


(9.1.2) Fink Initialisieren und Upgrade
Wir beschreiben im folgenden nur den Umgang mit fink direkt, der wirklich bereits sehr komfortabel ist. Wie gesagt empfielt sich die Lektüre der man-pages
$ man fink

Die wichtigen Befehle können schnell nochmals konsultiert werden, wenn fink ohne Parameter gestartet wird:
$ fink

Wichtig: Fink soll nur von einem Benutzer mit Admin-Rechten gestartet werden (kurz: der Benutzer muss in der sudoers Liste sein). Also bei Bedarf Benutzer vor den nächsten Befehlen wechseln.

Fink initialisieren
$ fink scanpackages
$ fink index


Fink Upgrade
Wie in der Online-Anleitung angegeben, empfiehlt es sich, fink zuerst auf den neusten Stand zu bringen, bevor andere Programme gesucht werden (Punkt 6 der Online-Anleitung). Bevor wir dies machen, sollten wir sicherstellen, dass wir auf die gewünschte Paketbasis zurückgreifen.

Analog zu Debian GNU/Linux gibt es stable und unstable Pakete. stable Pakete sind gut bekannt, sehr stabil, jedoch recht alt. Auch gibt es weniger Pakete. unstable Pakete sind vielzähliger und neuer, jedoch evtl eher noch Fehlern drin. Eine Version testing (wie in Debian) gibt es nicht.
Im Gegensatz zu Servern, die ausserordentlich stabil gebaut sein sollen, empfiehlt es sich für Desktop-Computer die Anwendung der unstable pakete, da so mehr Features verwendet werden können.

Wir können die Wahl der Paketbasis, sowie zahlreiche andere Einstellungen (Auswahl der Mirrors, von denen die Pakete geholt werden, allfällig notwendige Proxies, Auswahl, ob immer compiliert werden soll oder auch vorkompilierte Pakete gesucht werden sollen...) in folgendem geführten Setup einstellen. Die Voreinstellungen werden immer in eckigen Klammern angezeigt (Grossbuchstabe für gewählte Option). Voreinstellungen können einfach mittels RETURN übernommen werden:
$ fink configure

Wir können diese Konfiguration im Verlauf immer wieder anpassen. Nachdem wir uns festgelegt haben (eben insbesondere, ob stable/unstable) benutzt werden soll, können wir kontrollieren, ob fink selbst aktuell ist.
$ fink selfupdate (fink selbst aktualisieren)
$ fink update-all (alle anderen Fink-Packages ebenso aktualisieren --> Betonung: alle Packages werden mit einem einzigen Befehl aktualisiert!)

Nebenbei: Insbesondere fink selfupdate sollte im Verlauf regelmässig benutzt werden (bietet sich als regelmässiger cron-job an). Gelegentlich sollten auch die anderen Pakete aktualisiert werden. Dies kann dann längere Zeit dauern (insbesondere bei notwendiger Compilation).


Ein Programm installieren wir als Beispiel dann in Teil 5.

Link: Fortsetzung Teil 5
 
Zuletzt bearbeitet von einem Moderator:

Tengu

Apfel der Erkenntnis
Registriert
05.02.07
Beiträge
721
Jetzt ist der Darwin/Unix Teil ja schon part 10 :). Hehe...

say -v Boing Vielen Dank

Da freuen sich zum Wochende hin bestimmt noch nen paar Leute mehr als nur ich ;)