[linux-l] Perl, Tomcat, IPSec, NFS, Linux, FreeBSD (war:Woody-nachbesserungs-Tool

[Peter Ross]

Hi,

ich habe es mal umbenannt, weil es ja mit Woody wenig zu tun hat. Sorry, 
wenn es sehr Off-Topic sein sollte.

Zum Originalthema vielleicht eines: Ich finde die Liste, die einem es
moeglich macht, einen Schritt in der Debian-Installation vor oder zwei
zurueck zu gehen, sehr schoen. Wenn es da etwas Nachbesserungswuerdiges 
gebe, sollte man das vielleicht als zusaetzlichen Punkt in die Liste 
einfuegen?

Wenn es "Gemaule" am Debian-Defaultkernel gibt, dann faellt mir nur ein,
dass die Markierung von soliden Kerneloptionen und "experimental" nicht
sehr gluecklich ist. Ein Distributor hat z.B. Defaults fuer Filesysteme,
die in der Kernelkonfig als "experimental" markiert sind. Das macht die
Auswahl von Dingen, denen man in der Produktion trauen kann, sehr schwer.

Aber mit diesem Problem muesste man wohl die Kernelbauern belaestigen..

On Sun, 29 Dec 2002, Steffen Dettmer wrote:

> > Dem entgegen steht ein maechtiges Tool, was man immer dabei haben muss und 
> > wenn der Rechner nur DNS-Server ist. 
> 
> Du meinst mit dem Tool Perl?

Ja. Wenn ich das immer dabei haben muss, ist eine Miniinstallation nicht 
mehr so mini.

> Na ja, tomcat, apache. 

Tomcat geht auch ohne Apache. Bei Anwendungen, die eh nur alles an Tomcat 
weiterreichen, kann man sich den Brocken durchaus sparen.

> Dann noch ca. eine Million classes in 1000
> jar's, oder? Oder gibt's da ein großes "ich-bins.jar", wo alles
> drin rumliegt? Na ja, however, nix gegen virtuelle Maschinen,
> aber wenn's da nicht mal ne Shell für gibt...

Fuer diese Fragen musst Du Dich an Java-Entwickler wenden. Ich nix wissen, 
kleine Java-Beispiele lesend verstehen und JDK installieren;-) Ich 
denke nur: Dieses eine Klasse - ein File ist nicht vi-kompatibel;-)

> >  Ich habe zwei vollstaendig verschiedene
> > Verbindungen zu unterschiedlichen Netzen in der Ferne und die
> > nehmen beide ipsec0. 
> 
> Ahh, Du hast also insgesammt vier SAs zu zwei Netzen. Oft hat man
> auch mehr als zwei SAs je Netzwerk (wenn man die GWs selbst auch
> gesichert ansprechen möchte).
> 
> > Das finde ich nicht gerade gluecklich (wenn ich z.B. dann auch
> > noch filtern will)
> 
> Wieso nicht glücklich? Hättest Du lieber 4 Devices? Die devices
> sind analog zu phyiskalischen Devices. Sehe hier keinen Nachteil.
> Hättest Du lieber vier devices?!

Ja, haette ich gern. Warum soll ich zwei vollstaendig verschiedene 
Verbindungen ueber das gleiche Interface jagen? Das ifconfig fuer ipsec0 
erzaehlt eigentlich nur Unsinn.

Daher auch, das ich fuers Gateway selbst eine andere Verbindung brauche 
(oder Pakete mit iptables umschaufele)

Mir erscheint der Weg, je Verbindung ein neues virtuelles Device 
aufzumachen, ordentlich zu konfigurieren und drueber routen, sinnvoller. 

IPSec und Verschluesselungen erlauben etc. mache ich natuerlich ueber das 
echte Device, das ist okay.
 
> Ich find, daß macht sich jedenfalls prima, auch das filtern.

Wenn ja Verbindung ein Interface da ist, dann geht "Verbindung1 darf 
alles" und "Verbindung2 darf nur auf Firmen-Webserver zugreifen" vile 
einfacher.
 
> Na ja, auch interoperabel? Vielleicht ist mein linux NFS Server
> zu buggy ;) Hilft mir dann aber auch nix :)

Es gibt kein flock(2) bei Linux ueber NFS. Und es gab ein Problem mit dem 
NFS-lockd bei freeBSD, der war mal als "broken" markiert, was aber, 
glaube ich, inzwischen wieder geht (das ist aber nur aus 2.Hand, ich 
betreibe gerade kein FreeBSD auf dem neuesten Stand).

NFS ist halt original ein Sun-Produkt,  das merkt man dann auch beim 
Filelocking. Sun laesst seit eh und je alles Locking, auch lokal, ueber 
den lockd laufen, was andere Systeme wie Linux und FreeBSD in die 
Filesysteme selbst integriert. So war Sun deutlich im Vorteil, 
Filelocking uebers Netz zu implementieren: lockd netzwerktauglich machen, 
Protokoll zur Verstendigung zwischen lockfordernden und lockenden lockd - 
transparent fuer den Clientprozess, den das gar nichts angeht, ob der 
lockd dass nicht lokal, sondern uebers Protokoll remote abfackelt. Andere 
Systeme muessen entweder lokal das Filesystem oder bei NFS den lockd 
fragen.

Den Punkt solltest Du zumindest mal durchdenken und wenn noetig testen, 
bevor Du da in die Falle rennst.

Gruss
Peter