rsc

Ob du es mir jetzt glaubst oder net: SuSE Linux 9 hat irgendwie viele Macken und Mucken, das mit dem DNS hab ich bisher nur von exakt der Version gehört *lol*

Ein lokaler DNS (reicht ja caching bzw. forwarder) ist immer von Vorteil, allerdings dann wäre es trotzdem empfehlenswert, dass du in der squid.conf die 127.0.0.1 auch in der resolv.conf einträgst. In der Schule hast du aber bestimmt auch kein SuSE Linux 9, oder? ;-)

Ahhhsoo...du willst den Samba 3 als Server in deine bestehende Domänenstruktur als untergeordnete Domäne oder untergeordneten Server einbinden...das geht natürlich. Sorry, aber an der Stelle muss ich aufs Samba-Manual verweisen, weil ich das selbst kaum brauche.

Schau dich doch mal auf http://us.dl.sf.net/sourceforge/jpackage/direct_download/1.5/redhat-9/RPMS.free/ um, dort wirst du sicher fündig...evtl. musste halt nur die rpms von denen nehmen und dafür deine über Bord werfen, weil die vmtl. nicht zueinander kompatibel sind. Im Zweifelsfall src-rpm saugen und rebuilden ;-)

Sorry, wenn ich so lapidar antworte, aber warum ist Solaris nicht Sinn der Sache? Ich meine, du kriegst auf Sparc IIRC Linux, diverse Unix-Derivate inklusive BSD-Zeugs lauffähig - wenn mich nicht alles täuscht...

Kann es sein, dass du DNS mit Windows-Domäne gleichsetzt, oder interprätiere ich dein Posting falsch? :confused:

Guck deine squid.conf mal durch, vermutlich ist dns_nameservers 194.25.2.131 194.25.2.132 o.ä. nicht gesetzt, das verursacht dann immer wieder Ausfälle, wenn das System nicht schnell genug auflöst.

Sorry, ich hab mich etwas undeutlich ausgedrückt. FATxx sind sehr simpel und haben keine ausführliche Rechte-Verwaltung und keine Journalisting-Filesystem-Features.

Der Aufbau des Dateisystems, die Rechte usw. sind nicht dokumentiert. Du hast bei einem Dateisystem auch mehr im Hintergrund - vor allem bei einem Journalisting Filesystem - als z.B. bei FAT8/12/16/32.

Das wird bereits gemacht. Aber finde mal bei einem geschlossenen Dateisystem mal was raus - das auch vermutlich nur übel zusammengehackt worden ist. Du scheinst die Aufwendigkeit zu unterschätzen. Programmier bei den Geeks mal mit, dann weißte, das es viel mehr ist, als du hier sagst :-D Außerdem NTFS4 war nicht soo das Problem, aber NTFS5 hats wohl in sich und der Nachfolger WinFS steht auch schon fast auf der Schwelle...

*hmpf* :eek: [...] Linux auf x86 (RedHat 6.2 to 8.x, oder Debian 2.1 oder höher) [...] Red Hat Linux (das jetzt übrigens inzwischen "Fedora Core" heißt) ist in Version 6.x gegen glibc 2.1.x gelinkt, in höheren Distributions-Versionen, eben gegen neuere glibc-Versionen z.B. Mit dem Kernel hat im Normalfall ein Programm recht wenig zu tun, eher mit einer grundlegenden System-Library wie glibc. Red Hat Linux und SuSE Linux sind - relativ - gleichwertig, was die Aktualität der Librarys betrifft und im Normalfall funktioniert ein kommerzielles Software-Paket auch unter SuSE. Die Workstation-Version des Virenscanners f-prot (Freeware für Homeuser) funktioniert z.B. problemlos unter Fedora, Debian, Gentoo, Red Hat, Mandrake und SuSE - dabei ist die Aktualität des jeweiligen Systemes noch nicht mal so 100%ig beachtet.

Geht definitiv auch ohne. Aber empfehlenswert ist, dass ein DNS-Server im Netz existiert. Oder setze alternativ den Linux-Rechner via OS-Level und Masterbrowser zum Master über die Rechner, dann sollte evtl. noch ein Problem mehr beseitigt sein.

Für deinen expliziten Wunsch würde ich z.B. folgendes nehmen: /dev/hdaX /mnt/windows ntfs auto,umask=0222,ro 0 0 IIRC gibt es aber "safe-file-override"-Support - mehr Infos: NTFS-Driver development status

Nun, dass dein OpenSSH herunterfährt, hängt sehr sicher nicht mit deiner Fehlermeldung zusammen. Die Fehlermeldung lässt sich erzeugen wie folgt (auf dem Linux-Server): "telnet localhost 22" und dann die Verbindung einfach wieder schließen. Meist wird dieser Log-Eintrag durch einen Portscanner wie z.B. nmap erzeugt. Dein Problem könnte ich mir z.B. darin vorstellen, dass ein OpenSSH einfach antiquarisch ist und es für 3.4p1 schon remote Exploits gibt, um den Server zu rooten Ich will damit sagen, dass der SSHD-Daemon problemlos remote crashbar ist. Mach mal ein OpenSSH-Update auf eine aktuelle Version (derzeit 3.7.1p2) - oder guck zumindest, dass dein altes OpenSSH gegen die aktuellen Probleme geschützt ist (wenn SuSE noch Update-Support bietet). Löst eine aktuellere Version das Problem nicht, so würde ich mich mit den Logfiles und den Konfigurationsdateien weiter auseinander setzen - der SSHD restartet nicht einfach so. Notfalls auch mittels Debugmaßnahmen. Wenn der Restart/die Unerreichbarkeit immer um die gleiche Zeit ist, solltest du mal Crontab checken und evtl. Netzwerk zu der Zeit sniffern. Hoffentlich hilfts, Robert

Also was hältst du von `man ls`? ls -lac könnte für dich z.B. von Bedeutung sein. Oder --full-time und --sort und z.B. -t -- gibt so viel. Musst nur die Augen aufmachen. Achso, ja, man liest nur ungerne Manual-Pages, ich weiß - http://www.engr.utk.edu/ecc/unix/man/ls.php - http://www.google.de/search?q=man+ls Für dein 2. Problem wäre hier z.B. eine Quick&Dirty-Lösung: `ls -la | grep Feb\ 02 | grep 2002`. Also `man ls` und damit fröhliches RTFM! Achja, und zu deinem letzten Punkt: ls is im Package fileutils und das ist GNU und damit ist das auf den meisten Plattformen/Systemen das gleiche http://www.gnu.org/software/fileutils/fileutils.html Robert