Re: benutzer umbenennen
Markus Wichmann
> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft ja
> ein Unix Kernel. Soll heißen die Frage passt hoffentlich ein wenig in
> diese Group.
Nur ein ganz kleines bisschen. Ich leite mal um.
> Ich habe einen Benutzer angelegt mit namen vornamename und
> kurzbezeichnung name. Nun habe ich aber festgestellt das ich da einen
> Fehler gemacht habe. Der Benutzer (nicht Kurzbezeichnung) soll name
> heißen. Wie mache ich das jetzt am besten. Im Ordner Users befindet sich
> auch der Ordner vornamename. Den einfach umbenennen ne gute Idee???
>
Nein. Ich würde die Datei /etc/passwd editieren. Die Zeilen dort haben
folgendes Format:
logname:Passwort-Hash:UID:GID:irgendwelche Infos:homedir:shell
Wenn als Passwort-Hash ein x da steht, dann ist shadow installiert und
die Passworte stehen in /etc/shadow. Verschlüsselt und gehasht. Aber
um die geht es ja nicht. logname ist der Name, den der Nutzer am
Prompt eingeben muss, damit er sich einloggen kann. Einfach diesen
Eintrag wie gewünscht ändern, dann sollte es gehen. Je nach
Display-Manager muss der auch noch neu gestartet werden, aber
prinzipiell sollte es jetzt gehen.
> Vielen Dank
HTH,
Markus
--
Progress (n.): process through which USENET evolved from smart people in front
of dumb terminals to dumb people in front of smart terminals.
Juergen P. Meier
> Bernd.Ludwig <B.Lu...@gmx.de> schrieb:
>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft ja
>> ein Unix Kernel. Soll heißen die Frage passt hoffentlich ein wenig in
>> diese Group.
Einen Unix Kern ja, aber ein darueber liegendes OS, dass die
Unix-Konventionen detulich erweitert.
> Nur ein ganz kleines bisschen. Ich leite mal um.
>
>> Ich habe einen Benutzer angelegt mit namen vornamename und
>> kurzbezeichnung name. Nun habe ich aber festgestellt das ich da einen
>> Fehler gemacht habe. Der Benutzer (nicht Kurzbezeichnung) soll name
>> heißen. Wie mache ich das jetzt am besten. Im Ordner Users befindet sich
>> auch der Ordner vornamename. Den einfach umbenennen ne gute Idee???
>>
>
> Nein. Ich würde die Datei /etc/passwd editieren. Die Zeilen dort haben
> folgendes Format:
>
> logname:Passwort-Hash:UID:GID:irgendwelche Infos:homedir:shell
Dort wird er seinen User nicht finden. Bei Mac OS X ist /etc/passwd
nur aus Legacygruenden vorhanden. Selbst ein 10 Jahre altes Unix egal
welcher Sorte (Linux, SunOS, IRIX etc.) hat laengst nicht mehr nur
plain files. Man muss also mindestens erstmal wissen, welcher
Namensdienst verwendung findet. Bei Mac OS X ist dies bis
einschliesslich Version 10.4 (Tiger) die NetInfo Datenbank, seit 10.5
(Leopard) der Nachfolger. Das Netinfo-Datenaenderungswerkzeug
dient hier zur manuellen Administration. Vorsicht ist geboten.
Useraccounts kann der Administrator bei 10.5 hingegen relativ
umfangreich ueber das normale Account-Admin-GUI aus den Preferences
veraendern. Der Accountname (username/kennung) ist IIRC jedoch nicht
aenderbar, da an diesem mehr als nur das Homedirectory haengen.
(WEnn er es trotzdem machen will, dass Kommandozeilenwerkzeug, dass
diese Aktion moeglich macht, heisst scutil)
Es gibt einen Artikel auf macworld mit genau diesem Thema:
http://www.macworld.com/article/132693/2008/03/changeshortusername.html
Backup vorher anlegen ist wohl selbstverstaendlich.
Wobei ich hier Ausdrueklich nicht TimeMachine meine, das duerfte mit
dieser Aktion durcheinander geraten.
Den Username aendern ist moeglich, aber nicht trivial. Ausser den bei
Apple mitgelieferten Programmen merken sich naemlich noch alle
moeglichen und unmoeglichen Third-Party-Programme in ihren
Einstellungen, Lizenzspeichern etc. den Benutzernamen bzw. den Namen
des Homedirs.
Mit Problemen ist zu rechnen.
Sicherer: Neuen Benutzer mit richtigen Daten anlegen, Dateien
transferrieren, alten Benutzer loeschen.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Rainer Frey
> Bernd.Ludwig <B.Lu...@gmx.de> schrieb:
>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft ja
>> ein Unix Kernel. Soll heißen die Frage passt hoffentlich ein wenig in
>> diese Group.
Genau genommen, ist es nicht ein Unix-*Kernel*, sondern ein Unix-*Userland*.
> Nur ein ganz kleines bisschen. Ich leite mal um.
Leider auch knapp vorbei. S.u.
>> Ich habe einen Benutzer angelegt mit namen vornamename und
>> kurzbezeichnung name. Nun habe ich aber festgestellt das ich da einen
>> Fehler gemacht habe. Der Benutzer (nicht Kurzbezeichnung) soll name
>> heißen. Wie mache ich das jetzt am besten. Im Ordner Users befindet sich
>> auch der Ordner vornamename. Den einfach umbenennen ne gute Idee???
>>
>
> Nein. Ich würde die Datei /etc/passwd editieren. Die Zeilen dort haben
> folgendes Format:
>
> logname:Passwort-Hash:UID:GID:irgendwelche Infos:homedir:shell
>
> Wenn als Passwort-Hash ein x da steht, dann ist shadow installiert und
> die Passworte stehen in /etc/shadow. Verschlüsselt und gehasht. Aber
> um die geht es ja nicht. logname ist der Name, den der Nutzer am
> Prompt eingeben muss, damit er sich einloggen kann. Einfach diesen
> Eintrag wie gewünscht ändern, dann sollte es gehen. Je nach
> Display-Manager muss der auch noch neu gestartet werden, aber
> prinzipiell sollte es jetzt gehen.
So funktionieren zwar viele, aber eben nicht alle Unix-ähnlichen Systeme.
Mac OS X nämlich gerade nicht. Die über die normalen Bordmittel angelegten
User werden nämlich im DirectoryService verwaltet, und nicht in der
(durchaus vorhandenen) /etc/passwd. Ich leite deshalb mal nach
de.comp.sys.mac.misc um.
An den OP:
Du kannst den User mit dem Kommandozeilen-Tool dscl ändern, oder auch mit
den Fortgeschrittenen Eigenschaften in der grafischen Benutzerverwaltung.
Wie genau weiss ich nicht aus dem Kopf, aber da kann bestimmt einer der
Experten einspringen, bzw. du kannst dort in der Gruppe nachsuchen.
>> Vielen Dank
>
> HTH,
> Markus
Gruß
Rainer
Noses
mitbekommt...
Watakushi no kioku ga tashika naraba, in de.comp.sys.mac.misc Rainer Frey <raine...@web.de> wrote:
>>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft ja
>>> ein Unix Kernel.
> Genau genommen, ist es nicht ein Unix-*Kernel*, sondern ein Unix-*Userland*.
Wenn jetzt gerade mal irgendwer definieren würde, was ein "Unix-Kernel" sein
mag...
Ansonsten ist diese Annahme Blödsinn - im Gegensatz zu vielen Kleinkrautern
und Pinguin-Exkrementen darf sich Mac OS 10.5 (oder besser: Das Darwin
darunter) Unix nennen, es hat die passende Zertifizierung. Dementsprechend
muß der Kernel auch die passenden Dienste liefern.
> So funktionieren zwar viele, aber eben nicht alle Unix-ähnlichen Systeme.
> Mac OS X nämlich gerade nicht. Die über die normalen Bordmittel angelegten
> User werden nämlich im DirectoryService verwaltet,
Und das widerspricht sich? Ich kenne einige Leute, die in der /etc/passwd
tatsächlivh ihre Accounts stehen haben, um nicht durch irgendwelche
Directories, die sich der Mac (er ist ja schließlich ein Mac, da muß sogar
die Server-Verwaltung einfach sein 8-() nicht einfach per LDAP ein
Verzeichnis aufschwatzen läßt, mit dem dann lokale Accounts kompromittiert
werden.
> An den OP:
> Du kannst den User mit dem Kommandozeilen-Tool dscl ändern, oder auch mit
> den Fortgeschrittenen Eigenschaften in der grafischen Benutzerverwaltung.
Und wenn Du seinen "short name" änderst, kannst Du Dich sogar bis zum Hals
im Treibsand eingraben, wenn Du es nicht richtig machst. Wer nich einmal die
tools kennt, um die Änderung herbeizuführen, sollte lieber einen neuen
Account anlegen und die Daten kopieren, das ist für das Usenet bekömmlicher.
Noses.
Rainer Frey
> Followup-To: ignoriert, da sonst das Establishment wieder einmal nichts
> mitbekommt...
Wie du meinst. Für diese Diskussion passt das, der OP wird aber dort
wahrscheinlich zielführendere Hinweise bekommen, denn die Details sind
schon mac-spezifisch.
> Watakushi no kioku ga tashika naraba, in de.comp.sys.mac.misc Rainer Frey
> <raine...@web.de> wrote:
>>>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft
>>>> ja ein Unix Kernel.
>
>> Genau genommen, ist es nicht ein Unix-*Kernel*, sondern ein
>> Unix-*Userland*.
>
> Wenn jetzt gerade mal irgendwer definieren würde, was ein "Unix-Kernel"
> sein mag...
Kernel ist der Kern des Betriebssystems, der I/O, Prozess- u.
Speicherverwaltung, Scheduling ... macht. Der ist eben nicht, wie viele
andere Systembestandteile, von einem Unix übernommen, sondern ist eine
Weiterentwicklung des Mach-Microkernels.
> Ansonsten ist diese Annahme Blödsinn - im Gegensatz zu vielen
> Kleinkrautern und Pinguin-Exkrementen darf sich Mac OS 10.5 (oder besser:
> Das Darwin darunter) Unix nennen, es hat die passende Zertifizierung.
> Dementsprechend muß der Kernel auch die passenden Dienste liefern.
Leider kenn ich weder die Standards noch die Zertifizierungen im Detail. Ich
gehe aber davon aus, dass die Kernel-Schnittstellen (verm. in Form von
system calls) beschreiben, nicht aber die Implementierung des Kernels.
Du hast natürlich insofern recht: OS X ist ein Unix, also kann man den
Kernel als Unix-Kernel bezeichnen.
Der OS X Kernel hat aber weder von der Historie noch vom Konzept viel mit
den Kerneln anderer Unix-Systemen zu tun (die meistens monolithisch, oder
modular (also prinzipiell auch monolithisch, aber mit dynamisch ladbaren
Modulen) aufgebaut sind. Darauf hab ich mich bezogen. Das war aber auch
eigentlich mehr als Randbemerkung gemeint.
>> So funktionieren zwar viele, aber eben nicht alle Unix-ähnlichen Systeme.
>> Mac OS X nämlich gerade nicht. Die über die normalen Bordmittel
>> angelegten User werden nämlich im DirectoryService verwaltet,
>
> Und das widerspricht sich? Ich kenne einige Leute, die in der /etc/passwd
> tatsächlivh ihre Accounts stehen haben, um nicht durch irgendwelche
> Directories, die sich der Mac (er ist ja schließlich ein Mac, da muß sogar
> die Server-Verwaltung einfach sein 8-() nicht einfach per LDAP ein
> Verzeichnis aufschwatzen läßt, mit dem dann lokale Accounts kompromittiert
> werden.
Ich weiss, dass das geht. Dem OP ging es aber darum, einen bereits
angelegten User zu ändern, und den wird er eben nicht in der /etc/passwd
finden (zumindest wenn er ihn, wie von mir unterstellt, über die GUI
angelegt hat). Wenn du mir jetzt sagst, dass man einen Useraccount in
mehreren der möglichen Quellen anlegen kann, dabei die lokalen
Legacy-Dateien die hörere Priorität haben als das lokale Directory bei der
Nicht-Server-Variante, und das alles funktioniert, werde ich alles
zurücknehmen und das Gegenteil behaupten :-)
>> An den OP:
>> Du kannst den User mit dem Kommandozeilen-Tool dscl ändern, oder auch mit
>> den Fortgeschrittenen Eigenschaften in der grafischen Benutzerverwaltung.
>
> Und wenn Du seinen "short name" änderst, kannst Du Dich sogar bis zum Hals
> im Treibsand eingraben, wenn Du es nicht richtig machst. Wer nich einmal
> die tools kennt, um die Änderung herbeizuführen, sollte lieber einen neuen
> Account anlegen und die Daten kopieren, das ist für das Usenet
> bekömmlicher.
Das ist allerdings ein echt guter Hinweis, an den ich nicht gedacht hab.
Deshalb hab ich ja auf die Experten in der Mac-Gruppe hingewiesen :-)
> Noses.
Gruß
Rainer
Rainer Frey
> Followup-To: ignoriert, da sonst das Establishment wieder einmal nichts
> mitbekommt...
Wie du meinst. Für diese Diskussion passt das, der OP wird aber dort
wahrscheinlich zielführendere Hinweise bekommen, denn die Details sind
schon mac-spezifisch.
> Watakushi no kioku ga tashika naraba, in de.comp.sys.mac.misc Rainer Frey
> <raine...@web.de> wrote:
>>>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft
>>>> ja ein Unix Kernel.
>
>> Genau genommen, ist es nicht ein Unix-*Kernel*, sondern ein
>> Unix-*Userland*.
>
> Wenn jetzt gerade mal irgendwer definieren würde, was ein "Unix-Kernel"
> sein mag...
Kernel ist der Kern des Betriebssystems, der I/O, Prozess- u.
Speicherverwaltung, Scheduling ... macht. Der ist eben nicht, wie viele
andere Systembestandteile, von einem Unix übernommen, sondern ist eine
Weiterentwicklung des Mach-Microkernels.
> Ansonsten ist diese Annahme Blödsinn - im Gegensatz zu vielen
> Kleinkrautern und Pinguin-Exkrementen darf sich Mac OS 10.5 (oder besser:
> Das Darwin darunter) Unix nennen, es hat die passende Zertifizierung.
> Dementsprechend muß der Kernel auch die passenden Dienste liefern.
Leider kenn ich weder die Standards noch die Zertifizierungen im Detail. Ich
gehe aber davon aus, dass die Kernel-Schnittstellen (verm. in Form von
system calls) beschreiben, nicht aber die Implementierung des Kernels.
Du hast natürlich insofern recht: OS X ist ein Unix, also kann man den
Kernel als Unix-Kernel bezeichnen.
Der OS X Kernel hat aber weder von der Historie noch vom Konzept viel mit
den Kerneln anderer Unix-Systemen zu tun (die meistens monolithisch, oder
modular (also prinzipiell auch monolithisch, aber mit dynamisch ladbaren
Modulen) aufgebaut sind. Darauf hab ich mich bezogen. Das war aber auch
eigentlich mehr als Randbemerkung gemeint.
>> So funktionieren zwar viele, aber eben nicht alle Unix-ähnlichen Systeme.
>> Mac OS X nämlich gerade nicht. Die über die normalen Bordmittel
>> angelegten User werden nämlich im DirectoryService verwaltet,
>
> Und das widerspricht sich? Ich kenne einige Leute, die in der /etc/passwd
> tatsächlivh ihre Accounts stehen haben, um nicht durch irgendwelche
> Directories, die sich der Mac (er ist ja schließlich ein Mac, da muß sogar
> die Server-Verwaltung einfach sein 8-() nicht einfach per LDAP ein
> Verzeichnis aufschwatzen läßt, mit dem dann lokale Accounts kompromittiert
> werden.
Ich weiss, dass das geht. Dem OP ging es aber darum, einen bereits
angelegten User zu ändern, und den wird er eben nicht in der /etc/passwd
finden (zumindest wenn er ihn, wie von mir unterstellt, über die GUI
angelegt hat). Wenn du mir jetzt sagst, dass man einen Useraccount in
mehreren der möglichen Quellen anlegen kann, dabei die lokalen
Legacy-Dateien die hörere Priorität haben als das lokale Directory bei der
Nicht-Server-Variante, und das alles funktioniert, werde ich alles
zurücknehmen und das Gegenteil behaupten :-)
>> An den OP:
>> Du kannst den User mit dem Kommandozeilen-Tool dscl ändern, oder auch mit
>> den Fortgeschrittenen Eigenschaften in der grafischen Benutzerverwaltung.
>
> Und wenn Du seinen "short name" änderst, kannst Du Dich sogar bis zum Hals
> im Treibsand eingraben, wenn Du es nicht richtig machst. Wer nich einmal
> die tools kennt, um die Änderung herbeizuführen, sollte lieber einen neuen
> Account anlegen und die Daten kopieren, das ist für das Usenet
> bekömmlicher.
Das ist allerdings ein echt guter Hinweis, an den ich nicht gedacht hab.
Bernd.Ludwig
>
> Wenn als Passwort-Hash ein x da steht, dann ist shadow installiert und
> die Passworte stehen in /etc/shadow. Verschlüsselt und gehasht. Aber
> um die geht es ja nicht. logname ist der Name, den der Nutzer am
> Prompt eingeben muss, damit er sich einloggen kann. Einfach diesen
> Eintrag wie gewünscht ändern, dann sollte es gehen. Je nach
> Display-Manager muss der auch noch neu gestartet werden, aber
> prinzipiell sollte es jetzt gehen.
>
>> Vielen Dank
>
> HTH,
> Markus
Danke erst mal für die Hilfe. Habe in etc zwar passwd und master.passwd
gefunden aber in beiden sehe ich nur die Systemuser und root. Mein Name
taucht da nicht auf. Noch ne Idee. Irgendwas steht am Anfang der Datei
von Singleusermode.
Noses
> Leider kenn ich weder die Standards noch die Zertifizierungen im Detail. Ich
> gehe aber davon aus, dass die Kernel-Schnittstellen (verm. in Form von
> system calls) beschreiben, nicht aber die Implementierung des Kernels.
Eben.
> Du hast natürlich insofern recht: OS X ist ein Unix, also kann man den
> Kernel als Unix-Kernel bezeichnen.
Darum ging es mir.
> Der OS X Kernel hat aber weder von der Historie noch vom Konzept viel mit
> den Kerneln anderer Unix-Systemen zu tun (die meistens monolithisch, oder
> modular (also prinzipiell auch monolithisch, aber mit dynamisch ladbaren
> Modulen) aufgebaut sind.
Das trifft auf den Darwin-Kernel auch zu. Irgendwo war mal ein Mach in der
Ahnenreihe, aber... Merkt man Dir noch irgendwo die Urmenschen unter Deinen
Vorfahren an? Ich fände ja einen Microkernel mit einem BSD-Server auch viel
schicker. Aber das ist wie mit den SysV-STREAMS: Nettes Konzept, kostete
aber soviel CPU, daß sich keiner die Mühe machen wollte, das jemals so
richtig in die Tat umzusetzen. Stattdessen fährt man in de Sackgasse, muß
irgendwelche obskuren Schnittstellen beibehalten und zimmert irgendwie ein
paar Rigips-Platten davor (das message passing-Zeugs ist wirklich noch da),
an denen man dann funktionierende Komponenten (große Teile eines
FreeBSD-Kernels) aufhängen kann. Und wehe, jemand bohrt einen Dübel durch
die Platte, dann fällt einem der ganze Dreck vor die Füße.
Noses.
Thomas Benziger
> Bernd.Ludwig <B.Lu...@gmx.de> schrieb:
>> hallo alle zusammen. habe mir grad nen macbook geleistet und da läüft ja
>> ein Unix Kernel. Soll heißen die Frage passt hoffentlich ein wenig in
>> diese Group.
>
> Nur ein ganz kleines bisschen. Ich leite mal um.
>
>> Ich habe einen Benutzer angelegt mit namen vornamename und
>> kurzbezeichnung name. Nun habe ich aber festgestellt das ich da einen
>> Fehler gemacht habe. Der Benutzer (nicht Kurzbezeichnung) soll name
>> heißen. Wie mache ich das jetzt am besten. Im Ordner Users befindet sich
>> auch der Ordner vornamename. Den einfach umbenennen ne gute Idee???
>>
>
> Nein. Ich würde die Datei /etc/passwd editieren.
Genau das würde ich eigentlich nicht machen.
Warum legst Du nicht einen neuen Benutzer mit dem richtigen Namen an,
verschiebst die Dateien in das neue home-Verzeichnis und "chown"-st sie
alle?
Danach den "falschen" Benutzer löschen, das müsste es gewesen sein.
Gruß
Thomas
Noses
> Einen Unix Kern ja, aber ein darueber liegendes OS, dass die
> Unix-Konventionen detulich erweitert.
Unix ist keine Konvention, sondern ein geschütztes Markenzeichen. Und Darwin
wird seit Version 9.2 zertifiziert.
> Dort wird er seinen User nicht finden. Bei Mac OS X ist /etc/passwd
> nur aus Legacygruenden vorhanden.
Das stimmt nicht. Du kanst ja mal der Eintragung für "console" in etc/ttys
/das "secure" wegnehmen und auf root in /etc/passwd ein password
legen.
> Mit Problemen ist zu rechnen.
*gröhl* Ich nehme an, Du nennst es auch nur Problem, wenn ein ICE mit 250
km/h in Dein Wohnzimmer rast. Norddeutsches Understatement?
Noses.
Juergen P. Meier
> ??????????, Juergen P. Meier <nospa...@jors.net> wrote:
>> Einen Unix Kern ja, aber ein darueber liegendes OS, dass die
>> Unix-Konventionen detulich erweitert.
>
> Unix ist keine Konvention, sondern ein geschütztes Markenzeichen. Und Darwin
> wird seit Version 9.2 zertifiziert.
Die Single UNIX Specification ist (mehr als) eine Konvention.
>> Dort wird er seinen User nicht finden. Bei Mac OS X ist /etc/passwd
>> nur aus Legacygruenden vorhanden.
>
> Das stimmt nicht. Du kanst ja mal der Eintragung für "console" in etc/ttys
> /das "secure" wegnehmen und auf root in /etc/passwd ein password
> legen.
Was kein Widerspruch ist, denn das ist eine legacy.
>> Mit Problemen ist zu rechnen.
>
> *gröhl* Ich nehme an, Du nennst es auch nur Problem, wenn ein ICE mit 250
> km/h in Dein Wohnzimmer rast.
Das wuerde ich nicht als "Problem" sondern eher als "extrem
ungewoehnlich" bezeichnen. Selbst wenn der ICE auf der naechstgelgenen
Bahnstrecke bei Vmax entgleist, duerfte es physikalisch ausgeschlossen
sein, dass es Teile des Zuges es bis in mein Wohnzimmer schaffen.
> Norddeutsches Understatement?
Falsche Himmelsrichtung.
Noses
>>> Einen Unix Kern ja, aber ein darueber liegendes OS, dass die
>>> Unix-Konventionen detulich erweitert.
>> Unix ist keine Konvention, sondern ein geschütztes Markenzeichen. Und Darwin
>> wird seit Version 9.2 zertifiziert.
> Die Single UNIX Specification ist (mehr als) eine Konvention.
Eben. Und wer sie nicht einhält, darf sein Werk nicht Unix nennen. Das
schränkt Entwickler übrigens massiv ein, was die Erweiterungen angeht.
Ich lache mir immer wieder einen Ast ab, wenn ich irgendwelche switches
finde, deren Erklärung in der man page dann "forces parameter evaluation by
Unix standards" lautet.
>>> Dort wird er seinen User nicht finden. Bei Mac OS X ist /etc/passwd
>>> nur aus Legacygruenden vorhanden.
>>
>> Das stimmt nicht. Du kanst ja mal der Eintragung für "console" in
>> /etc/ttys das "secure" wegnehmen und auf root in /etc/passwd ein password
>> legen.
> Was kein Widerspruch ist, denn das ist eine legacy.
Ah. Wieder eine neue Definition dafür gelernt. Ich hielt das bis jetzt für
Standard-Konformität.
>> Ich nehme an, Du nennst es auch nur Problem, wenn ein ICE mit 250 km/h in
>> Dein Wohnzimmer rast.
> Das wuerde ich nicht als "Problem" sondern eher als "extrem ungewoehnlich"
> bezeichnen.
Ach so. 8-) Ein paar km gleisaufwärts (bei Brühl) hatte die Bahn jedenfalls
vor ein paar Jahren einen Schnellzug in Haus und Garten geparkt. Die
Bewohner betrachteten das als problematich (so wie in "nachdem die Log dann
in unserem Eßzimmer stand, hatten wir Probleme, wieder einzuschlafen, weil
der Lokführer beim Aussteigen so einen Krach machen mußte").
Noses.
Rainer Frey
> Das trifft auf den Darwin-Kernel auch zu. Irgendwo war mal ein Mach in der
> Ahnenreihe, aber... Merkt man Dir noch irgendwo die Urmenschen unter
> Deinen Vorfahren an? Ich fände ja einen Microkernel mit einem BSD-Server
> auch viel schicker. Aber das ist wie mit den SysV-STREAMS: Nettes Konzept,
> kostete aber soviel CPU, daß sich keiner die Mühe machen wollte, das
> jemals so richtig in die Tat umzusetzen. Stattdessen fährt man in de
> Sackgasse, muß irgendwelche obskuren Schnittstellen beibehalten und
> zimmert irgendwie ein paar Rigips-Platten davor (das message passing-Zeugs
> ist wirklich noch da), an denen man dann funktionierende Komponenten
> (große Teile eines FreeBSD-Kernels) aufhängen kann. Und wehe, jemand bohrt
> einen Dübel durch die Platte, dann fällt einem der ganze Dreck vor die
> Füße.
Jetzt wird mir langsam klar, was du sagen willst. Da hab ich die Entwicklung
nicht mitbekommen, und war der Meinung, das ist nach wie vor ein
(abgewandelter - siehe IOKit) Mach-Kernel mit BSD-Server. Das inzwischen
viel vom BSD-*Kernel* übernommen wurde, wusste ich schlichtweg nicht. Gibt
es dazu irgendwo 'ne übersichtliche Dokumentation?
> Noses.
Rainer
Rainer Weikusat
> Noses wrote:
>> Das trifft auf den Darwin-Kernel auch zu. Irgendwo war mal ein Mach in der
>> Ahnenreihe, aber... Merkt man Dir noch irgendwo die Urmenschen unter
>> Deinen Vorfahren an? Ich fände ja einen Microkernel mit einem BSD-Server
>> auch viel schicker. Aber das ist wie mit den SysV-STREAMS: Nettes Konzept,
>> kostete aber soviel CPU, daß sich keiner die Mühe machen wollte, das
>> jemals so richtig in die Tat umzusetzen. Stattdessen fährt man in de
>> Sackgasse, muß irgendwelche obskuren Schnittstellen beibehalten und
>> zimmert irgendwie ein paar Rigips-Platten davor (das message passing-Zeugs
>> ist wirklich noch da), an denen man dann funktionierende Komponenten
>> (große Teile eines FreeBSD-Kernels) aufhängen kann. Und wehe, jemand bohrt
>> einen Dübel durch die Platte, dann fällt einem der ganze Dreck vor die
>> Füße.
>
> Jetzt wird mir langsam klar, was du sagen willst. Da hab ich die Entwicklung
> nicht mitbekommen, und war der Meinung, das ist nach wie vor ein
> (abgewandelter - siehe IOKit) Mach-Kernel mit BSD-Server.
Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
lediglich einen Addressraum.
> Das inzwischen viel vom BSD-*Kernel* übernommen wurde, wusste ich
> schlichtweg nicht.
Aehh ... das ist doch eigentlich der Witz bei allen diesen
BSD-basierten 'Pseudo-Microkernel-Systemen': Es laeuft ein ganz
normaler UNIX(*)-kern, weil man ja sonst soviel Code schreiben
muesste, und damit hat man natuerlich jeden theoretischen Vorteil des
Microkernels direkt aus dem Fenster geworfen: Der normale Kern ist
immer noch genauso monolitisch, wie er das vorher schon war, kommt es
innerhalb diesem zu einer gravierenden Software-Fehlfunktion hat das
aehnlich drastische Konsequenzen fuer 'den ganzen Rest', wie sonst
auch, und weil alle Teile dieses monolithischen Kerns in jedem Fall
immer noch in einem gemeinsamen Addressraum laufen, aendert sich auch
bezueglich 'Robustheit gegenueber Fehlern in logisch unabhaengigen
Komponenten' genau nichts. Das passende Stichwort waere 'Mogelpackung'.
> Gibt es dazu irgendwo 'ne übersichtliche Dokumentation?
Apple veroeffentlicht unter anderem einen 'Kernel Programming Guide',
dem man diesbezueglich jedenfalls mehr entnehmen kann, als wahllosen
Postings von Internet-Pseudonymen, die (mittlerweile etwas
angestaubte) kontroverse Themen stark einseitig, sachlich bestenfalls
oberflaechlich, oft aber auch nur falsch, und mit gewollt
provozierndem Sprachgebrauch darstellen.
Noses
> Jetzt wird mir langsam klar, was du sagen willst. Da hab ich die Entwicklung
> nicht mitbekommen, und war der Meinung, das ist nach wie vor ein
> (abgewandelter - siehe IOKit) Mach-Kernel mit BSD-Server.
Weniger und weniger. Erst zog man sich Jordan (und seinen Schatten) an Land,
dann bekam man plötzlich Leute wie Terry Lambert und seine Freunde (hat der
eigentlich welche?). Irgendwann fängt dann der Schwanz von alleine an, mit
dem Hund zu wedeln.
> Das inzwischen viel vom BSD-*Kernel* übernommen wurde, wusste ich
> schlichtweg nicht. Gibt es dazu irgendwo 'ne übersichtliche Dokumentation?
Die xnu-Quellen. 8-) Aber alleine ein Vergleich der aktuellen
FreeBSD-7-Merkmale mit dem, was Darwin 9.2 mitbringt zeigt, wie tief das
ganze mittlerweile geht. Klar, ganz unten fliegen immer noch Messages durch
die Gegend, aber das ist der einzige wahrnehmbare Überrest des
ursprünglichen Mach-Kernels. So ein Mach ist ja irgendwie ziemlich
beschränktes Ding ohne seine Server und anstatt ihn zu erweitern, sind alle
Zusatzfunktionen an den BSD-Server geschraubt worden. Ach ja - Mach
injection gibt es immer noch.
Meine Lieblings-Doku ist immer noch das Buch von Amit Singh...
Noses.
Rainer Frey
>> Das inzwischen viel vom BSD-*Kernel* übernommen wurde, wusste ich
>> schlichtweg nicht. Gibt es dazu irgendwo 'ne übersichtliche
>> Dokumentation?
>
> Die xnu-Quellen. 8-)
Ich redete von übersichtlich ;-)
> Meine Lieblings-Doku ist immer noch das Buch von Amit Singh...
Kannst du abschätzen, wie weit das noch stimmt (ist ja 2 Jahre alt)?
> Noses.
Rainer
Rainer Frey
> Rainer Frey <raine...@web.de> writes:
>> Jetzt wird mir langsam klar, was du sagen willst. Da hab ich die
>> Entwicklung nicht mitbekommen, und war der Meinung, das ist nach wie vor
>> ein (abgewandelter - siehe IOKit) Mach-Kernel mit BSD-Server.
>
> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
> lediglich einen Addressraum.
Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
>> Das inzwischen viel vom BSD-*Kernel* übernommen wurde, wusste ich
>> schlichtweg nicht.
>
> Aehh ... das ist doch eigentlich der Witz bei allen diesen
> BSD-basierten 'Pseudo-Microkernel-Systemen':
Gibt es ausser den OS-X-Varianten/Vorfahren/Basissystemen (Rhapsody,Darwin)
noch andere?
> Es laeuft ein ganz normaler UNIX(*)-kern,
Genau das war mir nicht klar. Zugegebenermassen habe ich micht noch nicht
viel damit beschäftigt. Aber ich hatte angenommen, dass der BSD-Server nur
ein BSD-Kernel-*Interface* bietet, und die eigentliche Kernfunktionalität
wie Speicherverwaltung, Scheduling und Treiber-Interface eigenständige
Mach-Services sind, auf die der BSD-Server zugreift.
[...]
>> Gibt es dazu irgendwo 'ne übersichtliche Dokumentation?
>
> Apple veroeffentlicht unter anderem einen 'Kernel Programming Guide',
Danke, hab schon mal kurz reingeschaut. Sieht gut aus, werde ich mal
durchlesen.
Gruß
Rainer
Noses
>>> Entwicklung nicht mitbekommen, und war der Meinung, das ist nach wie vor
>>> ein (abgewandelter - siehe IOKit) Mach-Kernel mit BSD-Server.
>> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
>> lediglich einen Addressraum.
> Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
Nein. Das war der Notnagel, weil Mach zwar ein nettes Konzept, aber ohne die
ganzen Server eher nutzlos war. Der Not gehorchend hat man dann den BSD
single server drangenietet, der alles schon konnte. Man mußte dazu dem
damaligen vmunix nur die untere Hälfet abflexen und den Rest mit ein paar
Handgriffen anfanschen.
> Gibt es ausser den OS-X-Varianten/Vorfahren/Basissystemen (Rhapsody,Darwin)
> noch andere?
Massen. Es war schließlich die offizielle Distribution - alles, was auf Mach
2.5 basiert, ist genau dieses Zeug.
>> Es laeuft ein ganz normaler UNIX(*)-kern,
> Genau das war mir nicht klar.
Es ist kein "ganz normaler" Unix Kernel. Schon alleine, weil es soetwas
nicht gibt. Aber ein typischer BSD-Kernel ist eben nicht nur eine Dame ohne
Unterleib. Nur am Rande: Schau mal in der verfügbaren Literatur (Tanenbaum
und ähnlichen) nach. Notfalls kann ich sie Dir leihen.
> Zugegebenermassen habe ich micht noch nicht viel damit beschäftigt. Aber
> ich hatte angenommen, dass der BSD-Server nur ein BSD-Kernel-*Interface*
> bietet, und die eigentliche Kernfunktionalität wie Speicherverwaltung,
> Scheduling und Treiber-Interface eigenständige Mach-Services sind, auf die
> der BSD-Server zugreift.
Genauso war es ursprünglich auch. Der Microkernel liefer das, was man nicht
delegieren kann und alles andere machen irgendwelche eigenständigen Knechte.
Nur merkt das keine Sau. Es sei denn, zur Zeit Deines Studiums war Mach
gerade in und Deine Uni hatte sowieso eine gute Beziehung zur CMU. Dann
konntest Du Dir an dem Ding die Finger blutig coden. Ich habe heute noch
Narben.
Noses.
Rainer Frey
> 私の記憶が確かならば, Rainer Frey <raine...@web.de> wrote:
>>> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
>>> lediglich einen Addressraum.
>> Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
>
> Nein.
Diese Frage bezog sich nur auf den geteilten Adressraum.
> Das war der Notnagel, weil Mach zwar ein nettes Konzept, aber ohne
> die ganzen Server eher nutzlos war. Der Not gehorchend hat man dann den
> BSD single server drangenietet, der alles schon konnte. Man mußte dazu dem
> damaligen vmunix nur die untere Hälfet abflexen und den Rest mit ein paar
> Handgriffen anfanschen.
Was verstehst du hier unter "untere Hälfte"? Das genau interessiert mich.
> Es ist kein "ganz normaler" Unix Kernel.
Aber es gibt schon eine konventionelle, verbreitete Art, einen Unix-Kernel
aufzubauen. Das war ja wohl gemeint.
> Schon alleine, weil es soetwas
> nicht gibt. Aber ein typischer BSD-Kernel ist eben nicht nur eine Dame
> ohne Unterleib. Nur am Rande: Schau mal in der verfügbaren Literatur
> (Tanenbaum und ähnlichen) nach. Notfalls kann ich sie Dir leihen.
Danke. Aber mit klassischem Unix kenn ich mich ein bisschen aus, und ein
Buch von Tanenbaum hab ich selber.
>> Zugegebenermassen habe ich micht noch nicht viel damit beschäftigt. Aber
>> ich hatte angenommen, dass der BSD-Server nur ein BSD-Kernel-*Interface*
>> bietet, und die eigentliche Kernfunktionalität wie Speicherverwaltung,
>> Scheduling und Treiber-Interface eigenständige Mach-Services sind, auf
>> die der BSD-Server zugreift.
>
> Genauso war es ursprünglich auch. Der Microkernel liefer das, was man
> nicht delegieren kann und alles andere machen irgendwelche eigenständigen
> Knechte.
Und genau da interessiert mich, wie diese "Knechte" bei Mac OS X heute
aussehen. In erster Linie der BSD-Kern, der alles macht, oder eben etliche
verschiedene Knechte, die mit dem Mach Message Passing kommunizieren.
> Nur merkt das keine Sau. Es sei denn, zur Zeit Deines Studiums
> war Mach gerade in und Deine Uni hatte sowieso eine gute Beziehung zur
> CMU. Dann konntest Du Dir an dem Ding die Finger blutig coden. Ich habe
> heute noch Narben.
Im Studium hab ich weder Mach noch C-Programmierung gemacht. Nur ein
bisschen Unix-"Konzepte". Von daher meine uninformierten Fragen.
> Noses.
Rainer
Rainer Weikusat
>> 私の記憶が確かならば, Rainer Frey <raine...@web.de> wrote:
>>>> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
>>>> lediglich einen Addressraum.
>>> Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
>>
>> Nein.
>
> Diese Frage bezog sich nur auf den geteilten Adressraum.
Es gibt/ gab durchaus beides, auch vor Mac OS X.
>> Das war der Notnagel, weil Mach zwar ein nettes Konzept, aber ohne
>> die ganzen Server eher nutzlos war. Der Not gehorchend hat man dann den
>> BSD single server drangenietet, der alles schon konnte.
Es gibt aber gar keine 'Notwendigkeit' schnell ein vollstaendiges
System mit moeglichst geringen Arbeitsaufwand zur Verfuegung stellen
zu koennen. Das war schon eine freiwillige Entscheidung der jeweiligen
System-Entwickler und nicht nur deswegen eine ausgesprochen
unguenstige, weil man durch Hinzufuegen eines monolithischen
UNIX(*)-kernels genau wieder das bekam, was man angeblich nicht haben
wollte, bloss mit einem funktional recht redundanten 'Overhead-Mach'
um seiner selbst Willen 'drangeklebt', sondern auch, weil der damalige
BSD-kernel kein bisschen Multiprozessor-faehig war, wodurch gleich
noch ein weiterer theoretischer Vorteil von Mach wirksam neutralisiert
wurde.
This setup does not change any of the properties of the
monolithic OS and thus means that there still is a single
point of failure. The main advantage of this setup is that is
allows to preserve a UNIX environment while experimenting with
a microkernel approach.
('Towards a true Microkernel Operating System', p. 6)
[...]
>> Es ist kein "ganz normaler" Unix Kernel.
>> Schon alleine, weil es soetwas nicht gibt.
> Aber es gibt schon eine konventionelle, verbreitete Art, einen Unix-Kernel
> aufzubauen. Das war ja wohl gemeint.
Das wird auch Herr Nasen wohl verstanden haben. Allerdings ist 'sich
absichtlich dumm stellen' um ein Gegenueber zu weitschweifigen
Erklaerungen von Selbstverstaendlichkeiten, die mit seiner
urspruenglichen Aussage gar nichts zu tun hatte, zu noetigen, ein
recht wirkungsvolles taktisches Diskussionsmittel.
[...]
>>> Zugegebenermassen habe ich micht noch nicht viel damit beschäftigt. Aber
>>> ich hatte angenommen, dass der BSD-Server nur ein BSD-Kernel-*Interface*
>>> bietet, und die eigentliche Kernfunktionalität wie Speicherverwaltung,
>>> Scheduling und Treiber-Interface eigenständige Mach-Services sind, auf
>>> die der BSD-Server zugreift.
>>
>> Genauso war es ursprünglich auch. Der Microkernel liefer das, was man
>> nicht delegieren kann und alles andere machen irgendwelche eigenständigen
>> Knechte.
>
> Und genau da interessiert mich, wie diese "Knechte" bei Mac OS X heute
> aussehen.
Genau so war gerade urspruenglich eben nicht. Mach-basierende Systeme
sind von Anfang an 'single server operating systems' gewesen, deren
praktischer Nutzen eher in der Moeglichkeit lag, unterschiedliche 'OS
personalities' unterschiedlichen Anwendungen gleichzeitig zur
Verfuegung stellen zu koennen. Das (groesstenteils noch) aktuelle
buzzword dafuer waere 'ein Hypervisor'.
BTW, wenn Dich soetwas interessiert, koenntest Du Dich mal hier
umsehen:
http://www.minix3.org/
(verlinkt auch zu allen moeglichen Ressourcen zu diesem
Thema).
Noses
>>>>> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
>>>>> lediglich einen Addressraum.
>>>> Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
>>> Nein.
>> Diese Frage bezog sich nur auf den geteilten Adressraum.
> Es gibt/ gab durchaus beides, auch vor Mac OS X.
Die ernsthafte Beschäftigung damit war schon fast beendet, als ich mit
meinem Studium fertig war.
Wenn Du das Machwerk namens Hurd meinst... Naja.
> Es gibt aber gar keine 'Notwendigkeit' schnell ein vollstaendiges
> System mit moeglichst geringen Arbeitsaufwand zur Verfuegung stellen
> zu koennen.
Quark. Das ganze war kein reines Forschungswerk der CMU, da sollten
handfeste Alternativen für die DARPA herauskommen.
> Das war schon eine freiwillige Entscheidung
Soweit eine von den Geldquellen gesteuerte Entscheidung "freiwillig" sein
kann.
> This setup does not change any of the properties of the
> monolithic OS and thus means that there still is a single
> point of failure
was den Entwicklungszielen wiedersprach.
>>> Es ist kein "ganz normaler" Unix Kernel.
>>> Schon alleine, weil es soetwas nicht gibt.
>> Aber es gibt schon eine konventionelle, verbreitete Art, einen Unix-Kernel
>> aufzubauen. Das war ja wohl gemeint.
> Das wird auch Herr Nasen wohl verstanden haben.
Genau das bezweifele ich. Ist ein Tandem NonStop Kernel ein "Unix Kernel"?
Wohl kaum. Glaubst Du, Du findest unter einem AIX auf einer zSeries etwas,
das auch nur so ähnlich aussieht? Hast Du Dir mal einen SysV Kernel
angesehen? Und nichts davon ist Darwin mehr als "irgendwie ähnlich". Über
RT-Unix-Varianten brauchen wir wohl gar nicht nachzudenken. Jeder Ansatz hat
andere Entwicklungsziele und sieht verdammt anders aus.
Wer hat jetzt recht. Apple mit seinem am weitesten verbreiteten Unix? Tandem
mit seinem unglaublich stabilen OS? Oder der Schwätzer, der meint, daß
alles, was eine bash trägt, einen gleich aussehenden "Unix Kernel" haben
muß?
> Genau so war gerade urspruenglich eben nicht. Mach-basierende Systeme
> sind von Anfang an 'single server operating systems' gewesen, deren
> praktischer Nutzen eher in der Moeglichkeit lag, unterschiedliche 'OS
> personalities' unterschiedlichen Anwendungen gleichzeitig zur
> Verfuegung stellen zu koennen.
Das ist ziemlicher Blödsinn; das hätte man auch leichter haben können (siehe
Apollo Domain).
> Das (groesstenteils noch) aktuelle buzzword dafuer waere 'ein Hypervisor'.
Auch das hat mit einem Microkernel wenig zu tun.
> BTW, wenn Dich soetwas interessiert, koenntest Du Dich mal hier
> umsehen:
Weia. Nur weil etwas aus wenig Code besteht, ist es doch kein Microkernel.
Noses.
Noses
>>>> Genau das ist es ja auch. Der 'BSD-Server' teilt sich mit Mach
>>>> lediglich einen Addressraum.
>>> Das ist aber schon 'ne Abwandlung zu einem klassischen Mach-Server, oder?
>> Nein.
> Diese Frage bezog sich nur auf den geteilten Adressraum.
Sorry, ich meinte: Das ist etwas ziemlich anderes, keine "Abwandlung".
Genaugenommen ist es ein Verstoß gegen alles, für das Mach stehen sollte.
> Was verstehst du hier unter "untere Hälfte"? Das genau interessiert mich.
"Obere Hälfte" ist das, mit dem das Userland kommuniziert. Die Untere Hälfte
ist das, was sich aus Treibern, Scheduling, Speicherverwaltung und dem ganzen
anderen schmutzigen Kram beschäftigt. Vor langer Zeit war der mal zum
größten Teil in Assembler geschrieben und ziemlich unverständlich.
>> Es ist kein "ganz normaler" Unix Kernel.
> Aber es gibt schon eine konventionelle, verbreitete Art, einen Unix-Kernel
> aufzubauen. Das war ja wohl gemeint.
Aber genau die gibt es nicht.
>> Genauso war es ursprünglich auch. Der Microkernel liefert das, was man
>> nicht delegieren kann und alles andere machen irgendwelche eigenständigen
>> Knechte.
> Und genau da interessiert mich, wie diese "Knechte" bei Mac OS X heute
> aussehen.
Da sind es keine eigenständigen Serverprozesse. Aber dazu könnte ich Dir
jetzt den Singh geben. Allerdings ist eben noch soviel Mach übrig, daß die
Kommunikation mit den ganz primitven Teilen noch immer Message Passing
stattfindet.
> Im Studium hab ich weder Mach noch C-Programmierung gemacht. Nur ein
> bisschen Unix-"Konzepte". Von daher meine uninformierten Fragen.
Mit Büchern kann ich Dich zuwerfen... 8-)
Noses.