Daß Updates unter SuSE problematisch sind, höre ich aus dem professionellen Umfeld sehr oft, dann habe ich dieses leider selbst auch schon öfters erfahren müssen. Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt. Meine Überlegungen z.Zt. sind diese, sich mit den Distributionen - Debian und - Corel Linux (setzt auf Debain auf) anzufreunden. Bei Debian ist es möglich, wie ich mit eigenen Augen gesehen habe, im laufenden Betrieb vom Debian-FTP-Server weg ein Update zu fahren, d.h., die Maschine muß dazu nicht heruntergefahren werden. Es werden zur Übernahme lediglich betreffende Dämonen ab- und wieder angeschaltet - das ist alles! Debian soll aber nicht für den Linux-Anfänger geeignet sein!! Corel Linux hatte ich in 30Min voll am laufen, dort ist eine sehr gute HW-Erkannung vorhanden. Updatefähigkeit über Netz wie bei Debian soll bei Corel auch möglich sein. Siehe dazu das Chip-Sonderheft 4. LINUX-Ausgabe 2000 "Linux für alle", welches sich mit einer beigelegten CD ganz dem Corel Linux 1.0 widmet. Das Deasaster nach dem SuSE-Update habe ich langsam über und eine Neuinstallation kommt bei mir wegen einem kontinuierlich gewachsenenm System eh nicht so in Frage. SuSE ist zwar Klasse mit der Eindeutschung für den normalen User sowie seinem ausführlichen Installationshandbuch. Bei UNIX/LINUX ist tiefer in den Admin-Gefilden sowieso dann alles auf Englisch. Linux möchte ich gerne so lange betreiben, wie ich lebe...! Also ist der Anspruch nach einem soliden Update sehr stark! Hat vielleicht jemand anderer so noch Erfahrung zum Thema Linux-Update im Distributionsumfeld SuSE, Debian und Corel Linux?? Schöne Grüße Christoph Walther Email: mailto:christoph.walther@telekom.de -----Ursprüngliche Nachricht----- Von: Illuminatus@t-online.de [mailto:Illuminatus@t-online.de] Gesendet am: Donnerstag, 6. April 2000 23:03 An: suse-users Betreff: Re: SuSE 6.4: eine Katastrophe Thomas Mueller wrote:
Hallo!
Ich habe heute den Fehler gemacht auf SuSE 6.4 (von 6.2) upzudaten, seither tut nichts mehr.
Beim Update habe ich YaST2 ausgewaehlt der dann abgestuerzt ist, stattdessen kam YaST1 hoch, der Teil war noch in Ordnung.
[...] Hi, als Du Dich fuer ein Update anstatt einer Neuinstallation entschieden hast, war Dir klar dass das nicht reibungslos sein kann?
Netscape laesst sich nicht starten: tmm@bandit:~ > netscape Bus-Zugriffsfehler
Siehe Thread in der Liste.. Vorgänger installieren.
Der MidnightCommander genauso wenig: Speicherzugriffsfehler Ich habe testweise die aktuellste Version gezogen und kompiliert: selbes Ergebnis.
Hmm, ja damit hatte ich auch ein Problem. Schau mal nach, ob unter /usr/share/terminfo/l ein file namens linux ist. Wenn nein, dann mach folgendes: Als root einloggen.. tic -v /usr/lib/mc/term/linux.ti ..ausfuehren.
xawtv (der uebrigends nur in einer uralt Version vorhanden ist) findet libjpeg.so.6 nicht, obwohl "locate" diese in /usr/lib findet (ldconfig habe ich schon laufen lassen).
Dass meine conf.modules ersetzt wurde und daher nach einem reboot nichts mehr lief oder aehnliches geht noch, das liess sich beheben durch ersetzen der SuSE Dateien durch meine alten Versionen.
Naja, wie gesagt, wenn Du solche Probleme nicht haben willst, darfst Du kein Update machen. Es ist uebrigens _nicht_ die beste Art, einfach die alte datei drüberzubügeln. Unter Umstaenden gehen Dir dadurch neue "Features" verloren. Z.B /etc/httpd/httpd.conf oder ISDN, da hat sich einiges verändert. Ich habe sowohl ein Update wie auch eine Neuinstallation mit 6.4 durchgefuehrt. Beim Update waren etliche Dinge, wie Du sie hier auch beschreibst, das war mir vorher klar ;-). Die Neuinstallation war absolut problemlos. o long... bernd --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 07-Apr-2000 Walther, Christoph wrote:
Daß Updates unter SuSE problematisch sind, höre ich aus dem professionellen Umfeld sehr oft, dann habe ich dieses leider selbst auch schon öfters erfahren müssen.
Leider muß ich das zum Teil bestätigen. Genau aus diesen Gründen mache auch ich kein Update mehr. Ich sehe zu, das ch so weit wie möglich meine Konfiguration sichere und dann eine Neuinstallation mache. Ich möchte hier jetzt nicht behaupten, das ein Update grundsätzlich mit Suse nicht funktioniert. Es sind nur meine Erfahrungen. Teilweise hatten wir Effekte nach einem Update, die erst etwas später aufgefallen sind. Nach einer Neinstallation waren sie dann verschwunden. Also, keine Updates mehr.
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt. Meine Überlegungen z.Zt. sind diese, sich mit den Distributionen
- Debian und - Corel Linux (setzt auf Debain auf)
anzufreunden.
Mag ein gangbarer Weg sein, habe ich aber noch nicht geprüft. Wenn meine Auslastung etwas zurückgeht werde ich mich aber auch damit beschäftigen und diese Sachen prüfen
Linux möchte ich gerne so lange betreiben, wie ich lebe...!
Dito. Ausserdem habe ich keine Lust unsere Server dauern umzustellen:-) -- mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
----- Original Message -----
From: Peter Kuechler
On 07-Apr-2000 Walther, Christoph wrote:
Daß Updates unter SuSE problematisch sind, höre ich aus dem professionellen Umfeld sehr oft, dann habe ich dieses leider selbst auch schon öfters erfahren müssen.
Leider muß ich das zum Teil bestätigen. Genau aus diesen Gründen mache auch ich kein Update mehr. Ich sehe zu, das ch so weit wie möglich meine Konfiguration sichere und dann eine Neuinstallation mache.
Ich möchte hier jetzt nicht behaupten, das ein Update grundsätzlich mit Suse nicht funktioniert. Es sind nur meine Erfahrungen. Teilweise hatten wir Effekte nach einem Update, die erst etwas später aufgefallen sind. Nach einer Neinstallation waren sie dann verschwunden.
Also, keine Updates mehr.
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt. Meine Überlegungen z.Zt. sind diese, sich mit den Distributionen
- Debian und - Corel Linux (setzt auf Debain auf)
anzufreunden.
Mag ein gangbarer Weg sein, habe ich aber noch nicht geprüft. Wenn meine Auslastung etwas zurückgeht werde ich mich aber auch damit beschäftigen und diese Sachen prüfen
Linux möchte ich gerne so lange betreiben, wie ich lebe...!
Dito. Ausserdem habe ich keine Lust unsere Server dauern umzustellen:-)
mfg Peter Küchler Registrierter Linux-User #127408
Es ist auch schade das kaum neue Versionen der Pakete für ältere Distributionen verfügbar sind und man wegen dauernden Wechsels der libc neue Pakete nicht verwenden kann. Klar ich kann mir aus den Quellen die neue Version bauen aber ich persönlich halte nichts davon z.B. einen Compiler mit einer Vorgängerversion des selben Compilers auf der gleichen Architektur zu bauen. mfg Martin Schreiber --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Das Deasaster nach dem SuSE-Update habe ich langsam über und eine
Tja, so unterschiedlich können die Erfahrungen sein. Ich habe mit Slackware angefangen und verwende SuSE seit der 4.0. Und mit den Upgrades hatte ich nie sonderliche Probleme, zumindest seit SuSE rpm verwendet und bestehende Konfigurationen gesichert werden. Desaster habe ich nie erlebt, zumindest keine, die nicht auf meine eigene Dummheit zurückzuführen waren.
Also ist der Anspruch nach einem soliden Update sehr stark!
Den haben wir auch, nur so nebenbei. Und das bisherige Feedback lässt darauf
schliessen, dass uns das auch einigermassen gut gelingt. Und das Feedback
kommt auch aus dem von dir angeführten professionellen Umfeld.
Klar ist auch bei uns nicht alles fehlerfrei, zumal bei dem Umfang unserer
Distribution. Corel hat es da schon leichter, einfach wegen des geringeren
Umfangs.
Philipp
--
Philipp Thomas
Hallo alle zusammen! Ich wollte hier mal eine Stange brechen fuer die SuSE, insbesondere die 6.4! Ich benutze SuSE schon, seit der Zeit, als man sich normalerweise Linux noch auf 40 Disketten verteilt vom Netz zog. Ich hatte davor die DLD (die es mittlerweile praktisch nicht mehr gibt) und bin dann irgendwann umgestiegen. Hin und wieder d /********************************************\ * * * Oliver Tennert * * * * +49 -7071 -9457-598 * * * * e-mail: O.Tennert@science-computing.de * * science + computing GmbH * * Hagellocher Weg 71 * * D-72070 Tuebingen * * * \********************************************/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Fri, 7 Apr 2000, Oliver.Tennert wrote:
Hallo alle zusammen!
Ich wollte hier mal eine Stange brechen fuer die SuSE, insbesondere die 6.4! Ich benutze SuSE schon, seit der Zeit, als man sich normalerweise Linux noch auf 40 Disketten verteilt vom Netz zog. Ich hatte davor die DLD (die es mittlerweile praktisch nicht mehr gibt) und bin dann irgendwann umgestiegen. Hin und wieder d
Hoppla, irgendwie muss ich auf "Send" gekommen sein. Naja, wie dem auch sei, was ich eigentlich sagen wollte: Probleme, die ich hin und wieder mit Installationen von SuSE hatte, waren meist eher kleinerer Natur und durch Behebung serselben habe ich einiges an UNIX dazugelernt. Aber man sollte unterscheiden zwischen a) Probleme augrund fehlerhafter Konfiguration (kann mal vorkommen, auch wenn's bloed ist) b) Probleme aufgrund fehlerhafter Software: da kann natuerlich SuSE nichts dafuer. Umso erfreulicher und bewundernswerter allerdings, dass SuSE sich die Muehe macht, hin und wieder mal selbst Hand anzulegen bei der Software. Ich sage nur: XF86, ISDN, ReiserFS. Und das bei einem Jahren stabilen Preis, das darf man naemlich nicht ausser Acht lassen. Bevor hier einige Leute halb ausrasten, weil bei Ihnen nix laeuft, sollten diese vielleicht mal so langsam anfangen, sich etwas weiterzubilden, um mitreden zu koennen und nicht wegen jedem Fehler gleich das Forum zusammenzuschreien. Ich kann natuerlich nur fuer mich sprechen: bei mir laeuft SuSE 6.4 einwandfrei, und ich verwende kwintv/NFS/ReiserFS/KDE, alles vermeintliche Problemkinder. Trotzdem tut's und ich habe nix rumkonfigurieren muessen. Vielleicht lassen andere da erst mal einen Quick-Hack rueberlaufen, der alles vermurkst? Ausserdem sollte dieses Forum zur Problemloesung da sein und nicht um Frust abzulassen! Wer Probleme hat, sollte sie hier stellen koennen, und wer eine Antwort weiss, darf sie posten. Fuer psychische Probleme wie Abreaktionen ist der Psychologe da! Nicht dass es hier noch eine Schlaegerei im Forum gibt! Gruss Oli /********************************************\ * * * Oliver Tennert * * * * +49 -7071 -9457-598 * * * * e-mail: O.Tennert@science-computing.de * * science + computing GmbH * * Hagellocher Weg 71 * * D-72070 Tuebingen * * * \********************************************/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Das Deasaster nach dem SuSE-Update habe ich langsam über und eine
Tja, so unterschiedlich können die Erfahrungen sein. Ich habe mit Slackware angefangen und verwende SuSE seit der 4.0. Und mit den Upgrades hatte ich nie sonderliche Probleme, zumindest seit SuSE rpm verwendet und bestehende Konfigurationen gesichert werden. Desaster habe ich nie erlebt, zumindest keine, die nicht auf meine eigene Dummheit zurückzuführen waren.
Nicht immer, aber bestimmt immer öfter ;) Meine updates sind auch alle recht gut verlaufen. .....auch wenn ein wenig "Handarbeit" angesagt war. Gruß, Clemens -- sig_44 locate oder:Wo ist das file ??? [Info: man locate] locate durchsucht die locate-Datenbank. $ updatedb erstellt die DB neu (als root) $ locate fstab findet alle fstab-files $ locate "*fstab" findet die fstab ;-) --------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Nein. Nach FHS gehört es auf keinen Fall nach /etc. /sbin/init.d enthält ausführbare Scripte, die definitiv keine Konfigurationsdateien sind. Laut FHS darf aber unter /etc nichts ausführbares liegen, sondern nur Konfigurationsdateien. Korrekt nach FHS wäre wahrscheinlich die Lösung, die ich schon mal auf einem kommerziellen Unix gesehen habe: /sbin/rc.d enthält die Scripte, /etc/rc?.d enthält die Links für die Run-Level. LSB schweigt sich zu diesem Thema noch aus. Da es im FHS nicht dokumentiert ist, fehlt es den Leuten an Argumenten, was richtig ist. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Nein. Nach FHS gehört es auf keinen Fall nach /etc.
Könntest Du das bitte ausführen. Ich halte das für eine bestreitbare Behauptung, da der FHS dies nach meinem Verständnis nicht in dieser Bestimmtheit ausdrückt: <FHS> 3.4 /etc : Host-specific system configuration /etc contains configuration files and directories that are specific to the current system. No binaries should be located under /etc. [..] Notes: The setup of command scripts invoked at boot time may resemble System V or BSD models. Further specification in this area may be added to a future version of this standard. </FHS> Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
/sbin/init.d enthält ausführbare Scripte, die definitiv keine Konfigurationsdateien sind.
Auch dies würde ich nicht in dieser Bestimmtheit ausdrücken. * Das Vorhandensein eines /sbin/init.d/<runlevel>/* Skripts stellt in gewissem Sinne eine Konfiguration dar. * Bootscripte Skripte können lokale Anpassungen (Konfiguration) erfordern (insb. boot.local/halt.local, boot/*). * /sbin/init.d/* sind in der Regel "Executables", jedoch keine "Binaries". * Der FHS sagt "should be", im Sinne einer "nachdrücklichen Empfehlung", aber nicht "must" oder "mandates" o.ä.
Laut FHS darf aber unter /etc nichts ausführbares liegen, sondern nur Konfigurationsdateien. Siehe oben, der FHS spricht von "Binaries" und nicht aber von "Executables".
Doch wenn man "Binaries" mit "ausführbaren Dateien" gleichsetzt, so ist SuSE nicht konsequent. Selbst unter 6.4 enthält /etc/* immer noch "ausführbare Dateien" (z.B.: /etc/filesystems), von "ausführbaren Dateien" unter /etc/*/* (z.B. /etc/cron.d/*, /etc/pppd/*) mal ganz zu schweigen.
Korrekt nach FHS wäre wahrscheinlich die Lösung, die ich schon mal auf einem kommerziellen Unix gesehen habe: /sbin/rc.d enthält die Scripte, /etc/rc?.d enthält die Links für die Run-Level. Soweit ich den FHS verstehe, dürfte dies im Sinne der FHS-Autoren sein (In meinem Verständnis stellt das Vorhandensein eines Runlevel-Links eine Konfiguration dar).
LSB schweigt sich zu diesem Thema noch aus. Da es im FHS nicht dokumentiert ist, fehlt es den Leuten an Argumenten, was richtig ist.
Lass es mich mal so ausdrücken, /sbin/init.d steht sicher nicht im Widerspruch zum FHS. --- Andererseits hält sich SuSE nicht an den FHS an Stellen, an denen der FHS eindeutig ist, z.B. /usr/share: /usr/share/doc statt /usr/doc /usr/share/dict statt /usr/dict usw. [Soweit ich sehe, scheint Euch dies bewußt zu sein, da seit 6.4 /usr/share/man statt /usr/man verwendet wird - Interessanterweise wurde /usr/man aber nicht eliminiert.] Gruss Ralf. -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
----- Original Message -----
From: "Ralf Corsepius"
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407
12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX
Standard gibt
es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Nein. Nach FHS gehört es auf keinen Fall nach /etc.
Könntest Du das bitte ausführen.
[und so weiter...] Also Leute, Linux ist doch ein wunderbares Betriebssystem. Statt hier kilobyteweise Text zu schreiben reicht doch ein kleiner "ln" und schon findet ihr die "Konfigurations-Boot-Executables" (auch) unter /etc. -- Marco Dieckhoff, der *diese* Diskussionen noch weniger als die Bitte, am 30. April nicht zu tanken, versteht... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Ralf Corsepius schrieb am 10.Apr.2000:
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Wieso gehört /sbin/init.d/* zur boot time? Das gilt doch nur für /sbin/init.d/boot und /sbin/init.d/boot.local. Die übrigen Dateien sind doch bei jedem Runlevelwechsel von Interesse. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Nein. Nach FHS gehört es auf keinen Fall nach /etc.
Könntest Du das bitte ausführen.
Habe ich.
Ich halte das für eine bestreitbare Behauptung, da der FHS dies nach meinem Verständnis nicht in dieser Bestimmtheit ausdrückt:
Wenn es der FHS Festlegen würde, warum tut sich dann LSB so schwer, eine Begründung für oder gegen init Skripte in /etc/ zu finden ?
<FHS> 3.4 /etc : Host-specific system configuration
/etc contains configuration files and directories that are specific to the current system.
No binaries should be located under /etc. [..] Notes:
The setup of command scripts invoked at boot time may resemble System V or BSD models. Further specification in this area may be added to a future version of this standard. </FHS>
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Genau. Und es steht dort auch nicht, das es erlaubt ist.
/sbin/init.d enthält ausführbare Scripte, die definitiv keine Konfigurationsdateien sind.
Auch dies würde ich nicht in dieser Bestimmtheit ausdrücken.
Doch. Definitiv. Du editierst nicht die Scripte, umd Deine Konfiguration zu ändern. Du editierst die Links oder die Variablen in /etc/rc.config.
* Das Vorhandensein eines /sbin/init.d/<runlevel>/* Skripts stellt in gewissem Sinne eine Konfiguration dar.
Ja, habe ich ja weiter unter gesagt.
* Bootscripte Skripte können lokale Anpassungen (Konfiguration) erfordern (insb. boot.local/halt.local, boot/*).
Ja, trotzdem bleiben es ausführbare Dateien.
* /sbin/init.d/* sind in der Regel "Executables", jedoch keine "Binaries".
Diese Unterscheidung würde ich nicht machen. Im ganzen FHS wird meines Wissens nach nicht explizit von Scripten gesprochen, sondern immer nur von "Binaries".
* Der FHS sagt "should be", im Sinne einer "nachdrücklichen Empfehlung", aber nicht "must" oder "mandates" o.ä.
Eben, im Sinne einer "nachdrücklichen Empfehlung", an die wir uns halten. Also folgen wir damit dem FHS.
Laut FHS darf aber unter /etc nichts ausführbares liegen, sondern nur Konfigurationsdateien. Siehe oben, der FHS spricht von "Binaries" und nicht aber von "Executables".
Ja, der FHS spricht nie explizit von Scripten. Er spricht immer nur von Binaries. Nach Deiner Argumentation darfst Du auch keine Scripte in /bin, /usr/bin oder sonsteinem bin Verzeichnis haben, weil es heißt für diese Verzeichnisse immer "für Binaries".
Doch wenn man "Binaries" mit "ausführbaren Dateien" gleichsetzt, so ist SuSE nicht konsequent. Selbst unter 6.4 enthält /etc/* immer noch "ausführbare Dateien" (z.B.: /etc/filesystems), von "ausführbaren Dateien" unter /etc/*/* (z.B.
^^^^^^^^^^^^^^^^^^ # dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems Wo ist das ausführbar ?
/etc/cron.d/*, /etc/pppd/*) mal ganz zu schweigen.
Ja, darüber könnte man sich unterhalten.
Korrekt nach FHS wäre wahrscheinlich die Lösung, die ich schon mal auf einem kommerziellen Unix gesehen habe: /sbin/rc.d enthält die Scripte, /etc/rc?.d enthält die Links für die Run-Level. Soweit ich den FHS verstehe, dürfte dies im Sinne der FHS-Autoren sein (In meinem Verständnis stellt das Vorhandensein eines Runlevel-Links eine Konfiguration dar).
LSB schweigt sich zu diesem Thema noch aus. Da es im FHS nicht dokumentiert ist, fehlt es den Leuten an Argumenten, was richtig ist.
Lass es mich mal so ausdrücken, /sbin/init.d steht sicher nicht im Widerspruch zum FHS.
---
Andererseits hält sich SuSE nicht an den FHS an Stellen, an denen der FHS eindeutig ist, z.B. /usr/share: /usr/share/doc statt /usr/doc
Darüber kann man sich wieder streiten. /usr/share/doc enthählt laut FHS Dokumentation, die Architekturunabhängig ist. Dieses gilt für unsere Dokumentation dort nicht. Aber ich stimme Dir bei, das, um den FHS voll zu erfüllen (was wir noch nicht machen und was wir ja auch nicht behaupten), dieses Verzeichnis verschoben werden sollte.
/usr/share/dict statt /usr/dict
? /usr/dict ist FHS conform ein Link auf /usr/share/dict. Wo ist das Problem ?
usw.
Was usw. ? Wenn Du schon Behauptungen aufstellst, dann belege Sie auch. Dann kÖnnen wir das zur nächsten Release ändern.
[Soweit ich sehe, scheint Euch dies bewußt zu sein, da seit 6.4 /usr/share/man statt /usr/man verwendet wird - Interessanterweise wurde /usr/man aber nicht eliminiert.]
/usr/share/man wird schon seit 6.2 benutzt. Es dauert nur 1800 Pakete umzustellen. Leider kann RPM den move /usr/man -> /usr/share/man nicht gescheit handeln, weswegen z.B. Red Hat diese Änderung im FHS gerne wieder Rückgängig gemacht hätte. Wir haben uns deswegen entschieden, die alten Verzeichnisse zu lassen, damit es beim Update und bei der Installation von Paketen, die /usr/man benutzen, keine Probleme mit RPM gibt. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thorsten Kukuk wrote:
On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
[..]
Doch wenn man "Binaries" mit "ausführbaren Dateien" gleichsetzt, so ist SuSE nicht konsequent. Selbst unter 6.4 enthält /etc/* immer noch "ausführbare Dateien" (z.B.: /etc/filesystems), von "ausführbaren Dateien" unter /etc/*/* (z.B.
^^^^^^^^^^^^^^^^^^ # dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems
Wo ist das ausführbar ?
So ist es auf meiner SuSE-6.4 CD enthalten: # rm -f /etc/filesystems # mount /cdrom # rpm --force -i /cdrom/suse/a1/util.rpm # ls -l /etc/filesystems -rwxr-xr-x 1 root root 24 Mar 11 11:49 /etc/filesystems # rpm -q -p /cdrom/suse/a1/util.rpm util-2.10f-24 Andere ausführbare Dateien, die ich hier auf unter /etc/* finde: /etc/my.cnf # rpm -q -f /etc/my.cnf mysql-3.22.32-7 /etc/mysqlaccess.conf # rpm -q -f /etc/mysqlaccess.conf mysqclnt-3.22.32-7 /etc/auto.net # rpm -q -f /etc/auto.net autofs-4.0.0pre6-10
Aber ich stimme Dir bei, das, um den FHS voll zu erfüllen (was wir noch nicht machen und was wir ja auch nicht behaupten), dieses Verzeichnis verschoben werden sollte.
Habe ich hoffentlich auch nie behauptet. Ihr seit eindeutig auf dem Weg dorthin, doch mit /sbin/init.d habe ich meine Probleme - wie andere offensichtlich auch -- sonst wäre /sbin/init.d weiter verbreitet. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thorsten Kukuk schrieb am 11.04.00 um 16.04 Uhr Hallo, ich möchte hier nochmal kurz nachhaken. Betreff /usr/man /usr/local/man.
On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Ich halte das für eine bestreitbare Behauptung, da der FHS dies nach meinem Verständnis nicht in dieser Bestimmtheit ausdrückt:
Wenn es der FHS Festlegen würde, warum tut sich dann LSB so schwer, eine Begründung für oder gegen init Skripte in /etc/ zu finden ?
Debian hat die bootscripte unter /etc. Nicht nur die, und ich hab da noch keinerlei Prob. mit gehabt. Ausser die dauernde Umdenkerei ;)
</FHS>
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Genau. Und es steht dort auch nicht, das es erlaubt ist.
Aber auch nicht das es verboten ist. /etc sollte wirklich für alle konfig-files dienen. Für die Zukunft eine clevere Überlegung Wert. Cron und ip-up usw sollte auch unter /etc bleiben. Da sind sie ja nun fast bei jeder Distri. (?)
* /sbin/init.d/* sind in der Regel "Executables", jedoch keine "Binaries".
Dann müßte ja noch was anderes herhalten, denn eigene scripte gehören nunmal nach /usr/local/bin....() Zumindest sehe ich das so. Alles was nicht zur Distri gehört/selber kompiliert und geschrieben wird, kommt bei mir, nach /usr/local.
# dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems
Wo ist das ausführbar ?
Also, nach Update auf 6.4 war bei mir dieses file auch ausführbar :-/
[Soweit ich sehe, scheint Euch dies bewußt zu sein, da seit 6.4 /usr/share/man statt /usr/man verwendet wird - Interessanterweise wurde /usr/man aber nicht eliminiert.]
Tatsache ist, dass ich immernoch zwei folder alla /man hab. Kann ich die /usr/man nicht einfach (liegt noch teilweise was drinn) nach /usr/share/man verschieben??
/usr/share/man wird schon seit 6.2 benutzt. Es dauert nur 1800 Pakete umzustellen. Leider kann RPM den move /usr/man -> /usr/share/man nicht gescheit handeln, weswegen z.B. Red Hat diese Änderung im FHS gerne wieder Rückgängig gemacht hätte. Wir haben uns deswegen entschieden, die alten Verzeichnisse zu lassen, damit es beim Update und bei der Installation von Paketen, die /usr/man benutzen, keine Probleme mit RPM gibt.
Genau deshalb ist ein wenig Chaos bei mir in Sachen manpages. Die eigens kompilierten sind in /usr/local/man, dass ist auch OK so. Aber was tun mit /usr/man? Für "verkehrte" RPM's stehen lassen? Oder nach /usr/share/man moven? Gruß, Clemens PS: Wo gerade mehrere SuSEMitarbeiter mitlesen: Könntet ihr bitte einen gewissen PETER MÜLLER abbestellen?? Seine Mailbox scheint voll und ich bekomme ohne Ende echomails :-/ -- sig_33 Ausgabe der aktuellen routing-tabelle: $ route -n [Info: man route ] $ netstat -rn [Info: man netstat] X-page:http://www.ndh.net/home/wohld/index.html ----------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Clemens Wohld schrieb am 11.Apr.2000:
Thorsten Kukuk schrieb am 11.04.00 um 16.04 Uhr
On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Ich halte das für eine bestreitbare Behauptung, da der FHS dies nach meinem Verständnis nicht in dieser Bestimmtheit ausdrückt:
Wenn es der FHS Festlegen würde, warum tut sich dann LSB so schwer, eine Begründung für oder gegen init Skripte in /etc/ zu finden ?
Vielleicht, weil es SuSE in /sbin macht und die meisten (alle?) anderen in /etc. Solche Regeln legen doch keine graue Herrn fernab von jeder Realität fest. Die schauen doch, was es gibt und versuchen zu vereinheitlichen. Wenn das eine irgendwie "logischer" als das Andere ist, so wird dies genommen. Aber die bootskripte haben nirgends einen richtigen Platz. Sie sind bei /sbin fehl am Platz und bei /etc auch. Bei /sbin sind sie es, weil sie nur beim Runlevelwechsel benötigt werden und bei /etc sind sie es, weil es Executables sind. Bei /boot wären sie übrigens auch völlig fehl am Platz, weil da nur Sachen stehen sollten, die gebraucht werden _bevor_ ein Dateisystem eingerichtet ist und nur über ihre Hardwareadresse zugegriffen werden kann. Unmittelbar unter / ist aber auch abzulehenen, da es da schon zu viele Verzeichnisse gibt. Ich sehe da auch keine "vernünftige" Lösung.
Debian hat die bootscripte unter /etc. Nicht nur die, und ich hab da noch keinerlei Prob. mit gehabt. Ausser die dauernde Umdenkerei ;)
Nein, Probleme natürlich nicht. Bei SuSE habe ich auch keine Probleme und bei den alten UNIXe die überhaupt kein /sbin hatten, sondern alles was in /sbin steht in /etc stand (oder im /bin) hatte ich auch keine Probleme mit, außer daß /etc noch unübersichtlicher ist als es jetzt schon ist.
</FHS>
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Genau. Und es steht dort auch nicht, das es erlaubt ist.
Aber auch nicht das es verboten ist.
Nein, wohl nicht. Wie gesagt, die wollen es sich mit keinem verderben.
/etc sollte wirklich für alle konfig-files dienen.
Sind die bootskripte Konfigfiles? An den Skripten, die direkt unter /sbin/init.d stehen sollte doch nicht rumgebastelt werden. /sbin/init.d/boot und /sbin/init.d/boot.local ist da was anderes und die Links auch.
Für die Zukunft eine clevere Überlegung Wert.
Vielleicht auf die Dinger ganz verzichten und alles direkt in der /etc/inittab schreiben? SCNR
Cron und ip-up usw sollte auch unter /etc bleiben. Da sind sie ja nun fast bei jeder Distri. (?)
Man sollte auch die kommerzielle UNIXe nicht außer Betracht lassen. Ich weiß aber nicht, wie die es machen.
* /sbin/init.d/* sind in der Regel "Executables", jedoch keine "Binaries".
Dann müßte ja noch was anderes herhalten, denn eigene scripte gehören nunmal nach /usr/local/bin....() Zumindest sehe ich das so. Alles was nicht zur Distri gehört/selber kompiliert und geschrieben wird, kommt bei mir, nach /usr/local.
Außer das, was schon zur boottime vorhanden sein muß. /etc/profile.local ist sicher selber geschrieben, ich würde es aber trotzdem nicht unter /usr/local legen. Es gibt ja auch kein /usr/local/etc.
# dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems
Wo ist das ausführbar ?
Also, nach Update auf 6.4 war bei mir dieses file auch ausführbar :-/
Mit chmod a+x machst Du so gut wie alles ausführbar. ;))
PS: Wo gerade mehrere SuSEMitarbeiter mitlesen: Könntet ihr bitte einen gewissen PETER MÜLLER abbestellen?? Seine Mailbox scheint voll und ich bekomme ohne Ende echomails :-/
Schreib soetwas doch am Owner, ich glaube nicht, daß alle SuSE-Mitarbeiter in ein, zwei Büros in Nürnberg sitzen. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Wed, Apr 12, Bernd Brodesser wrote:
PS: Wo gerade mehrere SuSEMitarbeiter mitlesen: Könntet ihr bitte einen gewissen PETER MÜLLER abbestellen?? Seine Mailbox scheint voll und ich bekomme ohne Ende echomails :-/
Schreib soetwas doch am Owner, ich glaube nicht, daß alle SuSE-Mitarbeiter in ein, zwei Büros in Nürnberg sitzen.
Die sitzen noch nicht einmal in einem Gebäude in Nürnberg ;) Abgesehen davon, das die Liste über suse.com läuft und nicht über suse.de. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mit, Apr 12, 2000 at 12:24:15 +0200, Bernd Brodesser wrote: [cron und ip-up]
Man sollte auch die kommerzielle UNIXe nicht außer Betracht lassen. Ich weiß aber nicht, wie die es machen.
cron-Konfiguration: /var/spool/cron/crontabs (SINIX 5.4x) z. B., bei HP-UX war das IIRC /usr/spool/cron/crontabs. [eigene Scripts nach /usr/local]
Außer das, was schon zur boottime vorhanden sein muß. /etc/profile.local ist sicher selber geschrieben, ich würde es aber trotzdem nicht unter /usr/local legen.
Es gibt ja auch kein /usr/local/etc.
Das wäre auch oft tödlich - wenn nämlich /usr ein eigenes FS hat. Dann fehlen da auf einmal etliche benötigte Sripts - oops. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Jan Trippler schrieb am 12.Apr.2000:
On Mit, Apr 12, 2000 at 12:24:15 +0200, Bernd Brodesser wrote:
[cron und ip-up]
Man sollte auch die kommerzielle UNIXe nicht außer Betracht lassen. Ich weiß aber nicht, wie die es machen.
cron-Konfiguration: /var/spool/cron/crontabs (SINIX 5.4x) z. B., bei HP-UX war das IIRC /usr/spool/cron/crontabs.
Ja, die haben oder hatten gar kein /var. Ursprünglich gab es weder /var noch /home noch /opt. Das war alles mit bei /usr bei. Und /sbin bei /etc. Und /root gabs auch nicht. Alles darin war direkt unter /.
[eigene Scripts nach /usr/local]
Außer das, was schon zur boottime vorhanden sein muß. /etc/profile.local ist sicher selber geschrieben, ich würde es aber trotzdem nicht unter /usr/local legen.
Es gibt ja auch kein /usr/local/etc.
Das wäre auch oft tödlich - wenn nämlich /usr ein eigenes FS hat. Dann fehlen da auf einmal etliche benötigte Sripts - oops.
Mein reden. Andererseits sind in /usr/local nur Sachen, die es zur bootzeit noch nicht geben muß. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: file://usr/doc/susehilf/index.html | mit Apache: http://localhost/doc/susehilf/index.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Bernd Brodesser schrieb am 12.04.00 um 22.04 Uhr
* Clemens Wohld schrieb am 11.Apr.2000:
Thorsten Kukuk schrieb am 11.04.00 um 16.04 Uhr
On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Wenn es der FHS Festlegen würde, warum tut sich dann LSB so schwer, eine Begründung für oder gegen init Skripte in /etc/ zu finden ?
Vielleicht, weil es SuSE in /sbin macht und die meisten (alle?) anderen in /etc. Solche Regeln legen doch keine graue Herrn fernab von jeder Realität fest. Die schauen doch, was es gibt und versuchen zu vereinheitlichen. Wenn das eine irgendwie "logischer" als das Andere ist, so wird dies genommen. Aber die bootskripte haben nirgends einen richtigen Platz. Sie sind bei /sbin fehl am Platz und bei /etc auch. Bei /sbin sind sie es, weil sie nur beim Runlevelwechsel benötigt werden und bei /etc sind sie es, weil es Executables sind.
Sorry, aber ich bin der Meinung das die rc.d-cripte nach /etc gehören. So bin ich es auch vonm anderen Distris gewohnt. Aussere SuSE,...aber anyway.
Ich sehe da auch keine "vernünftige" Lösung.
AFAIK ist /etc vernünftig.
Debian hat die bootscripte unter /etc. Nicht nur die, und ich hab da noch keinerlei Prob. mit gehabt. Ausser die dauernde Umdenkerei ;)
Nein, Probleme natürlich nicht. Bei SuSE habe ich auch keine Probleme und bei den alten UNIXe die überhaupt kein /sbin hatten, sondern alles was in /sbin steht in /etc stand (oder im /bin) hatte ich auch keine Probleme mit, außer daß /etc noch unübersichtlicher ist als es jetzt schon ist.
Kommt auf die Distri an die du jetzt mit Unübersichtlich meinst :-/
</FHS>
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Genau. Und es steht dort auch nicht, das es erlaubt ist.
Aber auch nicht das es verboten ist.
/etc sollte wirklich für alle konfig-files dienen.
Sind die bootskripte Konfigfiles?
Ich rede hier nicht mehr von bootscripten, sondern Konfig-files!
Für die Zukunft eine clevere Überlegung Wert.
Vielleicht auf die Dinger ganz verzichten und alles direkt in der /etc/inittab schreiben? SCNR
??? Lass man die sind schon sehr gut so zu händeln.
Zumindest sehe ich das so. Alles was nicht zur Distri gehört/selber kompiliert und geschrieben wird, kommt bei mir, nach /usr/local.
Außer das, was schon zur boottime vorhanden sein muß. /etc/profile.local ist sicher selber geschrieben, ich würde es aber trotzdem nicht unter /usr/local legen.
Ist profile_local ein Prog, tool oder ausführbares script? Also /etc.
Es gibt ja auch kein /usr/local/etc.
Wäre ja noch schöner, obwohl durchaus denkbar.
# dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems
Wo ist das ausführbar ?
Also, nach Update auf 6.4 war bei mir dieses file auch ausführbar :-/
Mit chmod a+x machst Du so gut wie alles ausführbar. ;))
Ich meine zu wissen wann ich als root ein chmod setze :-/ Und wenn ich meine nach update, meine ich nach Update lag dieses script ausführbar unter /etc.
PS: Wo gerade mehrere SuSEMitarbeiter mitlesen: Könntet ihr bitte einen gewissen PETER MÜLLER abbestellen?? Seine Mailbox scheint voll und ich bekomme ohne Ende echomails :-/
Schreib soetwas doch am Owner, ich glaube nicht, daß alle SuSE-Mitarbeiter in ein, zwei Büros in Nürnberg sitzen.
Wenn ich von Reaktion überzeugt wäre schon....... Aber der account ist noch nicht bekannt, also eh zwecklos :( Bei mir sind es jetzt auch schon 3 versch. accounts. Der suse fetchmaildaemon usw. ÄTZEN! Gruß, Clemens -- sig_17 "Sometimes the best medicine is to stop taking something." [http://www.ndh.net/home/wohld/indexhtml] [cwohld@ndh.net] ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Wed, Apr 12, 2000 Bernd Brodesser wrote: hi, [...]
richtigen Platz. Sie sind bei /sbin fehl am Platz und bei /etc auch. Bei /sbin sind sie es, weil sie nur beim Runlevelwechsel benötigt werden und bei /etc sind sie es, weil es Executables sind. [...]
das argument, weshalb die scripte in /sbin fehl am platz sin, versteh ich nicht. wie genau definiert denn der Linux Filesystem Standard /sbin, dass zum runlevel benötigte executables da nicht hingehören? und...wo gibts den Filesystem Standard im netz? (oder wars File Hierarchy Standard? ich mein beides schonmal gehört zu haben...) [...]
Ich sehe da auch keine "vernünftige" Lösung.
hmm, wie wäre es mit sowas wie /init? </lautdenk> ...ich weiss, dass man durch definieren dieses pfades alle standards übern haufen werfen würde. aber, diese frage des pfades der boot scripte, was sagt da der Filesystem Standard zu? vielleicht wird da eine neue, richtige und "vernünftige" lösung benötigt? [...]
Sind die bootskripte Konfigfiles? An den Skripten, die direkt unter /sbin/init.d stehen sollte doch nicht rumgebastelt werden.
also, ich persönlich find das eleganter, die befehle mit den parametern direkt diese scripte zu schreiben als irgendwelche anderen config files zu 'source'n. denn dann müsste man alle möglichen fälle in den scripten berücksichtigen und die scripte werden 3mal so gross als wenn man einfach nur die entsprechenden befehle reinschreibt. daher müsste ich schon z.b. /sbin/init.d/i4l editieren, wenn ich andere einstellungen brauch. [...]
Es gibt ja auch kein /usr/local/etc.
also, ich hab hier ein /usr/local/etc und da ist einiges drinne. z.b. eine systemweite muttrc, fvwm2rc. die proftpd und wine config und diverse andere. das find ich auch logisch: selbstkompilierte software soll das _prefix_ /usr/local haben. daraus folgt: executables nach prefix/bin und config files nach prefix/etc, usw.... -moritz -- Moritz Schulte - hp9001.fh-bielefeld.de/~moritz/, PGP Key available| ---- Zufallssignatur #22: -----------------------------------------| "We don't do a new version to fix bugs." - Bill Gates | "The new version - it's not there to fix bugs." - Bill Gates | --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Tue, Apr 11, Clemens Wohld wrote:
[Soweit ich sehe, scheint Euch dies bewußt zu sein, da seit 6.4 /usr/share/man statt /usr/man verwendet wird - Interessanterweise wurde /usr/man aber nicht eliminiert.]
Tatsache ist, dass ich immernoch zwei folder alla /man hab. Kann ich die /usr/man nicht einfach (liegt noch teilweise was drinn) nach /usr/share/man verschieben??
Was liegt da noch drin ? Von der 6.4 benutzt kein Paket mehr /usr/man. Verschieben geht nicht. Wenn Du das machst, löscht RPM Dir die Manual Pages beim update.
/usr/share/man wird schon seit 6.2 benutzt. Es dauert nur 1800 Pakete umzustellen. Leider kann RPM den move /usr/man -> /usr/share/man nicht gescheit handeln, weswegen z.B. Red Hat diese Änderung im FHS gerne wieder Rückgängig gemacht hätte. Wir haben uns deswegen entschieden, die alten Verzeichnisse zu lassen, damit es beim Update und bei der Installation von Paketen, die /usr/man benutzen, keine Probleme mit RPM gibt.
Genau deshalb ist ein wenig Chaos bei mir in Sachen manpages. Die eigens kompilierten sind in /usr/local/man, dass ist auch OK so. Aber was tun mit /usr/man? Für "verkehrte" RPM's stehen lassen?
Ja.
Oder nach /usr/share/man moven?
Nein. Wie oben bereits früher von mir geschrieben, geht das mit RPM nicht.
Gruß, Clemens
PS: Wo gerade mehrere SuSEMitarbeiter mitlesen: Könntet ihr bitte einen gewissen PETER MÜLLER abbestellen?? Seine Mailbox scheint voll und ich bekomme ohne Ende echomails :-/
Wenn Du seine Email Adresse hast, ist das möglich. Ich habe seinen Account bisher noch nicht auf der Liste gefunden. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Clemens Wohld (c.wohld@ndh.net) [20000409 15:07]:
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Eben gerade nicht! LSB sagt ausdrücklich, das ausführbare Dateien in /etc nichts zu suchen haben und Initscripte zählen dazu. Deshalb haben wir ja init.d nach /sbin verschoben.
Meine updates sind auch alle recht gut verlaufen. .....auch wenn ein wenig "Handarbeit" angesagt war.
Dito :) Bleib einem meistens nicht erspart.
Philipp
--
Philipp Thomas
Philipp Thomas schrieb in 0,9K (29 Zeilen):
* Clemens Wohld (c.wohld@ndh.net) [20000409 15:07]:
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Eben gerade nicht! LSB sagt ausdrücklich, das ausführbare Dateien in /etc nichts zu suchen haben und Initscripte zählen dazu. Deshalb haben wir ja init.d nach /sbin verschoben.
auf SuSE 6.4: fhs-2.0-68 (Build Date: Die 07 Mär 2000 12:19:36 CET) --------------------------------------------------------------------- Filesystem Hierarchy Standard October 26, 1997 3.4 /etc : Host-specific system configuration [...] No binaries should be located under /etc. [...] Notes: The setup of command scripts invoked at boot time may resemble System V or BSD models. Further specification in this area may be added to a future version of this standard. 3.10 /sbin : System binaries (binaries once kept in /etc) Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically contains binaries essential for booting the system in addition to the binaries in /bin. --------------------------------------------------------------------- Ich lese da *binaries*, nicht Executables. Sonst muesstet ihr euch bei /etc/ppp/ip-(up|down)(.local)?, /etc/cron.(hourly|daily|weekly|monthly)/*, erklaeren ...
Meine updates sind auch alle recht gut verlaufen. .....auch wenn ein wenig "Handarbeit" angesagt war.
Dito :) Bleib einem meistens nicht erspart.
Dito (aber kein Iomega). Selbst von 4.3 auf 5.2 :-) (Aber ich weiss, wozu ich im Zweifelsfall Backups habe und worauf ich mich einlasse.) :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Walther,! Walther, Christoph schrieb am Freitag, den 07. April 2000:
Daß Updates unter SuSE problematisch sind, höre ich aus dem professionellen Umfeld sehr oft, dann habe ich dieses leider selbst auch schon öfters erfahren müssen.
Probleme ich seit der 5.0 (?) immer, aber die liesen sich meistens in wenigen Stunden (auch zuviel) loesen, aber diesmal habe ich einen Tag (!) reingesteckt und es tut einiges immer noch nicht ... eigentlich habe ich bisher nur mutt in den Griff bekommen, dazu eine extra Mail.
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Das ist manchmal etwas aergerlich aber nicht so tragisch, ausserdem wurde jetzt einiges angepasst.
Meine Überlegungen z.Zt. sind diese, sich mit den Distributionen
- Debian und
Die ist wirklich gut, mit der habe ich schon oefters gearbeitet, aber noch nie von 0 hochgezogen, wie das aussieht werde ich in den naechsten Wochen testen (an unserer Uni ist ein Debian Mirror, darauf habe ich mit 100 MBit Zugriff, sehr geschickt :) ).
- Corel Linux (setzt auf Debain auf)
Hatte ich schon in der Hand, wuerde ich nicht empfehlen. Ist auf "moeglichst einfach" ausgelegt - die Installation ist wirklich gelungen, aber ansonsten waere mir dann eine "richtige" Debian lieber. BTW: ISDN ist nicht dabei, Amis (?) kennen das nicht ...
Bei Debian ist es möglich, wie ich mit eigenen Augen gesehen habe, im laufenden Betrieb vom Debian-FTP-Server weg ein Update zu fahren,
Ja, das ist wirklich super gemacht. Genauso das installieren einzelner Packete: apt-get install <packet> Und das Packet mit allen Abhaengigkeiten wird gezogen und installiert.
Debian soll aber nicht für den Linux-Anfänger geeignet sein!!
Das ist sicher nicht, nein.
Das Deasaster nach dem SuSE-Update habe ich langsam über und eine Neuinstallation kommt bei mir wegen einem kontinuierlich gewachsenenm System eh nicht so in Frage.
Geht mir auch so. Bis das wieder so laeuft brauche ich Wochen. Dafuer habe ich weder Nerven noch Zeit (und Lust).
SuSE ist zwar Klasse mit der Eindeutschung für den normalen User sowie seinem ausführlichen Installationshandbuch.
Vor allem letzteres muss man loben. Ich kenne keine Distribution die da auch nur annaehernd mithalten kann. Aber bei meinen Problemen hilft das leider auch nichts. -- mfg Thomas Mueller - http://tmueller.home.pages.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller wrote:
Das Deasaster nach dem SuSE-Update habe ich langsam über und eine Neuinstallation kommt bei mir wegen einem kontinuierlich gewachsenenm System eh nicht so in Frage.
Geht mir auch so. Bis das wieder so laeuft brauche ich Wochen. Dafuer habe ich weder Nerven noch Zeit (und Lust).
Wenn Ihr nicht einmal einen Überblick habt, was Ihr alles wohin installiert bzw konfiguriert habt, solltet Ihr Euch vielleicht einmal die Frage stellen, ob eine Neuinstallation z.B. jährlich vielleicht DOCH sinnvoll ist. Es schafft nämlich Klarheit ... Habt Ihr eigentlich bedacht, dass selber kompilierte Pakete unter /usr/local auch nach einem Update bestehen bleiben und neuere Pakete einer neueren Suse per rpm unter /usr installiert werden, sodass Ihr vermutlich ungewollt zwei Versionen installiert, die alte unter local aber statet, wenn Ihr die Applikationen blind startet? Daraus ergeben sich schnell Probleme, an denen Ihr tagelang sucht. Dann ist vielleicht eine Neuinstallation ratsamer. Das alles theoretisiere ich auf Euerer Aussage, dass Ihr nicht mehr den vollen Überblick über Euer derzeit installiertes System habt. Habt Ihr mal den Lerneffekt einer Neuinstallation berücksichtigt? Irgendwann wisst Ihr gar nicht mehr wie was konfiguriert wird, durch alljährliche Neuinstallation passiert das nicht. Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Ekkard! Ekkard Gerlach schrieb am Samstag, den 08. April 2000:
Das Deasaster nach dem SuSE-Update habe ich langsam über und eine Neuinstallation kommt bei mir wegen einem kontinuierlich gewachsenenm System eh nicht so in Frage.
Geht mir auch so. Bis das wieder so laeuft brauche ich Wochen. Dafuer habe ich weder Nerven noch Zeit (und Lust).
Wenn Ihr nicht einmal einen Überblick habt, was Ihr alles wohin installiert bzw konfiguriert habt, solltet Ihr Euch vielleicht einmal die Frage stellen, ob eine Neuinstallation z.B. jährlich vielleicht DOCH sinnvoll ist. Es schafft nämlich Klarheit ...
Mir ist klar was ich wo installiert/veraendert habe, daher weiss ich ja wieviel arbeit auf mich zukommen wuerde :-)
Habt Ihr eigentlich bedacht, dass selber kompilierte Pakete unter /usr/local auch nach einem Update bestehen bleiben und neuere Pakete einer neueren Suse per rpm unter /usr installiert werden, sodass Ihr
Ausser man macht es so dass man nie direkt installiert sondern immer RPMs erzeugt, die man dann auch noch so nennen sollte wie es die Distribution tut. Ich habe hier ca. 70 selbst gebackene RPMs ...
vermutlich ungewollt zwei Versionen installiert, die alte unter local aber statet, wenn Ihr die Applikationen blind startet? Daraus ergeben sich schnell Probleme, an denen Ihr tagelang sucht. Dann ist vielleicht eine Neuinstallation ratsamer. Das alles theoretisiere ich auf Euerer Aussage, dass Ihr nicht mehr den vollen Überblick über Euer derzeit installiertes System habt.
Das hast Du reininterpretiert! Ich habe nur gesagt dass es ein heidenaufwand ist alles wieder so hinzubekommen wie es jetzt ist. Wenn man an der Distribution kaum was veraendert hat und man wenig Software einsetzt ist das kein Problem klar, bei mir waere das aber einiges. In YaST/Administration des Systems/Backup (oder so aehnlich) kann man ein komplett Backup machen in dem nur alles landet was sich gegenueber dem Original im RPM geandert hat - sehr aufschlussreich! Darin sollten z.B. keine Binaries sein ... Ich habe hier einige Server wie cvs, Datenbanken, Samba, Apache etc laufen die alle neu aufsetzen muesste - oder ich kopiere alle Configs um dann ich mir auch ein neu installieren sparen, das bringt dann naemlich eh nichts :-)
Habt Ihr mal den Lerneffekt einer Neuinstallation berücksichtigt?
Dabei lernt man IMHO nichts. Ich habe die SuSE auf den verschiedensten Systemen sicher so 30 - 40 installiert - viel gelernt habe ich dabei nicht. Wenn ich jetzt aber mein aktuelles Problem loesen kann lerne ich dabei einiges.
Irgendwann wisst Ihr gar nicht mehr wie was konfiguriert wird, durch alljährliche Neuinstallation passiert das nicht.
Mach das YaST Backup und schau in das erzeugte Archiv und weisst JEDE Datei die veraendert wurde! Dafuer verdient SuSE ein grosses Lob, das ist wirklich gut gemacht! -- mfg Thomas Mueller - http://tmueller.home.pages.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller wrote:
Habt Ihr eigentlich bedacht, dass selber kompilierte Pakete unter /usr/local auch nach einem Update bestehen bleiben und neuere Pakete einer neueren Suse per rpm unter /usr installiert werden, sodass Ihr
Ausser man macht es so dass man nie direkt installiert sondern immer RPMs erzeugt, die man dann auch noch so nennen sollte wie es die Distribution tut. Ich habe hier ca. 70 selbst gebackene RPMs ...
aha! Gibt es einen Automatismus der das unterstützt, also aus dem makefile die Installationsvorschriften ausliest? Oder machst Du das per Hand? Hast Du vielleicht ein paar getippte Notizen dazu, die Du mal in die Liste posten kannst ? [...]
Mach das YaST Backup und schau in das erzeugte Archiv und weisst JEDE Datei die veraendert wurde!
aha! Du meinst yast -> Adminstration -> Backups erstellen (Suse 6.4) ? Was meinst Du mit "erzeugte Archiv" ? Das Backup macht doch keine Differenzen, oder ? Wo hast Du die Differenzen her ? Oder meinst Du das Backup, das bei der Deinstallation von rpm's angeboten wird ? Wo kommen dann die Differenzen her ? Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ekkard Gerlach schrieb in 1,3K (42 Zeilen):
Thomas Mueller wrote:
Ausser man macht es so dass man nie direkt installiert sondern immer RPMs erzeugt, die man dann auch noch so nennen sollte wie es die Distribution tut. Ich habe hier ca. 70 selbst gebackene RPMs ...
aha! Gibt es einen Automatismus der das unterstützt, also aus dem makefile die Installationsvorschriften ausliest? Oder machst Du das per Hand?
[...] BuildRoot: /tmp/RPMBUILDROOT/whatever_you_want [... Bin nicht sicher, ob das naechste immer geht ... ] %install make install prefix=$RPM_BUILD_ROOT/usr [... Beispiel:] find $RPM_BUILD_ROOT -not -type d -printf "/%%P\n" | \ sed -e "s:^:%%attr (0755,root,root) :" \ -e "s:%%attr (0755,root,root) \(/sbin/init.d/rc[23]\):\1:" \ -e "s:0755\(.*/man/\):0644\1:" \ -e "s:0755\(.*/etc/chrony.keys\):0600\1:" \ -e "s:0755\(.*/etc/\):0644\1:" \ -e "s:\(.*/etc/\):%%config \1:" \ > manifest %clean if [ "${RPM_BUILD_ROOT}" != '/' ] ; then rm -rf ${RPM_BUILD_ROOT} ; fi %post %files -f manifest %doc INSTALL %doc LICENCE %doc NEWS %doc README %doc texinfo.tex.patch
Mach das YaST Backup und schau in das erzeugte Archiv und weisst JEDE Datei die veraendert wurde!
aha! Du meinst yast -> Adminstration -> Backups erstellen (Suse 6.4) ? Was meinst Du mit "erzeugte Archiv" ? Das Backup macht doch keine Differenzen, oder ? Wo hast Du die Differenzen her ?
Das Backup macht wohl nur ein compare auf die mtime (und vielleicht noch auf die ctime) und/oder ein test der MD5-Summe. Keine Differenzen, AFAIK, nur die 'geaenderten' Dateien. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Ekkard! Ekkard Gerlach schrieb am Freitag, den 14. April 2000:
Habt Ihr eigentlich bedacht, dass selber kompilierte Pakete unter /usr/local auch nach einem Update bestehen bleiben und neuere Pakete einer neueren Suse per rpm unter /usr installiert werden, sodass Ihr
Ausser man macht es so dass man nie direkt installiert sondern immer RPMs erzeugt, die man dann auch noch so nennen sollte wie es die Distribution tut. Ich habe hier ca. 70 selbst gebackene RPMs ...
aha! Gibt es einen Automatismus der das unterstützt, also aus dem makefile die Installationsvorschriften ausliest? Oder machst Du das per Hand?
Per Hand, in 95% der Faelle ist es ja das selbe: configure, make, make install und das war's.
Hast Du vielleicht ein paar getippte Notizen dazu, die Du mal in die Liste posten kannst ?
Ich haette ein Beispiel SPEC File:
#
# spec file for powershell
#
%define ver 0.63
%define rel 0
%define prefix /opt/gnome
%define name powershell
Summary: gui frontend to most of the major archive programs in unix
Name: %name
Version: %ver
Release: %rel
Copyright: GPL
Group: X11/gnome
Source: %{name}-%{ver}.tar.gz
BuildRoot: /tmp/%{name}-root
Packager: Thomas Mueller
[...]
Mach das YaST Backup und schau in das erzeugte Archiv und weisst JEDE Datei die veraendert wurde! aha! Du meinst yast -> Adminstration -> Backups erstellen (Suse 6.4) ?
Genau, auch wenn die von der SuSE 6.4 bei mir nicht mehr tut :-((
Was meinst Du mit "erzeugte Archiv" ? Das Backup macht
Das Archiv das von obigem Menuepunkt erstellt wird.
doch keine Differenzen, oder ? Wo hast Du die Differenzen her ?
Ich habe nicht Differenzen geschrieben sondern Dateien :-) In dem Archiv sind alle Dateien die gegenueber denen im RPM veraendert wurden oder die neu dazu kamen. -- mfg Thomas Mueller - http://tmueller.home.pages.de for pgp key --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo ???
Von: Illuminatus@t-online.de [mailto:Illuminatus@t-online.de]
Die Mail kam hier nie an :-(
Beim Update habe ich YaST2 ausgewaehlt der dann abgestuerzt ist, stattdessen kam YaST1 hoch, der Teil war noch in Ordnung. [...]
als Du Dich fuer ein Update anstatt einer Neuinstallation entschieden hast, war Dir klar dass das nicht reibungslos sein kann?
Es hat mich nicht gewundert dass es Probleme gibt ja, aber dass die so heftig sind schon.
Der MidnightCommander genauso wenig: Speicherzugriffsfehler Ich habe testweise die aktuellste Version gezogen und kompiliert: selbes Ergebnis. Hmm, ja damit hatte ich auch ein Problem. Schau mal nach, ob unter
Puh, das beruhigt mich :-)
/usr/share/terminfo/l ein file namens linux ist. Wenn nein, dann mach folgendes:
Das "l" Verzeichniss fehlt.
Als root einloggen.. tic -v /usr/lib/mc/term/linux.ti ..ausfuehren.
bash-2.03# tic -v /usr/lib/mc/term/linux.ti "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': non-curses applications may be confused by ich/ich1 with smir/rmir "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_blink_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_bold_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_reverse_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': non-curses applications may be confused by ich/ich1 with smir/rmir "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_blink_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_bold_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_reverse_mode but no exit_attribute_mode Und der mc stuerzt aber immer noch ab :-(
xawtv (der uebrigends nur in einer uralt Version vorhanden ist) findet libjpeg.so.6 nicht, obwohl "locate" diese in /usr/lib findet (ldconfig habe ich schon laufen lassen).
Dass meine conf.modules ersetzt wurde und daher nach einem reboot nichts mehr lief oder aehnliches geht noch, das liess sich beheben durch ersetzen der SuSE Dateien durch meine alten Versionen.
Naja, wie gesagt, wenn Du solche Probleme nicht haben willst, darfst Du kein Update machen. Es ist uebrigens _nicht_ die beste Art, einfach die alte datei drüberzubügeln. Unter Umstaenden gehen Dir dadurch neue "Features" verloren. Z.B /etc/httpd/httpd.conf oder ISDN, da hat sich einiges verändert.
Ja das mache ich bei solchen Dateien auch nicht, bei der modules.conf ist das aber was anderes.
Ich habe sowohl ein Update wie auch eine Neuinstallation mit 6.4 durchgefuehrt. Beim Update waren etliche Dinge, wie Du sie hier auch beschreibst, das war mir vorher klar ;-). Die Neuinstallation war absolut problemlos.
Bist auf die Kleinigkeit dass Du nochmal zig Stunden Arbeit reinstecken musst bis alles wieder so laeuft :-) Einer der vielen Gruende warum ich mich fuer Linux entschieden habe war dass ich ein Update machen kann und nicht staendig neu installieren muss ... -- mfg Thomas Mueller - http://tmueller.home.pages.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller wrote: [...]
Puh, das beruhigt mich :-)
/usr/share/terminfo/l ein file namens linux ist. Wenn nein, dann mach folgendes:
Das "l" Verzeichniss fehlt.
Als root einloggen.. tic -v /usr/lib/mc/term/linux.ti ..ausfuehren.
bash-2.03# tic -v /usr/lib/mc/term/linux.ti "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': non-curses applications may be confused by ich/ich1 with smir/rmir "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_blink_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_bold_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 20, terminal 'linux': enter_reverse_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': non-curses applications may be confused by ich/ich1 with smir/rmir "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_blink_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_bold_mode but no exit_attribute_mode "/usr/lib/mc/term/linux.ti", line 48, terminal 'linux-132x43': enter_reverse_mode but no exit_attribute_mode
Und der mc stuerzt aber immer noch ab :-(
Hi, hast Du mal nachgesehen, ob das File jetzt existiert? Wenn nein, dann versuch mal die terminfo komplett neu zu installieren. Ist vermutlich im paket aaa.base auf CD. Hmm, es scheint, da ist tatsaechlich ein Fehler im Update. Jetzt sinds schon 3, die dieses Problem hatten. Mal sehen, vielleicht werdens noch mehr. Ich hatte mich deshalb an den Installationssupport gewendet, dort wurde vermutet mein RAM sei defekt etc.. Ich habe daraufhin den Debugger angeworfen, da war dann zu sehen, dass die terminfo nicht gefunden wurde. Eventuell ist das eine Meldung an SuSE Feedback wert... [...]
Naja, wie gesagt, wenn Du solche Probleme nicht haben willst, darfst Du kein Update machen. Es ist uebrigens _nicht_ die beste Art, einfach die alte datei drüberzubügeln. Unter Umstaenden gehen Dir dadurch neue "Features" verloren. Z.B /etc/httpd/httpd.conf oder ISDN, da hat sich einiges verändert.
Ja das mache ich bei solchen Dateien auch nicht, bei der modules.conf ist das aber was anderes.
Warum? IMHO ist diese Datei auch eine von denen, die eine sensible Bearbeitung verdient haben.
Ich habe sowohl ein Update wie auch eine Neuinstallation mit 6.4 durchgefuehrt. Beim Update waren etliche Dinge, wie Du sie hier auch beschreibst, das war mir vorher klar ;-). Die Neuinstallation war absolut problemlos.
Bist auf die Kleinigkeit dass Du nochmal zig Stunden Arbeit reinstecken musst bis alles wieder so laeuft :-)
zig Stunden... das stimmt für mich nicht. Ich habe mit SuSE 4.1 angefangen und kaufe so ca. jedes 2. Update. Ich habe gelernt, mir genau zu ueberlegen ob ich Neuinstallieren, oder Updaten will. Das haengt zum Beispiel von den Ankuendigungen von SuSE ab. Wenn die, wie bei Version 6.0 sagen da sind gravierende Aenderungen, dann mach ich Neuinstallation. Ausserdem haengts vom Rechner ab. Auf meinem Server war 6.2 drauf, ich habe dort nur die Dienste konfiguriert, Netzwerk, Fax, Printer, ISDN etc. Und nur das allernoetigste installiert. Hier hab ich die Konfigfiles gesichert, manche Einstellungen ausgedruckt (z.B:fdisk -l) und dann neuinstalliert. Ab dem Zeitpunkt, wo SuSE meint..have a lot of fun.. warens ca. 2 Stunden und alles, bis auf hylafax lief wieder. Der andere Rechner ist meine Spielkiste, hier hab ich soviel dran rumgedreht und Sachen von tarballs installiert, dass ich lieber ein Update versuchen wollte, zumal SuSE ja auch keine schwerwiegenden Aenderungen angekündigt hatte. ( Die naechste Version wird ein Fall fuer Neuinstallation werden, neuer Kernel, KDE 2 wird dann hoffentlich auch schon da sein etc.) Hier warens auch nicht zig Stunden sondern so um 4-5 und bis auf den mc ging dann alles. Gemessen an der Komplexitaet von Linux ist das Lichtgeschwindigkeit. Mein erstes UNIX Update SCO 3.0 -> SCO 3.2 hat 1 Tag + 1 Nacht gedauert ;-) In jedem Fall dauert die Vorbereitung dafuer genauso lange oder sogar laenger, wenn ich die Zeit dazurechne bis ich mich ent- schieden habe wie ich vorgehe ;-) Ein wichtiger Punkt dabei ist hier in der Liste nach diesbezueglichen Meldungen zu suchen und die SDB-History zu lesen.
Einer der vielen Gruende warum ich mich fuer Linux entschieden habe war dass ich ein Update machen kann und nicht staendig neu installieren muss ...
Das stimmt fuer einzelne Pakete vieleicht, fuer einen Versionswechsel hoechstens zufaellig und beim Wechsel der Version des Kernels oder der Lib o.ae. ist es unverschaemtes Glück. Ich vermute, Du spielst auf winxxxx an. IMHO ist der Unterschied, dass bei Linux nicht ohne Dein Zutun das System unbrauchbar wird. (Abgesehen von Hardwarefehlern) Deshalb ist es unnoetig eine DistriVersion neu zu installieren. Richtig gute Win Admins kriegen das u.U. auch ohne Neuinstallation hin ;-) Ein Update oder Neuinstallation erfordert _immer_ eine wohlueber- legte Strategie. Das stimmt fuer alle OS, die ich kenne, ohne Abstrich. Manche OS geben Dir halt nicht soviele Moeglichkeiten den Ablauf zu beeinflussen, da ist mir Linux lieber ;-) o long... bernd --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Bernd! Bernd Obermayr schrieb am Samstag, den 08. April 2000:
/usr/share/terminfo/l ein file namens linux ist. Wenn nein, dann mach folgendes:
[..] Ich habe mich jetzt fuer Helix Gnome entschieden. Die dort fuer SuSE 6.3 angebotenen RPMs funktionieren einwandfrei, man muss nur noch einen Link setzen libjpeg.6.so -> libjpeg.62.so Ich bin wirklich begeistert: die 1.1.x Version ist deutlich schneller und hat einige nette neue Features (das Panel ist in der Grosse veraenderbar etc). Die MC Version laeuft jetzt auch einwandfrei.
Eventuell ist das eine Meldung an SuSE Feedback wert...
Ich schaetze schon ja.
Naja, wie gesagt, wenn Du solche Probleme nicht haben willst, darfst Du kein Update machen. Es ist uebrigens _nicht_ die beste Art, einfach die alte datei drüberzubügeln. Unter Umstaenden gehen Dir dadurch neue "Features" verloren. Z.B /etc/httpd/httpd.conf oder ISDN, da hat sich einiges verändert.
Ja das mache ich bei solchen Dateien auch nicht, bei der modules.conf ist das aber was anderes.
Warum? IMHO ist diese Datei auch eine von denen, die eine sensible Bearbeitung verdient haben.
Auf jeden Fall, wenn ich aber weder den SuSE Kernel noch SuSE Modules installiere darf die ueberhaupt nicht angefasst werden!! Es kann dann naemlich keine neuen "Features" geben - es hat sich ja nichts geandert!
Ich habe sowohl ein Update wie auch eine Neuinstallation mit 6.4 durchgefuehrt. Beim Update waren etliche Dinge, wie Du sie hier auch beschreibst, das war mir vorher klar ;-). Die Neuinstallation war absolut problemlos.
Bist auf die Kleinigkeit dass Du nochmal zig Stunden Arbeit reinstecken musst bis alles wieder so laeuft :-)
zig Stunden... das stimmt für mich nicht. Ich habe mit SuSE 4.1 angefangen und kaufe so ca. jedes 2. Update. Ich habe gelernt, mir genau zu ueberlegen ob ich Neuinstallieren, oder Updaten will. Das haengt zum Beispiel
Das muss ich nicht ueberlegen. Ich will immer nur updaten! Das RPM System bietet dafuer IMHO eine sehr gute Grundlage. Das einzige Problem sind evtl die Homeverzeichnisse wo sich viele alte Sachen ansammeln. Da hilft aber auch ein Update nichts, /home laesst man da ja i.d.R. unangetastet.
von den Ankuendigungen von SuSE ab. Wenn die, wie bei Version 6.0 sagen da sind gravierende Aenderungen, dann mach ich Neuinstallation.
Das Update auf die 6.0 lief bei mir vollkommen problemlos (hat mich auch gewundert, gebe ich zu)! Ich habe jetzt dazu gelernt und mir nochmal eine 40 Gig Platte bestellt, ab jetzt gibt's vor jeder groesseren Aenderung ein komplett Backup. Bei Problemen laeuft dann der Rechner nach 10 Minuten wieder als waere nichts gewesen.
Ausserdem haengts vom Rechner ab. Auf meinem Server war 6.2 drauf, ich habe dort nur die Dienste konfiguriert, Netzwerk, Fax, Printer, ISDN etc. Und nur das allernoetigste installiert. Hier hab ich die
Damit laeuft mein Server immer noch. Daran traue ich mich erst wieder ran wenn die Workstation 100% das macht was sie soll :-)
Konfigfiles gesichert, manche Einstellungen ausgedruckt (z.B:fdisk -l)
Das sollte man unabhaengig vom update IMMER machen wenn sich die Partitionierung aendert! Sehr zu empfehlen ...
und dann neuinstalliert. Ab dem Zeitpunkt, wo SuSE meint..have a lot of fun.. warens ca. 2 Stunden und alles, bis auf hylafax lief wieder.
Davon werde ich dann in ein paar Wochen hoffentlich auch berichten koennen ;)
Der andere Rechner ist meine Spielkiste, hier hab ich soviel dran rumgedreht und Sachen von tarballs installiert, dass ich lieber ein Update versuchen wollte,
Das waere fuer mich das Gegenargument fuer ein Update :-) Aber bedeutet auch viel Arbeit wenn man neu installiert, klar.
zumal SuSE ja auch keine schwerwiegenden Aenderungen angekündigt hatte. ( Die naechste Version wird ein Fall fuer Neuinstallation werden, neuer Kernel, KDE 2 wird dann hoffentlich auch schon da sein etc.)
Na der Kernel wird hoffentlich in den naechsten Tagen endlich released! An den Kernel lasse ich meine Distribution nicht ran, das mache ich lieber selber :-) KDE ist fuer mich auch kein Thema, GNOME haelt ab jetzt Helix alle paar Tage Up-to-date - ich hoffe nicht dass ich in den naechsten Jahren neu installieren muss :-) Meine erste SuSE war die 5.2 - und das war auch die einzige die ich neu installiert habe, seither immer nur Updates.
Hier warens auch nicht zig Stunden sondern so um 4-5 und bis auf den mc ging dann alles.
Wie geschrieben hat mein GNOME immer noch gesponnen. Evtl war ich da aber auch teilweise selber Schuld, ich suche noch.
Gemessen an der Komplexitaet von Linux ist das Lichtgeschwindigkeit. Mein erstes UNIX Update SCO 3.0 -> SCO 3.2 hat 1 Tag + 1 Nacht gedauert ;-)
Wenn Du Dich mal wieder austoben willst: ich habe im Buero noch ein paar alte AIX, HP-UX und SCOs rumstehen, die sollte man auch mal updaten :-)) Ausser Y2K Fixes ist da seit Jahren nichts mehr passiert - die laufen einfach, und laufen, und laufen ...
In jedem Fall dauert die Vorbereitung dafuer genauso lange oder sogar laenger, wenn ich die Zeit dazurechne bis ich mich ent- schieden habe wie ich vorgehe ;-)
Jup klar. Ich denke (und hoffe) dass die ganzen UNIXe nach und nach von UNIX abgeloest werden, das wuerde die Betriebskosten nicht unerheblich senken. Nachdem HP und IBM Linux Kernel rausgebracht haben sehe ich da auch Chancen. Firmen wie SGI (dank SuSE?) engagieren ja auch nicht schlecht!
Ein wichtiger Punkt dabei ist hier in der Liste nach diesbezueglichen Meldungen zu suchen und die SDB-History zu lesen.
Klar, ueberfliegen tu ich die vor einem Update schon, aber wenn im Subjekt kein "6.4" vorkommt verpasse ich die wahrscheinlich schon.
Einer der vielen Gruende warum ich mich fuer Linux entschieden habe war dass ich ein Update machen kann und nicht staendig neu installieren muss ...
Das stimmt fuer einzelne Pakete vieleicht, fuer einen Versionswechsel hoechstens zufaellig und beim Wechsel der Version des Kernels oder der Lib o.ae. ist es unverschaemtes Glück.
Weshalb? Der Kernel ist vom Rest des Systems relativ unabhaengig. Der wechsel von 2.0 auf 2.2 war vollkommen problemlos. Dadurch dass ich parallel mit beiden testen kann laeuft nach max. 2 Minuten alles wieder (Reboot). Problemtisch ist nur wenn sich Schnittstellen zum Kernel geandert haben (2.0 auf 2.2 z.B. das Masquerading). Die Lib ist unproblematisch wenn man per Distribution updatet: alle Binaries der Distri sind mit der neuen Lib kompiliert, bei den selber kompilierten dauert das zwar evtl ein paar Tage - aber das macht mein Rechner ohne mein zutun: find /usr/src/packages/SRPM -name "*.srpm" -exec "rpm --rebuild {}" \; (Syntax aus dem Kopf, weiss nicht ob das so passt) Danach alle neu erzeugten RPMs installieren und fertig. Normalerweise kein Problem.
Ich vermute, Du spielst auf winxxxx an. IMHO ist der Unterschied,
Jein. Windows und Linux kann man nicht vergleichen. Beides laeuft auf der selben Hardware - das ist auch alles was die gemeinsam haben.
dass bei Linux nicht ohne Dein Zutun das System unbrauchbar wird.
Ja - und mit meinem Zutun ist es verflixt schwer. Wie gesagt, seit 5.2 keine Neuinstallation mehr ... und ich kompiliere (zu) viel selber und pfusche einiges am System rum. Zur Zeit kaempfe ich mit dem COM Port, wenn sich da jemand gut auskennt waere ich fuer eine eMail dankbar :-)
(Abgesehen von Hardwarefehlern) Deshalb ist es unnoetig eine DistriVersion neu zu installieren.
Ja.
Richtig gute Win Admins kriegen das u.U. auch ohne Neuinstallation hin ;-)
Das halte ich fuer ein Geruech :-)
Ein Update oder Neuinstallation erfordert _immer_ eine wohlueber- legte Strategie.
Die braucht nur eine Strategie wirklich: ein komplett Backup. Alles andere ist nicht so wichtig da man es rueckgaengig machen. Und da liegt eben auch wieder der Vorteil von Linux: 2 Platten reinhaengen, von Diskette booten und die Platten umkopieren, fertig. Man hat ein 100% Backup das auch sicher wieder laeuft.
Das stimmt fuer alle OS, die ich kenne, ohne Abstrich. Manche OS geben Dir halt nicht soviele Moeglichkeiten den Ablauf zu beeinflussen, da ist mir Linux lieber ;-)
Geht mir auch so - sonst haette ich es ja nicht :-) -- mfg Thomas Mueller - http://tmueller.home.pages.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (16)
-
B.Brodesser＠online-club.de -
c.wohld＠ndh.net -
Christoph.Walther＠telekom.de -
corsepiu＠faw.uni-ulm.de -
egerlach＠nikocity.de -
Illuminatus＠t-online.de -
Jan.Trippler＠t-online.de -
kukuk＠suse.de -
linux＠jwr.de -
Martin.Schreiber＠fgan.de -
moritz＠hp9001.fh-bielefeld.de -
pkuechle＠uvf.de -
pthomas＠suse.de -
tennert＠science-computing.de -
tmm＠bigfoot.de -
weissel＠netcologne.de