mysql

Frank Kaldewey

25 Oct 2002 25 Oct '02

13:04

Hallo, ich habe mysql mit yast auf suse 8.0 installiert linux:/bin # mysql start ERROR 2002: Can 't connect to local MYSQL server through socket' /var/lib/mysql/mysql.sock' (2) /var/lib/mysql der ordner ist leer bei ältern versionen 7.3 6.4 hat ich damit keine probleme Vielen Dank Frank

Show replies by date

Kroll, Volker

25 Oct 25 Oct

13:16

On 2002-10-25 03:04:00, Frank Kaldewey wrote:

...

Hallo,

ich habe mysql mit yast auf suse 8.0 installiert

linux:/bin # mysql start ERROR 2002: Can 't connect to local MYSQL server through socket' /var/lib/mysql/mysql.sock' (2)

Hast Du die DB initialisiert? Was sagt das errorlog? V.

Frank Kaldewey

13:25

Hallo, die DB mu? doch erstmal gestartet werden bevor die ins log schreibt, oder? mein problem ist das der ordner /var/lib/mysql leer ist. Da sollte doch bei einer rmp.file installation mit yast files wie mysql.sock liegen Vielen Dank -----Ursprungliche Nachricht----- Von: Kroll, Volker [mailto:Kroll@strato.de] Gesendet: Freitag, 25. Oktober 2002 15:17 An: suse-linux@suse.com Betreff: Re: mysql On 2002-10-25 03:04:00, Frank Kaldewey wrote:

...

Hallo,

ich habe mysql mit yast auf suse 8.0 installiert

linux:/bin # mysql start ERROR 2002: Can 't connect to local MYSQL server through socket' /var/lib/mysql/mysql.sock' (2)

Hast Du die DB initialisiert? Was sagt das errorlog? V. -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

Thorsten Haude

13:46

Moin, Bitte schreibe keine Tofumails. http://www.vranx.de/mail/tofu.html * Frank Kaldewey [02-10-25 15:25]:

...

die DB mu? doch erstmal gestartet werden bevor die ins log schreibt, oder?

Stimmt, versuchst Du das auch als root? Das Prompt sieht nicht danach aus. Hast Du schon eine Datenbank oder ist das der erste Versuch, den Server zu starten?

...

Da sollte doch bei einer rmp.file installation mit yast files wie mysql.sock liegen

Woher kommt die Information über mysql.sock? Thorsten -- If I have seen further, it is by standing on the shoulders of giants. - Sir Isaac Newton

Thorsten Haude

13:18

Moin, * Frank Kaldewey [02-10-25 15:04]:

...

ich habe mysql mit yast auf suse 8.0 installiert

linux:/bin # mysql start ERROR 2002: Can 't connect to local MYSQL server through socket' /var/lib/mysql/mysql.sock' (2)

/var/lib/mysql der ordner ist leer

Überprüf mal, ob die Privilegien entsprechend gesetzt sind.

...

bei ältern versionen 7.3 6.4 hat ich damit keine probleme

Die sind weit offen. Thorsten -- The goal is to keep the bewildered herd bewildered. It's unnecessary for them to trouble themselves with what's happening in the world. In fact, it's undesirable - if they see too much of reality they may set themselves to change it. - Noam Chomsky

Peter Wiersig

13:55

Frank Kaldewey wrote:

...

ich habe mysql mit yast auf suse 8.0 installiert

Und der neue Default fuer die meisten Daemonen lautet: Sie werden nicht automatisch in die Startkonfiguration uebernommen. Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein, am besten gefolgt von "/usr/sbin/rcmysql start", damit auch in der aktiven Sitzung eine Instanz laeuft.

...

linux:/bin # mysql start

Hier gibst du dem Client den Befehl, sich mir der Datenbank "start" zu verbinden. Gibt es die denn schon? wenn nicht, lass das zusaetzliche Argument ersteinmal weg. Peter

Frank Kaldewey

14:15

New subject: AW: mysql

Jo, läuft jetzt. Ist ja auch sicherer, wenn deamons nicht autom. in die Startconf übernommen werden Herzlichen Dank Frank -----Ursprüngliche Nachricht----- Von: Peter Wiersig [mailto:wiersig-ml@dns.glamus.de] Gesendet: Freitag, 25. Oktober 2002 15:55 An: suse-linux@suse.com Betreff: Re: mysql Frank Kaldewey wrote:

...

ich habe mysql mit yast auf suse 8.0 installiert

...

linux:/bin # mysql start

Hier gibst du dem Client den Befehl, sich mir der Datenbank "start" zu verbinden. Gibt es die denn schon? wenn nicht, lass das zusaetzliche Argument ersteinmal weg. Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

Thorsten Haude

14:35

Moin, * Peter Wiersig [02-10-25 15:55]:

...

Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein

Ist das was Neues von SuSE oder gibt's das für alle Linuxe? Thorsten -- If I have seen further, it is by standing on the shoulders of giants. - Sir Isaac Newton

Peter Wiersig

15:12

Thorsten Haude wrote:

...

* Peter Wiersig [02-10-25 15:55]:

...
Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein

Ist das was Neues von SuSE oder gibt's das für alle Linuxe?

Nee, ist LSB, also wird sowas fuer alle Linuxe kommen. Wie schon oefter erwaehnt, ich bin grosser Fan davon. Ok, stelle gerade fest, das Skript heisst noch anders als in der Spec http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/initscrcomconv.html aber Hauptsache es laeuft. Die Skripte unter /etc/init.d enthalten einen Kommentar-Block, ueber den dann gesteuert wird, welche Nummer im Start-Stop-Link verwendet wird. man insserv: "insserv enables an installed system init script (`boot script') by reading the comment header of the script, e.g.: ### BEGIN INIT INFO # Provides: boot_facility_1 [ boot_facility_2 ...] # Required-Start: boot_facility_1 [ boot_facility_2 ...] # Required-Stop: boot_facility_1 [ boot_facility_2 ...] # Default-Start: run_level_1 [ run_level_2 ...] # Default-Stop: run_level_1 [ run_level_2 ...] # Description: multiline_description ### END INIT INFO " Um einen Daemon aus der Start-Konfiguration zu entfernen gibt's "insserv -r /etc/init.d/mysql" Dieses neue Konzept hat auch einen Eintrag in der sdb. http://sdb.suse.de/de/sdb/html/start_foo80.html Die manpage zu insserv findet google. Peter

Thorsten Haude

15:34

Moin, * Peter Wiersig [02-10-25 17:12]:

...

Thorsten Haude wrote:

...
* Peter Wiersig [02-10-25 15:55]:

...
Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein

Ist das was Neues von SuSE oder gibt's das für alle Linuxe?

Nee, ist LSB, also wird sowas fuer alle Linuxe kommen. Wie schon oefter erwaehnt, ich bin grosser Fan davon.

Woody kennt's noch nicht, aber ich erinnere mich jetzt daran, daß SuSE das umgesetzt hat. Danke! Thorsten -- Auch Hunger ist Krieg. - Willy Brandt

Ralf Corsepius

15:45

Am Fre, 2002-10-25 um 17.34 schrieb Thorsten Haude:

...

Moin,

* Peter Wiersig [02-10-25 17:12]:

...
Thorsten Haude wrote:

...
* Peter Wiersig [02-10-25 15:55]:

...
Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein

Ist das was Neues von SuSE oder gibt's das für alle Linuxe?

Nee, ist LSB, also wird sowas fuer alle Linuxe kommen. Wie schon oefter erwaehnt, ich bin grosser Fan davon.

Woody kennt's noch nicht, aber ich erinnere mich jetzt daran, daß SuSE das umgesetzt hat. Eben nur zum Teil - Wie schon erwähnt, sollen die Tools laut LSB anders heissen: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/initsrcinstrm.html

Und nun (wundern und staunen!!) # ls -l /usr/lib/lsb/ lrwxrwxrwx 1 root root 23 Okt 22 10:48 install_initd -> ../../../sbin/chkconfig lrwxrwxrwx 1 root root 23 Okt 22 10:48 remove_initd -> ../../../sbin/chkconfig # cat /etc/*-release LSB_VERSION="1.2.0" Red Hat Linux release 8.0 (Psyche) Ralf

Peter Wiersig

15:50

Ralf Corsepius wrote:

...

# cat /etc/*-release LSB_VERSION="1.2.0" Red Hat Linux release 8.0 (Psyche)

Auf der SuSE-Page zur 8.1 prangt auch das LSB1.2-Logo, also wird da auch ein entsprechendes install_initd/remove_initd vorliegen. http://www.suse.de/de/private/products/suse_linux/i386/index.html Peter

Philipp Thomas

26 Oct 26 Oct

18:28

Ralf Corsepius [25 Oct 2002 17:45:35 +0200]:

...

http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/initsrcinstrm.html

Und nun (wundern und staunen!!) # ls -l /usr/lib/lsb/ lrwxrwxrwx 1 root root 23 Okt 22 10:48 install_initd -> ../../../sbin/chkconfig lrwxrwxrwx 1 root root 23 Okt 22 10:48 remove_initd -> ../../../sbin/chkconfig

Und nun noch mehr staunen! Sowohl für 8.0 als auf 8.1 gilt: [root:~]ls -l /usr/lib/lsb -rwx------ 1 root root 39 2002-09-19 19:23 install_initd -rwx------ 1 root root 42 2002-09-19 19:23 remove_initd [root:~]cat /usr/lib/lsb/install_initrd #!/bin/sh exec /sbin/insserv ${1+"$@"} [root:~]cat /usr/lib/lsb/remove_initd #!/bin/sh exec /sbin/insserv -r ${1+"$@"} Es ist alles da, wie man es erwartet. Und nun? ;-)))))) Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de

Ralf Corsepius

27 Oct 27 Oct

04:17

Am Sam, 2002-10-26 um 20.28 schrieb Philipp Thomas:

...

Ralf Corsepius [25 Oct 2002 17:45:35 +0200]:

...
http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/initsrcinstrm.html

[SuSE-8.1 und RH-8.0 besitzen /usr/lib/lsb/*_initd]

...

Es ist alles da, wie man es erwartet. Und nun? ;-))))))

... warten wir auf den Tag, an dem die Distributoren anfangen, diese Scripte auch zu verwenden und an dem die eigentlichen Bootscripte auch auf allen vorgeblich LSB-kompatiblen Systemen ohne jegliche Änderung laufen. Ralf Ralf

Philipp Thomas

12:12

New subject: LSB-Konfomität der Distributoren (was: mysql)

Ralf Corsepius [27 Oct 2002 05:17:52 +0100]:

...

[SuSE-8.1 und RH-8.0 besitzen /usr/lib/lsb/*_initd]

Das war schon in der SuSE 8.0 so.

...

... warten wir auf den Tag, an dem die Distributoren anfangen, diese Scripte auch zu verwenden

Wozu? LSB ist dafür gedacht, das ISVs ihre Programme/Scripte nur einmal zu schreiben brauchen und diese dann auf LSB-konformen System ohne Änderung laufen (sofern sie sich an die Spezifikation halten). SuSE kann also problemlos weiterhin insserv verwenden.

...

und an dem die eigentlichen Bootscripte auch auf allen vorgeblich LSB-kompatiblen Systemen ohne jegliche Änderung laufen.

Auch hier habe ich den Eindruck, dass du den Sinn von LSB nicht so ganz verstanden hast (s.o.). Die Initscripte der Distributoren werden wahrscheinlich nie auf einem anderen System laufen, schon weil z.B. zusätzliche herstellerspezifische Headereinträge (die mit X-<hersteller> starten) ausgewertet werden, die zusätzliche Funktionalitäten bietet, die der Standard so nicht vorsieht. Ein Beispiel dafür sind die X-UnitedLinux-should-start Einträge. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de

Ralf Corsepius

30 Oct 30 Oct

08:03

New subject: LSB-Konfomität der Distributoren (was: mysql)

Am Son, 2002-10-27 um 13.12 schrieb Philipp Thomas:

...

Ralf Corsepius [27 Oct 2002 05:17:52 +0100]:

...
[SuSE-8.1 und RH-8.0 besitzen /usr/lib/lsb/*_initd]

...

...
... warten wir auf den Tag, an dem die Distributoren anfangen, diese Scripte auch zu verwenden

Wozu? LSB ist dafür gedacht, das ISVs ihre Programme/Scripte nur einmal zu schreiben brauchen und diese dann auf LSB-konformen System ohne Änderung laufen (sofern sie sich an die Spezifikation halten). SuSE kann also problemlos weiterhin insserv verwenden. Offensichtlich ist der LSB derart ungenau, dass er diese Möglichkeit offenlässt.

...

...
und an dem die eigentlichen Bootscripte auch auf allen vorgeblich LSB-kompatiblen Systemen ohne jegliche Änderung laufen.

Auch hier habe ich den Eindruck, dass du den Sinn von LSB nicht so ganz verstanden hast (s.o.). Wenn Du meinst.

Allerdings gibt es Stellen im LSB die Deiner Interpretation widersprechen, z.B.: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/overpurp.html "The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB." Weiterhin, aus: http://www.linuxbase.org/FAQ.html "# Who is the LSB Specification written for? The LSB Specification is written for application developers and platform/operating system developers. For the application developer, it provides a set of rules which, when followed, will allow the completed application to run on a variety of platforms. For the platform/operating system developer it provides a minimal set of functionality required to support all applications written to comply to the LSB Specification." Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

...

Die Initscripte der Distributoren werden wahrscheinlich nie auf einem anderen System laufen, schon weil z.B. zusätzliche herstellerspezifische Headereinträge (die mit X-<hersteller> starten) ausgewertet werden, die zusätzliche Funktionalitäten bietet, die der Standard so nicht vorsieht. Ein Beispiel dafür sind die X-UnitedLinux-should-start Einträge.

Noch ein Zitat: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/initscrcomconv.html "LSB applications which need to execute script(s) at bootup and/or shutdown may provide one or more init.d files. These files are installed by the install_initd program described below, which copies it into a standard directory and makes whatever other adjustments (creation of symlinks, creation of entries in a database, etc.) are necessary so that the script can be run at boot-time." Beachte: "These files are installed by the install_initd program ..." Meine Interpretation: Man (Integratoren, Distributoren, Entwickler usw.) ist _verpflichtet_ install_initd zu verwenden, sobald eine "application" init.d-Scripte verwendet => chkconfig oder insserv sind Implementierungsdetail. Und noch ein Zitat: "The comment conventions described in this session are only required for use by LSB-compliant applications; system init scripts as provided by LSB-compliant run-time environments are not required to use the scheme outlined here." Hiermit weicht der LSB sich selbst auf, indem er es Distributoren freistellt, die install_initd zu verwenden, Applikationen (Und damit deren Entwicklern) aber dazu verpflichtet. Somit stellt sich die Frage wo "run-time environment" aufhört und wo "application" anfängt. (Ist mysql Teil des "run-time-environments" oder ist mysql eine "application"?). Weitgehend Ansichtssache und nur z.T. vom LSB abgedeckt (network, portmap sind z.B. vorgeschrieben, mysql z.B. aber nicht.). Und nun versetz dich in die Rolle eines Entwicklers, Integrators, SysAdmins o.ä. Sollte er inserv, chkconfig und was immer auch noch an proprietären Tools existieren mag, kennen und berücksichtigen müssen? Nein, da das nicht im Interesse eines (Industrie-) Standards liegen kann. Allerdings, steht aus meiner Sicht auch ausser Frage, dass der LSB nicht unbedingt zu den "starken, defakto-normativen Standards" gehört und mehr eine Art "kleinster gemeinsamer Nenner voller Widersprüche und mehrdeutiger Aussagen Detail", mit in der Praxis an dieser Stelle nur geringfügiger Bedeutung darstellt, . Ralf

Thorsten Kukuk

08:18

New subject: LSB-Konfomität der Distributoren (was: mysql)

On Wed, Oct 30, Ralf Corsepius wrote:

...

Am Son, 2002-10-27 um 13.12 schrieb Philipp Thomas:

...
Ralf Corsepius [27 Oct 2002 05:17:52 +0100]:

...
[SuSE-8.1 und RH-8.0 besitzen /usr/lib/lsb/*_initd]

...
...
... warten wir auf den Tag, an dem die Distributoren anfangen, diese Scripte auch zu verwenden

Wozu? LSB ist dafür gedacht, das ISVs ihre Programme/Scripte nur einmal zu schreiben brauchen und diese dann auf LSB-konformen System ohne Änderung laufen (sofern sie sich an die Spezifikation halten). SuSE kann also problemlos weiterhin insserv verwenden. Offensichtlich ist der LSB derart ungenau, dass er diese Möglichkeit offenlässt.

Nein, es ist technisch gar nicht moeglich, das Distributions-Init-Scripte 100% LSB konform sind. Und LSB fordert an keiner Stelle, das diese Scripte in irgendeiner Art und Weise LSB konform sind. Bei SuSE sind der Header, die Optionen und die Return-Werte LSB konform, weil es das Handling einfacher macht.

...

...
...
und an dem die eigentlichen Bootscripte auch auf allen vorgeblich LSB-kompatiblen Systemen ohne jegliche Änderung laufen.

Auch hier habe ich den Eindruck, dass du den Sinn von LSB nicht so ganz verstanden hast (s.o.). Wenn Du meinst.

Ja, er hat recht.

...

Allerdings gibt es Stellen im LSB die Deiner Interpretation widersprechen, z.B.: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/overpurp.html

"The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB."

Weiterhin, aus: http://www.linuxbase.org/FAQ.html "# Who is the LSB Specification written for? The LSB Specification is written for application developers and platform/operating system developers. For the application developer, it provides a set of rules which, when followed, will allow the completed application to run on a variety of platforms. For the platform/operating system developer it provides a minimal set of functionality required to support all applications written to comply to the LSB Specification."

Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

Nein. Deine Interpretation ist falsch. Du schreibst selber "Application developer". SuSE ist aber kein solcher, sondern ein Distributions-Hersteller.

...

Beachte: "These files are installed by the install_initd program ..."

Ja, aber Du solltest noch einmal lesen, an wen sich das wendet.

...

Meine Interpretation: Man (Integratoren, Distributoren, Entwickler usw.) ist _verpflichtet_ install_initd zu verwenden, sobald eine "application" init.d-Scripte verwendet => chkconfig oder insserv sind Implementierungsdetail.

Voellig falsch. Sonst waeren SuSE Linux 8.0 und 8.1 ja nicht LSB zertifiziert.

...

Und noch ein Zitat: "The comment conventions described in this session are only required for use by LSB-compliant applications; system init scripts as provided by LSB-compliant run-time environments are not required to use the scheme outlined here."

Hiermit weicht der LSB sich selbst auf, indem er es Distributoren freistellt, die install_initd zu verwenden, Applikationen (Und damit deren Entwicklern) aber dazu verpflichtet.

Nein, das ist keine Aufweichung. LSB hat sich niemals auf den Fahnen geschrieben, eine Linux-Distribution zu definieren, sondern ein Interface, damit LSB konforme Applikationen auf einer LSB konformen Distribution laufen koennen/

...

Somit stellt sich die Frage wo "run-time environment" aufhört und wo "application" anfängt. (Ist mysql Teil des "run-time-environments" oder ist mysql eine "application"?).

Wenn es vom Distributor komme, run-time, aber nicht vom LSB abgedeckt und somit kann keiner voraussetzen, das es vorhanden ist oder in welcher Art und Version.

...

Weitgehend Ansichtssache und nur z.T. vom LSB abgedeckt (network, portmap sind z.B. vorgeschrieben, mysql z.B. aber nicht.).

Auch falsch.

...

Und nun versetz dich in die Rolle eines Entwicklers, Integrators, SysAdmins o.ä. Sollte er inserv, chkconfig und was immer auch noch an proprietären Tools existieren mag, kennen und berücksichtigen müssen? Nein, da das nicht im Interesse eines (Industrie-) Standards liegen kann.

Lass den SysAdmin weg, und er hat fuer seine LSB konforme Applikation die LSB spezifizierten Tools zu verwenden.

...

Allerdings, steht aus meiner Sicht auch ausser Frage, dass der LSB nicht unbedingt zu den "starken, defakto-normativen Standards" gehört und mehr eine Art "kleinster gemeinsamer Nenner voller Widersprüche und mehrdeutiger Aussagen Detail", mit in der Praxis an dieser Stelle nur geringfügiger Bedeutung darstellt, .

Du hast wirklich den Sinn und Zweck vom LSB nicht verstanden. LSB will nicht die Konkurrenz und Neu-Entwicklungen/Verbesserungen verhindern, was bei Deinen Forderungen aber zwangslaeufig passieren wuerde, sondern ein Interface fuer ISVs zur Verfuegung stellen, damit die Ihre Applikation nicht auf jede Distribution extra portieren muessen. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B

Ralf Corsepius

09:09

New subject: LSB-Konfomität der Distributoren (was: mysql)

Am Mit, 2002-10-30 um 09.18 schrieb Thorsten Kukuk:

...

On Wed, Oct 30, Ralf Corsepius wrote:

...
Am Son, 2002-10-27 um 13.12 schrieb Philipp Thomas:

...
Ralf Corsepius [27 Oct 2002 05:17:52 +0100]:

...
[SuSE-8.1 und RH-8.0 besitzen /usr/lib/lsb/*_initd]

...
...
... warten wir auf den Tag, an dem die Distributoren anfangen, diese Scripte auch zu verwenden

Wozu? LSB ist dafür gedacht, das ISVs ihre Programme/Scripte nur einmal zu schreiben brauchen und diese dann auf LSB-konformen System ohne Änderung laufen (sofern sie sich an die Spezifikation halten). SuSE kann also problemlos weiterhin insserv verwenden. Offensichtlich ist der LSB derart ungenau, dass er diese Möglichkeit offenlässt.

Nein, es ist technisch gar nicht moeglich, das Distributions-Init-Scripte 100% LSB konform sind. Und LSB fordert an keiner Stelle, das diese Scripte in irgendeiner Art und Weise LSB konform sind. Bei SuSE sind der Header, die Optionen und die Return-Werte LSB konform, weil es das Handling einfacher macht.

...
...
...
und an dem die eigentlichen Bootscripte auch auf allen vorgeblich LSB-kompatiblen Systemen ohne jegliche Änderung laufen.

Auch hier habe ich den Eindruck, dass du den Sinn von LSB nicht so ganz verstanden hast (s.o.). Wenn Du meinst.

Ja, er hat recht. Da ihr beide SuSE-Mitarbeiter seit, erwarte ich auch von Dir keine andere Meinung ;)

...

...
Allerdings gibt es Stellen im LSB die Deiner Interpretation widersprechen, z.B.: http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/overpurp.html

"The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB."

Weiterhin, aus: http://www.linuxbase.org/FAQ.html "# Who is the LSB Specification written for? The LSB Specification is written for application developers and platform/operating system developers. For the application developer, it provides a set of rules which, when followed, will allow the completed application to run on a variety of platforms. For the platform/operating system developer it provides a minimal set of functionality required to support all applications written to comply to the LSB Specification."

Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

Nein. Deine Interpretation ist falsch. Du schreibst selber "Application developer". Aber ich - Um es auf den Punkt zu bringen: In deiner Interpretation des LSBs sind die LDB-*initd Scripte für mich ohne jeglichen Mehrwert - Sinnlose Featureitis, um es mal hart zu formulieren.

...

...
Beachte: "These files are installed by the install_initd program ..."

Ja, aber Du solltest noch einmal lesen, an wen sich das wendet. Application developers.

Gegenfrage: Wie soll ich (distributionsübergreifend) einen Daemon installieren, wenn die Installation von init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt sind und Detail-Wissen über die proprietären Tools erfordern? Oder um es konstruktiv zu formulieren: Zeige mir, wie ich (als Applikationdeveloper) distibutionsübergreifend ein initd Script schreiben/installieren kann.

...

...
Meine Interpretation: Man (Integratoren, Distributoren, Entwickler usw.) ist _verpflichtet_ install_initd zu verwenden, sobald eine "application" init.d-Scripte verwendet => chkconfig oder insserv sind Implementierungsdetail.

Voellig falsch. Sonst waeren SuSE Linux 8.0 und 8.1 ja nicht LSB zertifiziert. Und? Jede Zertifizierung ist nur so gut wie die ihr zugrundeliegende Zertifizierungssuite. Scheinbar wird die distributionsübergreifende Installation von 3rd-Party initd-Scripten nicht erfasst.

...

...
Und noch ein Zitat: "The comment conventions described in this session are only required for use by LSB-compliant applications; system init scripts as provided by LSB-compliant run-time environments are not required to use the scheme outlined here."

Hiermit weicht der LSB sich selbst auf, indem er es Distributoren freistellt, die install_initd zu verwenden, Applikationen (Und damit deren Entwicklern) aber dazu verpflichtet.

Nein, das ist keine Aufweichung. LSB hat sich niemals auf den Fahnen geschrieben, eine Linux-Distribution zu definieren, sondern ein Interface, damit LSB konforme Applikationen auf einer LSB konformen Distribution laufen koennen/ Offensichtlich fallen Applikationen, die initd-Scripte mit sich bringen und/oder bestimmte Dienste benötigen nicht darunter.

...

...
Und nun versetz dich in die Rolle eines Entwicklers, Integrators, SysAdmins o.ä. Sollte er inserv, chkconfig und was immer auch noch an proprietären Tools existieren mag, kennen und berücksichtigen müssen? Nein, da das nicht im Interesse eines (Industrie-) Standards liegen kann.

Lass den SysAdmin weg, Der SysAdmin kommt dann ins Spiel wenn er ein 3rd-Party Dienstprogramm installieren soll.

...

und er hat fuer seine LSB konforme Applikation die LSB spezifizierten Tools zu verwenden. Nur wie? Klar er kann seine init.d Scripte auf die von der jeweiligen Distri verwendeten "Defacto-Standards" anpassen. - Wie aber soll das distributionsübergreifend funktionieren?

So? # chkconfig: - 78 12 ### BEGIN INIT INFO # Provides: foobard # Required-Start: $network $remote_fs # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: # Description: Start the MySQL database server # X-Mandrake-... # X-SuSE-... # X-Debian-... # X-Redhat-... # X-UnitedLinux-... # X-FooBar-... ### END INIT INFO Das kann's ja nun wirklich nicht sein.

...

...
Allerdings, steht aus meiner Sicht auch ausser Frage, dass der LSB nicht unbedingt zu den "starken, defakto-normativen Standards" gehört und mehr eine Art "kleinster gemeinsamer Nenner voller Widersprüche und mehrdeutiger Aussagen Detail", mit in der Praxis an dieser Stelle nur geringfügiger Bedeutung darstellt, .

Du hast wirklich den Sinn und Zweck vom LSB nicht verstanden. LSB will nicht die Konkurrenz und Neu-Entwicklungen/Verbesserungen verhindern, was bei Deinen Forderungen aber zwangslaeufig passieren wuerde, sondern ein Interface fuer ISVs zur Verfuegung stellen, damit die Ihre Applikation nicht auf jede Distribution extra portieren muessen. Worauf ich raus will: Ich sehe keinen effektiven Mehrwert hinter den LSB-initd Scripten und ich sehe nicht wie man sie distributionsübergreifend einsetzen könnte. Ich betrachte den LSB an dieser Stelle als zu schwach und ungenau formuliert. Auch sehe ich an keiner Stelle, dass sich der LSB _nur_ an ISV's wendet.

Ralf

Thorsten Kukuk

09:26

New subject: LSB-Konfomität der Distributoren (was: mysql)

On Wed, Oct 30, Ralf Corsepius wrote:

...

...
...
Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

Nein. Deine Interpretation ist falsch. Du schreibst selber "Application developer". Aber ich - Um es auf den Punkt zu bringen: In deiner Interpretation des LSBs sind die LDB-*initd Scripte für mich ohne jeglichen Mehrwert - Sinnlose Featureitis, um es mal hart zu formulieren.

Wieso das? Hast Du schon mal einen Bug-Report gegen LSB ausgefuellt, wenn es Deiner ansicht nach flasch ist?

...

...
...
Beachte: "These files are installed by the install_initd program ..."

Ja, aber Du solltest noch einmal lesen, an wen sich das wendet. Application developers.

Gegenfrage: Wie soll ich (distributionsübergreifend) einen Daemon installieren, wenn die Installation von init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt sind und Detail-Wissen über die proprietären Tools erfordern?

Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil der Distribution ist, mit Distributions-Board-Mittel. Wenn er eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo ist das Problem? LSB hatte niemals im Sinn, die Administration eines Systems zu standarisieren. Das will LSB auch gar nicht, weil dieses zwangslaeufig zum Stop der weiteren Linux Entwicklung fuehren wuerde.

...

Oder um es konstruktiv zu formulieren: Zeige mir, wie ich (als Applikationdeveloper) distibutionsübergreifend ein initd Script schreiben/installieren kann.

Konstruktive Gegenfrage: Wo ist da Dein Problem? Diese Frage ist doch nun wirklich zur genuege im LSB behandelt und hat rein gar nichts damit zu tun, wie die Init-Scripte des Distributors aussehen.

...

...
...
Meine Interpretation: Man (Integratoren, Distributoren, Entwickler usw.) ist _verpflichtet_ install_initd zu verwenden, sobald eine "application" init.d-Scripte verwendet => chkconfig oder insserv sind Implementierungsdetail.

Voellig falsch. Sonst waeren SuSE Linux 8.0 und 8.1 ja nicht LSB zertifiziert. Und? Jede Zertifizierung ist nur so gut wie die ihr zugrundeliegende Zertifizierungssuite. Scheinbar wird die distributionsübergreifende Installation von 3rd-Party initd-Scripten nicht erfasst.

Meckern, meckern, meckern. Wo ist Dein Problem?

...

...
Nein, das ist keine Aufweichung. LSB hat sich niemals auf den Fahnen geschrieben, eine Linux-Distribution zu definieren, sondern ein Interface, damit LSB konforme Applikationen auf einer LSB konformen Distribution laufen koennen/ Offensichtlich fallen Applikationen, die initd-Scripte mit sich bringen und/oder bestimmte Dienste benötigen nicht darunter.

Und noch immer: Wo ist Dein Problem?

...

...
...
Und nun versetz dich in die Rolle eines Entwicklers, Integrators, SysAdmins o.ä. Sollte er inserv, chkconfig und was immer auch noch an proprietären Tools existieren mag, kennen und berücksichtigen müssen? Nein, da das nicht im Interesse eines (Industrie-) Standards liegen kann.

Lass den SysAdmin weg, Der SysAdmin kommt dann ins Spiel wenn er ein 3rd-Party Dienstprogramm installieren soll.

Warum das nicht? install_initd?

...

...
und er hat fuer seine LSB konforme Applikation die LSB spezifizierten Tools zu verwenden. Nur wie? Klar er kann seine init.d Scripte auf die von der jeweiligen Distri verwendeten "Defacto-Standards" anpassen. - Wie aber soll das distributionsübergreifend funktionieren?

Warum muss er LSB konforme init Scripte anpassen?

...

So?

# chkconfig: - 78 12

Das ist nicht LSB konform, diese Zeile loeschen.

...

### BEGIN INIT INFO # Provides: foobard # Required-Start: $network $remote_fs # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: # Description: Start the MySQL database server # X-Mandrake-... # X-SuSE-... # X-Debian-... # X-Redhat-... # X-UnitedLinux-... # X-FooBar-... ### END INIT INFO

Das kann's ja nun wirklich nicht sein.

Nein, Du hast es immer noch nicht verstanden. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B

Ralf Corsepius

31 Oct 31 Oct

06:14

New subject: LSB-Konfomität der Distributoren (was: mysql)

Am Mit, 2002-10-30 um 10.26 schrieb Thorsten Kukuk:

...

On Wed, Oct 30, Ralf Corsepius wrote:

...
...
...
Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

Nein. Deine Interpretation ist falsch. Du schreibst selber "Application developer". Aber ich - Um es auf den Punkt zu bringen: In deiner Interpretation des LSBs sind die LDB-*initd Scripte für mich ohne jeglichen Mehrwert - Sinnlose Featureitis, um es mal hart zu formulieren.

...

...
Gegenfrage: Wie soll ich (distributionsübergreifend) einen Daemon installieren, wenn die Installation von init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt sind und Detail-Wissen über die proprietären Tools erfordern?

Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil der Distribution ist, mit Distributions-Board-Mittel. Wenn er eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo ist das Problem? Wir reden aneinander vorbei: ICH schreibe, portiere, installiere einen Daemon, der weder LSB-Applikation ist, noch Bestandteil einer Distri ist, aber auf vorgeblich LSB-kompatiblem OSen laufen soll und will meinen Aufwand als Entwickler/Installer/SysAdmin minimieren. Dabei tritt die Frage auf: /usr/lib/lsb/* verwenden oder im Sumpf proprietärer Scripte versinken?

Mein Fazit ist: Die LSB-/usr/lib/lsb/*initd-Scripte helfen mir dabei nicht, da Sie immer noch Detailwissen über eine Vielzahl von Distributoren erforderen, deshalb faktisch in der Praxis, trotz LSB-Zertifizierung der Distris, nicht funktionieren.

...

LSB hatte niemals im Sinn, die Administration eines Systems zu standarisieren. Das will LSB auch gar nicht, weil dieses zwangslaeufig zum Stop der weiteren Linux Entwicklung fuehren wuerde.

...
Oder um es konstruktiv zu formulieren: Zeige mir, wie ich (als Applikationdeveloper) distibutionsübergreifend ein initd Script schreiben/installieren kann.

Konstruktive Gegenfrage: Wo ist da Dein Problem? Diese Frage ist doch nun wirklich zur genuege im LSB behandelt und hat rein gar nichts damit zu tun, wie die Init-Scripte des Distributors aussehen. Gegenfrage zur Gegenfrage: Warum verwendet SuSE die LSB-Scripte dann nicht? Es wäre nur konsequent und LSB-konform. Der LSB schreibt es zwar nicht vor, verbietet es aber auch nicht.

...

...
...
...
Meine Interpretation: Man (Integratoren, Distributoren, Entwickler usw.) ist _verpflichtet_ install_initd zu verwenden, sobald eine "application" init.d-Scripte verwendet => chkconfig oder insserv sind Implementierungsdetail.

Voellig falsch. Sonst waeren SuSE Linux 8.0 und 8.1 ja nicht LSB zertifiziert. Und? Jede Zertifizierung ist nur so gut wie die ihr zugrundeliegende Zertifizierungssuite. Scheinbar wird die distributionsübergreifende Installation von 3rd-Party initd-Scripten nicht erfasst.

Meckern, meckern, meckern. Ich danke für diesen sachlichen und wirklich konstruktiven Betrag. ;-)

...

Wo ist Dein Problem? Technisch betrachtet: Ein Detailproblem mit dem LSB (siehe oben).

Hinzu kommt ein weitergehendes, vorwiegend politisches: Zertifizierungen und Standards sagen nichts über deren Qualität und Bedeutung aus. Sie müssen kritisch hinterfragt werden, da sie oftmals nur Marketinginstrument und Rechtfertigung sind sich einen Orden mehr auf die Brust zu heften oder einen Aufkleber mehr auf die Packung zu kleben. In diesem Sinne betrachte ich den LSB einerseits als wünschenswerte technische Initiative, anderseits aber auch als Marketinginstrument, das bekanntermassen nicht zuletzt von SuSE gepuscht wurde/wird. Ich nehme diesen "Orden", den sich SuSE und andere da an die Brust/Packung heften genauso zu Kenntnis, wie das GS, TÜV, ISO-900x, Demeter, Bioland, Fresenius, MIL, GMA-Zertifikate oder das Warentest oder ComputerBild Testurteil an anderen Produkten. Deshalb nehme ich mir die Freiheit und das Recht den LSB kritisch zu hinterfragen. Dabei komme ich momentan zum Ergebnis, dass der LSB zwar einerseits an einigen Stellen durchaus eine wünschenswerte Standardisierungen erreicht hat (Ob er möglicherweise aber nur offensichtliche, unvermeidbare Entwicklungen dokumentiert hat sei dahin gestellt), andererseits aber auch immer noch vieles offen und zu wünschen übrig lässt. Die /usr/lib/lsb/*initd Scripte gehören nach meinem momentanem Eindruck zu letzter Kategorie. Ralf

jsj-hb＠t-online.de

06:38

New subject: LSB-Konfomität der Distributoren (=?iso-8859-15?q?was=3A mysql?=)

Hi, On Thursday 31 October 2002 07:14, Ralf Corsepius wrote:

...

Am Mit, 2002-10-30 um 10.26 schrieb Thorsten Kukuk:

...
On Wed, Oct 30, Ralf Corsepius wrote:

...
Gegenfrage: Wie soll ich (distributionsübergreifend) einen Daemon installieren, wenn die Installation von init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt sind und Detail-Wissen über die proprietären Tools erfordern?

Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil der Distribution ist, mit Distributions-Board-Mittel. Wenn er eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo ist das Problem?

Wir reden aneinander vorbei: ICH schreibe, portiere, installiere einen Daemon, der weder LSB-Applikation ist, noch Bestandteil einer Distri ist, aber auf vorgeblich LSB-kompatiblem OSen laufen soll und will meinen Aufwand als Entwickler/Installer/SysAdmin minimieren. Dabei tritt die Frage auf: /usr/lib/lsb/* verwenden oder im Sumpf proprietärer Scripte versinken?

Na bitte, dann bist Du ein ISV, der versucht, seine(*) Software LSB-compliant auf den Markt zu bringen. (*) ob selbstgeschriebene Software oder GPL aus dem Netz setze ich jetzt mal gleich.

...

Mein Fazit ist: Die LSB-/usr/lib/lsb/*initd-Scripte helfen mir dabei nicht, da Sie immer noch Detailwissen über eine Vielzahl von Distributoren erforderen, deshalb faktisch in der Praxis, trotz LSB-Zertifizierung der Distris, nicht funktionieren.

Doch, sie helfen Dir. http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB.html#INITSRCINSTRM Da steht drin, wie Du sie verwendest. Wie die init.d-scripte aussehen müssen, steht dirket drüber.

...

Gegenfrage zur Gegenfrage: Warum verwendet SuSE die LSB-Scripte dann nicht? Es wäre nur konsequent und LSB-konform. Der LSB schreibt es zwar nicht vor, verbietet es aber auch nicht.

Eben, weil SuSE es selbst nicht muss. Das LSB-Zeug ist eine minimale Voraussetzung, die eine Distribution mitbringen muss, damit ein ISV (der keinerlei Verbindung zu jedwedem Distributor hat) Software auf dem Markt bringen kann, die auf _jeder LSB-konformen_ Distrbution ohne hacken läuft. Sicherlich wäre es gut, wenn ein Distributor diese Tools auch anwenden würde (dann würden alle install-scripte gleich aussehen), aber das wäre in meinen Augen troztdem Bullshit, weil ein Distributor einen eigenen Weg bei der Installation von Software gehen kann, diesen eigenen für eigene Programme nutzen kann, denselben aber für die ISVs zusammenpacken und in den LSB-konforment scripts zusammenfasst.

...

...
Wo ist Dein Problem?

Technisch betrachtet: Ein Detailproblem mit dem LSB (siehe oben).

Hinzu kommt ein weitergehendes, vorwiegend politisches: Zertifizierungen und Standards sagen nichts über deren Qualität und Bedeutung aus. Sie müssen kritisch hinterfragt werden, da sie oftmals nur Marketinginstrument und Rechtfertigung sind sich einen Orden mehr auf die Brust zu heften oder einen Aufkleber mehr auf die Packung zu kleben.

In diesem Sinne betrachte ich den LSB einerseits als wünschenswerte technische Initiative, anderseits aber auch als Marketinginstrument, das bekanntermassen nicht zuletzt von SuSE gepuscht wurde/wird.

Ich nehme diesen "Orden", den sich SuSE und andere da an die Brust/Packung heften genauso zu Kenntnis, wie das GS, TÜV, ISO-900x, Demeter, Bioland, Fresenius, MIL, GMA-Zertifikate oder das Warentest oder ComputerBild Testurteil an anderen Produkten.

Deshalb nehme ich mir die Freiheit und das Recht den LSB kritisch zu hinterfragen.

Dabei komme ich momentan zum Ergebnis, dass der LSB zwar einerseits an einigen Stellen durchaus eine wünschenswerte Standardisierungen erreicht hat (Ob er möglicherweise aber nur offensichtliche, unvermeidbare Entwicklungen dokumentiert hat sei dahin gestellt), andererseits aber auch immer noch vieles offen und zu wünschen übrig lässt.

Die /usr/lib/lsb/*initd Scripte gehören nach meinem momentanem Eindruck zu letzter Kategorie.

Ich verstehe nach Deinem letzten Posting immer noch nicht, was Dir nicht gefällt. Ich habe allerdings den Eindruck, dass Du von "LSB" mehr erwartest, als eigentlich definiert ist. Das wird wohl auch das sein, was Thomas und Thorsten Dir sagen wollten, es nur nicht direkt hingeschrieben haben. Ich sehe die Funktionalität als add-on, damit es endlich Software für Linux gib und nicht nur für RedHat (in den USA de-facto Linux-Standard, ein anderes Linux gibt es gar nicht).

...

Ralf

Stefan -- Stefan Schmidt jsj-hb at t-online dot de

Thorsten Kukuk

07:34

New subject: LSB-Konfomität der Distributoren (was: mysql)

On Thu, Oct 31, Ralf Corsepius wrote:

...

Am Mit, 2002-10-30 um 10.26 schrieb Thorsten Kukuk:

...
On Wed, Oct 30, Ralf Corsepius wrote:

...
...
...
Hier ist explizit von "Application developer" und "Industrial Standards" die Rede. Somit widerspricht Deine (und offensichtlich SuSE's) Interpretation der Intension des LSB.

Nein. Deine Interpretation ist falsch. Du schreibst selber "Application developer". Aber ich - Um es auf den Punkt zu bringen: In deiner Interpretation des LSBs sind die LDB-*initd Scripte für mich ohne jeglichen Mehrwert - Sinnlose Featureitis, um es mal hart zu formulieren.

...
...
Gegenfrage: Wie soll ich (distributionsübergreifend) einen Daemon installieren, wenn die Installation von init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt sind und Detail-Wissen über die proprietären Tools erfordern?

Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil der Distribution ist, mit Distributions-Board-Mittel. Wenn er eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo ist das Problem? Wir reden aneinander vorbei: ICH schreibe, portiere, installiere einen Daemon, der weder LSB-Applikation ist, noch Bestandteil einer Distri ist, aber auf vorgeblich LSB-kompatiblem OSen laufen soll und will meinen Aufwand als Entwickler/Installer/SysAdmin minimieren. Dabei tritt die Frage auf: /usr/lib/lsb/* verwenden oder im Sumpf proprietärer Scripte versinken?

Wenn er keine LSB konforme Applikation werden soll: Im Sumpf proprietärer Scripte versinken. Wie kannst Du erwarten, das LSB Dein Problem lösen soll, wenn Du es nicht benutzen willst?

...

Mein Fazit ist: Die LSB-/usr/lib/lsb/*initd-Scripte helfen mir dabei nicht, da Sie immer noch Detailwissen über eine Vielzahl von Distributoren erforderen, deshalb faktisch in der Praxis, trotz LSB-Zertifizierung der Distris, nicht funktionieren.

Schwachsinn. Du willst sie nicht benutzen. Das ist alles. Du willst unbedingt mehr, als vom LSB zur Verfügung gestellt wird, das ist OK. Dann darfst Du aber auch nicht über LSB jammern.

...

...
Konstruktive Gegenfrage: Wo ist da Dein Problem? Diese Frage ist doch nun wirklich zur genuege im LSB behandelt und hat rein gar nichts damit zu tun, wie die Init-Scripte des Distributors aussehen. Gegenfrage zur Gegenfrage: Warum verwendet SuSE die LSB-Scripte dann nicht? Es wäre nur konsequent und LSB-konform. Der LSB schreibt es zwar nicht vor, verbietet es aber auch nicht.

Hatten wir schon. Liess noch mal im Thread nach.

...

Deshalb nehme ich mir die Freiheit und das Recht den LSB kritisch zu hinterfragen.

Du hinterfragst es nicht, Du willst es nicht warhaben, weil LSB Dich einschränkt (wie jeder Standard), Du Dich aber nicht an die Einschränkung halten willst.

...

Die /usr/lib/lsb/*initd Scripte gehören nach meinem momentanem Eindruck zu letzter Kategorie.

Warum? Sie installieren ein init Script und sie deinstallieren es wieder. Genau das, was sie machen sollen, und nicht mehr. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B

Philipp Thomas

30 Oct 30 Oct

09:35

New subject: LSB-Konfomität der Distributoren (was: mysql)

Ralf Corsepius [30 Okt 2002 10:09:26 +0100]:

...

### BEGIN INIT INFO # Provides: foobard # Required-Start: $network $remote_fs # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: # Description: Start the MySQL database server ### END INIT INFO

Das müsste reichen und tut es in den meisten Fällen auch. Die X- Geschichten kannst du als Applikationsentwickler schlicht ignorieren.

...

Das kann's ja nun wirklich nicht sein.

Was fehlt dir?

...

Worauf ich raus will: Ich sehe keinen effektiven Mehrwert hinter den LSB-initd Scripten und ich sehe nicht wie man sie distributionsübergreifend einsetzen könnte.

Denk mal an die Zeit vor LSB, wo es keinerlei Möglichkeiten gab, die Abhängigkeiten zwischen Init-Skripten anzugeben, das Verzeichnis für die Skripte von der Distribution abhing etc. Im Vergleich dazu ist der LSB konforme Weg doch eine erhebliche Verbesserung.

...

Auch sehe ich an keiner Stelle, dass sich der LSB _nur_ an ISV's wendet.

Es steht dir frei, dies auf der öffentlichen LSB-Liste anzusprechen, wenn dir Thorstens und meine Aussage nicht reicht. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de

Ralf Corsepius

31 Oct 31 Oct

06:00

New subject: LSB-Konfomität der Distributoren (was: mysql)

Am Mit, 2002-10-30 um 10.35 schrieb Philipp Thomas:

...

Ralf Corsepius [30 Okt 2002 10:09:26 +0100]:

...

...
Das kann's ja nun wirklich nicht sein.

Was fehlt dir? Probiers aus. Es funktioniert in der Praxis nicht.

z.B. bei RH geht ohne # ckconfig nicht viel (Es ist ein Kommentar, deshalb LSB-compliant, wird aber von den RH-Tools benötigt), SuSE's Gegenstück zu RH's /etc/init.d/functions habe ich noch nicht gefunden, die /usr/lib/lsb/*initd Scripte scheinen ebenfalls nicht call-kompatibel zu sein, davon mal abgesehen dass /usr/lib/lsb als Pfad nicht unbedingt geschickt gewählt ist. Trotzdem behaupten beide Distris von sich LSB-1.2 kompatibel zu sein. Wer in diesem speziellen Fall nun nicht wirklich LSB-compliant ist und ob die LSB-Certification-Suite die hier diskutierte Problematik abdeckt, sei nun mal dahingestellt

...

...
Worauf ich raus will: Ich sehe keinen effektiven Mehrwert hinter den LSB-initd Scripten und ich sehe nicht wie man sie distributionsübergreifend einsetzen könnte.

Denk mal an die Zeit vor LSB, wo es keinerlei Möglichkeiten gab, die Abhängigkeiten zwischen Init-Skripten anzugeben, das Verzeichnis für die Skripte von der Distribution abhing etc. Ich weiss, von den BSD-bootscript-Zeiten mal abgesehen.

...

Im Vergleich dazu ist der LSB konforme Weg doch eine erhebliche Verbesserung. Ja, aus meiner Sicht geht er aber nur den halben Weg.

...

...
Auch sehe ich an keiner Stelle, dass sich der LSB _nur_ an ISV's wendet.

Es steht dir frei, dies auf der öffentlichen LSB-Liste anzusprechen, wenn dir Thorstens und meine Aussage nicht reicht. Nun, meiner Meinung nach widersprechen die LSB Webseiten Eurer Interpretation ganz eindeutig:

http://www.linuxbase.org/FAQ.html "# Who is the LSB Specification written for? The LSB Specification is written for application developers and platform/operating system developers. For the application developer, it provides a set of rules which, when followed, will allow the completed application to run on a variety of platforms. For the platform/operating system developer it provides a minimal set of functionality required to support all applications written to comply to the LSB Specification." Dort steht: "application developers and platform/operating system developers" - Das umfasst zwar ISVs, beschränkt es aber nicht darauf. "Variety of platforms" .. Vielzahl von Plattformen, Ich interpretiere das als distributionsübergreifend. Ralf

Thorsten Kukuk

07:30

New subject: LSB-Konfomität der Distributoren (was: mysql)

On Thu, Oct 31, Ralf Corsepius wrote:

...

Am Mit, 2002-10-30 um 10.35 schrieb Philipp Thomas:

...
Ralf Corsepius [30 Okt 2002 10:09:26 +0100]:

...
...
Das kann's ja nun wirklich nicht sein.

Was fehlt dir? Probiers aus. Es funktioniert in der Praxis nicht.

z.B. bei RH geht ohne # ckconfig nicht viel (Es ist ein Kommentar, deshalb LSB-compliant, wird aber von den RH-Tools benötigt), SuSE's

Ja und, RH darf es ja benutzen, wenn sie wollen.

...

Gegenstück zu RH's /etc/init.d/functions habe ich noch nicht gefunden, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ist das LSB? NEIN! Also, warum sollte es ein Gegenstück geben? Bleib bei den Sachen, die LSB definiert hat! Nimm /lib/lsb/init-functions

...

die /usr/lib/lsb/*initd Scripte scheinen ebenfalls nicht call-kompatibel

Wieso sind sie nicht call compatibel? Sie erwarten genau ein Argument, wie Du wunderschön im Standard nachlesen kannst.

...

zu sein, davon mal abgesehen dass /usr/lib/lsb als Pfad nicht unbedingt geschickt gewählt ist.

Schon einen Bug an LSB assigned?

...

Trotzdem behaupten beide Distris von sich LSB-1.2 kompatibel zu sein.

Sind sie ja auch. Du versuchst anscheinend nur ein Script zu schreiben, welches Distributionsspezifische Funktionen benutzt, das geht nicht.

...

Wer in diesem speziellen Fall nun nicht wirklich LSB-compliant ist und ob die LSB-Certification-Suite die hier diskutierte Problematik abdeckt, sei nun mal dahingestellt

Hier bist Du das Problem. Schmeiß den Distri-Spezifiscen Krempel raus.

...

Nun, meiner Meinung nach widersprechen die LSB Webseiten Eurer Interpretation ganz eindeutig:

http://www.linuxbase.org/FAQ.html "# Who is the LSB Specification written for? The LSB Specification is written for application developers and platform/operating system developers. For the application developer, it provides a set of rules which, when followed, will allow the completed application to run on a variety of platforms. For the platform/operating system developer it provides a minimal set of functionality required to support all applications written to comply to the LSB Specification."

Dort steht: "application developers and platform/operating system developers" - Das umfasst zwar ISVs, beschränkt es aber nicht darauf.

Arg, ich gebs auf. Du willst einfach nichts verstehen. Wo ist der Unterschied? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B

Ralf Corsepius

08:12

New subject: LSB-Konfomität der Distributoren (was: mysql)

Am Don, 2002-10-31 um 08.30 schrieb Thorsten Kukuk:

...

Arg, ich gebs auf. Du willst einfach nichts verstehen. Ich auch, Wir reden aneinander vorbei.

EOS Ralf

Ralf Corsepius

25 Oct 25 Oct

15:19

Am Fre, 2002-10-25 um 16.35 schrieb Thorsten Haude:

...

Moin,

* Peter Wiersig [02-10-25 15:55]:

...
Willst du, das nach jedem Systemstart der MySQL-Server startet, gib als root "insserv /etc/init.d/mysql" ein

Ist das was Neues von SuSE oder gibt's das für alle Linuxe? Weder noch.

AFAICT, gibt's insserv nur bei SuSE und das seit SuSE-7.3. [SuSE's Gegenstück zu chkconfig und service. Mir ist keine andere Disti bekannt, die es ebenfalls benutzt.] Ralf

Martin

14:07

Frank Kaldewey wrote:

...

Hallo,

ich habe mysql mit yast auf suse 8.0 installiert

linux:/bin # mysql start ERROR 2002: Can 't connect to local MYSQL server through socket' /var/lib/mysql/mysql.sock' (2)

/var/lib/mysql der ordner ist leer

bei ältern versionen 7.3 6.4 hat ich damit keine probleme

Vielen Dank

Frank

Hallo Frank! Versuch doch einmal folgenden Weg: auf der Konsole 'mysql_db_install' eingeben anschließend 'chown mysql:daemon /var/lib/mysql/*' Danach sollte Dein Problem eigentlich gelöst sein. Gruß, Martin Grabbel

7854

Age (days ago)

7860

Last active (days ago)

List overview

Download

27 comments

9 participants

participants (9)

Frank Kaldewey
jsj-hb＠t-online.de
Kroll, Volker
Martin
Peter Wiersig
Philipp Thomas
Ralf Corsepius
Thorsten Haude
Thorsten Kukuk

mysql

Frank Kaldewey

Kroll, Volker

Frank Kaldewey

Thorsten Haude

Thorsten Haude

Peter Wiersig

Frank Kaldewey

Thorsten Haude

Peter Wiersig

Thorsten Haude

Ralf Corsepius

Peter Wiersig

Philipp Thomas

Ralf Corsepius

Philipp Thomas

Ralf Corsepius

Thorsten Kukuk

Ralf Corsepius

Thorsten Kukuk

Ralf Corsepius

jsj-hb＠t-online.de

Thorsten Kukuk

Philipp Thomas

Ralf Corsepius

Thorsten Kukuk

Ralf Corsepius

Ralf Corsepius

Martin

tags

participants (9)