Halloechen, weiß jemand von Euch, was man anstellen muß, damit für alle schon existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet? Danke Gruß Peter
On 21 Mar 2001, at 12:54, Peter Bossy wrote:
Halloechen,
weiß jemand von Euch, was man anstellen muß, damit für alle schon existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Tja, /etc/skel gilt nur für neue User. Ansonsten kommst Du wohl nicht drumherum, die Dateien von Hand zu kopieren. Andreas
On Mit, Mär 21, 2001 at 01:06:04 +0100, Andreas Kyek wrote:
On 21 Mar 2001, at 12:54, Peter Bossy wrote:
weiß jemand von Euch, was man anstellen muß, damit für alle schon existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Tja, /etc/skel gilt nur für neue User. Ansonsten kommst Du wohl nicht drumherum, die Dateien von Hand zu kopieren.
Nana, von Hand muss man unter Linux fast gar nix machen ;-) <ungetestet> for ben in `ls /home`; do cd/etc/skel find . -type d -mindepth 1 -print | \ while read dvz; do if test ! -d /home/$ben/$dvz; then mkdir /home/$ben/$dvz && chown ${ben}.users /home/$ben/$dvz fi done find . -type f -print | \ while read datei; do if test ! -f /home/$ben/$datei; then cp $datei /home/$ben && chown ${ben}.users /home/$ben/$datei fi done done </ungetestet> Nur als Anregung, man kann (z. B. durch Auswertung der /etc/passwd und /etc/group) noch einige hier benutzte Konstanten durch Variablen ersetzen und so das Ganze variabler gestalten. VORSICHT: Das *ungetestet* bitte ernst nehmen! Jan
Jan Trippler wrote:
On Mit, Mär 21, 2001 at 01:06:04 +0100, Andreas Kyek wrote:
On 21 Mar 2001, at 12:54, Peter Bossy wrote:
weiß jemand von Euch, was man anstellen muß, damit für alle schon existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Tja, /etc/skel gilt nur für neue User. Ansonsten kommst Du wohl nicht drumherum, die Dateien von Hand zu kopieren.
Nana, von Hand muss man unter Linux fast gar nix machen ;-)
<ungetestet> for ben in `ls /home`; do [...] done </ungetestet>
Nur als Anregung, man kann (z. B. durch Auswertung der /etc/passwd und /etc/group) noch einige hier benutzte Konstanten durch Variablen ersetzen und so das Ganze variabler gestalten.
VORSICHT: Das *ungetestet* bitte ernst nehmen!
Vor allen Dingen sollte man überprüfen, ob die User Änderungen an den betroffenen Dateien durchgeführt haben. Ansonsten könnte es sein, dass es nicht nur technisch massiven Ärger gibt :) In echten Multiuser-Netzen würde ich die Finger von derartigen Massnahmen lassen. Ralf
On Mit, Mär 21, 2001 at 03:29:16 +0100, Ralf Corsepius wrote: [Kopieren aus /etc/skel in die HOME's]
Vor allen Dingen sollte man überprüfen, ob die User Änderungen an den betroffenen Dateien durchgeführt haben.
Ansonsten könnte es sein, dass es nicht nur technisch massiven Ärger gibt :) In echten Multiuser-Netzen würde ich die Finger von derartigen Massnahmen lassen.
Du hast Dir offensichtlich mein Code-Fragment nicht angeschaut! Ich habe exakt aus diesem Grund nur die Dateien + Verzeichnisse aus /etc/skel kopiert, die im Home des Users _nicht vorhanden_ sind. *Änderungen in den betroffenen Dateien* gibt es also nicht, weil keine Dateien überschrieben werden. Sonst hätte ich ja gleich einen cp -a oder cpio -pdmu nehmen können. Für wie naiv hälst Du mich? Jan
Jan Trippler wrote:
On Mit, Mär 21, 2001 at 03:29:16 +0100, Ralf Corsepius wrote: [Kopieren aus /etc/skel in die HOME's]
Vor allen Dingen sollte man überprüfen, ob die User Änderungen an den betroffenen Dateien durchgeführt haben.
Ansonsten könnte es sein, dass es nicht nur technisch massiven Ärger gibt :) In echten Multiuser-Netzen würde ich die Finger von derartigen Massnahmen lassen.
Du hast Dir offensichtlich mein Code-Fragment nicht angeschaut! Ich habe exakt aus diesem Grund nur die Dateien + Verzeichnisse aus /etc/skel kopiert, die im Home des Users _nicht vorhanden_ sind.
Auch das hilft nur bedingt. Das Risiko dabei die Funktion von von Usern eingerichteten und u.U. modifizierten Dateien zu zerstören ist nicht unerheblich. Das Problem sind optionale Dateien, die die Funktion von anderen Programmen verändern: Beispiel: Manche User-Profiles enthalten derartige Konstrukte: if [ -r ~/datei ]; then . ~/datei fi In ~/.xinitrc ist z.B. oft folgendes zu finden: if [ -f ~/.Xresources ]; then xrgb -f ~/.Xresources fi Ein weiteres Beispiel aus ~/.xinitrc von SuSE-7.1 # Start the XIM server: test -r $HOME/.xim && source $HOME/.xim Das /etc/skel/.xim von SuSE-7.1's CDs ist buggy und war in älteren SuSE-Versionen nicht vorhanden :) Da eine SysAdmin die Folgen auf den einzelnen User kaum überblicken kann, halte ich pauschale Push-Updates aus /etc/skel generell für eine sehr schlechte Idee. Pull-Updates hingegen (jeder User kopiert sich das aus /etc/skel von dem er glaubt es zu brauchen) liegen in der Verantwortung der User. Ralf
On Don, Mär 22, 2001 at 01:20:31 +0100, Ralf Corsepius wrote: [...]
Das Risiko dabei die Funktion von von Usern eingerichteten und u.U. modifizierten Dateien zu zerstören ist nicht unerheblich. Das Problem sind optionale Dateien, die die Funktion von anderen Programmen verändern:
OK, _zusätzliche_ oder _neue_ Dateien, die die Funktion von Programmen beeinflussen, sind was anderes. Wie gesagt, existierende Dateien werden mit meiner Variante nie angefasst (wenn sie getestet wurde ;-) - das Risiko für alle (un)modifizierten existierenden Dateien ist NULL. [Beispiele für optionale Dateien]
Da eine SysAdmin die Folgen auf den einzelnen User kaum überblicken kann, halte ich pauschale Push-Updates aus /etc/skel generell für eine sehr schlechte Idee. Pull-Updates hingegen (jeder User kopiert sich das aus /etc/skel von dem er glaubt es zu brauchen) liegen in der Verantwortung der User.
Die Aussage ist mir zu pauschal. Du hast sicher Recht bei Anwendern, die soviel vom System verstehen, dass sie sich das selbst einrichten können (Studenten im Uni-Netz, Entwickler, ...), aber in einer *normalen* Abteilung eines Betriebs herrscht (wenn die DV-Administration funktioniert) eine ziemlich restriktive Politik. Da gibt es nur eine Handvoll Einstellungen, die der User selbst bestimmen kann, der Rest wird vorgegeben! Und das Problem verschiedener Versionen einer SW sollte da auch nicht existieren, sowas ist Wildwuchs (es gibt Ausnahmen)! Da machen Push-Updates sehr viel Sinn, der Anwender will + kann das gar nicht selbst machen. Ein anderer Anwendungsfall für sinnvolle Push-Updates: Die Einführung neuer SW (das sollte sogar für die *wissende* Anwendergruppe gelten). Mit ein paar kleineren Änderungen lässt sich das Script ganz fix auf Teile von /etc/skel einschränken. Voraussetzung ist aber immer der SysAdmin, der weiss was er tut (also testet und die Systeme seiner Anwender kennt). Jan
On Don, 22 Mär 2001, Jan Trippler wrote:
On Don, Mär 22, 2001 at 01:20:31 +0100, Ralf Corsepius wrote: Ein anderer Anwendungsfall für sinnvolle Push-Updates: Die Einführung neuer SW (das sollte sogar für die *wissende* Anwendergruppe gelten). Mit ein paar kleineren Änderungen lässt sich das Script ganz fix auf Teile von /etc/skel einschränken. Voraussetzung ist aber immer der SysAdmin, der weiss was er tut (also testet und die Systeme seiner Anwender kennt).
Ack. In dem Falle wuerde sich dann IMHO eine Installation als ".<whatever>rc.new" oder so anbieten... Und was das Thema mit dem sourcen von config-dateien angeht: IMHO sollten (eh) nur Dateien (als default) gesourced werden, die in skel oder systemweit vorhanden sind -- ob sich $DISTRO an diese Maxime haelt ist ein anderes Thema! Wenn ein User genug weiss, um eine solche Datei zu loeschen (wenn er sie nicht braucht (oder eben doch *eg*)), dann sollte er auch wissen, wie man (a) die sourcende Datei aendert und (b) er ggfs. die gesourcte Datei nicht loescht sondern einfach nur leert (denn dann wuerde sie von Jan's script nicht angefasst). Wenn man die Richtlinie "fehlt $datei aus skel, wird sie erstellt wenn vorhanden, wird $datei.new erstellt, sonst passiert nix" bekannt macht, dann sollten alle die in ihren configs herumwerkeln wissen was Sache ist, ansonsten sind das eh hoffnungslose Faelle, die's nicht besser verdient haben... Sorry, Ralf, aber deine Argumentation halte ich ein wenig arg an den Haaren herbeigezogen -- und wenn dir sowas schon passiert ist, dann hast du mein Mitgefuehl. *snigger* -dnh, ja ich lese (d)asr, wieso? -- Paranoid schizophrenics outnumber their enemies at least two to one. -- from the fortune file
David Haller wrote:
On Don, 22 Mär 2001, Jan Trippler wrote:
On Don, Mär 22, 2001 at 01:20:31 +0100, Ralf Corsepius wrote: Ein anderer Anwendungsfall für sinnvolle Push-Updates: Die Einführung neuer SW (das sollte sogar für die *wissende* Anwendergruppe gelten).
ACK, darum schrieb ich auch "pauschale Push-Updates". Gemeint waren damit Scripte wie die von Euch diskutierten.
Und was das Thema mit dem sourcen von config-dateien angeht:
IMHO sollten (eh) nur Dateien (als default) gesourced werden, die in skel oder systemweit vorhanden sind NACK, Sourcen von optionalen Dateien aus $HOME ist ein gängiges Mittel zur Strukturierung von Scripten, um Usern in einfacher Weise Modifikationen zu erlauben.
-- ob sich $DISTRO an diese Maxime haelt ist ein anderes Thema! Aus gutem Grund tun sie es nicht: Du kannst Usern und Programmen nicht verbieten in ihrem HOME beliebige Modifikationen vorzunehmen.
Ganz im Gegenteil: /etc/skel, der Name deutet es schon an, sind Vorlagen, die User modifizieren dürfen und _keine_ globalen Konfigurationsdateien.
Wenn ein User genug weiss, um eine solche Datei zu loeschen (wenn er sie nicht braucht (oder eben doch *eg*)),
Er braucht gar nichts zu wissen: Viele können mit KDE/GNOME/X11 Frontends bearbeitet werden oder aber werden automatisch angelegt.
Wenn man die Richtlinie "fehlt $datei aus skel, wird sie erstellt wenn vorhanden, wird $datei.new erstellt, sonst passiert nix" bekannt macht, dann sollten alle die in ihren configs herumwerkeln wissen was Sache ist, ansonsten sind das eh hoffnungslose Faelle, die's nicht besser verdient haben... Noch einmal: Die Dateien unter HOME sind dazu da, um von Usern beliebig geändert werden zu können, ob sie wissen was sie tun, ob sie es bewusst und manuell tun, oder ob mit Frontends gearbeitet wird spielt keinen Rolle.
Ralf
Moin, On Don, 22 Mär 2001, Ralf Corsepius sent incredible lines:
David Haller wrote: [...]
IMHO sollten (eh) nur Dateien (als default) gesourced werden, die in skel oder systemweit vorhanden sind NACK, Sourcen von optionalen Dateien aus $HOME ist ein gängiges Mittel zur Strukturierung von Scripten, um Usern in einfacher Weise Modifikationen zu erlauben.
Das halte ich für falsch und würde ich auf meinen Systemen auch nicht so einrichten. In /home können Dateien liegen die zusätzliche Informationen für irgendwelche Programme enthalten, ich habe als Systemadministrator aber keine Garantie das diese dort liegen da jeder User sie löschen kann. D.h., ein gutes System wird nie Dateien aus den Userverzeichnissen Sourcen sondern durch globale Konfigurationen lauffähig sein. Z.B. findet sich in /etc/skel auf Red Hat 7.0 sage und schreibe: <----------------------- begin cut ----------------------> [admin@ds9 admin]$ ll -a /etc/skel/ insgesamt 16 drwxr-xr-x 5 root root 1024 Feb 25 14:56 . drwxr-xr-x 42 root root 4096 Mär 22 11:56 .. -rw-r--r-- 1 root root 24 Aug 22 2000 .bash_logout -rw-r--r-- 1 root root 230 Aug 22 2000 .bash_profile -rw-r--r-- 1 root root 124 Aug 22 2000 .bashrc drwxr-xr-x 4 root root 1024 Mär 20 12:13 .kde drwxr-xr-x 2 root root 2048 Feb 22 12:13 .plan.dir -rw-r--r-- 1 root root 3651 Aug 15 2000 .screenrc drwxr-xr-x 4 root root 1024 Mär 20 12:15 Desktop [admin@ds9 admin]$ <------------------------ end cut -----------------------> Also ohne KDE und plan gerade mal 4 Dateien. Trotzdem ist jedes Programm nutzbar. Sollte das System es erfordern /etc/skel intensiver zu nutzen so halte ich einen Pushmechanismus durchaus für sinnvoll da man so vollautomatisch und ohne Risiko (ein vernünftig konfiguriertes System vorausgesetzt) User Konfigurationsdateien übermitteln kann. Alternativ kann man natürlich auch Webseiten, Email, ... nutzen, finde ich aber nicht so elegant. [...]
Wenn man die Richtlinie "fehlt $datei aus skel, wird sie erstellt wenn vorhanden, wird $datei.new erstellt, sonst passiert nix" bekannt macht, dann sollten alle die in ihren configs herumwerkeln wissen was Sache ist, ansonsten sind das eh hoffnungslose Faelle, die's nicht besser verdient haben... Noch einmal: Die Dateien unter HOME sind dazu da, um von Usern beliebig geändert werden zu können, ob sie wissen was sie tun, ob sie es bewusst und manuell tun, oder ob mit Frontends gearbeitet wird spielt keinen Rolle.
Ja und? Solange keine zentrale Konfigurationsdatei Dateien aus /home voraussetzt und ein Script nur Dateien die nicht vorhanden sind ins /home kopiert und die vorhanden sind erkennt und eine Formatvorlage anbietet, wo ist das Problem. Dann kann der User ändern bis er kringelig wird und wenn er es zu toll getrieben hat rm -rf /home/user und anschliessend mit /etc/skel neu anlegen (natürlich vorher ein Backup machen und ...). Sollte das häufiger Vorkommen kann sich der Mitarbeiter aber auch auf ein sechs Augen Gespräch freuen (SysOp, Chef, ehm. MA). ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...!
Thomas Bendler wrote:
Moin,
On Don, 22 Mär 2001, Ralf Corsepius sent incredible lines:
David Haller wrote: [...]
IMHO sollten (eh) nur Dateien (als default) gesourced werden, die in skel oder systemweit vorhanden sind NACK, Sourcen von optionalen Dateien aus $HOME ist ein gängiges Mittel zur Strukturierung von Scripten, um Usern in einfacher Weise Modifikationen zu erlauben.
Das halte ich für falsch und würde ich auf meinen Systemen auch nicht so einrichten.
Du kannst es nicht verhindern. In realen Systemen sind derartige Scripte teilweise Jahre alt, teilweise kann sich niemand mehr daran erinnern, warum und wieso sie angelegt wurden und haben Generationen von SysOps überlebt, bzw. wurden über Generationen von Usern zu Usern vererbt.
In /home können Dateien liegen die zusätzliche Informationen für irgendwelche Programme enthalten, ich habe als Systemadministrator aber keine Garantie das diese dort liegen da jeder User sie löschen kann. D.h., ein gutes System wird nie Dateien aus den Userverzeichnissen Sourcen sondern durch globale Konfigurationen lauffähig sein.
So etwas kommt vor, wenn * User Software einsetzen, die nicht global zugänglich ist (z.B. nur auf einzelnen Maschinen verfügbar ist/Single-Seat-Lizenzen) oder User (bzw. User-Gruppen) spezielle Konfigurationen einsetzen. * SysOps Push-Updates von Dateien in $HOME durchführen. Spätestens, wenn ein User einmal seine, auf seine speziellen Bedürfnisse angepasste Konfiguration durch nachlässig durchgeführte Push-Updates verloren hat (Soetwas kommt vor), wird er beginnen, seine Anpassungen in eigene Skripte auszulagern und sie zu "sourcen".
Z.B. findet sich in /etc/skel auf Red Hat 7.0 sage und schreibe:
[ls -l /etc/skel von RH-7.0]
Also ohne KDE und plan gerade mal 4 Dateien. Trotzdem ist jedes Programm nutzbar. So sollte es auch sein.
Nur, bei SuSE ist es anders: ls -l /etc/skel | wc -l 41 [Das ist vermutlich auch der Grund, warum diese Diskussion überhaupt entstanden ist.]
Sollte das System es erfordern /etc/skel intensiver zu nutzen so halte ich einen Pushmechanismus durchaus für sinnvoll da man so vollautomatisch und ohne Risiko (ein vernünftig konfiguriertes System vorausgesetzt) User Konfigurationsdateien übermitteln kann. Alternativ kann man natürlich auch Webseiten, Email, ... nutzen, finde ich aber nicht so elegant. Lass es mich so ausdrücken, auf einem vernünfig konfigurierten System sollte es die Notwendigkeit für Push-Updates gar nicht geben.
[...]
Wenn man die Richtlinie "fehlt $datei aus skel, wird sie erstellt wenn vorhanden, wird $datei.new erstellt, sonst passiert nix" bekannt macht, dann sollten alle die in ihren configs herumwerkeln wissen was Sache ist, ansonsten sind das eh hoffnungslose Faelle, die's nicht besser verdient haben... Noch einmal: Die Dateien unter HOME sind dazu da, um von Usern beliebig geändert werden zu können, ob sie wissen was sie tun, ob sie es bewusst und manuell tun, oder ob mit Frontends gearbeitet wird spielt keinen Rolle.
Ja und? Solange keine zentrale Konfigurationsdatei Dateien aus /home voraussetzt <*g*> ... dann gäbe es auch keine Notwendigkeit für Updates.
Der Sysop kann dann globale Konfigurationen in /etc/profile[.local], der System xinitrc u.ä. eintragen. Alternatives Vorgehen: Der SysOp legt Skript-Fragmente an einem globalen Ort an und weisst die User an, falls sie etwas spezielles brauchen, diese zu "sourcen". Recht elegant finde ich auch pull-updates über vom SysOp bereitgestellte Skripte durchzuführen statt brute-force auf /etc/skel zu zugreifen (z.B. ein install-[netscape|mutt]-Skript, das selektiv Änderungen an Dateien in $HOME vornimmt.)
und ein Script nur Dateien die nicht vorhanden sind ins /home kopiert und die vorhanden sind erkennt und eine Formatvorlage anbietet, wo ist das Problem.
Leg .Xmodmap oder .Xresources in /etc/skel und installier sie bei Usern, die sie nicht installiert haben. Wahrscheinlich wirst Du den Effekt sehen, von dem ich spreche. [Vgl. /etc/X11/xinit/xinitrc und /etc/skel unter SuSE]. IMHO, sollte es in sauber konfigurierten Systemen keine Notwendigkeit geben, .Xmodmap oder .Xresources in $HOME zu halten, SuSE tut es aber :). Ähnliches lässt sich vermutlich in anderen Tools finden. Ralf
Hallo, On Don, 22 Mär 2001, Ralf Corsepius wrote:
* SysOps Push-Updates von Dateien in $HOME durchführen.
Falscher Begriff. Es geht hier weniger um ein Update, sondern um eine _Ergaenzung_. Und dass in skel nur Vorlagen liegen ist klar. Nur: Wie kommt der User an eine _neu hinzugekommene_ Vorlage? Neu angelegte User bekommen sie. Und die bisherigen? Eben.
Lass es mich so ausdrücken, auf einem vernünfig konfigurierten System sollte es die Notwendigkeit für Push-Updates gar nicht geben.
s.o. Ich denke du hast die Intention missverstanden. Es geht _nicht_ um das was du unterstellst (insbesondere nicht um Portabilitaet oder grosse Ausgereiftheit) sondern um eine _Anregung_ wie man ein _spezielles_ Problem auf einer _speziellen_ Maschine loesen _koennte_. Ich wette, du als sysadmin hast schon X shell- oder sonstige Scripte geschrieben um diverse Sachen zu vereinfachen und oder zu automatisieren. Und _nichts_ anderes als eine Anregung / Hilfe beim Erstellen eines solchen scripts geht es!
Recht elegant finde ich auch pull-updates über vom SysOp bereitgestellte Skripte durchzuführen statt brute-force auf /etc/skel zu zugreifen (z.B. ein install-[netscape|mutt]-Skript, das selektiv Änderungen an Dateien in $HOME vornimmt.)
Und wie soll so ein install-script aussehen? Eben.
Leg .Xmodmap oder .Xresources in /etc/skel und installier sie bei Usern, die sie nicht installiert haben. Wahrscheinlich wirst Du den Effekt sehen, von dem ich spreche. [Vgl. /etc/X11/xinit/xinitrc und /etc/skel unter SuSE]. IMHO, sollte es in sauber konfigurierten Systemen keine Notwendigkeit geben, .Xmodmap oder .Xresources in $HOME zu halten, SuSE tut es aber :).
Ist SuSE zwingend? Nein. Also raus damit aus skel und fertig. Aber z.B. eine (vom admin auf das system vorkonfigurierte .muttrc, ggfs. auf die vom User anpassbaren Werte gekuerzt wegen der Uebersichtlichkeit) wuerde _ich_ in skel ablegen (und bei einer Nachinstallation[1] von mutt auch an die schon angelegten User verteilen) -- und als User wuerde ich so einen Service begruessen. [1] d.h. dass es mutt bisher nicht auf dem System gab -dnh -- 86: Installationsparty: Zusammenkunft von Installateuren, die beim Installieren von Installationen für Nichtinstallateure, die Installationen haben wollen, aber sich die Installation ihrer Installation nicht installieren können, bzw. sich die Installation ihrer Installatione nicht zutrauen, ihre Freude haben. (Detlef Neubauer)
Hallo, * Ralf Corsepius schrieb am 22.Mär.2001:
Jan Trippler wrote:
Du hast Dir offensichtlich mein Code-Fragment nicht angeschaut! Ich habe exakt aus diesem Grund nur die Dateien + Verzeichnisse aus /etc/skel kopiert, die im Home des Users _nicht vorhanden_ sind.
Auch das hilft nur bedingt.
Das Risiko dabei die Funktion von von Usern eingerichteten und u.U. modifizierten Dateien zu zerstören ist nicht unerheblich. Das Problem sind optionale Dateien, die die Funktion von anderen Programmen verändern:
Beispiel: Manche User-Profiles enthalten derartige Konstrukte: if [ -r ~/datei ]; then . ~/datei fi
Da wird doch nur abgefragt, ob eine Datei vorhanden ist, bevor sie ausgeführt wird, um Fehlermeldungen zu vermeiden. Wenn einem Fehlermeldungen egal sind, ist hier die Abfrage überflüssig. Was Du meinst, wären Konstrukte wie: if test -r ~/datei then irgendwelche Befehele, in denen ~/datei nicht vorkommt fi das ist aber ehr selten.
Da eine SysAdmin die Folgen auf den einzelnen User kaum überblicken kann, halte ich pauschale Push-Updates aus /etc/skel generell für eine sehr schlechte Idee. Pull-Updates hingegen (jeder User kopiert sich das aus /etc/skel von dem er glaubt es zu brauchen) liegen in der Verantwortung der User.
Dazu hat Jan ja schon was gesagt. Vielleicht wäre es besser, wenn mittels eines Skripts alles was im Verzeichnis /etc/skel.new steht einerseits nach /etc/skel und andererseits nach allen schon existierenden User Homverzeichnisse kopiert und bei Erfolg /etc/skel.new gleich löscht. Könnte auch /tmp/skel heißen, bin mir nicht so sicher, wie das Verzeichnis heißen sollte. Am besten den Namen als Argument mitgeben. Dann kann man auch gleich ein paar Options einführen. Zum Beispiel die 500 ab der die UID ein richitiger User ist, kann Variabel gehalten werden, es kann per Option bestimmt werden, ob das Ausgangsverzeichnis gelöscht werden soll oder nicht (nur bei Erfolg) es können User hinzugefügt (z.B root) oder ausgeschlossen werden, auch /etc/skel. Bernd -- Bitte die Etikette beachten: http://home.t-online.de/~f.walle/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Bernd Brodesser wrote:
Hallo,
* Ralf Corsepius schrieb am 22.Mär.2001:
Jan Trippler wrote:
Du hast Dir offensichtlich mein Code-Fragment nicht angeschaut! Ich habe exakt aus diesem Grund nur die Dateien + Verzeichnisse aus /etc/skel kopiert, die im Home des Users _nicht vorhanden_ sind.
Auch das hilft nur bedingt.
Das Risiko dabei die Funktion von von Usern eingerichteten und u.U. modifizierten Dateien zu zerstören ist nicht unerheblich. Das Problem sind optionale Dateien, die die Funktion von anderen Programmen verändern:
Beispiel: Manche User-Profiles enthalten derartige Konstrukte: if [ -r ~/datei ]; then . ~/datei fi
Da wird doch nur abgefragt, ob eine Datei vorhanden ist, bevor sie ausgeführt wird, um Fehlermeldungen zu vermeiden. Wenn einem Fehlermeldungen egal sind, ist hier die Abfrage überflüssig.
Nein, ich meinte schon das was ich da schrieb: Bedeutung: Falls vorhanden, wird ein Scriptfragment gesource'd. Derartige Konstrukte werden oft verwendet um komplexe Scriptfragmente in andere Scripte einzubinden, z.B. um in komplexer Software user-konfigurierbare, optionale Teile zu konfigurieren (Werden oft aus User-Initialisierungs-/Konfigurationsscripten heraus generiert). Ein reales Beispiel aus einem realen .login: if [ -r ~/.khoros_env ]; then . ~/.khoros_env fi [Wird in dieser Form automatisch bei der User-Installation von Khoros so eingerichtet.] Ein etwas komplexeres Beispiel: if [ -r /opt/SUNWspro/bin/cc ]; then . ~/.SUNWspro_env fi [Source persönliches SUN-WSPro-Compiler Environment, falls Sun-CC gefunden, ignoriere es sonst.]
Was Du meinst, wären Konstrukte wie:
if test -r ~/datei then irgendwelche Befehele, in denen ~/datei nicht vorkommt fi
das ist aber ehr selten. Vgl. das .Xresources-Beispiel aus meinem anderen Posting.
Wozu allerdings die Einschränkung auf "~/datei nicht vorkommt"?
Da eine SysAdmin die Folgen auf den einzelnen User kaum überblicken kann, halte ich pauschale Push-Updates aus /etc/skel generell für eine sehr schlechte Idee. Pull-Updates hingegen (jeder User kopiert sich das aus /etc/skel von dem er glaubt es zu brauchen) liegen in der Verantwortung der User.
Dazu hat Jan ja schon was gesagt. Vielleicht wäre es besser, wenn mittels eines Skripts alles was im Verzeichnis /etc/skel.new steht einerseits nach /etc/skel und andererseits nach allen schon existierenden User Homverzeichnisse kopiert und bei Erfolg /etc/skel.new gleich löscht.
Könnte auch /tmp/skel heißen, bin mir nicht so sicher, wie das Verzeichnis heißen sollte. Am besten den Namen als Argument mitgeben. Dann kann man auch gleich ein paar Options einführen. Zum Beispiel die 500 ab der die UID ein richitiger User ist, kann Variabel gehalten werden, es kann per Option bestimmt werden, ob das Ausgangsverzeichnis gelöscht werden soll oder nicht (nur bei Erfolg) es können User hinzugefügt (z.B root) oder ausgeschlossen werden, auch /etc/skel.
Das ist etwas völlig Anderes wie die bisher hier diskutiertenen for-Schleifen Varianten. Derartige Konventionen machen in kleineren Netzen durchaus Sinn. Ansonsten düfte Euch bekannt sein, dass [ ] Homes in Netzwerken nicht permanent gemountet sein müssen und auch nur selten sind. [ ] auch Dummy-User ohne reales HOME existieren können, die keine login-Scripte benötigen oder die sie gar stören würden. [ ] /etc/passwd in der Regel nur die lokalen User einer Maschine beinhaltet (vgl. yp/nis). [ ] /etc/skel Vorlagen beinhaltet, die dazu bestimmt sind um von Usern modifiziert zu werden. Dies sind keine globalen Konfigurationsdateien. [ ] Die UID 500 SuSE-spezifische Konvention ist und frei konfigurierbar ist. [ ] SuSE's etc/skel Scripte auf anderen Betriebssystemen nur bedingt laufen. Ralf
On Don, Mär 22, 2001 at 12:16:19 +0100, Ralf Corsepius wrote:
Bernd Brodesser wrote: [...]
Dazu hat Jan ja schon was gesagt. Vielleicht wäre es besser, wenn mittels eines Skripts alles was im Verzeichnis /etc/skel.new steht einerseits nach /etc/skel und andererseits nach allen schon existierenden User Homverzeichnisse kopiert und bei Erfolg /etc/skel.new gleich löscht.
Könnte auch /tmp/skel heißen, bin mir nicht so sicher, wie das Verzeichnis heißen sollte. Am besten den Namen als Argument mitgeben. Dann kann man auch gleich ein paar Options einführen. Zum Beispiel die 500 ab der die UID ein richitiger User ist, kann Variabel gehalten werden, es kann per Option bestimmt werden, ob das Ausgangsverzeichnis gelöscht werden soll oder nicht (nur bei Erfolg) es können User hinzugefügt (z.B root) oder ausgeschlossen werden, auch /etc/skel.
Das ist etwas völlig Anderes wie die bisher hier diskutiertenen for-Schleifen Varianten. Derartige Konventionen machen in kleineren Netzen durchaus Sinn.
Ralf, was soll das? Du reitest auf Peanuts rum. Wie das Source-Verzeichnis heisst und wie ich Schleifen-Bedingungen verändere, um User ein- oder auszuschließen, das ändert doch nichts am Prinzip! Nochmal: Du behauptest, pauschale Push-Updates aus /etc/skel heraus sind _immer_ Sch*, wir sagen: Das stimmt nicht. Du hast sicher Deine Erfahrungen, ich habe andere. Das liegt sicher daran, dass wir es bisher mit anderen Benutzergruppen zu tun hatten.
Ansonsten düfte Euch bekannt sein, dass [ ] Homes in Netzwerken nicht permanent gemountet sein müssen und auch nur selten sind. [ ] auch Dummy-User ohne reales HOME existieren können, die keine login-Scripte benötigen oder die sie gar stören würden. [ ] /etc/passwd in der Regel nur die lokalen User einer Maschine beinhaltet (vgl. yp/nis). [ ] /etc/skel Vorlagen beinhaltet, die dazu bestimmt sind um von Usern modifiziert zu werden. Dies sind keine globalen Konfigurationsdateien. [ ] Die UID 500 SuSE-spezifische Konvention ist und frei konfigurierbar ist. [ ] SuSE's etc/skel Scripte auf anderen Betriebssystemen nur bedingt laufen.
Was soll denn diese Argumentation? Sind wir Dir irgendwie auf den Schlips getreten? Wenn ja, dann sorry; aber Deine Aussagen oben haben doch überhaupt nichts mit dem Thema zu tun! Was sollen die [ ]? Du kannst davon ausgehen, dass alle am Thread Beteiligten diese Punkte kennen. - Das Script war nie als distributions-, konfigurations-übergreifendes Zwangs-Push-Update gedacht. Das willst Du jetzt draus machen. Es war und ist als Anregung zur Lösung des ursprünglichen Problems gedacht. - Diese ML heisst suse-linux, also ist es ja wohl gestattet, dass wir uns hier auch vorrangig darüber unterhalten und Kompatibilität mit anderen *nuxen und *nixen nicht Hauptthema ist (auch wenn wir dieses Thema nicht vergessen - siehe der andere Teilthread). Also, damit wieder Ruhe einkehrt: Die Diskussion ging (zumindest von meiner Seite aus) vorrangig darum, dass ich aus meiner Erfahrung heraus Deine Aussage (alle pauschalen Push-Updates aus /etc/skel heraus sind Mist) nicht bestätigen kann. Wir haben dafür IMHO auch ein paar passende Argumente gebracht. Wenn Du das anders siehst, dann ist das Dein gutes Recht, aber deswegen musst Du nicht gleich so rumfauchen. Jan
Hi,
From: Andreas Kyek
On 21 Mar 2001, at 12:54, Peter Bossy wrote:
Halloechen,
weiß jemand von Euch, was man anstellen muß, damit für alle schon existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Tja, /etc/skel gilt nur für neue User. Ansonsten kommst Du wohl nicht drumherum, die Dateien von Hand zu kopieren.
for x in `ls /home` ; do cp Datei /home/$x ; done by Joerg
On Wednesday, 21. March 2001 14:23, Joerg Zimmermann wrote:
existierenden User in die Homeverzeichnise die gleichen Datei/Verzeichnisse zusätzlich zu den schon bestehenden Dateien kopiert zu werden? Allein in /etc/skel kopieren reicht wohl > > nicht.
Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Tja, /etc/skel gilt nur für neue User. Ansonsten kommst Du wohl nicht drumherum, die Dateien von Hand zu kopieren.
for x in `ls /home` ; do cp Datei /home/$x ; done
Das würde wohl grundsätzlich funktionieren. Leider werden die so kopierten Dateien nicht den Benutzern zugewiesen. Trotzdem Danke Gruß Peter
On Mit, 21 Mär 2001, Peter Bossy wrote:
Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Wozu script? Das ist doch mit einer simplen for-Schleife gemacht: for d in `ls -d /home/* | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d; done Bei Bedarf baut man noch ein chown ein: cd home; for d in `ls -d * | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d && chown ${d}.users ${d}/wasauchimmer; done -dnh -- Danke für´s Woggen. Ich glaube Ich sollte den Satz:"Dankeschön für das Woggen!" als Signatur nehmen. [Woko° in dag°]
On Wednesday, 21. March 2001 13:49, David Haller wrote:
On Mit, 21 Mär 2001, Peter Bossy wrote:
Allein in /etc/skel kopieren reicht wohl nicht. Gibt da noch ein Skript, das die Homeverzeichnisse updatet?
Wozu script? Das ist doch mit einer simplen for-Schleife gemacht:
for d in `ls -d /home/* | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d; done
Bei Bedarf baut man noch ein chown ein:
cd home; for d in `ls -d * | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d && chown ${d}.users ${d}/wasauchimmer; done
Das war eine gute Idee. Ich habe allerdings chmod --reference .... benutzt. Trotzdem dachte ich, daß es eine fertige und implementierte Lösung für dieses Problem geben würde. Ich würde da jedenfalls echten Bedarf sehen. Danke Gruß Peter
On Mit, Mär 21, 2001 at 01:49:01 +0100, David Haller wrote: [...]
Bei Bedarf baut man noch ein chown ein:
cd home; for d in `ls -d * | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d && chown ${d}.users ${d}/wasauchimmer; done
und zerdonnert sich sämtliche bestehenden Konfigurationen! Als absolutes Minimum an Sicherheit würde ich mal die Option -i ansehen, IMHO ist es aber besser, bestehende Dateien gar nicht anzufassen. Siehe meine andere Mail zu diesem Thema. Ausserdem werden durch den einfachen cp Unterverzeichnisse und ihre Inhalte nicht kopiert. Jan
On Mit, 21 Mär 2001, Jan Trippler wrote:
On Mit, Mär 21, 2001 at 01:49:01 +0100, David Haller wrote: [...]
Bei Bedarf baut man noch ein chown ein:
cd home; for d in `ls -d * | grep -v lost+found`; do cp /etc/skel/wasauchimmer $d && chown ${d}.users ${d}/wasauchimmer; done
und zerdonnert sich sämtliche bestehenden Konfigurationen! Als absolutes Minimum an Sicherheit würde ich mal die Option -i ansehen, IMHO ist es aber besser, bestehende Dateien gar nicht anzufassen. Siehe meine andere Mail zu diesem Thema. Ausserdem werden durch den einfachen cp Unterverzeichnisse und ihre Inhalte nicht kopiert.
Im Prinzip natuerlich volles ACK, ich dachte halt (nur) an den Fall, dass z.B. der admin ein neues Programm installiert, eine default-config dafuer in /etc/skel erstellt und dann eben den schon vorhandenen usern die default-config zukommen lassen will. ;) Als script natuerlich ungeeignet fuer alles in /etc/skel ungeeignet. Ansonsten wuerde ich aehnlich wie du die Dateien und Unterverzeichnisse von skel abklappern, auf die Existenz im user-dir testen und ggfs. nachinstallieren. z.B: ==== ungetestet, wieder nur als Ideenlieferant gedacht ==== for user in `cd /home; ls -d * | grep -v lost+found` do if cut -d: -f1 < /etc/passwd | grep "^$user$" then for dir in `find /etc/skel -type d | grep -v '^/etc/skel/$'` do targetdir="/home/$user/`echo $dir | sed 's%/etc/skel/%%'`" ## if bash: # targetdir="/home/$user/${dir//\/etc\/skel\//}" if ! test -d $targetdir then install -d -o $user -g users -m 755 $targetdir fi done for file in `find /etc/skel -type f` do target="/home/$user/`echo $file | sed 's%/etc/skel/%%'`" ## if bash: target="/home/$user/${file//\/etc\/skel\//}" if ! test -f $target install -o $user -g users -m 644 $file $target ## else z.B. backup (mit install -b -S SUFFIX machen ## oder als .new oder .default installieren... fi done fi done ==== -dnh -- [Frage war: Wie mail mit xemacs unter NT ohne sowas wie sendmail]
Wer will sowas? Vor allem mit den drei genannten "Programmen" ... Welche Programme? Ich sehe ein "Betriebssystem", ein Betriebssystem und eine Droge fuer Config-Junkies.
On Mit, Mär 21, 2001 at 09:59:21 +0100, David Haller wrote: [...]
Im Prinzip natuerlich volles ACK, ich dachte halt (nur) an den Fall, dass z.B. der admin ein neues Programm installiert, eine default-config dafuer in /etc/skel erstellt und dann eben den schon vorhandenen usern die default-config zukommen lassen will. ;)
Ja, genau da dachte ich auch dran ;-) Da ist es IMHO aber eher ungewöhnlich, dass /etc/skel vorher leergemacht wird - es soll ja für neue Benutzer _alle_ Defaults und Templates vorhalten.
==== ungetestet, wieder nur als Ideenlieferant gedacht ====
Wenn wir so weitermachen, können wir das Ding bald an freshmeat oder suse schicken ;-) Ich kann mir ein kleines *literarisches Quartett* mal wieder nicht verkneifen *g*
for user in `cd /home; ls -d * | grep -v lost+found` do if cut -d: -f1 < /etc/passwd | grep "^$user$" then
Wie wäre es an dieser Stelle gleich mit einem Durchsuchen der passwd; dann könnte man auch User erwischen, deren Homes irgendwo anders liegen.
for dir in `find /etc/skel -type d | grep -v '^/etc/skel/$'`
BTW: Den grep kann man sich schenken, wenn -mindepth 1 als find-Option verwendet wird.
do targetdir="/home/$user/`echo $dir | sed 's%/etc/skel/%%'`" ## if bash: # targetdir="/home/$user/${dir//\/etc\/skel\//}"
Wenn man vorher in /etc/skel wechselt und dann den find mit relativem Suchpfad angibt, braucht man sich das targetdir nicht zu basteln, dann kann man es einfach anhängen. Aah - ich habe gerade noch eine bessere Lösung gefunden: Guck Dir mal die printf-Option des find an!
if ! test -d $targetdir then install -d -o $user -g users -m 755 $targetdir fi done for file in `find /etc/skel -type f` do target="/home/$user/`echo $file | sed 's%/etc/skel/%%'`" ## if bash: target="/home/$user/${file//\/etc\/skel\//}"
Wie oben: Mit relativem Suchpfad im find kann man die Pfade einfach aneinanderhängen. Oder man benutzt printf.
if ! test -f $target install -o $user -g users -m 644 $file $target ## else z.B. backup (mit install -b -S SUFFIX machen ## oder als .new oder .default installieren... fi done fi done ====
=== Mein neuer Vorschlag (nicht vollständig getestet!) === # Username, UID, GID, HOME aus /etc/passwd cut -d: -f1,3,4,6 /etc/passwd | sed 's/:/ /g' | \ while read user u_id g_id home; do # UID pruefen: keine System-Accounts, kein nobody test $u_id -lt 500 -o $user = "nobody" && continue # Directories kopieren (Modus von /etc/skel mitnehmen) find /etc/skel -type d -mindepth 1 -printf "%m %P\n" | while read d_mode dir; do test ! -d $home/$dir && \ install -d -o $user -g $g_id -m $d_mode $home/$dir done # Dateien kopieren (Modus von /etc/skel mitnehmen) find /etc/skel -type f -printf "%m %P\n" | while read f_mode f_name; do if test ! -f $home/$f_name; then install -o $user -g $g_id -m $f_mode \ /etc/skel/$f_name $home/$f_name else ## z.B. backup (mit install -b -S SUFFIX machen ## oder als .new oder .default installieren... fi done done === Schnapp === So, jetzt noch ein wenig testen, Leerzeichen in Pfadnamen und ähnliche Schweinereien abfangen, dann kann es losgehen :-) Jan
Hallo, On Don, 22 Mär 2001, Jan Trippler wrote:
On Mit, Mär 21, 2001 at 09:59:21 +0100, David Haller wrote: [...] Ja, genau da dachte ich auch dran ;-) Da ist es IMHO aber eher ungewöhnlich, dass /etc/skel vorher leergemacht wird - es soll ja für neue Benutzer _alle_ Defaults und Templates vorhalten.
Ja logisch! Nein, ich meinte, dass der admin eine Datei zu /etc/skel _hinzufuegt_. Dann haben die existierenden Benutzer ja das file noch nicht... Und das will er (diese eine File) auch in den homes der user hinzufuegen (so hatte ich das jedenfalls verstanden/gedacht). Aber die letzte script-Loesung von dir kommt glaub einer anstaendigen Loesung ziemlich nahe :)
Wenn wir so weitermachen, können wir das Ding bald an freshmeat oder suse schicken ;-) Ich kann mir ein kleines *literarisches Quartett* mal wieder nicht verkneifen *g*
*g*
for user in `cd /home; ls -d * | grep -v lost+found` do if cut -d: -f1 < /etc/passwd | grep "^$user$" then
Wie wäre es an dieser Stelle gleich mit einem Durchsuchen der passwd; dann könnte man auch User erwischen, deren Homes irgendwo anders liegen.
Hm. Jein. Wozu braucht ein ftp- oder mail-only user die Dateien aus skel? Ich wuerde eher eine Variable HOMES am Anfang des scripts (oder zur Not als Umgebungsvariable) setzen, die dann abgearbeitet wird. Mit z.B.: HOMES="/home:/export/homes:/ftp/homes" ## Oder was sonst halt gibt OLDIFS=$IFS; IFS=':'; eval set -- "$HOMES" for homeroot in $@; do for user in `cd $homeroot && ls -d * | grep -v lost+found`; do if cut -d: -f1 < /etc/passwd | grep "^$user$" [...] done done IFS=$OLDIFS geht das auch mit dem : als Pfadtrenner...
for dir in `find /etc/skel -type d | grep -v '^/etc/skel/$'`
BTW: Den grep kann man sich schenken, wenn -mindepth 1 als find-Option verwendet wird.
Jup. Uebersehen.
do targetdir="/home/$user/`echo $dir | sed 's%/etc/skel/%%'`"
Wenn man vorher in /etc/skel wechselt und dann den find mit relativem Suchpfad angibt, braucht man sich das targetdir nicht zu basteln, dann kann man es einfach anhängen. Aah - ich habe gerade noch eine bessere Lösung gefunden: Guck Dir mal die printf-Option des find an!
Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;)
=== Mein neuer Vorschlag (nicht vollständig getestet!) === # Username, UID, GID, HOME aus /etc/passwd cut -d: -f1,3,4,6 /etc/passwd | sed 's/:/ /g' | \ while read user u_id g_id home; do # UID pruefen: keine System-Accounts, kein nobody test $u_id -lt 500 -o $user = "nobody" && continue
s.o. Ich halte diese Loesung fuer weniger geeignet, da ja nur "echte" User ein home mit den skel-Dateien haben sollen... Ich halte also das ls der $HOMES mit anschliessender Ueberpruefung von /etc/passwd fuer sinnvoller, aber das soll jeder selbst entscheiden. Aber das ist ja weitestgehend vom "Schleifenrumpf" unabhaengig, ggfs. definiert man eben (wieder im Scriptkopf): d_mode="750" f_mode="640" (mode 'xx0', denn was gehen "other" die Config-Dateien eines users an? :) [...]
So, jetzt noch ein wenig testen, Leerzeichen in Pfadnamen und ähnliche Schweinereien abfangen, dann kann es losgehen :-)
Hm. Leerzeichen sollten sich durch "" und/oder -printf "%P\n" loesen lassen (und die meisten andern Sonderzeichen > ASCII 32). Ein \n oder \r im Dateinamen dagegen wird schwierig. Naja, wer einen Usernamen hat, der \;\n\r enthaelt hat eh andere Probleme am Hals -- IMHO ;) -dnh -- Heh du da! Mit dem Schuh da! Wer bei mir im Grab liegt der bleibt auch da. Weil offiziell als Tot erklärt. Tote haben nix zu sagen. Und wenn se wiederkommen sind se Zombies. die werden dann mit dem Laser zermatsch. Bevor die noch wen anfressen. [WoKo in dag°]
Moin, On Don, 22 Mär 2001, David Haller sent incredible lines:
On Don, 22 Mär 2001, Jan Trippler wrote: [...]
Wie wäre es an dieser Stelle gleich mit einem Durchsuchen der passwd; dann könnte man auch User erwischen, deren Homes irgendwo anders liegen. Hm. Jein. Wozu braucht ein ftp- oder mail-only user die Dateien aus skel? Ich wuerde eher eine Variable HOMES am Anfang des scripts (oder zur Not als Umgebungsvariable) setzen, die dann abgearbeitet wird. Mit z.B.:
HOMES="/home:/export/homes:/ftp/homes" ## Oder was sonst halt gibt OLDIFS=$IFS; IFS=':'; eval set -- "$HOMES" for homeroot in $@; do for user in `cd $homeroot && ls -d * | grep -v lost+found`; do if cut -d: -f1 < /etc/passwd | grep "^$user$" [...] done done IFS=$OLDIFS
geht das auch mit dem : als Pfadtrenner... [...]
Wie wärs mit einer Abfrage in passwd ob die Nutzer eine Shell haben, also bash oder ... und diese mit in den Pfad aufnehmen. [...]
Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;) [...]
Wichtiges Argument, leider habe ich momentan keine Solaris Kiste rumstehen um das mal zu testen. Hab aber evtl. demnächst wieder Zugriff auf selbige. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...!
Thomas Bendler wrote:
Moin,
On Don, 22 Mär 2001, David Haller sent incredible lines:
On Don, 22 Mär 2001, Jan Trippler wrote: [...] Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;) [...]
Wichtiges Argument, leider habe ich momentan keine Solaris Kiste rumstehen um das mal zu testen. Hab aber evtl. demnächst wieder Zugriff auf selbige.
Wird laut man-pages von find weder unter SunOS4 noch unter SunOS5 unterstützt. Ralf
* Ralf Corsepius schrieb am 22.Mär.2001:
Thomas Bendler wrote:
On Don, 22 Mär 2001, David Haller sent incredible lines:
Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;)
Wichtiges Argument, leider habe ich momentan keine Solaris Kiste rumstehen um das mal zu testen. Hab aber evtl. demnächst wieder Zugriff auf selbige.
Wird laut man-pages von find weder unter SunOS4 noch unter SunOS5 unterstützt.
Schön, und wie sieht es bei AIX oder UP_HX aus? Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
On Don, Mär 22, 2001 at 06:02:52 +0100, David Haller wrote:
On Don, 22 Mär 2001, Jan Trippler wrote: [...]
Wie wäre es an dieser Stelle gleich mit einem Durchsuchen der passwd; dann könnte man auch User erwischen, deren Homes irgendwo anders liegen.
Hm. Jein. Wozu braucht ein ftp- oder mail-only user die Dateien aus skel? Ich wuerde eher eine Variable HOMES am Anfang des scripts (oder zur Not als Umgebungsvariable) setzen, die dann abgearbeitet wird. Mit z.B.:
OK, dann könnte man Thomas' Idee noch mit reinbringen und die Shell abprüfen. Aber, wie Du schon sagtest: Das wird jetzt mehr philosophisch und hängt mehr oder weniger vom eigenen Geschmack ab.
HOMES="/home:/export/homes:/ftp/homes" ## Oder was sonst halt gibt OLDIFS=$IFS; IFS=':'; eval set -- "$HOMES" for homeroot in $@; do for user in `cd $homeroot && ls -d * | grep -v lost+found`; do if cut -d: -f1 < /etc/passwd | grep "^$user$"
An der Stelle würd ich auf jeden Fall aus der passwd die GID, die Shell (und u. U. zum Querchecken noch das Home) rausholen.
[...] done done IFS=$OLDIFS
[...]
Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;)
Nach Ralf nicht (ich kann mich auch aus meinen *nix-Zeiten nicht an ein printf erinnern), also muss man in diesem Fall doch auf sed o. ä. zurückgreifen :-( Äh, damit's nicht langweilig wird: Es geht auch ohne sed ;-) dir=`echo $dir | cut -f4- -d"/"` oder: dir=`echo $dir | cut -c11-` Das ist in diesem Fall ok, weil ja das abzuschnippelnde Teil bekannt ist. [...]
Aber das ist ja weitestgehend vom "Schleifenrumpf" unabhaengig, ggfs. definiert man eben (wieder im Scriptkopf):
d_mode="750" f_mode="640"
(mode 'xx0', denn was gehen "other" die Config-Dateien eines users an? :)
Damit habe ich noch so meine Probleme! Es gibt ja Dateien, die nicht ohne Grund andere Permissions haben, wie z. B. die .fetchmailrc. Deshalb war ich auch so wild darauf, sie vom find zu kriegen. Na was solls, dann holen wir sie eben aus dem ls, und zwar gaaanz kompatibel ;-) Da ich kein Kommando kenne, welches mir die Rechte schön in chmod-Format liefert (tut wer was kennen?): perms=`ls -l /etc/skel/irgendwas | cut -c2-10` p_opt="u="`echo $perms | cut -c1-3 | tr -d '-'` p_opt=$p_opt",g="`echo $perms | cut -c4-6 | tr -d '-'` p_opt=$p_opt",o="`echo $perms | cut -c7-9 | tr -d '-'` Ein wenig mühevoll, aber so haben wir schicke Originalpermissions der Quelldatei. Jan
On Don, 22 Mär 2001, Jan Trippler wrote:
On Don, Mär 22, 2001 at 06:02:52 +0100, David Haller wrote:
On Don, 22 Mär 2001, Jan Trippler wrote:
OK, dann könnte man Thomas' Idee noch mit reinbringen und die Shell abprüfen. Aber, wie Du schon sagtest: Das wird jetzt mehr philosophisch und hängt mehr oder weniger vom eigenen Geschmack ab.
Ack.
HOMES="/home:/export/homes:/ftp/homes" ## Oder was sonst halt gibt OLDIFS=$IFS; IFS=':'; eval set -- "$HOMES" for homeroot in $@; do for user in `cd $homeroot && ls -d * | grep -v lost+found`; do if cut -d: -f1 < /etc/passwd | grep "^$user$"
An der Stelle würd ich auf jeden Fall aus der passwd die GID, die Shell (und u. U. zum Querchecken noch das Home) rausholen.
Ack.
Ack. Aber ist 'find ... -printf' portabel? Obige Loesung mit sed auf jeden Fall... Naja, egal ;)
Nach Ralf nicht (ich kann mich auch aus meinen *nix-Zeiten nicht an ein printf erinnern), also muss man in diesem Fall doch auf sed o. ä. zurückgreifen :-(
Muss? Pfui! Was ich fuer (GNU) features in meinen privat Scripten verwende geht niemanden was an! :-) [cut statt sed]
Das ist in diesem Fall ok, weil ja das abzuschnippelnde Teil bekannt ist.
Und vor allem eine statische Laenge hat :)
[...]
(mode 'xx0', denn was gehen "other" die Config-Dateien eines users an? :)
Damit habe ich noch so meine Probleme! Es gibt ja Dateien, die nicht ohne Grund andere Permissions haben, wie z. B. die .fetchmailrc.
Jup. Alternativ koennte man erst die in skel "korrigieren" (also z.B. eben chmod -cR o-rwx ;) und dann diese als Referenz nehmen.
Deshalb war ich auch so wild darauf, sie vom find zu kriegen. Na was solls, dann holen wir sie eben aus dem ls, und zwar gaaanz kompatibel ;-) Da ich kein Kommando kenne, welches mir die Rechte schön in chmod-Format liefert (tut wer was kennen?):
*lol* Erst ich mit dem -printf von find und jetzt du mit: $ chmod --help --reference=RFILE Verweundung von RFILE's Modus anstatt eines MODE Wertes. Ach ja: kpsestat = $file liefert den oktalen Wert der gesetzten Permissions (gehoert zu kpathsea, also teTeX). Statt = kann auch ein Modifier wie die symbolischen von chmod verwendet werden, ein kpsestat o-rwx $file liefert also den oktalwert mit den flags fuer other auf 0 gesetzt. -dnh -- Wenn Ihr irgendwas Zischen und Krachen höhrt, keine Angst. das ist nur mein Kopf, bei der Produktion von wognaturen. [WoKo in dag°]
On Don, Mär 22, 2001 at 10:00:25 +0100, David Haller wrote: [Kompatibilität]
Muss? Pfui! Was ich fuer (GNU) features in meinen privat Scripten verwende geht niemanden was an! :-)
Du hast doch mit der Kompatibilität (niedliches Wort ;-) angefangen ;-)
Jup. Alternativ koennte man erst die in skel "korrigieren" (also z.B. eben chmod -cR o-rwx ;) und dann diese als Referenz nehmen.
Ja, so war meine Idee.
*lol* Erst ich mit dem -printf von find und jetzt du mit:
$ chmod --help --reference=RFILE Verweundung von RFILE's Modus anstatt eines MODE Wertes.
Also, das ist mit Sicherheit nicht kompatibel, das wird ja noch nicht mal auf den älteren Linuxen unterstützt. Ich habe 2.2.10 auf dem Server, der chmod --version liefert 3.16 und da taucht das nicht auf.
Ach ja:
kpsestat = $file
liefert den oktalen Wert der gesetzten Permissions (gehoert zu kpathsea, also teTeX). Statt = kann auch ein Modifier wie die symbolischen von chmod verwendet werden, ein kpsestat o-rwx $file liefert also den oktalwert mit den flags fuer other auf 0 gesetzt.
Und das ist mir nun total unbekannt (ich bin allerdings TeX-mäßig eher Embryo). Jan
Hallo Jan, On Fre, 23 Mär 2001, Jan Trippler wrote:
On Don, Mär 22, 2001 at 10:00:25 +0100, David Haller wrote: [Kompatibilität]
Muss? Pfui! Was ich fuer (GNU) features in meinen privat Scripten verwende geht niemanden was an! :-)
Du hast doch mit der Kompatibilität (niedliches Wort ;-) angefangen ;-)
Ja! Und? Genau! Eben! Der Punkt ist doch dabei der, dass "man" sich bewusst ist, und ggfs. recherchiert ob etwas kompatibel (zu was) ist oder ausdruecklich auf diese Einschraenkungen hinweist, wenn man das Teil dann weitergibt. Ich glaube, da sind wir uns aber eh einig! :) Leider gibt eben nicht jedes GNU-Tool preis, welche Features POSIX konform[1] sind... Ein positives Beispiel ist z.B. stty. Wenn ich weiss und ggfs. deutlich sage, dass das Script foo nur mit (der bash|dem GNU find|dem GNU make|...) getestet wurde oder sogar definitiv nur mit $VERSION von eben diesen funktioniert sehe ich keine Probleme, wenn ich das Script weitergebe. Und ansonsten: Ob das, was bei mir in ~/bin rumfaehrt (auch und gerade von root), kompatibel auch nur zu einem anderen SuSE-Linux System ist, ist mir ehrlich gesagt wurscht. Und wenn ich ein '#!/bin/bash', ein '#!/usr/bin/gawk' in meine scripte schreibe, halte ich nicht mal die Hinweise, dass es moeglicherweise unter der sh oder awk nicht tut fuer ueberfluessig -- es steht ja ausdruecklich drin, dass es ne bash bzw. das GNU-awk sein soll... IMHO (und dabei haben wir AFAIK wieder die gleiche Meinung) ist die Messlatte, ob und was der Anspruch ist oder gar "behauptet" wird (also z.B. ein 'laeuft auch unter $UNIX mit $SHELL').
*lol* Erst ich mit dem -printf von find und jetzt du mit:
$ chmod --help --reference=RFILE Verweundung von RFILE's Modus anstatt eines MODE Wertes.
Also, das ist mit Sicherheit nicht kompatibel, das wird ja noch nicht mal auf den älteren Linuxen unterstützt. Ich habe 2.2.10 auf dem Server, der chmod --version liefert 3.16 und da taucht das nicht auf.
Huch! Hier: $ chmod --version chmod (GNU fileutils) 4.0 Habe aber keine Ahnung mehr, ob und wann ich das evtl. aktualisiert habe ;) Naja, s.u.
kpsestat = $file liefert den oktalen Wert der gesetzten Permissions
Und das ist mir nun total unbekannt (ich bin allerdings TeX-mäßig eher Embryo).
Ach du Armer! *scnr* Ich hab's bis gestern abend (in der direkten Anwendung) auch nicht gekannt, aber ein 'apropos mode' hat's zu Tage gefoerdert :) Hmja. Es wird kolportiert, dass teTeX (und dessen kpse*-Tools) sehr portabel sind... Und wer unter Linux kein teTeX hat... Naja, zur Not lassen sich die Quellen von kpsestat sicher besorgen, teTeX samt kpathsea steht ja komplett unter der GPL oder LPPL. Und das Binary hat grad mal 4852 Bytes[2], das kann man ggfs. "mitliefern" ;) Und selbst kpsestat.ii.gz hat grad mal 17097 Bytes. /tmp/teTeX-1.0.7/texk/kpathsea (0) $ ls -l kpsestat* -rwxr-xr-x 1 dh users 4900 Mar 23 06:02 kpsestat -rw-r--r-- 1 dh users 4080 Jun 6 1999 kpsestat.c -rw-r--r-- 1 dh users 147274 Mar 23 06:08 kpsestat.ii -rw-r--r-- 1 dh users 17261 Mar 23 06:08 kpsestat.ii.bz2 -rw-r--r-- 1 dh users 18804 Mar 23 05:59 kpsestat.ii.gz -rw-r--r-- 1 dh users 136842 Mar 23 05:59 kpsestat.iii -rw-r--r-- 1 dh users 15731 Mar 23 05:59 kpsestat.iii.bz2 -rw-r--r-- 1 dh users 17097 Mar 23 06:00 kpsestat.iii.gz -rw-r--r-- 1 dh users 2896 Mar 23 06:01 kpsestat.o -rwxr-xr-x 1 dh users 13592 Mar 23 06:01 kpsestat.unstripped Das .iii ist durch ein sed-script das 'Leerzeilen' entfernt gejagt: sed '/^[ \t]*$/d' [1] was ein anerkannter Standard ist, der aber auch nicht von allen kommerziellen *nixen eingehalten wird -dnh -- "AOL would be a giant diesel-smoking bus with hundreds of ebola victims on board throwing dead wombats and rotten cabbage at the other cars" - a.s.r throws the Information Superhighway metaphor into reverse.
Moin, On Fre, Mär 23, 2001 at 06:11:21 +0100, David Haller wrote: [Kompatibel sein]
IMHO (und dabei haben wir AFAIK wieder die gleiche Meinung) ist die Messlatte, ob und was der Anspruch ist oder gar "behauptet" wird (also z.B. ein 'laeuft auch unter $UNIX mit $SHELL').
ACK, ich schreibe meist vorsichtshalber die Kernel-Version, unter der ich was geschrieben habe, in den Header. Da ich teilweise noch 2.0.35 habe (die *legendäre* suse 5.3), ist das - vor allem im Hinblick auf die Versionen der einzelnen Programme - extrem wichtig. Ich erinnere mich z. B. an die Notwendigkeit, dem file einen Alias zu verpassen, weil er auf meinem 2.0-er die -b-Option noch nicht konnte. [...]
Also, das ist mit Sicherheit nicht kompatibel, das wird ja noch nicht mal auf den älteren Linuxen unterstützt. Ich habe 2.2.10 auf dem Server, der chmod --version liefert 3.16 und da taucht das nicht auf.
Huch! Hier: $ chmod --version chmod (GNU fileutils) 4.0
Eine kleine Versionsabfrage an den Anfang des Scripts,
versionsabhängig eine Shell-Funktion einrichten - fertig. Wenn man
weiss, _dass_ solche Unterschiede bestehen, kann man sie auch
schnell umgehen:
=== Schnipp ===
chmod_v3 () {
src=$1
dst=$2
# ls $src + Modus fuer chmod zusammenbasteln
chmod $modus $dst
}
chmod_v4 () {
src=$1
dst=$2
chmod --reference=$src $dst
}
if `chmod --version | sed "s/.* //g;s/\..*//g` -lt 4; then
alias chmod_ref=chmod_v3
else
alias chmod_ref=chmod_v4
fi
=== Schnapp ===
Dann rufen wir im Script nur noch
chmod_ref /etc/skel/$datei $home/$datei
auf, fertig.
[TeX - kpsestat]
Andere Variante: Wir basteln uns ein Mini-Programm dafür selber (nur
für diesen Anwendungsbereich, deshalb auch nur mit rudimentärsten
Funktionen):
=== Schnipp ===
#include
participants (8)
-
Andreas Kyek -
Bernd Brodesser -
David Haller -
Jan.Trippler＠t-online.de -
Joerg Zimmermann -
Peter Bossy -
Ralf Corsepius -
Thomas Bendler