Re: OT: Sicherer Webserver - Bitte wie?

Bernd <bernd(at)mynet.at> wrote:
> Ich bin noch immer am üben, aber hätte doch noch ein paar kleine Fragen
> betreffend der Jail-Lösung.
>
> Ich teste im Moment mit 30 Jails, aber:
> - Wieviel aliase könnte ich eigentlich einer Netzwerkkarte geben?

Die Anzahl ist nicht begrenzt (außer durch den verfügbaren
Kernel-memory).

> Wenn ich in einem Jail einen NFS Mount benötigen würde, dann hab ich ein
> Problem (laut Google),

Nö, hast Du nicht.

> aber ich kann es doch am Hostsystem direkt in das
> Jail mounten oder?

Eben. Genau so macht man das.

> - Ist das so richtig (es funzt zumindest im Test) oder soll ich besser
> einen link machen (hab ich nicht probiert)?

Hat beides Vor- und Nachteile:

 - NFS-Mounts lassen sich leichter pflegen und verwalten
   (insbesondere auch leichter und gefahrloser aktualisie-
   ren), und nötigenfalls rasch austauschen. Du kannst
   z.B. auch mehrere verschiedene Versionen des Basissys-
   tems (Userland) bereithalten und je nach Bedarf die eine
   oder andere in die verschiedenen Jails hineinmounten,
   d.h. Du bist damit sehr flexibel. Außerdem sind bei
   dieser Lösung die einzelnen Jails stärker voneinander
   isoliert.

 - Die Lösung mit den Hardlinks dagegen hat den Vorteil,
   daß sie Speicher spart, weil z.B. Binaries und Libraries
   nur einmal in den Speicher gemappt werden müssen (das
   System »weiß« ja, daß die verschiedenen Hardlinks auf
   dieselben Daten zeigen, hingegen ist das bei verschie-
   denen Mounts nicht der Fall). Diese Lösung skaliert
   also besser, wenn man sehr viele Jails braucht (z.B.
   eine dreistellige Anzahl), soweit es die Speicehrnut-
   zung betrifft. Man kann natürlich im Bedarfsfall auch
   einfach RAM nachlegen; kostet ja nix mehr heutzutage ...

(Man könnte auch argumentieren, daß die NFS-Lösung weniger
performant ist, weil sie mehr Overhead mit sich bringt.
Davon merkt man aber in der Praxis normalerweise nichts,
da das System bei Loopback-NFS schon »Abkürzungen« zur Op-
timierung nimmt.)

Von der Variante mit NULLFS oder UNIONFS würde ich abraten,
da sie dieselben Nachteile hat wie die NFS-Lösung, und zu-
sätzlich gibt es gewisse Stabilitätsprobleme, die bei be-
stimmten Konstellationen auftreten können. Man kann aller-
dings die NFS-Lösung mit der mount-Option "-o union" kombi-
nieren (das hat nichts mit UNIONFS zu tun!), um z.B. die
Read-only-Mounts mit lokal veränderbaren Verzeichnissen
(die read+write gemountet sind) zu mischen.

> - Wieviel NFS Mounts sind überhaupt von einem NFS Client aus möglich
> (das hätt mich schon vor einiger Zeit mal interessiert)

Die Anzahl ist nicht begrenzt (theoretisch; ich habe das im
Source nachgeschaut). In der Praxis hatte ich schon Rech-
ner mit weit über 100 Mounts in den Fingern.

> - Kann ich die Jails einfach mit cp -pr kopieren, oder muss ich was
> "spezielleres" nehmen (cpdup oä)?

Die Option -r bei cp gehört verboten. Das ist eines der
»Features«, das dazu neigt, Probleme zu verursachen, wenn
man es am wenigsten erwartet. Darüberhinaus ist diese Op-
tion vollkommen überflüssig und verstößt gegen die UNIX-
Philosophie.

In diesem Fall würde ich tatsächlich cpdup empfehlen:

cd $QUELLE $ZIEL

Eine andere (portablere, d.h. auch auf anderen UNIX-Syste-
men verwendbare) Möglichkeit ist find|cpio:

cd $QUELLE; find . | cpio -dump $ZIEL

Falls Du die Dateien nicht kopieren, sondern einen soge-
nannten »Shadow-tree« aus Hardlinks anlegen willst (für
die o.g. Hardlink-Lösung), brauchst Du zu den cpio-Optionen
nur noch ein -l hinzuzufügen (cpio -dumpl). Details fin-
dest Du in den jeweiligen manpages.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"anyone new to programming should be kept as far from C++ as
possible;  actually showing the stuff should be considered a
criminal offence" -- Jacek Generowicz
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message