Update meiner OpenBSD Firewall

W

Weihnachtsmann

Member
Hallo,

ich betreibe aktuell 2 OpenBSD 3.6 Firewalls, auf denen das dev-Paket nicht mitinstalliert ist, und sich auch keine Sourcen auf den Systemen befinden.

Momentan spiele ich die Updates erst immer auf einem Testsystem ein und kopiere dann die kompilierten Dateien auf die Firewalls hinüber. Solang nur wenige Files geändert werden ist das ja auch kein Problem nur mit dem aktuellen 008 Patch betrifft das jetzt eine ganze Menge an Files.

Hat jemandnd eine Idee wie man das optimieren kann oder vllt. gibts da ja schon irgendwo fertige Scripte.

Gruß
Weihnachtsmann
 
Mir schwirrt dazu folgendes durch den Kopf:

release(8) lesen, Installsets erzeugen und per NFS mounten oder auf die betroffenen Rechner kopieren und damit ein Systemupdate durchfuehren.

Da ich allerdings noch nie ein Update von CD gemacht habe, sondern nur Installationen auf nackten Rechnern, weiss ich nicht, was das Update mit /etc anstellt. Also besser erstmal auf einer Testmaschine ausprobieren.

Da mein Testeisen leider gerade das zeitliche segnet und ich mich daher gezwungen sehe, meinen Desktop auf -current zu bringen, werde ich das vielleicht mal am Wochenende auf dem sterbenden Rechner durchspielen (3.5 installieren -> Update 3.6 von CD -> Update -current mit per release(8) erstellen Files), wenn ich die Zeit finde.
 
Meine Idee wäre, die Sourcen und die Tools, wie gcc make usw. auf einen Wechseldatenträger zu packen und mit einem mount_union ins Filesystem zu hängen. Anschließend das System or whatever updaten. Habe das ganze mal unter FreeBSD mit den Sourcen auf CD und kleiner HD gemacht. Dauerte zwar lange, aber es ging.

Gruß c.
 
Das scheint ein wenig veraltet zu sein und muesste wohl fuer 3.5 und 3.6 noch aufgemoebelt werden.
 
Ich denke der von kili beschrieben Weg dürfte der schmerzloseste sein. Das System auf einem Testrechner bauen, release(8) erstellen, die .tgz auf die Firewalls bringen und dort auspacken.

In der FAQ ist beschrieben, wie man von 3.5 auf 3.6 "upgraden" kann, das beabsichtigte Update würde nicht viel anders funktionieren, nur eben schneller und ohne das /etc-Gedöns.

kili schrieb:
Da ich allerdings noch nie ein Update von CD gemacht habe, sondern nur Installationen auf nackten Rechnern, weiss ich nicht, was das Update mit /etc anstellt. Also besser erstmal auf einer Testmaschine ausprobieren.
Zum Vergrößern anklicken....
Soweit ich weiss macht das Update garnichts mit /etc. Das bleibt Handarbeit.
 
C-Keen schrieb:
Eine weitere Möglichkeit wäre, die sourcen / ports per NFS zu mounten und dann zu kompilieren....
Zum Vergrößern anklicken....

Hi,

relativ alter Thread, aber trifft genau mein aktuelles Problem.
Habe ein Alix mit CF-Karte. Das identische System hab ich zusätzlich in einer qemu-vm.

Da ich dem kleinen Alix die ganze Kompilierarbeit sparen will, dachte ich in der vm zu kompilieren und die Dateien rüberzukopieren. Geht erstmal nur um Patches.

Da es aber teilweise recht viele Dateien werden können und ich nicht alle einzeln kopieren möchte, würde ich die Variante mit dem NFS-Mount gerne mal ausprobieren.

Könnte ich in der qemu-vm quasi bis zum 'make' einschliesslich alles fertigkompilieren, dann das /usr/src Verzeichnis per NFS im Alix mounten und dort 'make install' ausführen? :p
 
Vielleicht bin ich noch nicht so bewandert in openbsd... weiss jetzt nich genau wie ich installsets erzeuge.. :rolleyes:

könnte mann damit auch die patches einspielen oder ist das eher für system updates von 4.4 auf 4.5 und ähnliches gedacht?

Die Methode die ich grade geschrieben hatte funktioniert aber. Gerade getestet.
 
ollic schrieb:
Vielleicht bin ich noch nicht so bewandert in openbsd... weiss jetzt nich genau wie ich installsets erzeuge.. :rolleyes:
Zum Vergrößern anklicken....

man release

könnte mann damit auch die patches einspielen oder ist das eher für system updates von 4.4 auf 4.5 und ähnliches gedacht?
Zum Vergrößern anklicken....

Nein, das geht selbstverstaendlich auch fuer Patches, aber....

Die Methode die ich grade geschrieben hatte funktioniert aber. Gerade getestet.
Zum Vergrößern anklicken....

Du kannst auf einem schnelleren System die Patches einspielen und dann anhand der Patchanleitung das neu bauen, was eben neu gebaut werden muss. Das ist ja je nach Patch unterschiedlich -- mal nur ein einzelnes Programm oder nur der Kernel, aber wenn z.B. mal ein Patch fuer eine Library kommt, dann muss typischerweise auch das ganze statisch gelinkte Geraffel neu gebaut werden. Das Problem dabei ist, dass Du jetzt garantiert nicht anfangen willst, alles, was nun tatsaechlich neu gebaut und installiert wurde, manuell auf das Zielsystem (Dein Alix-Board) zu kopieren. Deshalb ist es am einfachsten, nach release(8) einmal das komplette System zu bauen, die Installsets zu erzeugen, und dann wie ich vor etlichen Jahren schon schrub, dort ein normales Update durchzufuehren.

Es ist dabei wirklich voellig egal, ob Du das mit einem -current machst (obwohl man da auch gleich Snapshots nehmen und sich die Compiliererei sparen kann), oder ob Du aktuell 4.5 nimmst. Bei letzterem waere es auch sinniger, nicht mit den Patches zu hantieren, sondern einfach den OPENBSD_4_5_STABLE Branch zu nehmen.

Das Prozedere (auf dem schnellen Rechner) ist dann wie gesagt das, was in release(8) steht: Kern bauen ggf. rebooten, Userland bauen, ggf. rebooten, dann (als root)

Code: 
export DESTDIR=/var/tmp/whateverdest
export RELEASEDIR=/var/tmp/whateverreleasedir
mkdir $RELEASEDIR $DESTDIR
make release
cd ../distrib/sets
sh checkflist
# wenn checkflist ein Diff produziert, muss man noch mal draufsehen,
# was da genau fehlt oder zuviel ist, kann aber auch harmlos sein.
rm -rf $DESTDIR
unset DESTDIR RELEASEDIR

(Warnung: das ist jetzt moeglicherweise nicht exakt das, was in release(8) steht, weil ich es jetzt einfach mal schnell hier reingetippert habe)

Und dann hast Du in /var/tmp/whateverreleasedir in etwa das Geruempel, das Du so aehnlich auch auf offiziellen Mirrors in den Snapshot-Directories findest, inklusive bsd, bsd.rd, bsd.mp, pxeboot, base45.tgz, ...

Wenn mir der Sinn mal gerade nicht nach Snapshots steht, mache ich das jedenfalls exakt so (allerdings mit -current), und meinen Soekris-Truemmer update ich dann via Netboot des bsd.rd Kernels, die benoetigten Files werden von dem gleichen Rechner, von dem bsd.rd per tftp geladen wird, per ftp abgeholt, ebenso eine Hand von Packages (ddclient, pftop, ntop). Eventuelle Aenderungen an Configfiles werden mit sysmerge(8) erledigt.

Das ist alles total entspannt, das Bauen des Systems (auf dem "schnellen" Rechner) inklusive make release dauert zwar einige Zeit, aber da muss ich ja nicht dabei sitzen und zugucken, das laeuft ja so durch. Und das Update des Soekris-Teils dauert dann nervige 20 Minuten, aber auch nur, weil ich da bloederweise eine uralte langsame CF-Karte drin habe. Mit 'ner richigen Platte (oder sonst einem schnellen Blockdevice) waere das wahrscheinlich in weniger als fuenf Minuten erledigt.

Also nochmal: release(8) lesen und einfach mal ausprobieren.
 
Wenn man snapshots benützt kann man meistens auch einfach die snapshot sets runterladen und drüber extrahieren, das machen laut -misc einige devs auch so.... (-current faq beachten, falls sich noch was geändert hat).
Wenn man dabei zwischen Versionen hüpft eben upgrade.html lesen...
 
Auf meinem Notebook update ich -current per CD. Das geht am einfachsten, schnellsten und sichersten. Hinterher die /etc configs per sysmerge auf den neuesten Stand bringen und die Packages updaten. Das macht sinn, da ich das sehr häufig mache und viele Packages installiert habe. Aus den sourcen bauen würde jedesmal ewig dauern und meine Produktivität einschränken.

Auf meinem Webserver kann ich schlecht eine CD einlegen und die AMD -current packages hinken auch ein wenig in der Aktualität hinterher. Daher baue ich mir dort mein komplettes -current System aus den sourcen, siehe release(8). Genauso die Ports werden aus den sourcen gebaut.

Eine andere Alternative wäre dann noch, die sets downloaden und in den entsprechenden locations zu entpacken, sysmerge für die configs, fertig. So mache ich das auf meinem Soekris, da ich dort weder ein CD-Laufwerk habe, noch einen compiler.

Als letztes kann man sich natürlich nur den bsd.rd Kernel downloaden (Ram-Kernel) und diesen in / kopieren. Beim booten dann den bsd.rd Kernel auswählen und das update wie beim update auf CD durchführen. Das update dauert aber länger, da die ganzen sets aus dem Netz geladen werden müssen. Ausserdem braucht man hier eine Ausgabe auf der Konsole bzw. auf einer seriellen Konsole.

Wichtig ist bei -current immer, http://openbsd.org/faq/current.html im Auge zu behalten und evtl. Änderungen durchzuführen.
 
condor schrieb:
Wenn man snapshots benützt kann man meistens auch einfach die snapshot sets runterladen und drüber extrahieren, das machen laut -misc einige devs auch so....
Zum Vergrößern anklicken....

Das kann zwar manchmal ganz praktisch sein, wenn man z.B. zu faul ist ein serielles Kabel anzustoepseln und einen Rechner ueber eine SSH-Session updaten will und wenn man mit den potentiellen Nebenwirkungen leben kann, aber IMHO ist ein Update via bsd.rd im Zweifelsfall vorzuziehen.

Es macht z.B. keinen Spass, wenn man so einen Soekris-Truemmer mit viel zu kleiner CF-Karte betreibt (ja, ich koennte und sollte da einfach mal was groesseres reinstecken) und dann beim manuellen Auspacken der Installsets ein ENOSPC auf den Schirm gerotzt bekommt, weil diverse Programme und shared Libraries zwar ueberschrieben wurden, aber durch noch existierende Prozesse (wie z.B. sshd) in Beschlag sind.

Und wenn dann mal ernsthaft was in die Hose geht, muss man sowieso an die Console (pysikalisch oder per serieller Schnittstelle).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben