Re: ipfw forward, 7.1 und options IPFIREWALL_FORWARD

Alvar Freude wrote:
> Oliver Fromme wrote:
> > Das »make world« von Release zu Release wird selbstver-
> > ständlich auch getestet. Sonst würde es die Binär-Updates
> > ja gar nicht geben, weil die genau auf diese Weise ent-
> > stehen.
>
> klar -- ich meinte das anders: es ist mit exakt den Konfigurationen, mit
> denen es erstellt wurde, getestet.

Das ist eigentlich kein Argument: Getestet wird es natür-
lich mit den Default-Konfigurationen, also GENERIC-Kernel,
leerer make.conf-Datei und so weiter. Und wenn Du es mit
den gleichen Voraussetzungen selbst compilierst, dann ist
garantiert, dass am Ende genau das gleiche herauskommt.
Nur der Weg dorthin ist ein anderer, aber es ist genauso
einfach und genauso (wenig) fehleranfällig.

Sobald Du an der Kernel-config, make.conf oder sonstwo
herumfummelst, bringst Du natürlich potentielle Fehler-
quellen ins Spiel. Das darf man dann aber nicht mit
freebsd-update vergleichen, wo man die Möglichkeit gar
nicht hat, von den Defaults abzuweichen.

Das ist für mich übrigens einer der beiden Hauptgründe,
warum ich freebsd-update nicht verwende, nämlich dass man
von den Defaults nicht abweichen kann. Ich habe z.B.
gerne spezielle Sachen in /etc/make.conf.

(Der andere Hauptgrund ist, dass ich in der Regel keine
Releases verwende, sondern -stable. Dies wird von freebsd-
update nicht unterstützt.)

Wenn man mit den Voraussetzungen, die freebsd-update erfor-
dert, leben kann, dann kann man es natürlich benutzen.
Aber einfacher oder weniger fehleranfällig als ein »make
world« _unter_ _den_ _gleichen_ _Voraussetzungen_ ist es
nicht.

> > Das kann bei freebsd-update ebenso passieren. Du erhältst
> > ja am Ende denselben Code mit demselben Verhalten (und
> > denselben Bugs).
>
> das ist wohl wahr; aber ich hätte da noch die Hoffnung, dass es
> vielleicht weniger hat ;)

Wie gesagt: Wenn Du GENERIC nimmst, make.conf und Dein
Environment löschst, und Du die Release-Sourcen korrekt
ausgecheckt hast, dann erhältst Du präzise denselben Code.
Bit für Bit, und Bug für Bug.

> Ich habe zum Beispiel bei meinen Kernels meist das deaktiviert, was ich
> eh nicht brauche; aber das macht letztendlich nur Arbeit

Sehe ich auch so. Früher, als der RAM noch im ein- bis
zweistelligen Bereich gemessen wurde, war das noch anders.
Aber heutzutage bringt es auf einem typischen Rechner
nichts, aus der Kernel-Config Sachen rauszulöschen.
(Im Embedded-Bereich und für sonstige Spezialanwendungen
mag das natürlich anders aussehen.)

Und Treiber, die nicht in GENERIC sind, kann man i.allg.
als Module laden. Also muss man auch dafür nicht an der
Kernel-config drehen.

In der Praxis gibt es meistens nur zwei (gute) Gründe, um
einen eigenen Kernel zu compilieren: Erstens, um die
Compilierung zu optimieren (CPUTYPE=xxx in make.conf),
und zweitens, um bestimmte Optionen zu ändern, die (leider)
nicht per sysctl, loader-Tunable oder sonstwie geändert
werden können. Typisches Beispiel ist IPFIREWALL_FORWARD.

> > Das kann man per /etc/mergemaster.rc weitgehend konfigu-
> > rieren.
>
> hmmm, ich habe da mal ein wenig herumgespielt, mal schauen was es bringt.
>
> Im Idealfall sollte das einfach alle neuen Dateien, die vom User nicht
> geändert wurden, installieren. Ich ändere nichts an
> /etc/rc.d/defaults/* -- und dann soll das natürlich auch nicht bei jedem
> Mist fragen.

Das lässt sich durchaus konfigurieren. Es ist nur nicht
der Default (aus POLA-Gründen).

Ich persönlich möchte auch durchaus sehen, wenn sich an den
Dateien etwas ändert. Zum einen aus Neugierde, zum ande-
ren, damit ich evtl. neue, nützliche Features mitbekomme
bzw. frühzeitig davon erfahre, wenn bestehende Features
»obsoleted« werden und ich evtl. meine rc.conf anpassen
muss. Da ich nicht allzu oft update (ca. alle paar Monate
mal, oder bei akutem Bedarf), nehme ich mir dann die paar
Minuten Zeit, mir die nennenswerten Änderungen anzusehen.

Das ist natürlich persönliche Ansichtssache.

> > > 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 ...
> >
> > Das ist richtig, wobei man innerhalb eines Stable-Zweiges
> > (7.x --> 7.y) normalerweise darauf verzichten kann.
>
> mache ich auch oft so, aber das Handbuch verlangt das explizit anders ;)

Ja, damit sich die Benutzer nicht in den Fuß schießen und
dann die Mailinglisten mit Beschwerden füllen, die bei
anderer Vorgehensweise vermeidbar gewesen wären. :-)

Wir zwei sind ja recht erfahren und können uns im Notfall
selbst wieder am Schopf aus dem Sumpf ziehen. Aber das
gilt nicht unbeding für jeden.

> Falls es schief geht stört mich eher die Änderung bei den
> gmirror-Metadaten ...

Ja, das ist in der Tat ein problem. Ich glaube, PJD wollte
das mal irgendwie ändern, aber ich bin da nicht ganz auf
dem Laufenden.

bei ZFS ist es besser gelöst: Da muss man die Metadaten
explizit updaten (»zpool upgrade«).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"I made up the term 'object-oriented', and I can tell you
I didn't have C++ in mind."
        -- Alan Kay, OOPSLA '97
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message