FreeBSD aktuell halten. Wie genau?

itti

Well-Known Member
Ich habe mir vor einiger Zeit 5.1 installiert und auch schon soweit als Router für DSL laufen mit PPP und NAT. natürlich läuft da auch ssh und genau das is der punkt. ich weiß dass es in letzter zeit ein paar sicherheitslücken in openssh gab und möchte gern einfach mein komplettes system aktualisieren. ich habe cvsup-without-gui installiert und ein ports-supfile angelegt mit dem ich meinen ports-tree auf neuesten stand gebracht habe. wie geht das aber jetzt weiter? gibts einen befehl mit dem man alle installierten ports jetzt auf den neuesten stand bringen kann? und wie läufts mit dem restlichen system das ja aus packages besteht. die sources ebenfalls mit cvsup updaten? mir ist schon öfters etwas wie "buildworld" aufgefallen aber ich weiß echt nicht wie man das nun einsetzt. enthält src auch den kernel source? dafür habe ich wenigstens noch eine anleitung im handbuch gefunden.
 
itti,

tja, das ist eine gute Frage. Ich für meinen Teil würde die auch gerne für OpenBSD beantwortet wissen. Für OpenBSD gibt es so ein Tool nicht und bei FreeBSD muß man auch einiges händisch machen (wenn ich es richtig mitbekommen habe)

<Provokation>
Wenn man dieses Thema auf Mailinglisten und in Foren anspricht, kommt meist eine Antwort, die zig Befehle auflistet, die man in bestimmter Reihenfolge abarbeiten muß, wobei jeder Befehl nochmal mind. 5 Parameter enthält.
In den Antworten schwingt dann immer ein Unterton mit: Wer zu blöde ist, sich diese Befehle alle zu merken, solls besser sein lassen.

Aber: Ich will mein System täglich BENUTZEN, und _nicht_ täglich ADMINISTRIEREN. Daher wünsche ich mir als User ein einfache Updatemöglichkeit (Optimum: 1 Befehl), der meine ganzen administrativen Updatewünsche erledigt.
Oft wird bei den Entwicklern aus den Augen verloren, dass die Zielgruppe nun mal User sind, die nicht jeder Innerei des Systems kennen und administrieren (wollen).
Ich verstehe z. B. nicht, was an SUSEs yast2 prinzipiell schlecht ist. Das Konzept ist gut und es wird die Angst vor der Administration genommen. Klar, man kann damit nicht die hinterletzte Option in jeder noch so seltenen Konfig-Datei ändern, aber für die Standard-Administrationsaufgaben ist es OK. yast2 ist m. M. nach einer der Erfolgsfaktoren der SUSE-Distri.
</Provokation>

So, jetzt zerpflückt mich ;)

Gruß
RW
 
An dieser Stelle möchte ich die "Suchen" -Funktion dieses Forums vorschlagen, welche bereits mehrfach ihren Nutzen beweisen konnte !
 
installierte ports auf dem neusten standd halten

hallo,

installiere dir /usr/porst/sysutils/portupgrade

mache in /usr/ports dein make update

dann pkg_version -v | grep needs

damit siehst was neu ist, unnd mit

portupgrade -aC

datest du alle ab, portupgrade -fC <portname>

bringt nur diiesen port auf zack.

gruss Breiti
 
Lieber RW, bitte vergiss nicht, das die BSDs im wesentlichen durch den freiwilligen Einsatz von Arbeitskraft entstehen. Wenn Du sagst:
Oft wird bei den Entwicklern aus den Augen verloren, dass die Zielgruppe nun mal User sind, die nicht jeder Innerei des Systems kennen und administrieren (wollen).
dann ist das zunächst mal in diesem Kontext *falsch*, weil "der User" eben sein System *nicht* immer neu baut. "Der User" wird sich eben ein Release installieren und von Release zu Release upgraden.

yast2 ist m. M. nach einer der Erfolgsfaktoren der SUSE-Distri.
Da stimme ich Dir zu. Warum bleibst Du denn dann nicht bei SUSE? In diesem Thread hat ja keiner behauptet, das es schlecht ist. Ganz im Gegenteil, wenn es für dich passt, dann benutze es. Das ist für Dich vermutlich einfacher, als dich über den zugegebenermassen nicht ganz trivialen Update/-grade Prozess zu ärgern.
 
Cvsup und anschliessendes portsdb -Uu kann man auch per cronjob erledigen.

Einiges andere auch, gemaess Set it and forget it. ;)
 
Und jetzt noch die Antwort auf die eigentliche Frage: um das Basissystem aktuell zu halten, benutzt Du auch cvsup. Ein sup-File findest Du unter /usr/share/examples/cvsup/standardsupfile. Leg' Dir eine Kopie davon an und trage einen deutschen cvsup-Mirror ein, z.B.
Code:
*default host=cvsup3.de.freebsd.org

Nach dem cvsup lauf liest Du zunächst /usr/src/UPDATING. Typischerweise machst Du dann folgendes:
Code:
cd /usr/src
make buildworld
make buildkernel
make installkernel
--> Reboot in single user
mount -a
cd /usr/src
make installworld
mergemaster
So mache ich es zumindest. Mein Laptop ist damit von 4.0-RELEASE bis 5.1-CURRENT über diesen Mechanismus gross geworden :)
 
Original geschrieben von itti
paar sicherheitslücken in openssh gab und möchte gern einfach mein komplettes system aktualisieren. ich habe cvsup-without-gui installiert und ein ports-supfile angelegt mit dem ich meinen ports-tree auf neuesten stand gebracht habe. wie geht das aber jetzt weiter?

Die Ports sind NICHT das System.
Das was Du willst ist eine update Deiner Systemsourcen.
cvsup file dazu:
Code:
*default host=cvsup2.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_1
*default delete use-rel-suffix
src-all

Danach baust Du, wie Du schon selbst geschrieben hast, das System neu.
Code:
cd /usr/src/
less UPDATING #lesen!
make buildworld 
make buildkernel KERNCONF=$DEINE_KERNEL_CONF
make installkernel KERNCONF=$DEINE_KERNEL_CONF
make installworld
mergemaster

Das ist die Kurzfassung, suche hier im Forum danach, bzw. konsiltiere das FreeBSD Handbuch.

Deinen Portstree hälst Du auch mit cvsup up-to-date.
Ich empfehle Dir folgendes:
Installiere "portsupgrade" aus den Ports.
Suche bei onlamp.com nach einer Anleitung zu "portsupgrade" oder hier im Forum (es ist einfach zu verstehen).
Nutze nur noch portsupgrade für Deine Ports.

Ansonsten kann man auch einfach patches zu den Problemen installieren.
Wenn es Sicherheitsprobleme gibt, so sind diese unten rechts auf www.freebsd.org (Security Advisories) angegeben.
Auf einen der links geklickt und Du bekommst zu lesen um was es geht, was es verursacht und wie man einen patch dafür installiert.
Patches werden wie folgt instaliert:
Code:
# cd /usr/src
# patch < /path/to/sshd.patch
# cd /usr/src/secure/usr.sbin/sshd
# make obj && make depend && make all install

Ab und an muss man dann das System neu starten, den Kernel neu backen und/oder das ganze System. Dies steht in den jeweiligen Meldung aber alles drin.

Hth.
 
Original geschrieben von ReinerWein
<Provokation>
Wenn man dieses Thema auf Mailinglisten und in Foren anspricht, kommt meist eine Antwort, die zig Befehle auflistet, die man in bestimmter Reihenfolge abarbeiten muß, wobei jeder Befehl nochmal mind. 5 Parameter enthält.
In den Antworten schwingt dann immer ein Unterton mit: Wer zu blöde ist, sich diese Befehle alle zu merken, solls besser sein lassen.

Nun ja, das System wird immer auf die gleiche weisse gebaut, ebenso der Kernel. Da braucht man sich nicht viele Befehle merken. Das Problem ist dann für viele noch "mergemaster".

Aber: Ich will mein System täglich BENUTZEN, und _nicht_ täglich ADMINISTRIEREN. Daher wünsche ich mir als User ein einfache Updatemöglichkeit (Optimum: 1 Befehl), der meine ganzen administrativen Updatewünsche erledigt.

<Provokation>
Schreib Dir nen Shellscript welches dies für Dich erledigt
</Provokation>

Und, wie ich meine, ist das wirklich kein Problem sich die paar Befehle zu merken.

Code:
Oft wird bei den Entwicklern aus den Augen verloren, dass die Zielgruppe nun mal User sind, die nicht jeder Innerei des Systems kennen und administrieren (wollen).

Stimmt, was die Ports angeht, so wäre eine Applikation wie bei Darwin "PortsApp" oder so heisst das Ding, nicht schlecht.
Im Prinzip nur eine GUI die die ganzen Ports auflistet, diese kann man anklicken und installieren. Gut ist. Aber, sollte es ein problem sein "portinstall xxx" einzugeben? Ok, das suchen auf der shell fällt weg, aber viele dieser User nutzen diese auch nicht, sondern einen Dateimanager....

Ich verstehe z. B. nicht, was an SUSEs yast2 prinzipiell schlecht ist. Das Konzept ist gut und es wird die Angst vor der Administration genommen. Klar, man kann damit nicht die hinterletzte Option in jeder noch so seltenen Konfig-Datei ändern, aber für die Standard-Administrationsaufgaben ist es OK. yast2 ist m. M. nach einer der Erfolgsfaktoren der SUSE-Distri.

Das ist der Erfolgsfaktor. Ja.
Nur, ein User der nicht mehr weiss was passiert wenn er Knopf A drückt, will man das wirklich? Ich will das nicht für mich. Auf keinen Fall. Dann kann man gleich zu MS zurück.
Ob einer nun SuSE nutzt und sein System nur grafisch kennt, oder MS, wo ist der Unterschied? Mit dem open source kann dieser User so oder so nichts anfangen. So gesehen, SuSE goes MS.

Und nur weil findige Marktingstrategen meinten die Maus und GUI wäre der Weisheit letzter Schluss, muss ich das nicht glauben.
In der Firma z.B. wird lieber mit der Tastatur gearbeitet, als mit der Maus, und das schneller und effektiver.

Was nun diese Update-Funktion angeht, so könnte man diese evtl. durch ein GUI tool erleichtern.
Dieses könnte den Patch selbst holen, die md5 checken und diesen installieren. Dann dem User sagen was zu tun ist (System neustart,...), ABER es sollte bei den Aktionen immer einen xterm öffnen in dem der User sieht was das Programm macht und nicht still und leise arbeiten.
 
die benutzung von cvsup habe ich bereits drauf ;)

nunja habe am freitag mein system wie hier beschrieben upgedated. im moment fahre ich somit also 5.1-release-p10 mit meinem custom kernel. bringts eigentlich viel in der /etc/make.conf athlon-tbird anzugeben bzw. in der kernelconf i686_cpu alleinig stehen zu lassen? habe ich gemacht aber bisher funktioniert noch alles :)
 
der theorie nach soll das mehr performance bringen, in der paxis allerdings wirst du den unterschied nicht bemerken.
 
ja ich hab ja auch irgendwo gelesen dass im moment lediglich der sshd davon profitieren soll... keine ahnung inwiefern diese aussage noch zutrifft.
 
okidoki, das hatte ich auch rausgelesen, ich meine: -> $DEINE_KERNEL_CONF

bin jetzt gerade nämlich an diesem schritt... *g*
 
/usr/src/sys/i386/conf
Da stehen die Kernelconfigs, als Standard ist dies GENERIC. Diese Datei kopieren mit dem Namen Deiner Wahl (am besten wie Dein neuer Kernel heissen soll):

cp GENERIC HOMER

Dann die Datei "HOMER", also die Kernelconfig bearbeiten.
Danach nach /usr/src wechseln und folgendes eingeben:

make buildkernel KERNCONF=HOMER
make installkernel KERNCONF=HOMER
 
im thread: http://www.bsdforen.de/forums/showt...11&perpage=15&highlight=kernconf&pagenumber=3

steht, das auch ein "make buildkernel" und ein "make installkernel" reichen würde...nimmt er dann den standardkernel? (in meinem fall 5.2)

danke für das howto, wenn meine vorlage nicht klappt, nehm ich mal den generic mir vor...



scheint auch zu klappen:
>>> Kernel build for GENERIC completed on Sun Jan 11 20:46:12 CET 2004
 
Zuletzt bearbeitet:
GENERIC sollte immer klappen, aber den Kernel brauchste je nicht neu bauen, der rennt ja eh.
 
wenn ich das jetzt alles gemacht habe, wie sehe ich dann ob alles geklappt hat, also ich mein jetzt wie kann ich mir die version anzeigen lassen, die ich gerade von FreeBSD draufhab?
 
Hast Du Dir wohl gelöscht, wenn es weg ist.
Wie sieht Dein cvsup file aus um die sourcen zu ziehen?
Sollte dies beinhalten, mehr nicht:

*default host=cvsup2.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_1
*default delete use-rel-suffix
src-all

Den "tag" RELENG_5_1 natürlich auf die Version anpassen die Du nachher auch fahren willst.
 
bin gerade beim cvsup drin...so langsam ist das src wieder da ;)
kernel ist schon auf 5.2, fehlt nur noch der weltenneubau...

danke!
 
Du solltest Kernelland und Userland IMMER in snyc halten. Insbesondere unter CURRENT, was Du ja fährst. Es kann sonst zu unangenehme Überraschungen kommen die bis zu einer Unbrauchbarkeit des Systems gehen können.
 
Zurück
Oben