Ports

LeoLinux

Well-Known Member
Hi,

ich würde gerne wissen, wie Ihr denn vorgeht, wenn ihr Software aus den Ports installiert und davon nur ein Programm und dessen Abhängigkeiten (wie in meinem Fall z.B. Dovecot) auf den aller neusten Stand bringen wollt?
Beim Studieren des FreeBSD Handbuchs wurde ich auf portupgrade aufmerksam gemacht. Dazu müsste man doch aber zuvor den kompletten Portstree auf den Stand bringen sodass die neue Dovecot Software darin vorhanden ist, oder gibt es da Tricks?

Danke & Grüße
 
portsnap fetch update
portmaster mein-port

anstatt portmaster mit portupgrade
portupgrade mein-port

Klar bringe ich zuvor den Portstree auf den aktuellen Stand. Das empfiehlt sich auch wegen der Abhängigkeiten.
 
Danke für deine Antwort.

Ich frage mich wozu "portsnap fetch update" gut ist? Macht das fetch nicht exakt das Selbe wie ein "cvsup /usr/share/examples/cvsup/ports-supfile -h cvsup.de.FreeBSD.org" ?? Würde mir bei einem noch nicht vorhandenen Portstree ein "portsnap fetch extract" nicht den Portstree erst einmal herunterladen und in /usr/ports anlegen? Und hat ein "portsnap update" nicht erst dann einen Effekt, wenn man zuvor das komplette System von lass sagen 8.x auf 9.x bereits upgetdated wurde und nur der Portstree noch irgendwo bei 8.x hinterher hinkt? Ansonsten sollte sich doch eigentlich nichts ändern, oder?!
Bitte entschuldige, wenn sich meine Fragen etwas noob-like anhören, aber ich habe dieses Update-Szenario bei FreeBSD noch nie ganz durchschaut.


Mein bisheriges Vorgehen war folgendes:

Code:
cvsup /usr/share/examples/cvsup/ports-supfile -h cvsup.de.FreeBSD.org
Um den Portstree upzudaten - doch leider scheint der noch mit genau den selben Versionen befüllt zu sein wie zuvor ;(

Danach habe ich ein
Code:
portupgrade -Rpv dovecot ;
gemacht. Doch leider war der Dovecot bereits in der Verison installiert, also gab es nichts zu "portupgraden". ;/



Grüße
 
P.S. Ich bin gerade dabei mir ein CVSUP supfile zu erstellen (FreeBSD Hanbuch --> "A.6.5 CVSup File Collections")


Code:
#======================================#
#                                      #
#       CVSUP Configuration File       #
#                                      #
#======================================#


*default host=cvsup.de.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress


#ports-all

ports-base release=current
#ports-accessibility
#ports-arabic
#ports-archivers
#ports-astro
#ports-audio
#ports-benchmarks
#ports-biology
#ports-cad
#ports-chinese
#ports-comms
#ports-converters
#ports-databases
#ports-deskutils
#ports-devel
#ports-dns
#ports-editors
#ports-dns
#ports-editors
#ports-emulators
#ports-finance
#ports-french
#ports-ftp
#ports-games
#ports-german
#ports-graphics
#ports-hebrew
#ports-hungarian
#ports-irc
#ports-japanese
#ports-java
#ports-korean
#ports-lang
ports-mail release=current
#ports-math
#ports-mbone
#ports-misc
#ports-multimedia
#ports-net
#ports-net-im
#ports-net-mgmt
#ports-net-p2p
#ports-news
#ports-palm
#ports-polish
#ports-ports-mgmt
#ports-portuguese
#ports-print
#ports-russian
#ports-science
#ports-security
#ports-shells
#ports-sysutils
#ports-textproc
#ports-ukrainian
#ports-vietnamese
#ports-www
#ports-x11
#ports-x11-clocks
#ports-x11-drivers
#ports-x11-fm
#ports-x11-fonts
#ports-x11-servers
#ports-x11-themes
#ports-x11-toolkits
#ports-x11-wm

sollte mir das nicht den ganzen Ports tree auf Current bringen? Leider funktioniert es so nciht ... ich bekomme folgende Fehlermeldung, da er mit dem Begriff "current" wohl als solches nichts anzufangen weiß ...:

Code:
server [/usr]# cvsup /usr/share/examples/cvsup/ports-supfile
Connected to cvsup.de.FreeBSD.org
Server message: Unknown release "current" for "ports-base"
Server message: Unknown release "current" for "ports-mail"
Skipping collection ports-base/current
Skipping collection ports-mail/current
Finished successfully
server [/usr]#


Grüße
 
Du hast ja schon die ports-mgm/portupgrade-Suite erwähnt und mit ihr kommt portversion(1) einher, mit dem zuerst herausgefunden wird, welche Ports z.B. veraltet sind:

%portversion -l\<
[Rebuilding the pkgdb <format:bdb_btree> in /var/db/pkg ... - 82 packages found (-0 +82) .................................................................................. done]
mysql-client <


Dann könnten z.B. die neuen Versionen aktualisiert werden:

%portupgrade -a

FALSCH: ==> Auf dem Weg ist erst mal der explizite Einsatz eines low-level-Tools wie portsnap nicht nötig. <==
RICHTIG: portversion/portupdate aktualisiert nicht den Portstree!!!

Ich selbst hänge die Sache noch eine Stufe höher auf, indem ports-mgmt/portcheck regelmäßig läuft und gleich mehrere Sachen macht, nämlich erst den Portstree mit portsnap aktualisert, dann mit pkg_version veraltete Ports findet und abschließend mit portaudit Ports mit Sicherheitlücken berichtet.

---

Wie auch immer, bzgl. der Updaterei sollte man immer einen Plan B vor Augen haben, wenn irgend etwas schief gehen sollte. So könnte man z.B. mit pkg_create -b alle Pakete erst mal sichern, bevor man zum eigentlich Update schreitet. Und man tut auch nicht schlecht daran, wenn immer ein aktuelles Backup aller selbst und somit absichtlich modifizierten Konfigurationsdateien vorgewiesen werden kann. Dann berichten andere Leute von wiederum anderen Leuten wie Administratoren, die erst mal wichtige Upgrades in einem Testsystem durchexerzieren und sich dann erst die Produktion verknöpfen. Und dann gibt es noch ein wunderbares Tool pkg_libchk aus sysutils/bsdadminscripts, das herausfindet ob wirklich für alle dynamisch gelinkten Programme die Bibliotheken installiert sind. *be peace with u*
 
Zuletzt bearbeitet:
Wie auch immer, bzgl. der Updaterei sollte man immer einen Plan B vor Augen haben, wenn irgend etwas schief gehen sollte. So könnte man z.B. mit pkg_create -b alle Pakete erst mal sichern, bevor man zum eigentlich Update schreitet. Und man tut auch nicht schlecht daran, wenn immer ein aktuelles Backup aller selbst und somit absichtlich modifizierten Konfigurationsdateien vorgewiesen werden kann. Dann berichten andere Leute von wiederum anderen Leuten wie Administratoren, die erst mal wichtige Upgrades erst mal in einem Testsystem durchexerzieren und sich dann erst die Produktion verknöpfen. Und dann gibt es noch ein wunderbares Tool pkg_libchk aus sysutils/bsdadminscripts, das herausfindet ob wirklich für alle dynamisch gelinkten Programme die Bibliotheken installiert sind. *be peace with u*
Gebe ich dir völlig Recht. Ich selbst sitze hier deshalb vor einem geklonten System, das ich mir dank Xen-Virtualisierung immer wieder auf den Ursprungszustand zurückschießen kann.


Sehe ich das richtig, dass mir "portversion -l\<" genau das Selbe liefert wie: "pkg_version -L ="? Beide Tools geben überprüfen, ob in meinem *Portstree* eine neuere Version des bereits installierten vorhanden ist?!

Code:
server [/usr]# portversion -l\<
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 227 packages found (-0 +1) . done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 21980 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000......... ..... done]
freetype2                   <
gnupg                       <
isc-dhcp41-server           <
libgpg-error                <
libksba                     <
mysql-client                <
mysql-server                <
p5-Archive-Tar              <
p5-HTML-Parser              <
perl                        <
pkg-config                  <
python26                    <
python31                    <
rrdtool                     <
screen                      <
server [/usr]#

Code:
server [/usr]# pkg_version -L =
freetype2                           <
gnupg                               <
isc-dhcp41-server                   <
libgpg-error                        <
libksba                             <
mysql-client                        <
mysql-server                        <
p5-Archive-Tar                      <
p5-HTML-Parser                      <
pango                               <
perl                                <
pkg-config                          <
python26                            <
python31                            <
rrdtool                             <
screen                              <
server [/usr]#


Ein
Code:
portupgrade --all
würde demnach jetzt ein "reinstall" mit allen oben aufegelisteten Tools durchführen - ggfs. auch deren Abhängigkeiten - ich denke das habe ich soweit verstanden. Mir ist nur noch immer nicht ganz klar -WIESO- ? ;)
Denn laut meines Kenntnisstands ist es so, dass mit einem FreeBSD RELEASE die Ports eingefroren werden. Somit sollte der Portstree zu FreeBSD 8.1 doch _immer_ mit gleichem Inhalt gefliefert werden, richtig? Weshalb würde mir ein cvsup oder ein portsnap fetch oder update nun einen neuen Tree herunterladen, wenn der doch sowieso RELEASE 8.1 bezüglich ist? Tut mir echt leid, aber da fehlt mir irgendwie noch die nötige Transparenz ... ;)
 
P.S.:
Auf dem Weg ist erst mal der explizite Einsatz eines low-level-Tools wie portsnap nicht nötig.

Gegen was überprüft "pkg_version -L =" oder "portversion -l\<" dann, wenn nicht gegen den mit "cvsup" oder "portsnap update" aktualisierten Portstree??


Grüße
 
P.S.:

Gegen was überprüft "pkg_version -L =" oder "portversion -l\<" dann, wenn nicht gegen den mit "cvsup" oder "portsnap update" aktualisierten Portstree??


Grüße

Die Frage habe ich mir beim Schreiben des Posts oben auch gestellt bzgl. portversion und portupgrade und habe in den Ruby-Scripts nichts gefunden, was auf ein vorheriges portsnap, etc. hinausläuft.

pkg_version hingegen läuft gegen den Portstree bzw. über den Portsindex:

pkg_version(1):
...
Each package's version number is checked against one of two sources to
see if that package may require updating. If the package contains infor-
mation about its origin in the FreeBSD ports tree, and a version number
can be determined from the port's Makefile, then the version number from
the Makefile will be used to determine whether the installed package is
up-to-date or requires updating.

If no origin for a package can be found, or if the port's Makefile cannot
be located, pkg_version will search for the package in the ports collec-
tion index file (typically /usr/ports/INDEX-8). Any matching version
number(s) there will be used to determine whether the installed package
is up-to-date or requires updating.
...

Und in dem Fall macht das auch Sinn, da ja portcheck vorher ein portsnap anstößt und dann pkg_version ausführt.
 
Sehe ich das richtig, dass mir "portversion -l\<" genau das Selbe liefert wie: "pkg_version -L ="?

Also erfahrungsgemäß liefern beide das selbe Ergebnis nur wird das anders ermittelt. portupgrade hinterlegt in einer indexierten Datenbank entsprechende Metainformationen zu den Ports, die dann z.B. portversion auswertet. Und die manpage zu portversion berichtet dann von einer etwas schnelleren Ausführung z.B. eben wegen der indexierten Datenbank.

portversion is very similar to pkg_version(1), but is optimized for
portupgrade(1) and runs much faster than pkg_version(1) thanks to the
ports database generated from the INDEX file. See portsdb(1) for
details.


Beide Tools geben überprüfen, ob in meinem *Portstree* eine neuere Version des bereits installierten vorhanden ist?!
Bzgl. portupgrade/portversion bin ich mit da nicht sicher.
 
portcheck vorher ein portsnap anstößt und dann pkg_version
^^ Ja, macht Sinn.


... nochmals zur eindeutigen Klarstellung:
Code:
cvsup /usr/share/examples/cvsup/ports-supfile -h cvsup.de.FreeBSD.org
potsnap fetch exctract
portsnap update
bewirken am Ende ein und das Selbe - nämlich einen geupdateten Portstree & Index - ist das korrekt?


Und dann noch zu einer anderen unbeantworteten Frage: Wenn ich FreeBSD neu installiere - via Sysinstall - dann werde ich an einer Stelle gefragt, ob ich die Ports installieren möchte oder nicht. In der Regel mache ich das an dieser Stelle bereits.
Aber mal angenommen ich hätte die Ports nicht zu Beginn oder auch später mit der Hilfe von Sysinstall installiert - würde ein "portsnap fetch extract" nicht exakt das für micht machen???


und nochmal zurück zu meinem Verständniskonten:
Denn laut meines Kenntnisstands ist es so, dass mit einem FreeBSD RELEASE die Ports eingefroren werden. Somit sollte der Portstree zu FreeBSD 8.1 doch _immer_ mit gleichem Inhalt gefliefert werden, richtig? Weshalb würde mir ein cvsup oder ein portsnap fetch oder update nun einen neuen Tree herunterladen, wenn der doch sowieso RELEASE 8.1 bezüglich ist? Tut mir echt leid, aber da fehlt mir irgendwie noch die nötige Transparenz ...
Wird der Portstree also doch nicht eingefroren? Oder ist er eingefroren und es werden nur NÖTIGSTE Änderungen darin vorgenommen, so dass ein portsnap update diese Änderungen aktualisieren würde und ein portupgrade -a das auf den neusten Stand in Relation zu dem Portstree bringen würde?


Besten Dank & Viele Grüße
 
Code:
potsnap fetch exctract
portsnap update
bewirken am Ende ein und das Selbe - nämlich einen geupdateten Portstree & Index - ist das korrekt?

portsnap aktualisiert auf jeden Fall den Portstree und den Index.

---

Und bzgl. portversion, portupgrade kommt das ebenfalls in dessen Tool-Suite enthaltene portsdb in Spiel, was letztendlich vom Portsindex die Werkseigene portsdb abgleicht.

FALSCH: ==> Insofern liegt es nahe, dass die Tools kaum einen anderen Mechanismus wie portsnap benutzen, an den Portsindex heran zu kommen. <==
RICHTIG: portversion/portupgrade benutzen letztendlich auch nur die Information im Portstree und basieren auf veralteten Angaben, wenn nicht vorher aktualisiert wurde.
 
Zuletzt bearbeitet:
Ok, vielen Dank - das hat aufjedenfall schonmal etwas mehr Licht ins Dunkle gebracht ;)


Im Moment mache ich folgendes auf meiner Kiste.

Code:
portsnap update
^^ da ich ja die Ports bereits damals bereits über Sysinstall installiert habe. Ansonsten hätte ich fetch extract vorziehen müssen, oder sehe ich das falsch?

Dann habe ich folgendes gemacht um mir einen Überblick zu verschaffen, was ansteht, wenn ich anschließend portupgrade drüber laufen lassen würde:
Code:
portversion -l\<
Dies verschafft lediglich _mir_ einen Überblick, richtig? Ich muss diesen Befehl nciht ausführen, um portupgrade zu informieren - das ist lediglich zu meiner Information, oder?


Dann habe ich noch:
Code:
portaudit -Fda # einmalig DB erstellen und checken
portaudit -a # ansonsten nur noch
um zu erfahren, was es an Sicherheitslücken zu beheben gibt. Diese Ausgabe dient auch lediglich meiner Inormation, oder muss ich den Befehl ebenfalls ausführen, dass portupgrade auch bescheid weiß, was es zu upgraden hat?!


... Und zu guter letzt habe ich ein:
Code:
portupgrade -a
... das läuft auch jetzt noch. Wenn ich das jetzt richtig verstanden habe, dass tauscht der mir jetzt alles aus was vorhin mit "portversion -l\<" aufgelistet wurde PLUS das Apache Problem das er mir via "portaudit -a" gefunden hat - oder muss ichdas extra aktualisieren / patchen?


Vielen Dank
 
Und dann noch zu einer anderen unbeantworteten Frage: Wenn ich FreeBSD neu installiere - via Sysinstall - dann werde ich an einer Stelle gefragt, ob ich die Ports installieren möchte oder nicht. In der Regel mache ich das an dieser Stelle bereits.
Aber mal angenommen ich hätte die Ports nicht zu Beginn oder auch später mit der Hilfe von Sysinstall installiert - würde ein "portsnap fetch extract" nicht exakt das für micht machen???
Das ist eine ganz transparente Geschichte. Du kannst während der Installation vom Medium den Portstree installieren, dann wird das ports.tgz Archiv in /usr/ports installiert. Den selben Effekt hat portsnap, oder auch die cvs-Geschichte.

Es ist in dem Fall also eher die Frage, nicht wie sondern wann willst du Ports installieren und dann brauchst du dann (z.B.) den Portstree.

Genau genommen könntest du nach der Installation auch /usr/ports wieder löschen, wolltest du kein Upgrade mehr durchführen, indem Ports immer wieder frisch compiliert würden. Und es spricht im Prinzip nichts dagegen, irgendwann später den aktuellen Portstree wieder zu installieren, um auf den aktuellen Stand zu kommen. Allerdings bevorzuge ich es, regelmäßig als in größeren Abständen zu aktualisieren. Was man aber auf jeden Fall dauerhaft auf dem System erhalten sollte, das sind dann Konfigurationsdateien wie eben /etc/make.conf.
 
Das ist eine ganz transparente Geschichte. Du kannst während der Installation vom Medium den Portstree installieren, dann wird das ports.tgz Archiv in /usr/ports installiert. Den selben Effekt hat portsnap, oder auch die cvs-Geschichte.
Super - genau so habe ich mri das vorgestellt. Danke ;)


Was man aber auf jeden Fall dauerhaft auf dem System erhalten sollte, das sind dann Konfigurationsdateien wie eben /etc/make.conf.
Ist klar. Die /etc/make.conf hege & pflege ich bereits ;) - in der Hoffnung später dann immer "portupgrade --batch" drüber laufen lassen zu können ...


Muss ich "portaudit -a" nun eigentlich ausführen bevor ich portupgrade durchführe, oder würde mir ein portupgrade auch so bemerken, dass er beispielsweise den Apache patchen / ersetzen muss?!
 
gerade eben ist mein portupgrade -a fertig geworden. Nun habe ich folgende Begebenheit:

Code:
server [/usr/ports]# portversion -l\<
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 232 packages found (-0 +1) . done]
server [/usr/ports]# portaudit -Fda
auditfile.tbz                                 100% of   61 kB   47 kBps
New database installed.
Database created: Mon Jul 26 21:05:02 CEST 2010
Affected package: apache-2.2.15_9
Type of problem: apache -- Remote DoS bug in mod_cache and mod_dav.
Reference: <http://portaudit.FreeBSD.org/28a7310f-9855-11df-8d36-001aa0166822.html>

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.
server [/usr/ports]#

Wie man sehen kann wurde die Apache-Lücke nicht gestopft. Ein portupgrade bewirkt also ncihts bezüglich der portaudit -a Meldungen?!

Grüße
 
Denn laut meines Kenntnisstands ist es so, dass mit einem FreeBSD RELEASE die Ports eingefroren werden. Somit sollte der Portstree zu FreeBSD 8.1 doch _immer_ mit gleichem Inhalt gefliefert werden, richtig? Weshalb würde mir ein cvsup oder ein portsnap fetch oder update nun einen neuen Tree herunterladen, wenn der doch sowieso RELEASE 8.1 bezüglich ist? Tut mir echt leid, aber da fehlt mir irgendwie noch die nötige Transparenz ...
Wird der Portstree also doch nicht eingefroren? Oder ist er eingefroren und es werden nur NÖTIGSTE Änderungen darin vorgenommen, so dass ein portsnap update diese Änderungen aktualisieren würde und ein portupgrade -a das auf den neusten Stand in Relation zu dem Portstree bringen würde?
Also genau genommen genommen ist der Portstree zu jedem Releasewechsel wirklich vollständig gelockt, so dass in der Phase so viel geportsnapt, gecvst, geportupgradet versucht werden kann wie man will, es ergibt sich einfach keine Änderung mehr. Sinn und Zweck der Angelegenheit ist, man will neben Kernel und Userland ja auch z.B. fix und fertig kompilierte Pakete für den Vertrieb des Releases z.B. auf DVD-ISO zum Download anbieten. Und nur auf dem Weg ist erst mal sicher gestellt, dass alle erzeugten Portpakete in sich schlüssig sind bzgl. Versionsnummer und damit auch bzgl. der Abhängigkeiten.

Wenn doch Änderungen vorgenommen werden, dann sind das nur ganz spezielle und müssen vom Portsteam durchgewunken werden.

http://www.freebsd.org/doc/en/articles/committers-guide/ports.html#AEN1466
 
Muss ich "portaudit -a" nun eigentlich ausführen bevor ich portupgrade durchführe, oder würde mir ein portupgrade auch so bemerken, dass er beispielsweise den Apache patchen / ersetzen muss?!
portaudit stellt erst mal nur fest, ob es bzgl. der installierten Pakete (einerlei ob es da nun womöglich neuere Versionen geben könnte) eine Sicherheitslücke gibt. Zwecks dessen wird immer erst auditfile.tbz abgeglichen und dann mit den installierten Paketen verglichen und entsprechend ein Fehlerreport erzeugt.

portupgrade hingegen aktualisiert nur auf eine neuere Version, weil eben diese da ist nicht aber wegen einer Sicherheitslücke. Andersrum kann es aber sein, dass erst mal unterbunden wird, ein Port mit Sicherheitslücke zu installieren, wenn dieser noch gar nicht installiert wurde bzw. wenn es noch keinen Patch dafür gibt. Kurzum, portupgrade hängt nicht von portcheck ab und vice versa, und aus der Manpage zu portupgrade geht nicht hervor, dass es diese "intelligenz" hätte, Sicherheitslücken zu erkennen außer wenn Ports halt für die Installation gesperrt sind.

Von der Reihenfolge her macht es daher Sinn, erst portaudit (bzw. pkg_version oder portversion) aufzrufen und dann das evtl. notwendige portupgrade bzw. portmaster (was in dem Zusammenhang nicht verschwiegen werden soll). Oder aber man lässt portcheck dran was alles möglich erkennt (und so auch von portaudit abhängig ist).
 
Zuletzt bearbeitet:
Oder aber man lässt portcheck dran was alles möglich erkennt (und so auch von portaudit abhängig ist).
Ahhja, gerade sehe ich, dass "portcheck" portsnap und portaudit verint, jedoch muss man von selbst portupgrade involvieren ?!

Code:
[...]
/usr/ports/x11/gnome2/
/usr/ports/x11/libgnomekbd/
Building new INDEX files... done.
Done fetching and updating the ports.

Portcheck step [2/3] - Normal checkup.

Doing a normal checkup of all installed packages..
This may take a while!

Portcheck step [3/3] - Security checkup.

Doing a security checkup of all installed packages..
auditfile.tbz                                 100% of   61 kB   48 kBps

Portcheck result..

apache-2.2.15_9                     <   needs updating (port has 2.2.16)
p5-Compress-Raw-Bzip2-2.027         <   needs updating (port has 2.030)
p5-Compress-Raw-Zlib-2.027          <   needs updating (port has 2.030)

The following packages has security issues!

New database installed.
Database created: Mon Jul 26 22:25:01 CEST 2010
Affected package: apache-2.2.15_9
Type of problem: apache -- Remote DoS bug in mod_cache and mod_dav.
Reference: <http://portaudit.FreeBSD.org/28a7310f-9855-11df-8d36-001aa0166822.html>

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.

A copy of the above result is kept in /var/log/portcheck.log
Portcheck.. done.

server [/usr/ports]#

Wie würde ich das mit dem "Upgrading" jetzt am besten machen? Von hand in das alte und ein make deinstall und anschließend in den neuen Port und von dort aus ein make install, oder gibt es da trickreichere Lösungen?

Vielen Dank & Viele Grüße
 
gerade eben ist mein portupgrade -a fertig geworden. Nun habe ich folgende Begebenheit:

Code:
server [/usr/ports]# portversion -l\<
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 232 packages found (-0 +1) . done]
server [/usr/ports]# portaudit -Fda
auditfile.tbz                                 100% of   61 kB   47 kBps
New database installed.
Database created: Mon Jul 26 21:05:02 CEST 2010
Affected package: apache-2.2.15_9
Type of problem: apache -- Remote DoS bug in mod_cache and mod_dav.
Reference: <http://portaudit.FreeBSD.org/28a7310f-9855-11df-8d36-001aa0166822.html>

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.
server [/usr/ports]#

Wie man sehen kann wurde die Apache-Lücke nicht gestopft. Ein portupgrade bewirkt also ncihts bezüglich der portaudit -a Meldungen?!

Grüße
Stimmt, portupgrade bewirkt garnichts, es aktualisiert den Portstree nicht selbst, wie ich oben falsch geschrieben habe. :huth:

Ich habe (die meiste Zeit) portcheck benutzt, um eben herauszufinden was aktualisiert werden muss und das verwendet halt portsnap. Hätte ich nur portupgrade verwendet, dann wären die Pakete noch auf dem Stand von 2006. :huth:
 
Die Ports mit Sicherheitsluecken, die per portaudit gefunden werden, werden meist in Kuerze aktualisiert. Niemand wird daran gehindert, selbst die Luecke zu fixen, wenn er kann. ;-)
Portaudit sagt Dir bloss, dass da ne Luecke ist bekanntermassen.
Meines Wissens nach sollte man "portsnap fetch extract" trotzdem einmal ausfuehren, wenn man die Ports per sysinstall installiert hat. Man moege mich hierbei korrigieren. Danach reicht ein "portsnap fetch update" um den Portstree auf einen aktuellen Stand zu bringen. Afaik wird der dafuer zum Download angebotene Tree alle 2h aktualisiert. Cvsup ist hier etwas zeitnaher, man kann dies allerdings verschmerzen und daher immer portsnap benutzen. Man aktualisiert seine Ports ja auch nicht alle Nase lang.
Da letztendlich viele Wege nach Rom fuehren, kann man seine Ports auch wie folgt aktualisieren:
portsnap fetch update && portversion -c >> ~/update.sh && sh ~/update.sh
Dabei wird wie ersichtlich ein Script erzeugt, welches man noch bearbeiten kann. Also beispielsweise einige Ports auskommentieren, die nicht aktualisiert werden sollen oder die Optionen von portupgrade manipulieren (z.B. -fk).
Die /etc/make.conf hilft nicht immer und ein make BATCH=YES will man auch seltenst. Die Ports, die bestimmte Optionen per ncurses Dialog abfragen, speichern diese dann in /var/db/ports ab und dort wird dann beim naechsten Update auch nachgeschaut, ob schon ein Eintrag vorhanden ist. Wenn es etwas spezieller sein soll, ist die /etc/pkgtools.conf eine gute Anlaufstelle.

Dies alles nur mal schnell ausm Kopp geschrieben, da ich grad kein FBSD zur Hand hab, kleine Fehler bitte ich daher zu verzeihen.
 
Dann habe ich noch:
Code:
portaudit -Fda # einmalig DB erstellen und checken
portaudit -a # ansonsten nur noch
um zu erfahren, was es an Sicherheitslücken zu beheben gibt.
Also mit den Switches im ersten Fall wird auditfile.tbz jedes Mal neu geholt, der Zeitstempel der Datei wird ausgegeben und anschließend wird ein Report der Lücken bzgl. installierter Ports auf dem System ausgegeben. Genau so macht es portcheck auch.

Im zweiten Fall wird lediglich auf Basis der bereits vorher untergeladenen auditfile.tbz wieder ein Report erzeugt, der sich nur dann ändert, wenn bereits ein oder mehrere unsicherer Ports von dir aktualisiert wurden. Wenn die File nun nicht jedes Mal heruntergeladen werden soll, sondern z.B. nur alle drei Tage dann, dann sind die Switches richtig:

%portsnap -da -X3

wobei

%portsnap -da -X0

ein Synonym für das erste Beispiel ist.
Diese Ausgabe dient auch lediglich meiner Inormation, oder muss ich den Befehl ebenfalls ausführen, dass portupgrade auch bescheid weiß, was es zu upgraden hat?!
Richtig, der Befehl dient nur zu deiner Information und der Befehl teilt z.B. portupgrade nichts mit.

Wie ich jetzt genau weiß, so beziehen portupgrade als auch portversion ihre Information aus ihrer eigenen portsdb, die letztendlich mit Informationen aus dem Portstree versorgt wird. Damit Informationen brauchbar sind, muss z.B. mit portsnap der Portstree aktualisiert werden. Wird dann portupgrade bzw. portversion aufgerufen, dann erkennen diese die Änderung im Portstree, gleichen die Änderungen mit ihrer Datenbank ab und nehmen dann die Auswertung vor.

... Und zu guter letzt habe ich ein:
Code:
portupgrade -a
... das läuft auch jetzt noch. Wenn ich das jetzt richtig verstanden habe, dass tauscht der mir jetzt alles aus was vorhin mit "portversion -l\<" aufgelistet wurde PLUS das Apache Problem das er mir via "portaudit -a" gefunden hat - oder muss ichdas extra aktualisieren / patchen?


Vielen Dank
"portupgrade -a" versucht alles zu aktualisieren was "portversion -l\<" ausgibt. Apache hingegen wird erst dann auf eine neue Version aktualisiert, wenn diese im Portstree z.B. mit Patch vorliegt. Somit hat portaudit nichts mit portupgrade zu tun und hängt auch nicht davon ab.
 
Wie würde ich das mit dem "Upgrading" jetzt am besten machen? Von hand in das alte und ein make deinstall und anschließend in den neuen Port und von dort aus ein make install, oder gibt es da trickreichere Lösungen?

Vielen Dank & Viele Grüße
Nein, "make"s werden nicht mehr von dir angestoßen sondern portupgrade macht das und mehr; Abhängigkeiten feststellen, Backup des alten Paketes, installieren des neuen Paketes, wenn das scheitert wird das Backup zurückgespielt...

Und wie moonlock treffend gesagt hat, alle Ports werden sich nicht immer automatisch aktualisieren lassen. Aber auch da gibt es irgend einen Schalter, erst mal die Ports zu aktualisieren, die nicht vorher händisch konfiguriert werden müssen.
 
... nun weiß ich jedoch leider noch immer nicht wie ich denn verfahren soll, wenn ich nur möchte, dass Dovecot und dessen Abhängigkeiten auf den neusten Stand gebracht werden sollen? Gibt es hierbei irgendwelche Tricks anzuwenden? Was macht ihr denn, wenn ihr feststellt, dass ihr ein Programm definitiv mit einer neueren Version braucht als es derzeit zum aktuellen RELEASE in den Ports vorhanden ist?


Grüße
 
Ich aktualisiere die Ports wie oben beschrieben und aktualisiere nur diesen Port wie oben beschrieben.
 
Zurück
Oben