Hallo LUG,
ich bin dabei meine rc.initscripts ein bisschen aufzuräumen (die Slackware-Standardkonfiguration erscheint mir ein wenig unübersichtlich). Es existiert eine /etc/rc.d/rc.modules, die beim Start automatisch ein paar Kernelmodule hochlädt, soweit ganz praktische Sache. In diesem Script werden die Module (jetzt) so geladen:
<schnipp>
infoline busy "Loading sound blaster support modules" if /sbin/modprobe sb io=0x220 irq=5 dma=1 >/dev/null 2>&1; then infoline ok else infoline fail fi
</schnapp>
(Die Umleitung auf /dev/null soll später in eine logdatei fließen) 'infoline' ist ein kleines Programm von mir, dass den über- gebenen Text (Parameter 2) anzeigt und dahinter eine Markierung setzt - im ersten Fall ein BUSY. Ich hab diese Art Boot- Meldungen mal bei einer DLD 6.0 gesehen und fand es recht über- sichtlich, da man anhand der farbigen BUSY/OK/FAIL- Markierungen einen schnellen Überblick bekommt.
Das Ganze sieht dann in etwa so aus:
Loading sound blaster support modules.............. [BUSY]
Wenn 'infoline' mit nur einem Parameter (ok / fail) aufgerufen wird, wird der Cursor per ANSI-Sequenz 5 Zeichen zurück gesetzt und das [BUSY] durch [ OK ] oder [FAIL] überschrieben. In meinem Beispiel oben will ich auf diese Weise auch die Module laden - allerdings geben die bei Ihrer Initialisierung ebenfalls Meldungen aus, die ich bis jetzt nicht unterdrücken kann. Das ist auch mein Problem, denn die machen mir die ganze Übersicht kaputt.
Ich hab auch schon modprobe -q und modprobe -s probiert - die Meldungen bleiben.
Gibt es noch einen Ausgabekanal, den ich evtl. auf /dev/null umleiten muss oder wie bekomme ich die Meldungen sonst weg?
Viele Grüße,
Matthias
On Fri, Aug 31, 2001 at 02:35:31PM +0200, Matthias Petermann wrote:
In meinem Beispiel oben will ich auf diese Weise auch die Module laden - allerdings geben die bei Ihrer Initialisierung ebenfalls Meldungen aus, die ich bis jetzt nicht unterdrücken kann. Das ist auch mein Problem, denn die machen mir die ganze Übersicht kaputt.
Ich hab auch schon modprobe -q und modprobe -s probiert - die Meldungen bleiben.
Gibt es noch einen Ausgabekanal, den ich evtl. auf /dev/null umleiten muss oder wie bekomme ich die Meldungen sonst weg?
Die Meldungen kommen von printk aus dem kernel. Ich glaube mit klogd kann man beeinflussen, was davon auf der Console ankommt.
Reinhard
Danke Reinhard, das war genau die Lösung für mein Problem.
Zum Zeitpunkt, zu dem die Module bei mir geladen werden, ist im _originalen_ Slackware Linux noch kein klogd vorhanden; der wird dann erst später nach der Netzwerkinitialisierung und dem Starten verschiedener rpc.-Dienste gestartet. Ich hab den klogd jetzt einfach ganz am Anfang des rc-Scripts eingetragen, quasi nachdem die Dateisysteme geprüft werden - gibt es dagegen irgendwelche Einwände bzw. hat es einen bestimmten Hintergrund, dass der klogd _original_ nach den rpc.-Diensten gestartet wird?
Noch eine andere Frage: wo finde ich im Internet eine Beschreibung über die Verzeichnishierarchie von UNIX-Systemen? So wie ich es bis jetzt erfahren habe hat da jeder Distributor so seine eigenen Vorstellungen - ich würde gern mehr darüber erfahren was z.B. Abkürzungen wie '/var' bedeuten und welche Daten dort abgelegt werden sollten (und welche nicht).
Viele Grüße,
Matthias
On Fri, Aug 31, 2001 at 09:42:32PM +0200, Reinhard Foerster wrote:
On Fri, Aug 31, 2001 at 02:35:31PM +0200, Matthias Petermann wrote:
In meinem Beispiel oben will ich auf diese Weise auch die Module laden - allerdings geben die bei Ihrer Initialisierung ebenfalls Meldungen aus, die ich bis jetzt nicht unterdrücken kann. Das ist auch mein Problem, denn die machen mir die ganze Übersicht kaputt.
Ich hab auch schon modprobe -q und modprobe -s probiert - die Meldungen bleiben.
Gibt es noch einen Ausgabekanal, den ich evtl. auf /dev/null umleiten muss oder wie bekomme ich die Meldungen sonst weg?
Die Meldungen kommen von printk aus dem kernel. Ich glaube mit klogd kann man beeinflussen, was davon auf der Console ankommt.
Reinhard
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
On Fri Aug 31, 2001 at 23:21:08 +0200, Matthias Petermann wrote:
Noch eine andere Frage: wo finde ich im Internet eine Beschreibung über die Verzeichnishierarchie von UNIX-Systemen? So wie ich es bis jetzt erfahren habe hat da jeder Distributor so seine eigenen Vorstellungen - ich würde gern mehr darüber erfahren was z.B. Abkürzungen wie '/var' bedeuten und welche Daten dort abgelegt werden sollten (und welche nicht).
Pointers: o Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ o Allgemeineres: http://www.freestandards.org/ o Debian unstable benutzen o http://learn.to/quote
Adam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 01 September 2001 00:16, Adam Lackorzynski wrote:
o Debian unstable benutzen
Von Beruf Bastard Operator? ;-)
Sid hat das Alias "unstable" durchaus verdient. Woody (alias "testing") ist dagegen schon ziemlich stabil.
Konrad
- -- BOFH excuse #43:
boss forgot system password
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 31 August 2001 23:21, Matthias Petermann wrote:
Noch eine andere Frage: wo finde ich im Internet eine Beschreibung über die Verzeichnishierarchie von UNIX-Systemen? So wie ich es bis jetzt erfahren habe hat da jeder Distributor so seine eigenen Vorstellungen - ich würde gern mehr darüber erfahren was z.B. Abkürzungen wie '/var' bedeuten und welche Daten dort abgelegt werden sollten (und welche nicht).
Falls Dir der FHS zu trocken ist, hier eine Kurzfassung:
/etc - globale Konfigurationsdateien /bin - Programme, die von allen Nutzern und von Systemdiensten gebraucht werden /sbin - Programme, die vom Admin und von Systemdiensten gebraucht werden /lib - wichtige Bibliotheken (auch DLL's oder Shared Objects genannt) /home - Homeverzeichnisse /var - Daten, die vom System selbst erstellt werden (Spoolverzeichnisse von Druckern und Mail (/var/spool/*), Hinweise auf laufende Daemons (/var/run), Logbücher (/var/log), etc.pp) /tmp - Temporäre Dateien (wird meistens auch automatisch vom System aufgeräumt) /usr - Hierarchie von Programmen/Daten, die nicht vom System gebraucht werden: /usr/bin - Programme, die von allen Nutzern gebraucht werden /usr/sbin - Adminprogramme /usr/share - Datenbanken (fortune-DB's, Lokalisierungsdb's, etc.) /usr/doc (/usr/share/doc) - Dokumentation, HowTo's, README's /usr/man - Man-Pages /usr/info - Info-Pages /usr/X11R6 - X-Window System (darunter gibt es nochmal eine Hierarchie mit lib, bin usw.)
/usr/local, /opt - wird von einigen Distributoren als Ablage für "Zusatzprogramme" (wie die das auch immer definieren) genutzt, ich benutze es für selbst kompilierte Programme - das läßt sich dann besser wieder aufräumen.
Der FHS definiert dann was unter welchen Bedingungen wo hin gehört. Die meisten Distris sind noch dabei ihre eigenen Vorstellungen von Dateihierarchien auf den FHS anzupassen.
Konrad
- -- BOFH excuse #125:
we just switched to Sprint.
On Sat Sep 01, 2001 at 11:44:08 +0200, Konrad Rosenbaum wrote:
/bin - Programme, die von allen Nutzern und von Systemdiensten gebraucht werden /sbin - Programme, die vom Admin und von Systemdiensten gebraucht werden
Essential command binaries. Der FHS legt genau fest, welche binaries da zu liegen kommen (zumindest fuer /bin recht genau). Generell solche, die vorm mounten /usr gebraucht werden. /usr kann auch via NFS kommen...
/lib - wichtige Bibliotheken (auch DLL's oder Shared Objects genannt)
plus kernel modules.
/usr - Hierarchie von Programmen/Daten, die nicht vom System gebraucht werden:
Wichtigstes Merkmal von /usr: es musz shareable und readonly sein, d.h. man kann /usr via NFS (o.ae.) an mehrere (FHS-kompatible) Rechner verteilen.
/usr/share - Datenbanken (fortune-DB's, Lokalisierungsdb's, etc.)
Architektur_un_abhaengige Daten.
/usr/doc (/usr/share/doc) - Dokumentation, HowTo's, README's
_Nur_ /usr/share/doc
/usr/man - Man-Pages
/usr/share/man
/usr/info - Info-Pages
/usr/share/info
/usr/local, /opt - wird von einigen Distributoren als Ablage für "Zusatzprogramme" (wie die das auch immer definieren) genutzt, ich benutze es für selbst kompilierte Programme - das läßt sich dann besser wieder aufräumen.
man stow(ES)
Der FHS definiert dann was unter welchen Bedingungen wo hin gehört. Die meisten Distris sind noch dabei ihre eigenen Vorstellungen von Dateihierarchien auf den FHS anzupassen.
Deswegen sid....
Adam
On Sat Sep 01, 2001 at 11:22:41 +0200, Konrad Rosenbaum wrote:
o Debian unstable benutzen
Von Beruf Bastard Operator? ;-)
Immer mehr... ;)
Sid hat das Alias "unstable" durchaus verdient. Woody (alias "testing") ist dagegen schon ziemlich stabil.
Anhaltspunkt:
$ grep -c "name: dists/potato" woody/main/binary-i386/Packages 520 $ grep -c "name: dists/potato" sid/main/binary-i386/Packages 276
Sid ist potentiell mehr FHS kompatibel, da es weniger potato-Packages enthaelt...
Adam
Vielen Dank für eure Postings zu meiner Filesystem-Frage. Ich bin heute erst dazu gekommen mich damit zu beschäftigen und werd jetzt gleich einen Ausflug zu den FHS's unternehmen :)
Matthias
On Sat, Sep 01, 2001 at 12:59:42PM +0200, Adam Lackorzynski wrote:
Der FHS definiert dann was unter welchen Bedingungen wo hin gehört. Die meisten Distris sind noch dabei ihre eigenen Vorstellungen von Dateihierarchien auf den FHS anzupassen.
Hallo
On Sat, Sep 01, 2001 at 12:16:37AM +0200, Adam Lackorzynski wrote:
o Debian unstable benutzen
...ich bin mit meiner Slackware eigentlich zufrieden. Ist Debian 'unstable' in besonderem Maße FHS-konform oder was ist der Vorteil von Debian in dieser Sache?
Entschuldigung :) für gewöhnlich kann ich quoten bzw. denke das zu können. Wahrscheinlich war ich diesmal ein bisschen zu schnell...
Viele Grüße,
Matthias
On Wed Sep 05, 2001 at 22:36:48 +0200, Matthias Petermann wrote:
On Sat, Sep 01, 2001 at 12:16:37AM +0200, Adam Lackorzynski wrote:
o Debian unstable benutzen
...ich bin mit meiner Slackware eigentlich zufrieden. Ist Debian 'unstable' in besonderem Maße FHS-konform oder was ist der Vorteil von Debian in dieser Sache?
Debian nimmt FHS Konformitaet ziemlich ernst. Ich denke mal, dass man an sid am besten sehen kann, wie ein FHS-System aussehen soll, auch wenn es vielleicht noch nicht "perfekt" ist...
Adam
On 01.09.01 Konrad Rosenbaum (konrad.rosenbaum@t-online.de) wrote:
Moin,
/usr/local, /opt - wird von einigen Distributoren als Ablage für "Zusatzprogramme" (wie die das auch immer definieren) genutzt, ich benutze es für selbst kompilierte Programme - das läßt sich dann besser wieder aufräumen.
Moment, in der FHS steht IIRC drin, daß in einer vanilla-Installation /usr/local bis auf die Verzeichnisstruktur darin, leer sein muß.
H.
On Sunday 09 September 2001 14:40, Hilmar Preusse wrote:
Moment, in der FHS steht IIRC drin, daß in einer vanilla-Installation /usr/local bis auf die Verzeichnisstruktur darin, leer sein muß.
Stimmt. Aber man muß dazu sagen, daß da auch viel Zeug drin steht, was den Namen "Standard" nicht verdient hat, eher "Übergangslösung" oder "Ein Versuch, aus 30 Jahren Unix-Wirrwar was zu machen". >90% aller Linuxer wären sicher mehr daran interessiert, ein Gesamtkonzept für Dokumentationen etc. zu sehen, als optionale Programme wie sendmail oder traceroute darin beschrieben zu sehen, oder solche wie rwhod.
Ich denke mal, langfristig wird sich sowas wie Unified Namespaces durchsetzen (siehe reiserfs-Doku).
Was ich aber lustig finde: 5.3 /var/crash : System crash dumps (if supported) Das wäre was für Cygwin :-)
Josef Spillner
Hallo,
allgemein würde mich mal interessieren, wo ich ein gemeinsames Arbeitsverzeichnis für User einer bestimmten Gruppe anlegen kann (sollte). Muss ich dazu einen User "Public" erzeugen, diesen User in eine Gruppe "Workgroup" einordnen und sein Homeverzeich- nis für Mitglieder der "Workgroup" beschreib-/lesbar machen? Oder ist es besser z.B. in /var/fileserver/workgroup zu schreiben? Das FHS besagt ja, dass "/var" für Dateien verwendet werden soll, die vom System selbst erzeugt werden (z.B. von Programmen aus /usr/bin, weil /usr read-only ist). Indirekt würden bei meiner zweiten Version ja auch die Daten vom System geschrieben werden - vom nfsd. Die erste Version fände ich aus dem Blickwinkel der Datensicherung sinnvoller - ist sie das auch?
Matthias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 09 September 2001 14:40, Hilmar Preusse wrote:
On 01.09.01 Konrad Rosenbaum (konrad.rosenbaum@t-online.de) wrote:
/usr/local, /opt - wird von einigen Distributoren als Ablage für "Zusatzprogramme" (wie die das auch immer definieren) genutzt, ich benutze es für selbst kompilierte Programme - das läßt sich dann besser wieder aufräumen.
Moment, in der FHS steht IIRC drin, daß in einer vanilla-Installation /usr/local bis auf die Verzeichnisstruktur darin, leer sein muß.
Korrekt. Deswegen ist SuSE auf /opt ausgewichen und wartet darauf, dass ihnen jemand erklärt, was ein Standard ist... ;-)
Ich persönlich benutze /usr/local als PREFIX für alle Programme, die der Distributor nicht so compiliert hat, wie ich das gerne hätte (z.B. OpenLDAP).
Konrad
- -- BOFH excuse #143:
had to use hammer to free stuck disk drive heads.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 10 September 2001 14:56, Matthias Petermann wrote:
Hallo,
allgemein würde mich mal interessieren, wo ich ein gemeinsames Arbeitsverzeichnis für User einer bestimmten Gruppe anlegen kann (sollte). Muss ich dazu einen User "Public" erzeugen, diesen User in eine Gruppe "Workgroup" einordnen und sein Homeverzeich- nis für Mitglieder der "Workgroup" beschreib-/lesbar machen?
Soweit ich das verstanden habe ist das eine Art Home-Verzeichnis einer Gruppe. Es gehört also unter /home - einfach anlegen und der Gruppe zuordnen:
mkdir /home/mygrp chgrp mygrp /home/mygrp chmod 02770 /home/mygrp
Das chmod am Ende setzt u.A. das S-Bit für die Gruppe, damit werden alle Dateien, die dort drin landen automagisch der Gruppe mygrp zugeordnet.
Wenn Du noch willst, dass die User nur ihre eigenen Dateien manipulieren (speziell: umbenennen und löschen) können, dann setze auch das Sticky Bit (chmod +t).
Konrad
- -- The sooner our happiness together begins, the longer it will last. -- Miramanee, "The Paradise Syndrome", stardate 4842.6
lug-dd@mailman.schlittermann.de
-
Adam Lackorzynski -
Hilmar Preusse -
Josef Spillner -
konrad.rosenbaum＠t-online.de -
Matthias Petermann -
Reinhard Foerster