Re: ipfw forward, 7.1 und options IPFIREWALL_FORWARD

From: Alvar Freude <alvar(at)a-blast.org>
Date: Sun, 15 Mar 2009 11:19:21 +0100

Hi,

-- Oliver Fromme <olli(at)lurza.secnetix.de> wrote:

> Es ist tatsächlich so, es geht nicht anders. Es ist eine
> reine Compile-Option, kein eigenes Modul (wie IPFW_NAT).

schade ...

> Hmm, da bin ich jetzt nicht sicher, da ich freebsd-update
> selbst nicht benutze. Aber ich nahm bisher an, dass man
> durchaus auch einen eigenen Kernel compilieren kann. Man
> darf nur nicht von der Version abweichen, d.h. in Deinem
> Fall muss es ein 7.1-RELEASE-Kernel bleiben. Sobald Du
> den Kernel auf 7-stable updatest, geht freebsd-update
> nicht mehr.

Wenn ich die Doku jetzt nicht falsch verstanden habe, dann geht das nicht
bzw. zumindest dürfte dann nach dem Update das ipfw-Forwarding nicht
mehr gehen.

<http://www.freebsd.org/cgi/man.cgi?query=freebsd-update&apropos=0&sektion=8&manpath=FreeBSD+7.1-RELEASE&format=html>

Und wenn ich das zudem richtig verstanden habe, dann werden aber
Sicherheitspatches auch beachtet ...

> > Bisher mache ich Updates zwar manuell (und deswegen selten), aber
> ich > hätte mit freebsd-update die Hoffnung, dass es einfacher und
> weniger > fehleranfällig geht ...
>
> Ich kann mir jetzt gerade nicht vorstellen, warum freebsd-
> update einfacher und weniger fehleranfällig sein sollte als
> der etablierte »make world«-Mechanismus, zumal die Daten,
> die freebsd-update herunterlädt, ja exakt durch den »make
> world«-Mechanismus erzeugt wurden.

klar, aber zum einen sitzt da noch ein Typ vor der Tastatur, der mal was
falsch machen kann, und zum anderen scheint freebsd-update ja einen
Rollback-Mechanismus zu haben. Außerdem haben das gleiche dann schon mal
andere Leute getestet.

i.d.R. ging es bei mir auch immer gut, bei einem Remote-Server ist das
aber halt immer so eine Sache. Und beim Update auf 6.4 (von einem alten
6.0) wollte das Ding mir meine Netzwerkkarte nicht mehr einbinden. Ohne
Netzwerk-Interface ist das ein wenig schwierig mit einem Server ;-)

> Das ist ziemlich genau
> mit dem Unterschied vergleichbar, der zwischen Pakete be-
> steht, die man aus der Ports-Collection compiliert hat und
> solchen, die man als Binärpakete heruntergeladen hat.

... mit dem Unterschied, dass es mich bei den Ports nicht stört, wenn
mal was nicht geht, das kann ich problemlos neu compilieren!

Und zumindest laut Doku scheint das Ding die Sachen in /etc besser zu
handhaben als mergemaster; der nervt ja manchmal schon etwas, wenn eine
Datei von mir in keiner Weise geändert wurde, dann braucht der mich ja
eigentlich nicht fragen, ob ich die überschreiben will ...

> Und natürlich gibt es einen psychologischen Unterschied.
> Gerade Anfänger sind von anderen Betriebsystemen Binär-
> Update gewöhnt und haben Hemmungen, ihr OS selbst zu compi-
> lieren.

damit habe ich keine Probleme, bin das so seit Jahren gewöhnt. Aber wie
gesagt, wenn dann der Server herumzickt ist das unschön.

Und außerdem soll man ja den mergemaster und das make installworld im
Single-User-Mode laufen lassen, das geht auf meinem Server nur wenn mal
die Lara dranhängt ...

> Aber wie gesagt: Für einen regulären Versionssprung (z.B.
> von 7.1-Release auf 7.1-pX oder 7.2-Release) -- und nur das
> kann man mit freebsd-update machen -- sehe ich keinen sig-
> nifikanten Unterschied bzgl. Einfachheit oder Fehleranfäl-
> ligkeit.

apropos:
Spricht was dagegen, von 6.0 direkt auf 7.1 via Sourcen upzudaten? Beim
Umweg über 6.4 ist halt leider das Netzwerk weg, ein 7.1 von CD scheint
damit aber klar zu kommen ...

Ciao
  Alvar

-- 
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.assoziations-blaster.de/
** http://www.wen-waehlen.de/
** http://www.perl-blog.de/

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 15 Mar 2009 - 11:19:40 CET

search this site