Ja, könnte man testen. Aber auf der alten HW krieg' ich die dicken Ottos (80GB Seagate & 300 GB Maxtor) nicht mehr zum Laufen - daher wollte ich ja auch auf eine neue HW wechseln.

In der Zwischenzeit hab' ich probiert, ob ich Suse 9.2 von der Heft-CD PC-Professionell 2/05 zum Laufen krieg - nach dem Booten bzw. ab dem Umschalten auf Grafik bleibt der BS schwarz - Suse dürfte mit meiner Matrox ein Problem haben.

Ich glaub', es wär' für mich jetzt am sinnnvollsten, ich wart' auf die DVDs/CDs von CentOS - Ende nächster Woche sollte ich dann auch mit dem Film soweit fertig sein, dass ich mehr Zeit zum Testen hab'.

MfG, Quintus

Den Backport von Kernel 2.6.7 würde ich bei produktiven servern aber meiden, da ein sehr kritisches Sicherheitloch enthalten ist. Im entsprechenden Incoming Verzeichnis gibt es zwar schon seit Wochen ein 2.6.8 Paket, welches aber bisher noch nicht zu Backports.org hinzugefügt wurde.

@ Philipp: nein, vom Produktionsrechner lass' ich eh vorläufig die Finger.

----------

Es ist eigentlich mal die Frage zu klären, ob es überhaupt vernünftig ist, dass jener Rechner, der Firewall spielt, überhaupt Datenserver sein soll.

Wenn nein, wäre es eigentlich wenig Aufwand,

• den Debian-Server "abzuspecken", ihn nur mehr als Firewall, Printerserver & Zeitsynchronisation
• und für die Samba-Dienste (oder ggf. Windows-Netzwerk-Freigaben) einen eigenen Rechner zu nutzen.

Da das System im Debian-Server auf einer SCSI-Ultra-HDD liegt und ich noch einen Adaptec 2940U in der Lade liegen hätte....könnt' ich diese eine HDD (ohne Uminstalliererei ;)) im Debian-(=Firewall-)Server weiter laufen lassen und die anderen (LVD-)SCSI-HDDs im Fileserver einsetzen - nur unter welchem BS ist halt noch die Frage...

... nur laufen halt dann 2 Rechner 24/365...:(.

Btwy - ich hab' jetzt auf einem 3GHz-Intel-Rechner (aktueller FC3-Kernel) testweise ein smb-upload gemacht - dasselbe in lila (Gott sei Dank - sonst hätt' ich an der A64-HW gezweifelt ;)).

MfG
Quintus

Weil ich jetzt neugierig war: so sieht übrigens ein smb-upload auf den alten Debian-Server aus.

Neben der Top-Speed und gutem Ansprechverhalten bei down- & upload wäre die Disziplin "DV Capturn aufs Netzlaufwerk" von Wichtigkeit.

Während WinXP bei up- und download hervorragende Datenraten zustande bringt, "patzt" es beim Capturen aufs Netzlaufwerk: leider kommt hin und wieder der Abbruch:

http://scifi.pages.at/karl1607/linux...dtslow_win.gif

Anscheinend tut XP hin und wieder irgend etwas zwischendurch, was mal den Datenfluss stoppt :(. Unter FC3 scheint es diesbezüglich besser zu laufen - aber auch hier hatte ich schon einen Abbruch zu verzeichnen :(.

Ich fürchte, weder bei WinXP als Fileserver noch mit FC3/smb ist eine derartige Betriebssicherheit zu erreichen, dass übers Netz beispielsweise ein 3-Stunden-Film (ohne Abbruch) gecapturt werden kann.

Ich fürchte, diese Dinge muss ich weiterhin lokal auf einer Workstation machen.

Natürlich teste ich in dieser Richtung weiter - momentan läuft ein Capturn unter FC3 (aktueller Standard-Kernel) bereits 50 Minuten problemlos...

Die sogenannte "Betriebssicherheit" wär' mich noch wichtiger als die Top-Speed - Mängel in der Tops-Speed könnte ich kompensieren, indem ich beispielsweise das Timeline-Abspielen so starte, dass VORHER der Buffer gefüllt wird, bevor die Wiedergabe startet. Gegen Capture-Abbruche gibt's keinen Workaround - abgebrochenes Capturn vom TV = Film ist kaputt.

MfG, Quintus

Ich hab' diesbezüglich weiter getestet:

• der WinXP-Fileservice hat sich da disqualifiziert, weil nach 10-20 Minuten durch irgendwelche Hintergrund-Aktivitäten ein Abbruch kam.
• Dem FC3-/smb-Server kann ich bescheinigen, dass er diese Disziplin anscheinend deutlich besser beherrscht - ich hab' jetzt 4½ Stunden am Stück gecapturt - kein Abbruch!

Es sieht also so aus, als wenn mein nächster Server wieder Linux wird - diese extreme Pulsiererei bei smb muss ich aber noch irgendwie weg kriegen! Ich hoffe, das erledigt sich weitgehend von selbst, wenn ich die für den A64 richtige Version installiere.(?)

Ich bin somit schon neugierig auf die Tests mit CentOS3.3 bzw. 4.0beta.

Die Frage stellt sich noch, ob ich in Zukunft 2 Rechner 7/24 - also Firewall & smb auf verschiedenen Maschinen - laufen lassen soll, oder alles wieder auf einer.

MfG, Quintus

Von der Stromkostenproblematik abgesehen eine sehr gute Idee: Wenn dein Fileserver keinen direkten Zugang ins I-Net hat, ist er wesentlich sicherer.

Auf einem Firewall Rechner sollten möglichst keine (Server-)Dienste rennen.

Ich fasse mal meine Tests bis jetzt zusammen:

• unter Linux hab' ich - wie bekannt - z.Z. noch eine langsame bzw. sehr "pulsierende" Netzwerk-Performance (Samba), aber große Stabilität - das Video-Capturn funzt.
• Unter XP hätte ich top Netzwerkperformance, um die 95% - allerdings macht XP alle paar Minuten irgend eine Hintergrundaktivität und daher Pause = Capture-Abbruch!
• W2K bringt eine kontinuierliche Netzwerkverbindung zustande (ich hab's aber nur 15 MInuten getestet) - allerdings liegt die Auslastung nur bei nur 60-70% (bei beiden NICs). Auch mager...

Nachgelesen hab' ich noch wegen dem Abschalten der IDE-HDD(s) - scheint auch nicht so einfach zu sein. Hier steht:

Zitat:

Bei IDE-Platten geht das mit hdparm -S, für SCSI-Platten ist ein Kernelpatch (SCSI-Idle) notwendig. In der Praxis ist ein solcher Spindown aber nur selten sinnvoll. Unter Linux, wie unter jedem Unix, erfolgt normalerweise spätestens alle paar Minuten irgendein Plattenzugriff, es sei denn, es handelt sich z.B. um eine reine Datenplatte, die nicht gemountet ist. Dadurch wird eine Platte, falls der Timeout so kurz ist, dass sie zwischen den Zugriffen den Motor abschalten kann, dauernd herunter- und und wieder heraufgefahren, was die Lebensdauer der Platte rapide verkürzen kann, insbesondere, wenn es sich um eine Desktopplatte handelt, die im Gegensatz zu einer Notebookplatte nicht für solche Stromsparmaßnahmen ausgelegt ist. Abhilfe schaffen kann hier der noflushd/ <http://sourceforge.net/projects/noflushd/>, der die Zugriffe bei Inaktivität unterbindet. Unbedingt die Warnhinweise im README beachten!

In der Readme von Spindown steht:

Zitat:

Be aware that noflushd might have problems with a mixed IDE/SCSI setup or large numbers of disks. noflushd will inform you of any conflict.

Hat das schon jemand probiert? Hab' ich Chancen, die IDE-HDD still zulegen?

Thx, Quintus

da ich nicht den ganzen thread nochmals nachlesen will: za wos soll das gut sein ?

Stromsparmassnahme wäre minimal, maximal bei einem Notebook im Akkubetrieb interessant, und an deinen Performanceproblemem ändert es sowieso nix.

:confused:

IDE soll halt - im Gegensatz zu SCSI - nicht für Dauerbetrieb ausgelegt sein. Und weil ich die dicke Maxtor nur zum Videocapturn einsetzen will und das nur alle paar Tag' mal tu', war die Idee, sie zwischendurch ab zu drehen.

Natürlich könnt' ich sie durchlaufen lassen und wenn sie nach 2 Jahr' hin ist, auf den Müll schmeißen - ist ja ned viel hin. Ich muss mir dann natürlich ein bißchen mehr Gedanken wegen Kühlung derselben machen.

MfG, Quintus

Ich wollt' jetzt bezüglich Performance-Problem Einsicht in die FC3-Kernel-Konfiguration nehmen, möglicherweise liegt da was schief oder wurde nicht hinein kompiliert.

2 Probleme dabei:

• Bei FC1 gab's bei 'Hinzufügen / Entfernen von Applikationen' den Punkt 'Kernel-Entwicklung' zum Anhaken ('installieren Sie diese Pakete, wenn sie selbst den Kernel übersetzen möchten'). Das gibt's bei FC3 anscheinend nicht...
• 'Die Kernelversionen befinden sich unter /usr/src/linux..... - dort ist aber gähnende Leere...

Wie kann ich mir die config anschauen (ob ev. der richtige Chipsatz rein kompiliert ist) bzw. wie komm' ich zu den Kernel-Entwicklungswerkzeugen und der Source?

Thx, Quintus

Danke, hab' eine Anleitung gefunden.

MfG, Quintus

Das Problem ist eingekreist! Es ist nicht FC3...

... es ist der Total-Commander, den ich zum Kopieren verwendete - siehe Vergleichsimages!

Damit ist es klar, dass der neue Server wieder Linux wird :) :tux: :) - vorerst nur mal Fileserver, sukzessive werd' ich dann den Printserver und die Firewall auch übernehmen, damit ich nicht 2 Kistln 24/365 laufen hab' - das macht schon irgendwie Platzprobleme (Bildschirm, Tastatur, Maus umstecken oder neue/gebrauchte Gerätschaft....)

Nachdem heute oder morgen noch Installations-CD/DVDs eintrudeln sollen, stellt sich nur die Frage, welche Version...

• CentOS 3.3 (64-Bit für A64)
• CentOS 4.0beta (64-Bit für A64)
• FC3 i386 (= jene, die grad drauf ist)
• FC3 i686 (wär noch zu beschaffen)

...ich verwenden soll (ich glaub', ich probier's mal mit der CentOS4.0beta).

MfG
Quintus

Ich würde CentOS 3.3 x86_64 nehmen, da es keine Beta ist und ausserdem die gleiche Samba Version verwendet (zumindest nach Update) wie CentOS 4.0 Beta

Auch hier gibt es ein Update ;)

Ich habe in der Zwischenzeit meinen eigenen Kernel 2.6.8-12 Backport erstellt, da ich ihn dringend für einen meiner Server gebraucht habe. Der 2.6er Kernel löst immerhin die MySQL Verbindungsprobleme die es normalerweise bei Hochlast gibt.

Ausserdem habe ich Kontakt mit Norbert Tretkowski aufgenommen. In den nächsten 24 Stunden erscheint voraussichtlich ein Kernel 2.6.8-13 Paket, welches auch wieder als Backport veröffentlicht wird.

hast du eine info warum diverse updates derzeit nur schleppend hochgeladen werden? auch das scponly update hat über 2 wochen gedauert :(

Nein, ich habe nur wegen dem Kernel 2.6 Paket nachgefragt. Ich schätze aber wegen Zeitmangel zum Testen, da nicht alle Backports von ihm stammen.

Zwei mögliche Alternativen:
1) Die Pakete gleich von http://www.backports.org/incoming installieren

2) Selber einen Backport erstellen. Viele Testing Pakete lassen sich ohne Probleme unter Woody rebuilden.

Um den Quelltext zu holen:
apt-get source <paketname>

Natürlich sollte dann schon eine Testing deb-src Quelle in /etc/apt/sources.list eingetragen sein ;).

Um das ganze dann zu kompilieren:
cd <paketname>
dpkg-buildpackage -us -uc -rfakeroot

Mit etwas Glück sollten jetzt die entsprechende deb Archive erzeugt worden sein. Falls es Probleme gibt, müssen eventuell andere Entwicklungspakete nachinstalliert werden. Machmal ist es auch notwendig die debian/control Datei anzupassen um Abhängigkeiten zu korregieren.

1.) Begeistert über die neue HW:

Ich hab' testweise ein Messgerät dazwischen gehängt

• der neue A64-Server verbrät nur ca. 68Watt (inkl. 3er IDE-HDDs).
• Zum Vergleich: mein Office-Rechner (3GHz Intel, auch 3 IDE-HDDs, anspruchslose GraKa Matrox G550) braucht im Leerlauf etwas über 100, beim Encoden 172...:).

2.) CentOS-CDs/DVDs heute gekommen:

leider ist beides nur beta:

1. CentOS 3.4Beta (meldet sich beim Installieren als Beta2),
2. CentOS 4.0Beta

Ich hab' mal testweise a.) drauf getan - lief dann nicht, störe sich daran, dass die Installations-HDD die 2. HDD war (hdb). Und weil beides Beta ist und weil ich gesehen hab', dass bei 3.4 nur Kernel 2.4 installiert wird, so hab' ich befürchtet, dass cooln'quiet damit ned funzt - somit hab' ich mal die HDDs vertauscht und testweise b.) drauf getan (was nicht so bleiben muss).

Das Kopieren mit dem Explorer funzt mit rund 85%, das Capturn übers Netz teste ich gerade - dürfte aber auch funzen :).

Ich teste jetzt noch ein wenig weiter - in ein paar Tagen könnte ich dann anfangen, mal die neue HW in Produktion zu bringen - schrittweise, d.h. parallel zum alten Server und sukzessive die Dienste (smb, Druckdienste, time-sync, firewall...) übernehmen.

Soll ich mit der 4.0Beta in Produktion gehen - oder mir noch eine andere Version dafür besorgen? FC3-64Bit oder CentOS3.3stable?

Vermutlich könnte ich zu gegebener Zeit (Mai?) mit der 4.0Beta dann durch ein online-Update über Nacht ohne viel Arbeit auf die stable umsteigen.?

Thx, Quintus

Eigentlich ist 3.4 keine echte Beta, sondern nur ein Test ob alle Pakete aus RHEL3 U4 richtig funktionieren. Vielleicht werden sich in CentOS 3.4 Final 1-2 Pakete ändern, aber das ist es schon.

Red Hat's Enterprise Kernel 2.4.21 hat nicht mehr sehr viel mit dem original Kernel 2.4.21 zu tun ;). Vieles wie z.B. POSIX Threads oder auch SATA Support wurden einfach aus Kernel 2.6 ausgeborgt.

Sollte funktionieren. Da RHEL4 schon nächsten Monat veröffentlicht wird, kann man Ende Februar mit CentOS4 rechnen.

Ich hab' ja am Nachmittag CentOS 4.0Beta installiert - und bis am Abend wurde das Update-Häkchen nicht rot...

Hab' gesucht - an der in up2date angegebenen URL
findet sich keine Version 4beta (mehr?). Auch nicht auf 'mirror.centos.org/centos'.... wird wohl dann Ende Februar ebendort zu finden sein.

Ich bin mir noch immer unschlüssig, ob ich 4.0beta drauf lassen und schon schön langsam mit der Übernahme beginnen soll (oder ob ich 3.4beta drauf tun + updaten soll).

----

FYI: das mit dem Video-Timeline-Abspielen, das unter Linux nicht so ganz zufriedenstellend bzw. unter Windows besser läuft, hat sich auch erledigt :) - im neuen Update meines Videoschnitt-Programms, das ich schon in der Lade liegen habe *), kann man konfigurieren, wie viele Frames in den Buffer geschaufelt werden sollen, bevor das Timeline-Playback los startet. Ein paar Frames mehr da hinein konfiguriert - und schon gibt's keine Abbrüche mehr... :).

MfG
Quintus

*) nach so viel Jahren EDV tut man kein Update drauf, bevor nicht das laufende Projekt abgeschlossen ist ;)

Ich hab' ja am Nachmittag CentOS 4.0Beta installiert - und bis am Abend wurde das Update-Häkchen nicht rot...

Hab' gesucht - an der in up2date angegebenen URL
findet sich keine Version 4beta (mehr?). Auch nicht auf 'mirror.centos.org/centos'.... wird wohl dann Ende Februar ebendort zu finden sein.

Nachdem ich den Produktionsrechner ohnedies nochmal (auf den SCSI-HDDs) neu aufsetzen muss, stellt sich die Frage, ob ich dann 3.4Beta (+ updaten) oder 4.0beta drauf tun soll.

----

FYI: das mit dem Video-Timeline-Abspielen, das unter Linux nicht so ganz zufriedenstellend bzw. unter Windows besser läuft, hat sich auch erledigt :) - im neuen Update meines Videoschnitt-Programms, das ich schon in der Lade liegen habe *), kann man konfigurieren, wie viele Frames in den Buffer geschaufelt werden sollen, bevor das Timeline-Playback los startet. Ein paar Frames mehr da hinein konfiguriert - und schon gibt's keine Abbrüche mehr... :).

MfG
Quintus

*) nach so viel Jahren EDV tut man kein Update drauf, bevor nicht das laufende Projekt abgeschlossen ist ;)

CentOS4x86_64Beta Updates (yum.conf):

[base]
name=CentOS-$releasever - Base
baseurl=http://beta.centos.org/centos/$releasever/os/$basearch/
#baseurl=http://sunsite.utk.edu/ftp/pub/linux/caos/centos/$releasever/os/$basearch/
# http://mirrors.ircam.fr/pub/cAos/centos/$releasever/os/$basearch/
# http://ftp.gui.uva.es/sites/caosity.org/centos/$releasever/os/$basearch/
# http://caos.bladeware.com/caosity/centos/$releasever/os/$basearch/

[updates]
name=CentOS-$releasever - Updates
baseurl=http://beta.centos.org/centos/$releasever/updates/$basearch/
#baseurl=http://sunsite.utk.edu/ftp/pub/linux/caos/centos/$releasever/updates/$basearch/
# http://mirrors.ircam.fr/pub/cAos/centos/$releasever/updates/$basearch/
# http://ftp.gui.uva.es/sites/caosity.org/centos/$releasever/updates/$basearch/
# http://caos.bladeware.com/caosity/centos/$releasever/updates/$basearch/

[extras]
name=CentOS-$releasever - extras
baseurl=http://beta.centos.org/centos/$releasever/extras/$basearch/

#[centosplus]
#name=CentOS-$releasever - centosplus
#baseurl=http://beta.centos.org/centos/$releasever/centosplus/$basearch/

[contrib]
name=CentOS-$releasever - contrib
baseurl=http://beta.centos.org/centos/$releasever/contrib/$basearch/

[addons]
name=CentOS-$releasever - addons
baseurl=http://beta.centos.org/centos/$releasever/addons/$basearch/

is aber no nix drinnen, daher kommt eine Fehlermeldung.

key importieren nicht vergessen:

rpm --import http://c4beta.caosity.org/centos/4.0...86/RPM-GPG-KEY

Danke - mach' ich dann auf den Produktions-(SCSI-)HDDs nach dem Umbau :).

Das mit den Entwicklungswerkzeugen für die Kernel-Kompilierung ist eigenartig - bei manchen Distributionen (z.B. bei CentOS3.4) gibt's die Kernel-Pakete zum Auswählen/Installieren, bei FC3 und CentOS4.0 hab' ich selbige nicht gesehen - warum?

Ich wollt' mal neugierig die config anschauen, was da rein kompiliert ist.

Thx, Quintus

Ich hab' jetzt testhalber mal die 3.4Beta-Version auf den Testrechner getan - auch hier findet er keine Updates von selbst, up2date bringt einen Error. An der angegebenen Stelle 'http://mirror.centos.org/3.4/os/' findet sich nur ein i386-Verzeichnis - und kein x86_64 für meinen A64.

???

Und: greift up2date auch auf die yum.conf zu?

Thx, Quintus


Nachtrag: gefunden - befindet sich auf Beta.

up2date config file:

/etc/sysconfig/rhn/up2date

Übernahme: Plan-A gescheitert!

Plan wäre gewesen:

• ich ersetze den Adaptec-2940U2W aus dem Debian-Server gegen einen Adaptec2940U (weil die Debian-Sysstemplatte ohnedies nur die SCSI-Ultra-HDD ist),
• nehm' die SCSI-LVD-HDDs heraus fürs neue System
• ... und lass' die Debian-System-HDD im alten Server - er sollte weiter laufen, bis ich alle sonstigen Dienste (hpts. Firewall) am neuen Server zum Laufen gebracht hab'.

Pech: wenn ich den Adaptec tausch' und die LVD-SCSI-HDDs weg häng', gibt's eine Kernel-Panic! Mein "genialer" Plan funzt somit nicht!

:heul: - Plan-B wäre gesucht...

Die Hauptfrage: wie krieg' ich möglichst schnell den neuen Server dazu, Windows-Router zu spielen? Am Debian-Server hatte ich die Shorewall installiert - war nicht so problematisch. Was mach' ich jetzt unter CentOS 4.0Beta? Dieses hier hätte ich gefunden - schaut mir aber recht kompliziert aus. Geht's einfacher?

Ich schraub' in der Zwischenzeit mal die Gehäuse um...

Thx, Quintus

Hi!

Kernel Panik am Debian Server?
Kannst Du kurz die alte bzw. neue Platten Situation beschreiben.

vorher:
3 SCSI HDD mit xy Partitionen
am besten wäre noch:
/dev/sda1 /boot
/dev/sda2 /
/dev/sda2 swap
/dev/sdb1 /home
... usw.

bzw jetzt:

Weil er dir ja nicht mehr hochfährt kannst Du auch mit Knoppix booten, die Debian / -Partition mounten und die /etc/fstab posten bzw. die /etc/modules wäre auch interessant.

Grüße

Manx

Um den Debian-Server kümmern wir uns später: jetzt krieg' ich den neuen CentOS-Server nicht in die Höh'!

Weigert sich von der SCSI-HDD zu booten!

Ich hab'

• natürlich die SCSI-IDs richtig terminiert,
• die HDDs melden sich auch beim Boot mit der richtigen ID sowie Übertragsungsgeschwindigkeit,
• im Adaptec-Setup ist auch die HDD mit ID-0 auf bootable gesetzt,
• CentOS ließ sich via DVD ohne Probeme instalieren, gratulierte mir auch noch zur erfolgreichen Installation...

...aber nach Entfernung der DVD aus dem Laufwerk bzw. dem Boot kommt kein Lilo....

Was tun?

Thx, Quintus
(momentan jetzt etwas verzweifelt...)



Nachtrag: natürlich hab' ich im BIOS die richtige SCSI-HDD fürs Booten angegeben...

So - ich hab' den CentOS-Server nun provisorisch zum Laufen gebracht - mit einigen Kompromissen:

• den alten Debian-Server parallel weiter laufen zu lassen, ging nicht - siehe oben ("Kernel Panic" nach Austausch des Adaptecs - und ich hab' leider nur einen U2W).
• Ich musste eine IDE-HDD rein hängen, weil aus irgend einem Grund CentOS nach erfolgter Installation nicht von der SCSI-HDD booten wollte!
• Der ISDN-Router hängt provisorisch nun intern (es haben alle WS eingerichtete Personal Firewalls).

Als nächstes gilt es zu klären:

1. Warum ließ sich CentOS nicht von der SCSI-HDD starten? Hab' ich beim händischen Partitionieren einen Fehler gemacht? Hat CentOS das Lilo auf die falsche HDD (IDE?) geschrieben? Fehlt ein Treiber? Soll ich versuchen, FC3 auf die SCSI-HDD zu installieren?
2. Wie konfiguriere ich die CentOS-Firewall(?) - Samba-Zugriff gibt's nur bei deaktivierter Firewall. Irgendwo muss man doch konfigurieren können, welche IP-#n Zugriff haben dürfen und welche nicht.
3. Wie mach' ich den neuen CentOS-Server möglichst rasch zum Firewall-Router? Am Debian-Server hatte ich die Shorewall installiert - war nicht so problematisch einzurichten. Was mach' ich jetzt unter CentOS 4.0Beta? Dieses hier hätte ich gefunden - schaut mir aber recht kompliziert aus. Geht's einfacher?

Mit der Hoffnung auf hilfreichen Input...

Thx,
Quintus

Läuft - Linux macht wieder Spass :) :

a.) hab' ich gelöst - anscheinend war doch LILO auf einer IDE-Platte installiert und als ich mit SCSI booten wollte, hat er LILO nicht gefunden... (ich hab' mal die IDEs abgesteckt :ms: und nochmal installiert...)

b.) und c.) bleiben als Fragen offen - zur Zeit mach' ich mal ein yum update.

Und morgen kann ich nicht viel weiter machen - Hochzeitstag...:( :) :D

Thx
Quintus

Firewall config:

redhat-config-securitylevel
Applications-System Settings-Security level

/etc/sysconfig/iptables

Samba:
Ports 137,138,139,443 für dein lokales Netz freigeben



Shorewall: gibst auch rpm's für RedHat/Fedora:

http://shorewall.net/download.htm

Mittlerweile sind

• alle HDDs eingebaut,
• die Daten übernommen bzw. dort, wo sie letztendlich hin gehören,
• Samba läuft
• und Printerserver spielt mein neuer CentOS-Server mittlerweile auch schon.

:) :) :)

Zitat:

Original geschrieben von callas Firewall config: redhat-config-securitylevel Applications-System Settings-Security levelhttp://shorewall.net/download.htm

Die Befehle kennt er ned :(.

Ich hab' in der graphischen Sicherheitslevel-Konfiguration nun die Firewall aktiviert und die (zukünftig interne) eth0 als "sicher" definiert - der Samba-Zugriff funzt noch :).

-----

Wie soll ich jetzt weiter machen, sodass der neue CentOS-Server nun zum Firewall-Router wird? Ausgangssituation:

• eth0 = internes Netz 192.168.0.xxx / 255.255.255.0
• eth1 = extern, 10.168.110.xxx / 255.0.0.0 - sollte die Verbindung zum ISDN-Router aufnehmen,
• d.h. der ISDN-Router gehört nun auf "extern" (eth1) umgehängt und der CentOS-Server sollte dazwischen Routerdienste tun.

Soll ich mir jetzt die Shorewall (oder eine andere Firewall) installieren - oder reicht's, wenn ich in die '/etc/sysconfig/iptables' die richtigen Einträge rein tu (welche?)?

Thx,
Quintus

Nachtrag: so ein Mist - seit 2 Stunden versuch' ich über die eth1 den umgehängten ISDN-Router zu erreichen - er pfeift mir was...

... jeder PING geht sichtlich ins interne Netz über die eth0...

MfG, Quintus

APF ist sehr beliebt als Server Firewall für Red Hat Linux. Ein entsprechendes How-to gibt es hier: http://www.fedoraforum.org/forum/showthread.php?t=11096

FYI - was sich getan hat: ich hab' jetzt mittlerweile 3 Netzwerkkarten probiert - mit der 3. hatte ich Erfolg. Anscheinend ist das Problem bei den 3Coms, dass selbige 3 Anschlüsse haben - und bei Windows-Treibern kann ich mir aussuchen, welcher Anschluss aktiv sein soll (diese Wahlmöglichkeit fehlt mir unter Linux - man weiß nie, wo die NIC horcht...)...

Egal - jetzt funzt das PING über die eth1 (extern) zum Router und auch darüber das Internt vom Server aus :) - allerdings häng' ich bei der Shorewall:

• Ich hab' Shorewall installiert
• und die Konfiguration so vorgenommen, wie ich sie damals beim Debian-Server gemacht hab' (hab' dazu damals alles peinlich genau notiert, auch die config-files vom Debian-Server hab' ich noch im Zugriff)...

...aber die Shorewall lässt sich nicht starten - Fehler:

Zitat:

/etc/shorewall/shorewall.conf: line 13: run_iptables: command not found /etc/shorewall/shorewall.conf: line 14: run_iptables: command not found ....

:( :( :(

Wenn ich den Fehler mit 'run_iptables' nicht find', werd' ich APF versuchen (der Grund, warum ich damals die Shorewall nahm, dürfte gewesen sein, weil sich selbige über Webmin administrieren lässt).

Thx,
Quintus


P.S.: kann mir der Befehl 'run_iptables' fehlen bzw. könnt er nachinstalliert gehören? Wie?

If you use a Windows system to download a corrected script, be sure to run the script through dos2unix after you have moved it to your Linux system.

aus:

http://shorewall.sourceforge.net/1.3/errata_2.htm

Ich sitz' jetzt nicht mehr beim Server - aber: ich hab' mir zwar unter Windows von dieser Seite das two-interface-sample downgeladen - aber ich hab' das *.tgz unter CentOS ausgepackt - dass ich es nicht unter Windows auspacken darf, wusste ich. Ich glaub' somit nicht, dass es der CR/LF-Fehler ist.

Problem ist, dass Linux den Befehl 'run_iptables' ned kennt - nicht einmal händisch eingegeben im Terminal.

MfG
Quintus

Ich hab' jetzt nachgeschaut: ich hab' die Konfigurationsdateien vom two-interfaces-sample ohnedies unter Linux downgeladen & entpackt - der CR/LF-Fehler kann es somit garantiert nicht sein (ich hab' nur die 'shorewall-2.2.0-1.noarch.rpm' unter Windows downgeladen & unter Linux installiert).

Folgendes steht im log:

Zitat:

/etc/shorewall/shorewall.conf: line 13: run_iptables: command not found /etc/shorewall/shorewall.conf: line 14: run_iptables: command not found /etc/shorewall/shorewall.conf: line 15: run_iptables: command not found /etc/shorewall/shorewall.conf: line 16: run_iptables: command not found /etc/shorewall/shorewall.conf: line 17: run_iptables: command not found /etc/shorewall/shorewall.conf: line 18: run_iptables: command not found /usr/sbin/shorewall: line 838: /usr/share/shorewall/firewall: Keine Berechtigung /usr/sbin/shorewall: line 838: exec: /usr/share/shorewall/firewall: cannot execute: Keine Berechtigung

Warum hat er mit 'run_iptables' in der 'shorewall.conf' ein Problem? Jemand eine Idee?

Thx, Quintus

Hat niemand den Hauch einer Idee...?

Thx, Quintus

Leider nicht :(

/usr/share/shorewall/firewall: Keine Berechtigung

das File würde ich mal mittels chmod 755 setzen.