FreeBSD automatisch aktualisieren (keine Upgrades)

Okapi

Active Member
Hi,

ich möchte mein FreeBSD 7.0 Release System automatisch auf aktuellem Stand halten udn habe nach Lektüre des hervorragendes Wikis folgendes zusammengebastelt.
Kann mir jemand bestätigten, dass das so in Ordnung ist?

Code:
sup

# cp /usr/share/examples/cvsup/stable-supfile /usr/local/etc/stable-supfile
# vi /usr/local/etc/stable-supfile

*default host=cvsup4.de.FreeBSD.org
 # vi /etc/periodic/daily/600.csup

#!/bin/sh
#
# Update FreeBSD sources
#

/usr/bin/csup -g -L 2 /usr/local/etc/stable-supfile >> /var/log/csup.log 2>&1
freebsd-update

# vi /etc/periodic/daily/610.freebsd-update

#!/bin/sh
#
# Update FreeBSD binaries
#

/usr/sbin/freebsd-update fetch && /usr/sbin/freebsd-update install >> /var/log/freebsd-update.log 2>&1
portupgrade

# vi /etc/periodic/daily/630.portupgrade

#!/bin/sh
#
# Update installed FreeBSD ports
#

/usr/local/sbin/portupgrade -aP >> /var/log/portupgrade.log 2>&1

Ich möchte damit erreichen, dass ich einen aktuellen Ports-Tree, aktuelle Binaries und aktuelle aus dem Portstree installierte Software habe.

Wie sieht es in diesem Fall mit Security Patches für den Kernel aus?
 
du solltest ports und system nicht automatisch aktualisieren, da evtl. wichtige dinge oder vorarbeiten in /usr/src/UPDATING bzw. /usr/ports/UPDATING aufgelistet sind. auch bringt das tägliche neu ziehen per csup relativ wenig, imo. du solltest lieber die announce bzw. security-liste abonnieren und somit über evtl. sicherheitslücken etc. im bilde sein, wenn auch patches bereit stehen.

portsnap bietet nen cronmodus.
 
Hi,

ich habe derzeit 41 Systeme, die ich sukzessiv auf FreeBSD migriere. Ein manuelles updaten ist nicht praktikabel möglich.

portsnap macht doch (fast) dasgleiche wie csup, nur dass es den kompletten Portstree komprimiert holt, oder? Oder meinst Du die cron-Option bei freebsd-update? Diese möchte ich nicht verwenden, da der Output des fetch Kommandos in die logs soll und zudem "cron" ansonsten nur zeitlich ein wenig abweicht, um paralelle Anfragen zu vermeiden.
 
ich wollte nur sagen, dass die gefahr eines "automatischen" updates sehr groß ist und man sich leicht dabei in den fuß schiessen kann.

portsnap holt nur die änderungen. beim ersten mal holt es nen gepackten snapshot, danach nur noch deltas. der cronmodus bedeutet, dass es zu eine zufälligen zeit anfängt, damit nicht jedes system gleichzeitig zum portsnap-server rennt und den nervt ;)
 
ich habe derzeit 41 Systeme, die ich sukzessiv auf FreeBSD migriere.
Da solltest du dir mal Tinderbox anschauen um die Ports zentral zu kompilieren. portaudit hilft dir dann auf den Systemen herauszufinden, welche Ports Sicherheitslücken aufweisen und rasch ersetzt werden sollten.

mousaka
 
Tinderbox sieht interessant aus – aber ich möchte es erstmal auf die o.g. Art und Weise mittels Automatisierung der Basiskommandos probieren, da mir praktische Erfahrungen mit Tinderbox fehlen.

Inwiefern ersetzt portsnap denn csup? Macht csup nicht genau das gleiche?
Was ist mit Updates des Kernels? csup/portsnap/portupgrade aktualisieren doch nicht automatisch auch den Kernel, oder doch?

Portaudit habe ich installiert.

Bezüglich in den Fuß schießen... ich habe schon ein Auge auf die Kisten, daher ja die Logfiles.
 
Inwiefern ersetzt portsnap denn csup? Macht csup nicht genau das gleiche?
Bedingt. Portsnap kann nur den Portstree aktualisieren, csup Ports- und Src-Tree.
Was ist mit Updates des Kernels? csup/portsnap/portupgrade aktualisieren doch nicht automatisch auch den Kernel, oder doch?
freebsd-update aktualisiert das Basis-System (Kernel und Userland) binär, also ohne Sourcen.

csup: aktualisert src und/oder Portsbaum (ersetzt cvsup)
portsnap: aktualisiert Portsbaum
portupgrade: aktualisiert installierte Ports (Alternative: portmaster)

Bezüglich in den Fuß schießen... ich habe schon ein Auge auf die Kisten, daher ja die Logfiles.
Was sollen den die Kisten machen? Sind alle identisch?

mousaka
 
Bedingt. Portsnap kann nur den Portstree aktualisieren, csup Ports- und Src-Tree.
Ok, dann sehe ich keinen Grund, portsnap zu benutzen.

freebsd-update aktualisiert das Basis-System (Kernel und Userland) binär, also ohne Sourcen.
Ideal. Da ich den GENERIC Kernel und RELEASE Version benutze, sollte es da auch keine Probleme geben.




Was sollen den die Kisten machen? Sind alle identisch?

Von WebObjects Maschinen auf denen Testentwicklungen laufen bis hinzu Web-/Datenbank oder gar Shared Hosting Servern. Also das klassische Server-Management für Fremdkunden.
 
Hi,
ich habe derzeit 41 Systeme, die ich sukzessiv auf FreeBSD migriere. Ein manuelles updaten ist nicht praktikabel möglich.

Automatisches update des Systems und der installierten Ports halte ich für grob fahrlässig. Man kann es machen, braucht sich aber nicht wundern wenn man damit früher oder später auf die Schnauze fällt.
Was ist wichtiger, ein laufendes, funktionierendes System, oder eines was Dir irgendwann nur noch Fehler ausspuckt, evtl. gar nicht mehr bootet?

Wir haben hier mehr als 2700 Server stehen, unterschiedlichste Systeme, aber es wird kein automatisches Update des Systems und/oder der installierten Programme gefahren. Die Gefahr das hier etwas hängen bleibt, nur weil man, wie im Falle von FBSD, nicht in die entsprechenden UPDATING Readmes geschaut hat, wäre viel zu gross.
 
Hi,

ich gebe Dir aus theoretischer Sicht natürlich recht. Ich muß in meinem Fall aber wirtschaftlich denken. Die Kunden wissen, dass es keine Hochverfügbarkeitsleistungen für einen Server gibt, dessen Management 99 € / Monat kostet.
Es geht mir darum, bei einem Security Patch z.B. für Apache, nicht 41x denselben Arbeitsschritt machen zu müssen.

Netzwerkboot wäre interessant - aber dafür sind die System zu individuell bzw. ich habe auch keine Möglichkeit, dass über PXE etc. zu realisieren, da die Server in verschiedenen Rechenzentren stehen.

Allerdings zum Thema "auf die Schnauze fallen mit automatischen Updates" - ich habe seit knapp 1 Jahr einen Testserver, der mit praktisch denselben Kommandos aktualisiert wird - bisher ohne Probleme. Auf dem Server läuft FreeBSD 6, WebObjects und PostgreSQL mit Apache 1.3
 
Die Kunden wissen, dass es keine Hochverfügbarkeitsleistungen für einen Server gibt, dessen Management 99 € / Monat kostet.

Welche SLA ist vereinbart?

Es geht mir darum, bei einem Security Patch z.B. für Apache, nicht 41x denselben Arbeitsschritt machen zu müssen.

Netzwerkboot wäre interessant - aber dafür sind die System zu individuell bzw. ich habe auch keine Möglichkeit, dass über PXE etc. zu realisieren, da die Server in verschiedenen Rechenzentren stehen.

Allerdings zum Thema "auf die Schnauze fallen mit automatischen Updates" - ich habe seit knapp 1 Jahr einen Testserver, der mit praktisch denselben Kommandos aktualisiert wird - bisher ohne Probleme. Auf dem Server läuft FreeBSD 6, WebObjects und PostgreSQL mit Apache 1.3

Du führst hier Apache auf, ebenso FreeBSD6 mit WebObjects, Postgres und Apache, schreibst aber auch das die Systeme zu individuell sind.
Wenn die Systeme so individuell sind, dann lass es mit den automatischen updates. Hier können sich Kleinigkeiten ändern das nur ein Dienst nicht startet, aber auch Dinge die Dein System nicht mehr booten lassen.

Wenn Du mehrere Server der gleichen Art hast, mit den gleichen Diensten, dann teste das update auf einem Server, wenn dieser danach anständig funktioniert, dann mach Dein automatisches Backup auf den anderen Servern. Ich würde das immer noch nicht für gut heissen, aber es wäre eine Möglichkeit das Risiko etwas zu minimieren.
 
Hi,

in der SLA ist lediglich eine MTR von 3 Stunden werktags ab Eingang der Schadensmeldung durch den Kunden vereinbart. Rückvergütung ist zudem auf maximal 99 € / Monat (also die Höhe der Managementgebühren) beschränkt.

Es kann doch nicht sein, dass ich 4 Jahre lang exzellent mit automatischen Updates bei Linux-Systemen gefahren bin (apt-get update && apt-get upgrade über Cron) und nun aus Liebe zu FreeBSD (als hauptberuflicher Cocoa-Entwickler) mit diesem System mehr Arbeit als vorher habe… dann bleibe ich besser bei Linux. Nein - Spaß beiseite.

Ich müsste Leute einstellen, wenn ich die ganzen kleinen Updates die täglich anfallen, manuell machen müsste. Und das wiederum würde die Kunden wesentlich mehr kosten - was aber in dem Segment in dem ich meine Leistungen anbiete nicht in Frage kommt.
 
Achso… falls etwas schief geht und nicht mehr startet, bekomme ich vom Monitoring eh bescheid, sodass ich eingreifen kann. Da zudem alles geloggt wird, kann man die Probleme doch recht gut nachvollziehen.
 
Dann mach es so wie Du es Dir vorgestellt hast. Ich selbst würde es so nicht machen, allerdings ist es immer problematisch wenn es um das Thema Finanzen geht, daher kann ich dies nachvollziehen.
 
Achso… falls etwas schief geht und nicht mehr startet, bekomme ich vom Monitoring eh bescheid, sodass ich eingreifen kann. Da zudem alles geloggt wird, kann man die Probleme doch recht gut nachvollziehen.

Wenn Dir mehrere Maschinen absemmeln, dann wird die Hektik gross.
Wie ich schon schrieb, nimm den Kompromiss. Mach es manuell auf einem Server. Lies Dir die entsprechenden UPDATING Readmes (2 an der Zahl). Wenn da alles gut geht, es keine Änderungen Bedarf die in UPDATING beschrieben sind, dann kann man die anderen automatisch in der Nacht updaten lassen.
 
Mir sind die Trade-Offs schon bewusst… so ist's nicht. Nur sehe ich das aus wirtschaftlicher Sicht (Geld macht viel kaputt) bzw. muß es aus dieser Perspektive sehen. Und für 99 € / Monat kann er Kunde halt einfach nur eine Art "Versicherung" erwarten, dass jemand die Scherben zusammenfegt, wenn es mal kracht. Und um das Risiko so klein wie möglich zu halten, fahre ich eben auch Updates ;)
Professionelle Administration eines System mit Hochverfügbarkeitsansprüchen kostet halt m.E. locker rund ab 500 € - 1500 € / Monat und erfordert einen Vollzeitadminstrator, der sich vielleicht um maximal 10 Systeme kümmern muß.
 
Ja, wie gesagt, verstehe das. Daher kannst Du es, rein technisch, so machen wie vorgestellt. portsnap oder csup, ist egal. Ich nutze selbst noch cvsup ;-)
 
Hallo,
bei uns läuft gerade ein Projekt an was sich der Konfiguration von vielen Servern beschäftigt. Es geht dabei um allgemeine Konfiguration von Systemen wie bestimmte Programmkonfiguration z.b. Apache, SSH usw.. Das ganze wird mit puppet praktiziert.

Über puppet ist es auch möglich Software zu verwalten sprich installieren, deinstallieren und upzudaten. Es ist natürlich auch möglich bloß Script auszuführen wenn sie vom Masterserver aus frei gegeben sind. Sprich du ändert das File auf dem Masterserver oder gibts halt die Anweisung das die Clienten (auch einzelne) bestimmte Sachen ändern sollen.

Das gute ist das puppet mit den Verschiedensten Softwareverwaltungen klarkommt ohne das der Admin gezielt was einrichten muss. Bei uns läuft das zum testen auf FreeBSd, Gentoo, Centos und SLES.

Mfg KO
 
Ich habe ein ähnliches Projekt laufen – http://github.com/yves-vogl/engineer/tree

Engineer ist dabei ein Hosting-Control-Panel auf Ruby-on-Rails-Basis, welches sich nicht so penetrant wie Plesk & Co. in Systeme einklinkt, sondern über net/ssh und Capistrano gewisse Tasks über SSH automatisiert. Dort ist auch geplant später mal solche Upgrade-Tasks zu testen usw. – eventuell können wir ja gegenseitig voneinander etwas dabei lernen.

Engineer ist derzeit übrigens noch im frühen Entwicklungsstadium.
 
Hi,

ein ganz anderes Problem als auf das ich bisher aufmerksam gemacht wurde, wenn man portupgrade per Cron laufen lässt:

Code:
34242 root        1 115    0  3156K   868K RUN    336:29 89.16% script

…

trace -p 34242
Process 34242 attached - interrupt to quit
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()
read(0, "", 1024)                       = 0
write(68, "", 0)                        = 0
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()
read(0, "", 1024)                       = 0
write(68, "", 0)                        = 0
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()
read(0, "", 1024)                       = 0
write(68, "", 0)                        = 0
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()
read(0, "", 1024)                       = 0
write(68, "", 0)                        = 0
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()
read(0, "", 1024)                       = 0
write(68, "", 0)                        = 0
gettimeofday({...}, NULL)               = 0
select(69, [?], NULL, NULL, {...})      = 1 ()

…

root    34242 91.5  0.2  3156   868  p1  R+    7:25PM 338:35.32 /usr/bin/script -qa /tmp/portupgrade.15145.3 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=ghostscript-gpl-8.60 UPGRADE_PORT_VER=8.60 make FETCH_BEFORE_ARGS=-q
root    35786  0.0  0.2  3308   960  p0  S+    1:32AM   0:00.01 grep script
root    15145  0.0  5.7 37320 29164  p1  I+    6:10PM   0:20.27 ruby18: portupgrade: [67/114] ghostscript-gpl-8.60 (ruby18)
root    34265  0.0  0.2  3456  1104  p2  I+    7:25PM   0:00.01 /bin/sh -ec cd /usr/ports/print/ghostscript8 && make config;
root    34280  0.0  0.3  3456  1352  p2  I+    7:25PM   0:01.51 /bin/sh -c if [ -e /var/db/ports/ghostscript8/options ]; then  . /var/db/ports/ghostscript8/options;  fi;  set -- A4SIZE^I"Set A4 (not Letter) as a default paper size"^Ioff  FONTCONFIG^I"fontconfig support"^Ion  FT_BRIDGE
root    34878  0.0  0.2  3456  1164  p2  I+    7:25PM   0:00.02 /bin/sh -c /usr/bin/dialog --checklist "Options for ghostscript8-nox11 8.62_5" 21 70 15  A4SIZE "Set A4 (not Letter) as a default paper size" off FONTCONFIG "fontconfig support" on FT_BRIDGE "FreeType bridge" off X11 "X11

…

Sowie es aussieht, hängt Portupgrade bei einem Bildschirmdialog fest, der natürlich aufgrund der detached session nicht beantwortet werden kann.

Kennt jemand eine Ausweg? Bitte jetzt nicht "manuell aktualisieren" sagen.
 
OK, ich möchte nicht als unbelehrbar gelten. Es ist definitiv fehl am Platze, dass man den Server erst recht dann hinrichtet, wenn man eigentlich Aufwand sparen möchte.

Es ist jedoch schade, dass portupgrade nicht selbstständig und unbeaufsichtigt Abhängigkeiten auflösen und aktualisieren kann, obwohl ein portupgrade -aP soetwas suggeriert. Ich scheine aber nicht der Einzige mit diesem Problem zu sein. Linux mag seine Macken haben – aber ein aptitude update && aptitude upgrade hat mir in den letzten 4 Jahren nie solche Probleme gemacht.

Immerhin kann ich csup und freebsd-update unbesorgt laufen lassen.

Produktiv:

Reicht es erfahrungsgemäß aus, jede Woche eine 10 Minuten für einen durchschnittlichen Server zur Aktualisierung einzuplanen, sofern dabei nichts schief geht? Bei derzeit 40 Servern könnte ich so täglich ca. 1 Stunde "Systempflege" einplanen.
 
Anbei der Screenshot… ein Blick in die Logs hätte das strace & Co gespart ;)
 

Anhänge

  • Picture 3.png
    Picture 3.png
    218,9 KB · Aufrufe: 342
Ideal. Da ich den GENERIC Kernel und RELEASE Version benutze, sollte es da auch keine Probleme geben.

Wie genau soll denn der Kernel im laufenden Betrieb ausgetauscht werden? Ich bezweifle übrigens, dass dein Debian das konnte...
Also zumindest die automatisierten Updates der Base weglassen. Ich sehe sowieso keinen Grund warum man das automatisch machen muss, so oft sollte es da nicht Probleme geben und wenn dann sollte man auch die neue Kernel laden.

Sowie es aussieht, hängt Portupgrade bei einem Bildschirmdialog fest, der natürlich aufgrund der detached session nicht beantwortet werden kann.

Kennt jemand eine Ausweg? Bitte jetzt nicht "manuell aktualisieren" sagen.
BATCH=1 in /etc/make.conf eintragen.
 
Zuletzt bearbeitet:
Zurück
Oben