Naja, für das Erscheinen der 2.4 vielleicht schon zufällig, aber die eigentliche 2.2 war ja schon lange heraus. Ich konnte nur nicht auf die endgültige umsteigen, da die 2.2 nicht mit dem Raid-Controller arbeiten wollte und ich schon bei der 2.2RC3 auf dem Server einen Fremdkernel nutzte. Never touch a running system.
Mein Verdacht war nur, dass für die RC-Versionen ein Zeitendpunkt existiert(e).
Ich setzte seit fast zwei Jahren die 2.2 RC3 auf einem Server ein. Am 2. November genau 15:01 Uhr ging dann gar nichts mehr - kein rein und raus im Datenverkehr - einfach nichts! Auch ein ping auf die Firewall war nicht möglich.
Ein Hardreset bootete die Firewall und für 5 Minuten war Verkehr da, und dann: wieder nichts! An der lokalen Konsole konnte ich aber arbeiten - zumindest nur auf dem Server um die Logs anzuschauen.
- die Netzwerkkarten waren "online" - es wurde aber nichts durchgelassen.
Die Logs in der /var/log/firewall hörten auch direkt nach 15:01 Uhr auf. Kein traffic, nichts! In der /var/log/messages keine Fehler auf Speicher oder anderer Hardware, Bootvorgang normal!
Ok, Kann ja sein dass der Server irgendwie eine Macke bekommen hat. Auf einem Desktoprechner 2.2RC3 neu aufgespielt, Backup rein - und an andere Switche gehangen - funktioniert.... ..... für 10 Stunden. Danach derselbe Mist. Neu gestartet, schnell Browser auf einem Client geöffnet um die Konfiguration auszudrucken - für eine Seite reichte es, dann spielte die Firewall auf dem Desktoprechner auch Zombie (neu starten, weiter drucken).
Dann habe ich auf dem Desktoprechner die 2.4 drauf installiert und handisch die Konfiguration eingespielt - und es läuft - seit nun 47 Stunden!
Da zwei völlig unterschiedliche unabhängige Hardwaresysteme eingesetzt wurden, und auf demselben Desktoprechner die 2.4 läuft, sind Hardwaredefekte ausgeschlossen. Es wurden auch keine Softwareupdates ausgeführt.
Jetzt stellt sich mir die Frage, warum genau ab diesem Zeitpunkt 02.11.10 15 Uhr, kurz nach dem Erscheinen von Version 2.4.1, die 2.2RC3 ausfällt? Ich kann zwar verstehen, dass Community-Versionen-Nutzer die Tester sind, aber müssen diese die alten Testversionen irgendwann updaten?
Tja, leider gilt dieses Workarround nicht mehr für die 2.3-Version:
Bei mir war es so, dass zwar der Treiber für den Controller (3Ware 9650SE) im endian2.3-Kernel enthalten war, aber nach der Installation der Boot-Vorgang immer mit Kernel-Panic abbrach.
Mit dem Debian-Kernel konnte zwar gebootet werden, aber das Netzwerk funktionierte nicht über dem Browser (ping und ssh funktionierte). Ursache scheint eine engere Zusammenarbeit einiger neuerer (notwendiger?) endian-Pakete mit dem spezifischen Kernel zu sein :twisted: - Offenbar mag Endian es nicht, dass man in der Community in ihren OpenSource-Paketen hackt 
Lösung
Da endian sich eher an redhat-Paketen (centOS, Fedora) orientiert probierte ich es nun mit einem CentOS-Kernel. Obwohl dieser älter ist, konnten alle Module für die Hardware des Servers eingeladen werden.
Die Installation von endian erkannte die Platte, so dass ich nun anders an die Sache heranging:
Ablauf
1. Fremdkernel installieren:
Cent-OS 5.4 (32Bit) Installation, minimale Auswahl
2. Kernel sichern:
mount /media/sda1
rsync -av /media/sda1/lib/modules root@gastrechner:/tmp/endian/lib
rsync -av /media/sda1/boot root@gastrechner:/tmp/endian3. endian installieren:
Standard-Installation
4. Kernel kopieren:
ssh root@gastrechner mv /tmp/endian/boot/grub /tmp/endian/boot/grub.centosmount /media/sda1
rsync -av root@gastrechner:/tmp/endian/lib/modules /media/sda1/lib
rsync -av root@gastrechner:/tmp/endian/boot /media/sda1cd /media/sda1/lib/modules
mv 2.6.22.19-72.e18 2.6.22.19-72.e18.old
ln -s 2.6.18-164.el5 2.6.22.19-72.e18
cd /media/sda1/boot
ls -1 *2.6.22* | while read I; do mv $I $I.old; NEU=`ls -1 ${I:0:5}*-2.6.18*`; ln -s $NEU $I; doneBeim booten gibt es allerdings noch ein SWAP-Resume-Hänger, der aber nur den boot-Prozess um 1 Minute verlängert 
Das wars und die efw ist nun auch im Webinterface aufrufbar. Ich hoffe nur, dass Endian sich wieder etwas mehr der Community öffnet und nicht in der nächsten Version wieder neue Hürden einbaut , die einen nach Alternativen ausprobieren lassen.
In der 2.2rc3-Version gab es noch das devel-RPMS-Paket, welches Entwicklungswerkzeuge (Compiler, etc.) enthält.
Das ist bei der 2.3 nicht der Fall. Wird das nicht mehr supported? - Was nützen mir die angebotenen SRPMS, wenn kein Compiler mit angeboten wird? 
Grundlage ist, dass ich noch die 2.2rc3 einsetze. Es heißt ja bekanntermaßen: Never touch a running system.
Super, aber dennoch sind ja die Pakete wie z.B. ssl nicht unbedingt fehlerfrei bzw. bekommen neue Features und werden weiter entwickelt.
Mit einem Update auf eine aktuellere efw-Release kann man zwar alles komfortabel auf einmal updaten, aber ein Kollege hat da so einige schlechte Erfahrungen gemacht, die mich davor abhalten, ein Netzwerk für ein paar Tage lahmzulegen:
Es gibt also für mich genug Grund bei der lieben funktionierenden Version zu bleiben. Zumindest die Features die geboten werden - Firewall-Optionen, die meine grafischen Wünsche in die komplexe IPTABLES-Notation übersetzen (und ich bewundere jeden, der IPTABLES händisch versteht :ugeek:). Alle anderen Features sind mit etwas Wissen auch "von Hand" :geek: arbeitbar.
So habe ich auch das openvpn an der Konsole gemanaged inklusive Zertifikatszeug und eigener CA - funktioniert prima, und die Firewall steht und Portweiterleitungen lassen sich grafisch wunderbar weiter klicken.
Dennoch muss man auch mal das eine oder andere Paket (vielleicht sogar den Kernel) dann selbst aktualisieren, und das habe ich z.B. gerade mit openvpn getan: Vorher 2.1rc7, Jetzt 2.1rc22
Dieses HowTo soll als Beispiel dienen, wie man den Server um Software-Pakete erweitert oder Software-Pakete aktualisiert ohne die Release zu wechseln. Man verzichtet natürlich teilweise auf die erleichternde grafische Oberfläche mit neuen Konfigurationsfeatures. Aber vor einem Release-Wechsel warte ich lieber noch ein bischen 
Installiert habe ich das Ganze unter /opt/local
der Compiler-Prefix lautete dann: --prefix=/opt/local
rpm -iv gcc4-4.1.2-14.endian1.i586.rpm binutils-2.15.92.0.2-24.endian1.i586.rpm glibc-devel-2.3.4-2.39.endian6.i386.rpm libgomp-4.1.2-14.endian1.i586.rpm glibc-headers-2.3.4-2.39.endian6.i386.rpm glibc-kernheaders-2.4-9.1.100.EL.endian1.i386.rpm# Path manipulation
PATH="/opt/local/bin:/opt/local/sbin:/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin"export PATH=/opt/local/bin:$PATH
export CC=gcc4WGET (1.12) installieren
GCC (4.4.2) aktualisieren
wget http://www.mpfr.org/mpfr-current/mpfr-2.4.1.tar.gz
tar xvfz gcc-core-4.4.2.tar.gz
tar xvfz gcc-g++-4.4.2.tar.gz
tar xvfz gmp-4.3.1.tar.gz
mv mpfr-2.4.1 gcc-4.4.2/mpfr
mv gmp-4.3.1 gcc-4.4.2/gmpexport CC=gccNCURSES (5.7) installieren
OPENVPN (2.1rc22) aktualisieren
./config --prefix=/opt/local --openssldir=/opt/local/opensslexport OPENSSL_CONF=/etc/openvpn/openssl.cnf./configure --prefix=/opt/local --with-lzo-headers=/opt/local/include --with-lzo-lib=/opt/local/lib/etc/init.d/openvpn stop
export PATH=/opt/local/sbin:$PATH/etc/init.d/openvpn start:arrow: Als nächstes könnte man auch noch das Perl updaten, da in openssl/openvpn auch mit Perl-Scripten gearbeitet wird.
Edit:
Also so reicht es für openvpn offenbar noch nicht ganz aus - Dem Verbose zu urteilen muss wohl auch noch python updatet werden.
Edit:
Tja, also um python zu aktualisieren müsste man auch die glibc aktualisieren - 5 Simulationen und jedes Mal schlägt die Installation einer aktuelleren glibc, mit dem Resultat das ganze System zerschossen zu haben, fehl.
Also ich habe keine Bestätigungsmail erhalten. Das einzige was nach dem Klicken auf den Link in der Validierungsmail im Browser erschien (und erscheint) lautet:
{'status':'validated'}
Ich habe dann mal einfach nach den Punkten 3 und 4 verfahren aber er bringt dann nur noch:
Failed acquiring release file for 'efw-community':
error: http://***:community@http://updates.endian.org/stable/repodata/repomd.xml: The requested URL returned error: 401
Also an die Logs kommst du auch mit ssh (scp) ran. Das Problem bei großen Logs (der vergangener Tage) ist, dass sie auf der Firewall erst entpackt (in den Swap) und dann per Download zur Verfügung gestellt werden. Wenn der Swap auf der FW dabei voll wird, bekommst du auch nur eine unvollständige Datei.
Mit scp kannst du dir die Logs holen: Pfad auf den Server: /var/log/Firewall-DATUM.gz
Ich mache das bei mir regelmäßig mit einem cronjob, um ein peer2peer (es entstehen besonders viele Verbindungen zu verschiedenen IPs (>50000) von einer Basis-IP heraus) in meinem Netz zu überwachen/unterbinden. Im Falle eines aggressiven P2P-Clients kann die Log-Datei entpackt schon mal bis zu einem 1GB groß werden und dafür reicht die (voreingestellte) Swap-Größe der Endian-Installation nicht aus.
Also ich habe gestern das ganze mal angefangen, allerdings mit einer Debian-Installation. Der Fehler es war eine 64Bit und nach dem ganzen Mischen der Bibliotheken ging gar nichts.
Heute nochmal mit der 32Bit-Version probiert und nach meinen gestrigen howto-Notizen vorgegangen und ..... es funktioniert! 
Die Firewall ist natürlich identisch was Host und IP angeht (also beim Test nur im separiertem Netzwerk nutzen). Auf der Weboberfläche sieht alles gleich aus. und es scheint auch gleich zu funktionieren. Morgen wird der Server eingebaut und nächste Woche löst er dann die andere FW ab.
Einziges Manko, ich wollte den host eigentlich anders nennen
wenn du eine passende Lösung hast kannst du es ja wenn du möchtest als HowTo Dokumentieren
habe ich nun gemacht
--------
Edit:
Einziges Manko, ich wollte den host eigentlich anders nennen
/var/efw/main/hostname.conf
/var/efw/main/settings
/etc/hostsProblem:
Der Kernel der Installations-CD ist zu alt und erkennt die neuere Hardware (RAID-Controller, Chipsatz, etc.) des neuen Servers nicht. Installation endet in einer Endlosschleife der Hardwareerkennung...
In dem hier beschriebenen Fall handelt es sich um die 2.2 RC3 Version mit integriertem Kernel 2.6.22.19-72.Endian15.
Ziel-Hardware:
Mainboard: Supermicro SMCI-X7DCLi, Chipsatz Intel 5100, 2x LAN 1GBit Intel 82573V/L
Prozessor: Intel Xeon E5405
Arbeitsspeicher: 2 GB ECC
RAID-Controller: 3Ware Escalade 9650SE-2LP, PCI-e, RAID1 mit 2x160GB
Lösung:
Klappt das Booten mit einer Live-CD einer anderen Linux-Distribution, die einen neueren Kernel verwendet, und kann diese die Hardware auch erkennen und ansprechen, kann man eine bestehende EFW mit dem neuen Kernel nachrüsten.
Vorraussetzung: EFW muss bereits auf einem anderen Rechner installiert sein.
Ablauf:
1. Fremdkernel installieren, hier: Debian-basierter Kernel:
debian-Installation (hier: Debian 5.0, Kernel 2.6.26 i386/686), expert-installation
1: /boot, 100 MB
2: swap, 4 GB
3: /, 55,9 GB
4: /var, 100 GB2. Kernel sichern und Platte neu formatieren:
mount /media/sda1
mount /media/sda3
rsync -av /media/sda1/* /tmp/boot
rmdir /tmp/boot/lost+found/
rsync -av /media/sda3/lib/modules/* /tmp/modules/media/sda1 (Bootpartition), /media/sda3 (Systempartition)
umount /media/sda1
umount /media/sda3
mkfs.ext3 -m 1 /dev/sda1
mkfs.ext3 -m 0.3 /dev/sda3
mkfs.ext3 -m 0.2 /dev/sda4Parameter m = Prozentualer Anteil der reservierten Blöcke für Superuser
3. Endian Firewall kopieren:
rsync -avz -e ssh remoteuser@remotehost:/remote/dir /this/dir/remoteuser=root, remotehost=Servername der Quelle, /remote/dir=die jeweiligen Verzeichnisse, /this/dir=die Zielpartition
mount /media/sda1
mount /media/sda3
mount /media/sda4
rsync -av -e ssh root@remotehost:/boot/* /media/sda1
for I in bin etc home lib mnt opt root sbin tmp usr; do rsync -avz -e ssh root@remotehost:/$I /media/sda3; done
rsync -av -e ssh root@remotehost:/var/* /media/sda44. Links erstellen und neue Kernel-Dateien kopieren:
mkdir /media/sda3/boot /media/sda3/var /media/sda3/dev /media/sda3/proc /media/sda3/sys
cp /tmp/boot/*-2.6.26-2-686 /media/sda1cd /media/sda1
ls -1 *2.6.22* | while read I; do mv $I $I.old; NEU=`ls -1 ${I:0:5}*-2.6.26*`; ln -s $NEU $I; donecd /media/sda1
mv config-2.6.22.19-72.endian15 config-2.6.22.19-72.endian15.old
mv initrd-2.6.22.19-72.endian15.img initrd-2.6.22.19-72.endian15.img.old
mv System.map-2.6.22.19-72.endian15 System.map-2.6.22.19-72.endian15.old
mv vmlinuz-2.6.22.19-72.endian15 vmlinuz-2.6.22.19-72.endian15.old
ln -s config-2.6.26-2-686 config-2.6.22.19-72.endian15
ln -s initrd.img-2.6.26-2-686 initrd-2.6.22.19-72.endian15.img
ln -s System.map-2.6.26-2-686 System.map-2.6.22.19-72.endian15
ln -s vmlinuz-2.6.26-2-686 vmlinuz-2.6.22.19-72.endian15rsync -av /tmp/modules/* /media/sda3/lib/modules
cd /media/sda3/lib/modules
mv 2.6.22.19-72.endian15 2.6.22.19-72.endian15.old
ln -s 2.6.26-2-686 2.6.22.19-72.endian155. Grub installieren: (optional!)
Zunächst sollte man probieren, ob der bereits durch Debian installierte Grub noch funktioniert - einfach neu ohne CD booten
Falls man die Knoppix-CD zum installieren des grub-loaders verwenden möchte, so hat Knoppix einen Bug, den es vor dem "chrooten" zu berücksichtigen gilt (siehe: http://www.knoppix.net/wiki/Dev_null_permission_denied
Also bei mir musste ich in der Simulation in einer virtuellen Maschinenumgebung den Grub neu installieren. Bei der echten Installation brauchte ich es nicht.
Die gesamte Firewall wurde nun geklont und läuft auf dem Server mit dem Kernel 2.6.26-2-686.
Selbstbeantwortete Fragen: 
-----------------------------------------
Edit (30.04.2009):
Also bei mir läuft das Ganze jetzt seit 1 Woche auf einem Produktiv-System ohne Ausfälle und ohne andere Probleme. Einzige Ausnahme: Ich kann über das Webfrontend die Passwörter für den Zugriff nicht ändern.
-----------------------------------------
Edit (30.04.2009):
Ok, es liefen auch die anderen cgi-Scripte nicht vernünftig zum Ändern :cry: . Das Problem war, dass der User "nobody" in der alten Version die ID 65534 hatte und somit die FW keinen Schreibzugriff mehr darauf hatte.
Ein Ändern aller 65534:nobody - Dateien auf nobody:nobody brachte Abhilfe und nun kann auch das Webfrontend-PAsswort geändert werden
cd /
find . -user 65534 -exec chown nobody:nobody {} \;Leider ist es ja auch nicht gedacht nachträglich einen neueren Kernel hinein zu kompilieren.
Theoretisch könnte es ja klappen, wenn man den installierten Kernel von einer Distribution kopiert, die auf der Maschine läuft.
Ich habe das jetzt mal in einer virtuellen Umgebung getestet:
Opfer: IPfire (Kernel 2.6.27.21)
kopiert und Links erstellt habe ich:
/boot:
/lib/modules:
Der Start in der VM ging problemlos . Nächste Woche werde ich das mal auf dem Server probieren. Die Treiber für die unterschiedliche Hardware werden ja in den Modulen geladen. Notfalls könnte es auch komplementär erfolgen: ipfire-Grundinstallation und alles andere (/bin, /etc, ...) wird kopiert.
Natürlich kann man mir nun die Frage stellen, warum ich nicht gleich bei IPfire bleibe - der Grund ist einfach: Ich nutze schon länger Endian (davor IPcop) und IPfire ist als Firewall überladen und schlecht konfigurierbar (Bsp: Zusätzliche Adressen auf dem Adapter, SNAT)
Ich wollte die 2.2 RC3 auf einer neuen Maschine installieren, jedoch bleibt sie bei der Hardware-Erkennung im Blue-Screen (flackert höchstens etwas) hängen. In der Konsole (2) fängt er eine Endlos-Schleife mit der Hardwareerkennung an.
Nach diversen Test mit anderen Distributionen (Knoppix 5.1.1 (Kernel 2.6.19) , Knoppix 6.01 (Kernel 2.6.28), Ipfire 2.3 (Kernel 2.6.25)) fand ich heraus, dass neuere Kernel (mindestens 2.6.25) die Treiber für Mainboard und Controller integriert haben, da diese die Festplatten sowohl an der SATA-Schnittstelle, als auch am 3Ware-BIOS erkannten.
Die RC3 ist ja nun auch nicht mehr die jüngste :|. Ist demnächst ein launch einer RC4 oder der endgültigen Version vorgesehen, und mit welchem Kernel wird die laufen?
Chipsatz: Intel 5100
Prozessor: Xeon E5405
RAID-Controller: 3Ware 9650SE-2LP