Debian: PHP 5 statt PHP 4

[Marc Reichelt]

Hallo an alle,

ich würde meinen Server (der derzeit auf Debian Sarge 3.1 mit den frischesten Updates läuft) gerne auf Etch aktualisieren, um PHP5 zu nutzen. Allerdings ist  Etch ja immer noch in der Testing-Phase, und soll erst zu Beginn des nächsten Jahres "stable" werden.

Auch, wenn Etch noch länger auf sich warten lässt, würde ich zumindest jetzt schon PHP5 statt PHP4 nutzen können.

Nun meine Frage hierzu: Welche der beiden folgenden Möglichkeiten ist besser:

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?
2. Die PHP5-Pakete aus dem Etch-Repository in Sarge einspielen?
3. Eventuell eine andere Möglichkeit?

Und wenn ich die zweite Möglichkeit erwägen sollte: Wie realisiere ich die beste Konformität, um später einfach auf Etch upgraden zu können?

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Andi]

3. Eventuell eine andere Möglichkeit?

wie wärs mit PHP5 einfach selbst kompilieren?

[Marc Reichelt]

Hallo Andi,

3. Eventuell eine andere Möglichkeit?
   wie wärs mit PHP5 einfach selbst kompilieren?

Würde ich ungerne - bei Etch könnte ich immerhin schon die aktuellsten Updates über einen simplen Aufruf des Tools "apt-get" einspielen.
Außerdem hatte ich mir beim Einrichten meines Debian Servers gesagt, dass ich keine Pakete selbst kompilieren und entsprechend aktualisieren möchte. :-)

Noch eine Info zur Technik: Ich verwende PHP als Apache-Modul.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Andi]

Hi Marc,

tja, schlecht ;-) wir haben uns halt 1x die Arbeit gemacht und das Ding komplett selbst aufgesetzt, mit Apache und PHP, und da kannst halt nun ohne Probleme die neusten Updates reinkompilieren... von daher werde ich dir dann auch nicht mehr wirklich helfen können ;-) sorry!

Andi

[Andreas Görtz]

Hi Marc,

Auch, wenn Etch noch länger auf sich warten lässt, würde ich zumindest jetzt schon PHP5 statt PHP4 nutzen können.

IMHO ist es bei intensiver Nutzung von PHP immens wichtig, immer die aktuellste Version installiert zu haben. Ich denke aber, dass es auch bei Etch immer relativ lange dauert, bis diese den Weg in die Paketverwaltung findet.

3. Eventuell eine andere Möglichkeit?

Schau Dir mal die Backports und Dotdeb, bei dem Du nebenbei eine aktuelle MySQL-Version dazubekommst, an. Bei Letzterem bist du allerdings auf "eine Person" angewiesen. Dennoch habe ich bisher kaum schlechte Erfahrungen damit gemacht.

Gruß,
Andreas.

[Marc Reichelt]

Hallo Andreas,

Auch, wenn Etch noch länger auf sich warten lässt, würde ich zumindest jetzt schon PHP5 statt PHP4 nutzen können.

IMHO ist es bei intensiver Nutzung von PHP immens wichtig, immer die aktuellste Version installiert zu haben. Ich denke aber, dass es auch bei Etch immer relativ lange dauert, bis diese den Weg in die Paketverwaltung findet.

Bei mir war es bislang nicht immens wichtig, da alle meine PHP-Skripte bislang unter PHP 4 geschrieben, getestet und eingesetzt wurden.
Allerdings möchte ich nun doch für ein neues Projekt ("Linux Drivers") auf PHP 5 aktualisieren, da OOP unter PHP 4 wirklich schlecht ist. Meine Kollegen haben zu Beginn versucht, mich zu PHP 5 zu bewegen, aber ich wollte unbedingt auf die offiziellen Quellen setzen. Nun habe ich meine Meinung geändert (vielleicht auch, weil Weihnachten ist ;), und möchte uns die Entwicklung "ein wenig" vereinfachen. Außerdem macht OOP in PHP 5 mehr Spaß.

3. Eventuell eine andere Möglichkeit?

Schau Dir mal die Backports und Dotdeb, bei dem Du nebenbei eine aktuelle MySQL-Version dazubekommst, an. Bei Letzterem bist du allerdings auf "eine Person" angewiesen. Dennoch habe ich bisher kaum schlechte Erfahrungen damit gemacht.

Ich denke auch, dass man mit diesen Paketen arbeiten kann.
Allerdings würde ich schon gerne die "offiziellen" Quellen bevorzugen, wenn möglich. Und sogar auch dann, wenn das ganze Server-System 2-3 Monate lang als "testing" laufen würde (bis Etch "stable" wird).

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[hkl]

Hallo !

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?

Hab ich versucht und bin derart auf die Nase gefallen dass eine Nueinstalltion faellig war:

GDM / KDM / XDM starteten nicht mehr.
Selbst startx klappte nicht.
Konnte zwar einzelne (Log-)Fehler aber nicht die Symptome.

Gruesse

Holger

[Mathias Brodala]

Hallo hkl.

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?

Hab ich versucht und bin derart auf die Nase gefallen dass eine Nueinstalltion faellig war:

Du verwechselst gerade Debian Sid (Unstable, fahre ich zum Beispiel) mit Debian Etch (Testing), bald Stable.

GDM / KDM / XDM starteten nicht mehr.
Selbst startx klappte nicht.

In solchen Fällen sind aber /var/log/Xorg.0.log und ~/.xsession-errors stets sehr aufschlussreich.

Konnte zwar einzelne (Log-)Fehler aber nicht die Symptome.

Du hättest auch nach Bugreports suchen können.

Einen schönen Sonntag noch.

Gruß, Mathias

[hkl]

Hallo !

Hallo hkl.

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?

Hab ich versucht und bin derart auf die Nase gefallen dass eine Nueinstalltion faellig war:

Du verwechselst gerade Debian Sid (Unstable, fahre ich zum Beispiel) mit Debian Etch (Testing), bald Stable.

Mag sein; weiss ich nicht mehr.
Die Quintessenz ist fuer mich aber die gleiche:

Never touch a running Debian !
;-)

GDM / KDM / XDM starteten nicht mehr.
Selbst startx klappte nicht.

In solchen Fällen sind aber /var/log/Xorg.0.log und ~/.xsession-errors stets sehr aufschlussreich.

Konnte zwar einzelne (Log-)Fehler aber nicht die Symptome.

Du hättest auch nach Bugreports suchen können.

Hab damals so ziemlich alles greped was irgendwie nach "X" und "Log" klang; Testausschriften in Startskripts eingefuegt etc.

Google brachte auch keinen Aufschluss.

Nach einem Abend hab ich's aufgegeben und ueber Nacht das System neu installieren lassen.

Hat letztlich Zeit gespart - solche Bugs mag ein Maintainer downtracken.
Not me !

Gruesse

Holger

Einen schönen Sonntag noch.

Gruß, Mathias

[Marc Reichelt]

Hallo hkl,

Hab ich versucht und bin derart auf die Nase gefallen dass eine Nueinstalltion faellig war:

GDM / KDM / XDM starteten nicht mehr.
Selbst startx klappte nicht.

Damit werde ich kein Problem haben. Auf dem Server läuft weder GDM, KDM noch XDM - selbst das große X nicht. ;-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[hkl]

Hallo !

Hallo hkl,

Hab ich versucht und bin derart auf die Nase gefallen dass eine Nueinstalltion faellig war:

GDM / KDM / XDM starteten nicht mehr.
Selbst startx klappte nicht.

Damit werde ich kein Problem haben. Auf dem Server läuft weder GDM, KDM noch XDM - selbst das große X nicht. ;-)

Na ja, vim lief noch... ;-)

Wuerde mir auf jeden Fall vorher einen package-dump ziehen; etwa mittels
dpkg -l > mydump.

Damit kann man dann ggf. das System mittels

apt-get install cat mydump | irgendein\_filter

nach Basis-Neuinstallation restaurieren.

Aber sowas kennst Du ja sicherlich.

Gruesse

Holger

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Vinzenz Mai]

Hallo Holger,

Damit kann man dann ggf. das System mittels
nach Basis-Neuinstallation restaurieren.

Aber sowas kennst Du ja sicherlich.

ich glaube, Marc hat eher ein Image-Backup im Sinn :-)

Freundliche Grüße

Vinzenz

[hkl]

Hallo Vinzenz !

Hallo Holger,

Damit kann man dann ggf. das System mittels
nach Basis-Neuinstallation restaurieren.

Aber sowas kennst Du ja sicherlich.

ich glaube, Marc hat eher ein Image-Backup im Sinn :-)

Na ja, DEM Charme kann sich auch die boeseste libc nicht entziehen...

Aber es gibt alternative Ansaetze.

;-)

Freundliche Grüße

Vinzenz

Gruesse

Holger

[Marc Reichelt]

Hallo Vinzenz,

ich glaube, Marc hat eher ein Image-Backup im Sinn :-)

Nun ja, nicht ganz. ;-)
Der Server läuft im Rechenzentrum, und wird aus dem laufenden System heraus gesichert (alles außer /sys und /proc).

"Partition Image" kommt bei mir bei lokalen Rechnern zum Einsatz, und zwar zum:
1. Klonen und
2. Sichern.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Manuel B.]

Ich grüsse den Cosmos,

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?

Solange du kein KDE mit mehreren Monitoren nutzt, kein Problem. Läuft sauber und stabil

2. Die PHP5-Pakete aus dem Etch-Repository in Sarge einspielen?

Ist so einfach gar nicht möglich. Im endeffekt hast du dann wieder ein Etch, wenn du alle Abhängigkeiten bereinigt hast ;)

3. Eventuell eine andere Möglichkeit?

Selber kompilieren ;)

Möge das "Self" mit euch sein

[Marc Reichelt]

Hallo Manuel,

1. Auf Etch aktualisieren, auch, wenn dieses noch nicht als "stable" markiert ist?

Solange du kein KDE mit mehreren Monitoren nutzt, kein Problem. Läuft sauber und stabil

Ist ja eigentlich auch zu erwarten, schließlich soll Etch sehr bald "stable" werden.

2. Die PHP5-Pakete aus dem Etch-Repository in Sarge einspielen?

Ist so einfach gar nicht möglich. Im endeffekt hast du dann wieder ein Etch, wenn du alle Abhängigkeiten bereinigt hast ;)

Das habe ich mir bereits gedacht. Wozu sollten denn sonst die Backports gut sein? ;-)

3. Eventuell eine andere Möglichkeit?

Selber kompilieren ;)

Fällt - wie bereits gesagt - flach.
Also werde ich kurzerhand heute noch kurz ein komplettes Backup erstellen, sichern und danach auf Etch upgraden (natürlich nicht ohne vorher zu schauen, was das Update genau macht).
Aber natürlich erst zu einer genehmen Uhrzeit - frisch ausgeruht kann man so etwas IMHO wesentlich besser angehen. :-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[hkl]

Hallo !

Solange du kein KDE mit mehreren Monitoren nutzt

Kann mir das bitte mal jemand verdummusern ?
KDE Window Manager, KDM, oder KDE Apps ?

Mei, woher habt Ihr eigentlich immer dieses Detailwissen ?
Sowas geht an mir oft genug vorbei...

Fällt - wie bereits gesagt - flach.
Also werde ich kurzerhand heute noch kurz ein komplettes Backup erstellen, sichern und danach auf Etch upgraden (natürlich nicht ohne vorher zu schauen, was das Update genau macht).
Aber natürlich erst zu einer genehmen Uhrzeit

Wieso hab ich eigentlich immer Wartungsfenster zu dunkelster naechtlicher  Stunde ?
:-(

• frisch ausgeruht kann man so etwas IMHO wesentlich besser angehen. :-)

Wie gesagt, alles Gute !
Postest Du bitte mal ein Fazit ?

Gruesse

Holger

[Manuel B.]

Ich grüsse den Cosmos,

Kann mir das bitte mal jemand verdummusern ?
KDE Window Manager, KDM, oder KDE Apps ?

Grundsystem von KDE, also der Teil, der die Fenster verwaltet, Loginmanager etc, Programme, die unter KDE laufen

Ich hoffe, ich hab mich auf die Schnelle nicht vertan ;)

Mei, woher habt Ihr eigentlich immer dieses Detailwissen ?
Sowas geht an mir oft genug vorbei...

Nachdem Etch nach jedem Update entweder KDE gar nicht mehr oder nur noch den primären Monitor gestartet hat, hab ich mich zwangsläufig mit diesen Internas befassen müssen ;)
So schön die Umstellung auf xorg war, soviele Probleme gibts im Multimonitorbetrieb.

Wenn es aber nur um das Update ohne grafische Oberfläche geht, hab ich schon erfolgreich von Woody nach Sarge und von Sarge nach Etch updates gefahren. Kleinere Anpassungen waren zwar auch nötig (Apache 1 auf Apache 2, Bind8 auf Bind9 usw.) aber insgesammt hats immer geklappt.
Bei Suse funktionierte noch nie ein Versionssprung ohne Neuinstallation.

Möge das "Self" mit euch sein

[Mathias Brodala]

Hallo Manuel.

Kann mir das bitte mal jemand verdummusern ?
KDE Window Manager, KDM, oder KDE Apps ?

Grundsystem von KDE, also der Teil, der die Fenster verwaltet,

Das ist KWin, der Standard-Windowmanager von KDE.

So schön die Umstellung auf xorg war,

Ohje, dass muss bei mir Äonen her sein.

soviele Probleme gibts im Multimonitorbetrieb.

Habe ich (noch) nicht ausprobiert.

Einen schönen Montag noch.

Gruß, Mathias

[Manuel B.]

Ich grüsse den Cosmos,

So schön die Umstellung auf xorg war,

Ohje, dass muss bei mir Äonen her sein.

Wurde ja erst mit Etch in die Pakete aufgenommen. Als 90%iger Anwender (der Rest ist SysAdmin ;)) kompilier ich nur dann selbst Pakete, wenn es nötig ist.

soviele Probleme gibts im Multimonitorbetrieb.

Habe ich (noch) nicht ausprobiert.

Das neueste ist, das der Bildschirminhalt beim Scrollen "verschmiert". Links sind an einer anderen Stelle, als sie auf dem Monitor erscheinen, der Mauszeiger ist mehrmals zu sehen. Das ganze nur auf dem Sekundärmonitor.
Den Dualhead auf meiner Radeon9200 hab ich nie zum laufen bekommen ohne Xinerama und jedes Update von xorg hat mir die ganze Config zerschossen. Bin mal gespannt, ob das mit der Stable dann behoben ist. Mit Sarge und X11 hatte ich diese Probleme nie.

Möge das "Self" mit euch sein

[Mathias Brodala]

Hallo Manuel.

So schön die Umstellung auf xorg war,

Ohje, dass muss bei mir Äonen her sein.

Wurde ja erst mit Etch in die Pakete aufgenommen. Als 90%iger Anwender (der Rest ist SysAdmin ;)) kompilier ich nur dann selbst Pakete, wenn es nötig ist.

Ich kompiliere mir meine Pakete auch nur, wenn ich keine Wahl habe. Und selbst dann nutze ich entweder checkinstall oder erstelle ein sauberes Paket.

soviele Probleme gibts im Multimonitorbetrieb.

Habe ich (noch) nicht ausprobiert.

Das neueste ist, das der Bildschirminhalt beim Scrollen "verschmiert".

Kenne ich persönlich nur von Operas „Smooth Scrolling“-Funktion. (Wobei dies aber nun mit Version 9.10 endlich behoben worden sein soll. Muss ich heute zuhause einmal ausprobieren.)

Den Dualhead auf meiner Radeon9200 hab ich nie zum laufen bekommen ohne Xinerama und jedes Update von xorg hat mir die ganze Config zerschossen.

Die sollte aber normalerweise nicht angerührt werden bzw. zumindest eine Abfrage (debconf) erscheinen, ob deine vorhandene Konfiguration durch die des Paketbetreuers ersetzt werden soll. Zusätzlich steht noch am Anfang der xorg.conf, wie man sie vor unbeabsichtigten Upgrades schützen kann.

Einen schönen Dienstag noch.

Gruß, Mathias

[hkl]

Hallo !

Bei Suse funktionierte noch nie ein Versionssprung ohne Neuinstallation.

SuSE empfehl ich schon aus "Wettbewerbsgruenden" nicht - SuSE bietet dem Kunden diverse mehrwerte Leistungen an die ich eher bei mir angesiedelt sehen moechte.
Es bringt imo nichts wenn Support zwischen Dienstleistern geteil wird.

Aber dass das Produkt technische Schwaechen aufweist ist mir neu - danke fuer die Info !

Die - wenigen - PC-UNIX-Server die ich noch verwalte laufen mittlerweile unter Debian Sarge - das sind "Black Boxes" die im wesentlichen eine Anwendung hosten.

Hatte da gar keine Upgrades versucht sondern gleich eine Neuinstallation angesetzt ( Platten dabei jeweils getauscht ).

Also : Server mit Debian installieren ? Oder gibt's Deiner Meinung nach was Besseres ?

Gruesse

Holger

P.S.: Bin echt gespannt was Marc zu berichten hat.

[Manuel B.]

Ich grüsse den Cosmos,

Also : Server mit Debian installieren ? Oder gibt's Deiner Meinung nach was Besseres ?

Meiner Meinung nach ist Debian das Beste. Das problem dabei ist aber, ich kenne mittlerweile diese Distri ;) Es gibt sicher andere, die Debian richtig sch... finden.
Als 90%iger Anwender bin ich natürlich interessiert, das installationen schnell und unkompliziert gehen und deshalb ist aptitude für mich ein Traum. Bei Yast dauert ja die Paketinstallation ewig, da man sich erstmal durch die Menüs wühlen muss.

Ich werde bei Debian bleiben und kanns auch empfehlen. egal ob Desktopbereich oder Serverbereich.

Allerdings befürchte ich, das ich grad wieder einen Glaubenskrieg ausgelöst hab und eine Diskussion über Distries startet ;)

Möge das "Self" mit euch sein

[dedlfix]

echo $begrüßung;

Hallo !
Kann mir das bitte mal jemand verdummusern ?
KDE Window Manager, KDM, oder KDE Apps ?
Wieso hab ich eigentlich immer Wartungsfenster zu dunkelster naechtlicher  Stunde ?
Wie gesagt, alles Gute !
Postest Du bitte mal ein Fazit ?

Mei, woher habt Ihr eigentlich immer dieses Detailwissen ?

Wir verschwenden unsere Zeit nicht mit dem Tippen von überflüssigen Leerzeichen vor dem Satzendezeichen, stattdessen beschäftigen wir uns eben mit den Details.

echo "$verabschiedung $name";

[hkl]

Hallo dedlfix !

echo $begrüßung;

Hallo !
Kann mir das bitte mal jemand verdummusern ?
KDE Window Manager, KDM, oder KDE Apps ?
Wieso hab ich eigentlich immer Wartungsfenster zu dunkelster naechtlicher  Stunde ?
Wie gesagt, alles Gute !
Postest Du bitte mal ein Fazit ?

Mei, woher habt Ihr eigentlich immer dieses Detailwissen ?

Wir verschwenden unsere Zeit nicht mit dem Tippen von überflüssigen Leerzeichen vor dem Satzendezeichen, stattdessen beschäftigen wir uns eben mit den Details.

Es freut mich sehr wenn Kollegen eine so gute Sehschaerfe haben dass sie auch nach vielen Stunden am Rechner ein "l!" o.ae. noch einwandfrei aufloesen koennen.

Leider verfuege ich selbst nicht ueber eine derartige Sehschaerfe - deshalb plenke ich und werd's auch weiterhin tun. Es hilft mir beim abschliessenden Durchlesen meiner eigenen Posts Stilmittel ( "!" "?" ) besser wahrzunehmen .

echo "$verabschiedung $name";

Gruesse

Holger

P.S.:
@dedlfix
Wenn's ein Problem geben sollte, schick mir bitte ggf. gern eine Mail. Ich fuer meinen Teil schaetze Deine Beitraege sehr und wuerde mich fuen wenn wir ein Problem ggf. aus der Welt schaffen koennten.

[dedlfix]

echo $begrüßung;

Wenn's ein Problem geben sollte, schick mir bitte ggf. gern eine Mail. Ich fuer meinen Teil schaetze Deine Beitraege sehr und wuerde mich fuen wenn wir ein Problem ggf. aus der Welt schaffen koennten.

Nein, ein wirkliches Problem gibt es nicht. Die Einsortierung unter der Kategorie "Menschelei" sollte auf den nicht ganz ernst gemeinten Charakter meiner Antwort hinweisen. Ich konnte einfach deine Frage nicht ernst nehmen.
Ich schätze dein Wissen nicht gerade als gering ein. Doch manchmal wundere ich mich etwas über dich. Eben die Frage, wie man solches Detailwissen haben kann. Natürlich hat nicht jeder hier Detailwissen an jeder Ecke. Der Eindruck mag täuschen, weil hier viel Detailwissen vorhanden ist, das aber von einer Vielzahl an Personen beigesteuert wird. Oder dein Verwundern über nicht vorhandene Leistungsmerkmale eines Systems, das diese Leistungsmerkmale nie für sich proklamiert hat, nur von der breiten Masse, die mit den Grundfunktionen mehr als zufrieden ist, übermäßig gehypet wird.

echo "$verabschiedung $name";

[hkl]

Hallo dedlfix !

echo $begrüßung;

Wenn's ein Problem geben sollte, schick mir bitte ggf. gern eine Mail. Ich fuer meinen Teil schaetze Deine Beitraege sehr und wuerde mich fuen wenn wir ein Problem ggf. aus der Welt schaffen koennten.

Nein, ein wirkliches Problem gibt es nicht.

Das ist zwar gut, aber dann versteh ich den unhoeflichen Ton in Deinen Antworten nicht.

Die Einsortierung unter der Kategorie "Menschelei" sollte auf den nicht ganz ernst gemeinten Charakter meiner Antwort hinweisen. Ich konnte einfach deine Frage nicht ernst nehmen.

Die war auch nicht so bierernst gemeint. Vielleicht ist Dir einfach ein Scherz entgangen ?

Ich schätze dein Wissen nicht gerade als gering ein.

Arroganter Text !
Wie Du mein Wissen einschaetzt ist voellig unerheblich - dazu koennstest Du auch gar keine Aussage treffen, sondern lediglich zu meinen Beitraegen hier.

Doch manchmal wundere ich mich etwas über dich.

Und dies ist fuer mich unerheblich.

Eben die Frage, wie man solches Detailwissen haben kann. Natürlich hat nicht jeder hier Detailwissen an jeder Ecke. Der Eindruck mag täuschen, weil hier viel Detailwissen vorhanden ist, das aber von einer Vielzahl an Personen beigesteuert wird.

Das hast Du zwar wie ueblich sehr genau analysiert, trotzdem hast Du Deine Analyse nur dazu genutzt mich vor den Kopf zu stossen.

Vielleicht solltest Du eher mal darueber nachdenken als ueber die Erkenntnisfaehigkeit ( oder die Orthographie ) anderer Teilnehmer.

Man kann auch ueber eine schlecht formulierte Frage laecheln statt den Teilnehmer gleich vor den Bug zu feuern.

Das ist uebrigens imho der Unterschied zwischen Intelligenz und Weisheit.

Zwar steht in der Charta etwas zum Thema "Eigenrecherche", aber ueber deren Einhaltung moegen die Betreiber wachen - den "Forumssheriff" zu spielen ist unterhalb meines fachlichen Niveaus und somit sicherlich auch unterhalb des Deinen, oder ? Von menschlichen Aspekten gar nicht erst zu scheiben.

Oder dein Verwundern über nicht vorhandene Leistungsmerkmale eines Systems, das diese Leistungsmerkmale nie für sich proklamiert hat, nur von der breiten Masse, die mit den Grundfunktionen mehr als zufrieden ist, übermäßig gehypet wird.

Liegt's nicht viellicht eher daran dass die Kritik nicht von Dir selbst formuliert wurde ?

echo "$verabschiedung $name";

Wenn Du mit mir Streit vom Zaun brichst ist das gaenzlich ueberfleussig - ich schaetze Deine fachlichen Beitraege sehr und habe Dir auch schon mal persoenlich dafuer gedankt. Aber Fachkompetenz rechtfertigt noch lange keinen pampigen Umgangston.

Klar ?

Gruesse

Holger

[Marc Reichelt]

Hallo hkl,

Also werde ich kurzerhand heute noch kurz ein komplettes Backup erstellen, sichern und danach auf Etch upgraden (natürlich nicht ohne vorher zu schauen, was das Update genau macht).
[...]
Postest Du bitte mal ein Fazit ?

Erst mal hier mein Bericht über das "Update" auf Etch:
Zunächst habe ich alle Daten des Servers gesichert. Anschließend habe ich die /etc/apt/sources.list auf Etch angepasst und mir nach einem "apt-get update" über "apt-get -us dist-upgrade" die Änderungen anzeigen lassen, die er vornehmen wollte.
Die Änderungen sahen so auch gut aus, also ließ ich ein "apt-get dist-upgrade" laufen.
Die Pakete konnten ordnungsgemäß heruntergeladen werden, aber das Update verlief grausam.
Zunächst fragte apt-get mich, ob ich ein Kernel-Update vornehmen wollte. Da [No] die Voreinstellung war (und viele Sätze auf schwerwiegende Folgen eines "Yes" hinwiesen), wählte ich "No" - und prompt wurde das Upgrade beendet.
Also dachte ich mir: Wenn ich nun nochmals "apt-get dist-upgrade" aufrufen würde, müsste ich diese Entscheidung nochmals treffen können - aber Fehlanzeige.
Im weiteren Verlauf deinstallierte mir apt-get den Apache2 - und installierte nicht (wie angekündigt) den Apache2.2, sondern Apache 1.x.
Das alles wäre kein Problem gewesen. Schließlich kam ich nochmals zu der Entscheidung, ob ich ein Kernel-Update machen wolle - dieses Mal wählte ich "Yes".
Anschließend blieb das Upgrade beim Update von openssh-server und openssh-client mir Fehlern hängen, die ich nicht mal mehr mit "apt-get -f install" beheben konnte.
Da das Ganze auf einem entfernten Rechner lief, und ich gerade in der Universität arbeitete (und das Uni-Netz bei uns _sehr_ instabil ist), musste passieren, was passieren musste:
Die SSH-Verbindung zu meinem Server brach ab. Bei meinen Reperatur-Versuchen am SSH-Server scheint dieser wohl gestoppt worden zu sein, also konnte ich mich nicht wieder verbinden.
Anschließend entschied ich mich, das System auf Etch neu aufzusetzen - ohne Update.
Nach vier Stunden Downtime und einer großen Portion Stress habe ich Etch am Laufen und mein Fazit gezogen, dass folgende Punkte umfasst:

1. Ein Backup ist immer das Wichtigste.
2. Ein Ugrade von "stable" nach "testing" sollte vorher auf einem Testserver durchgeführt werden, bevor man ein Produktivsystem berührt. Wer vorsichtiger ist, testet auch ein Upgrade von "stable" nach "stable" zuerst auf einem Testserver.
3. Etch an sich läuft - wenn es einmal installiert ist - ohne Probleme.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Mathias Brodala]

Hallo Marc.

Nach vier Stunden Downtime und einer großen Portion Stress habe ich Etch am Laufen und mein Fazit gezogen, dass folgende Punkte umfasst:

1. Ein Backup ist immer das Wichtigste.

Lasse ich einfach mal stehen, da immer wieder erwähnenswert.

2. Ein Ugrade von "stable" nach "testing" sollte vorher auf einem Testserver durchgeführt werden, bevor man ein Produktivsystem berührt. Wer vorsichtiger ist, testet auch ein Upgrade von "stable" nach "stable" zuerst auf einem Testserver.

Auch empfehlenswert: auf „apt-get dist-upgrade“ und „apt-get upgrade“ gänzlich verzichten und alle installierten Pakete manuell aktualisieren. Hierdurch hat man volle Kontrolle über alle Abhängigkeiten und kann entscheiden, welche Aktualisierung wirklich vorgenommen werden soll. (Auf diese Weise wechselte ich problemlos von Sarge zu Etch und davon zu Sid.)

Einen schönen Mittwoch noch.

Gruß, Mathias

[Marc Reichelt]

Hallo Mathias,

2. Ein Ugrade von "stable" nach "testing" sollte vorher auf einem Testserver durchgeführt werden, bevor man ein Produktivsystem berührt. Wer vorsichtiger ist, testet auch ein Upgrade von "stable" nach "stable" zuerst auf einem Testserver.

Auch empfehlenswert: auf „apt-get dist-upgrade“ und „apt-get upgrade“ gänzlich verzichten und alle installierten Pakete manuell aktualisieren. Hierdurch hat man volle Kontrolle über alle Abhängigkeiten und kann entscheiden, welche Aktualisierung wirklich vorgenommen werden soll. (Auf diese Weise wechselte ich problemlos von Sarge zu Etch und davon zu Sid.)

Interessant - die Möglichkeit habe ich noch gar nicht in Erwähnung gezogen. :-)
Jedenfalls steht der Server nun, aber apt-get liefert bei einem "apt-get upgrade" aktuell noch folgende Ausgabe:
---snip---
Reading package lists... Done
Building dependency tree... Done
The following packages have been kept back:
  initscripts lilo sysvinit
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
---snap---

Wieso werden diese Pakete zurückgehalten? Und wann sollte ich diese Pakete mit "apt-get install initscripts lilo sysvinit" einspielen - wenn Etch "stable" ist?

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Mathias Brodala]

Hallo Marc.

Jedenfalls steht der Server nun, aber apt-get liefert bei einem "apt-get upgrade" aktuell noch folgende Ausgabe:
---snip---
Reading package lists... Done
Building dependency tree... Done
The following packages have been kept back:
  initscripts lilo sysvinit
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
---snap---

Wieso werden diese Pakete zurückgehalten?

Obgleich ich die theoretische Versionierung in Etch einsehen kann, wäre ein Ausgabe von „apt-cache policy $paketname“ für diese drei Pakete interessant.

Zudem könntest du einmal für jedes dieser Pakete „apt-get --simulate install $paketname“ ausprobieren, um zu sehen was passieren soll. Hier siehst du dann vielleicht schon, warum die Pakete zurückgehalten wurde. (Vermutung: einfach unerfüllte Abhängigkeiten.)

Einen schönen Mittwoch noch.

Gruß, Mathias

[Marc Reichelt]

Hallo Mathias,

Obgleich ich die theoretische Versionierung in Etch einsehen kann, wäre ein Ausgabe von „apt-cache policy $paketname“ für diese drei Pakete interessant.

Der Befehl "apt-cache policy initscripts lilo sysvinit" liefert folgende Ausgabe:

---snip---
initscripts:
  Installed: 2.86.ds1-20
  Candidate: 2.86.ds1-36
  Version table:
     2.86.ds1-36 0
        500 http://ftp.de.debian.org etch/main Packages
 *** 2.86.ds1-20 0
        100 /var/lib/dpkg/status
lilo:
  Installed: 1:22.6.1-7.1
  Candidate: 1:22.6.1-9
  Version table:
     1:22.6.1-9 0
        500 http://ftp.de.debian.org etch/main Packages
 *** 1:22.6.1-7.1 0
        100 /var/lib/dpkg/status
sysvinit:
  Installed: 2.86.ds1-20
  Candidate: 2.86.ds1-36
  Version table:
     2.86.ds1-36 0
        500 http://ftp.de.debian.org etch/main Packages
 *** 2.86.ds1-20 0
        100 /var/lib/dpkg/status
---snap---

Zudem könntest du einmal für jedes dieser Pakete „apt-get --simulate install $paketname“ ausprobieren, um zu sehen was passieren soll. Hier siehst du dann vielleicht schon, warum die Pakete zurückgehalten wurde. (Vermutung: einfach unerfüllte Abhängigkeiten.)

Der Befehl "apt-get --simulate install initscripts lilo sysvinit" liefert folgende Ausgabe:

---snip---
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  mbr sysvinit-utils
Suggested packages:
  lilo-doc
The following NEW packages will be installed:
  mbr sysvinit-utils
The following packages will be upgraded:
  initscripts lilo sysvinit
3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
---snap---

Sieht so aus als würde er nicht so viel unternehmen. Ob ich wohl ohne Sorgen updaten kann? Ein Backup ist jedenfalls wieder vorhanden. :-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Mathias Brodala]

Hallo Marc.

Obgleich ich die theoretische Versionierung in Etch einsehen kann, wäre ein Ausgabe von „apt-cache policy $paketname“ für diese drei Pakete interessant.

Der Befehl "apt-cache policy initscripts lilo sysvinit" liefert folgende Ausgabe:

Sieht gut aus.

Zudem könntest du einmal für jedes dieser Pakete „apt-get --simulate install $paketname“ ausprobieren, um zu sehen was passieren soll. Hier siehst du dann vielleicht schon, warum die Pakete zurückgehalten wurde. (Vermutung: einfach unerfüllte Abhängigkeiten.)

Der Befehl "apt-get --simulate install initscripts lilo sysvinit" liefert folgende Ausgabe:

---snip---
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  mbr sysvinit-utils

Das „mbr“-Paket muss von Lilo stammen, bei mir ist es nicht installiert und gebraucht hatte ich es auch nie. Das neue Paket „sysvinit-utils“ ist entstanden, weil einige Programme der einfacheren Wartung wegen ausgelagert wurden.

3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
---snap---

Sieht so aus als würde er nicht so viel unternehmen. Ob ich wohl ohne Sorgen updaten kann? Ein Backup ist jedenfalls wieder vorhanden. :-)

Dann kannst du es bedenkenlos wagen. (Ich meine mich erinnern zu können, dass „apt-get upgrade“ nicht ohne weiteres zusätzliche Pakete installiert. Vielleicht wurden diese drei deswegen zurück gehalten.)

Einen schönen Mittwoch noch.

Gruß, Mathias

[Manuel B.]

Ich grüsse den Cosmos,

Die Änderungen sahen so auch gut aus, also ließ ich ein "apt-get dist-upgrade" laufen.

Ich hatte damals keine Probleme. Vielleicht hätt folgendes geholfen:

apt-get update
apt-get upgrade
apt-get dist-upgrade

Allerdings kanns bei mir auch nur Zufall gewesen sein, das es funktioniert hat ;)

Möge das "Self" mit euch sein

[hkl]

Hallo Marc !

Anschließend entschied ich mich, das System auf Etch neu aufzusetzen - ohne Update.
[...]
3. Etch an sich läuft - wenn es einmal installiert ist - ohne Probleme.

Dazu erstmal meinen Glueckwunsch ! Good work !

Hallo hkl,

Also werde ich kurzerhand heute noch kurz ein komplettes Backup erstellen, sichern und danach auf Etch upgraden (natürlich nicht ohne vorher zu schauen, was das Update genau macht).
[...]
Postest Du bitte mal ein Fazit ?

Erst mal hier mein Bericht über das "Update" auf Etch:
Zunächst habe ich alle Daten des Servers gesichert. Anschließend habe ich die /etc/apt/sources.list auf Etch angepasst und mir nach einem "apt-get update" über "apt-get -us dist-upgrade" die Änderungen anzeigen lassen, die er vornehmen wollte.
Die Änderungen sahen so auch gut aus, also ließ ich ein "apt-get dist-upgrade" laufen.

Man koennte es natuerlich auch so machen daas man nur das "kritische" Paket, laso bei Dir wohl php5, installiert und die Abhaengigkeiten rekursiv von apt-get breinigen laesst.
Aber das laeuft vielleicht auf's gleich hianaus.

Die Pakete konnten ordnungsgemäß heruntergeladen werden, aber das Update verlief grausam.
Zunächst fragte apt-get mich, ob ich ein Kernel-Update vornehmen wollte. Da [No] die Voreinstellung war (und viele Sätze auf schwerwiegende Folgen eines "Yes" hinwiesen), wählte ich "No" - und prompt wurde das Upgrade beendet.

Manchmal versteh ich die Maintainer nicht....

Also dachte ich mir: Wenn ich nun nochmals "apt-get dist-upgrade" aufrufen würde, müsste ich diese Entscheidung nochmals treffen können - aber Fehlanzeige.
Im weiteren Verlauf deinstallierte mir apt-get den Apache2 - und installierte nicht (wie angekündigt) den Apache2.2, sondern Apache 1.x.
Das alles wäre kein Problem gewesen. Schließlich kam ich nochmals zu der Entscheidung, ob ich ein Kernel-Update machen wolle - dieses Mal wählte ich "Yes".
Anschließend blieb das Upgrade beim Update von openssh-server und openssh-client mir Fehlern hängen, die ich nicht mal mehr mit "apt-get -f install" beheben konnte.

dpkg --purge hilft manchmal.

Da das Ganze auf einem entfernten Rechner lief, und ich gerade in der Universität arbeitete (und das Uni-Netz bei uns _sehr_ instabil ist), musste passieren, was passieren musste:
Die SSH-Verbindung zu meinem Server brach ab. Bei meinen Reperatur-Versuchen am SSH-Server scheint dieser wohl gestoppt worden zu sein, also konnte ich mich nicht wieder verbinden.

Ach du Schreck...

Nach vier Stunden Downtime und einer großen Portion Stress habe ich Etch am Laufen und mein Fazit gezogen, dass folgende Punkte umfasst:

1. Ein Backup ist immer das Wichtigste.
2. Ein Ugrade von "stable" nach "testing" sollte vorher auf einem Testserver durchgeführt werden, bevor man ein Produktivsystem berührt. Wer vorsichtiger ist, testet auch ein Upgrade von "stable" nach "stable" zuerst auf einem Testserver.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

Kannste mir bitte mal ein dpkg -l mailen ?

Danke und viel Spass mit dem neuen Server !

Gruesse

Holger

[Johannes Zeller]

Hallo Marc,

3. Eventuell eine andere Möglichkeit?

Distribution wechseln.

Schöne Grüße,

Jo*SCNR*hannes

[Marc Reichelt]

Hallo Johannes,

3. Eventuell eine andere Möglichkeit?

Distribution wechseln.

Ich habe bereits von Gentoo nach Debian gewechselt. So manchereiner wird hier wohl lautlos aufschreien, aber dafür gab es mehrere Gründe:
1. Das alte System bekam sehr unregelmäßig Updates, weil so eine Updategeschichte bei Gentoo sehr lange dauert und ich dafür nicht jedes Mal Zeit aufbringen wollte.
2. Mein Kollege und ich haben damals mehrere Dinge unternommen, die sehr von den "Standards" abwichen, und die Wartbarkeit des Systems nicht gerade erhöhten (zumindest aus meiner Sicht).
3. Hinzu kommt, dass wir den Server damals zwar gemeinsam eingerichtet hatten, ich aber sehr wenig Erfahrung davon trug.

Und so habe ich (nachdem ich erst intensive Tests auf einem lokalen Testrechner durchgeführt hatte) nun ein Debian laufen.
Falls eingefleischte Gentoo-User mich wieder zurückbekehren wollen: Bis ich Gentoo nochmals ausprobiere wird einige Zeit vergehen. ;-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/