Hopser

Ausstattung auf Arbeit: Dell Desktop P4 2,66 GHz 512 MB Ram 40 GB Platte 15 Zoll TFT Anbindung des Büros über 2 MBit Standleitung direkt ins eigene Rechenzentrum. Seit Mitte des ersten Lehrjahres hab ich Admin- Rechte auf allen (!) Routern und Servern der Firma und auf den Rechnern eines Großteils der Kunden. Ich denke mal, damit kann ich wohl zufrieden sein. Zuhause arbeite ich mit meinem privaten Rechner, Stand 2001. Da stecken drin: Athlon 1200, 768 MB Ram, 200 GB Festplatte. Zugabe ist hier eine symmetrische DSL-Leitung mit 1 MBit und einem gerouteten /29 mit öffentlichen Adressen. Außerdem hab ich hier meine Domain liegen und betreibe auch Web-, DNS- und Mailserver selbst. Ist aber auch genau mein Aufgabengebiet in der Firma, so daß das nich schwer zu begründen war :-) Tschau, Hopser

Schau in die Quellcode-Dateien deines benutzten Soundtreibers. Ne ganze Weile lang hab ich die Default-Werte dort drin geändert, wie ichs brauchte. Ansonsten hilft dir vielleicht aumix, das kann Mixerwerte speichern und wiederherstellen. Tschau, Andreas

Setz die Route, die ich dir im letzten Beitrag geschrieben hab, mal nicht auf sit1, sondern auf sit0. sit1 hat eine Link Local Address. Tschau, Andreas

Falsch. Jeder, der die Rechte hat, bei dir ein CGI abzulegen, und der weiß, wo der PHP-Interpreter liegt, kann den auch benutzen. Das Risiko ist aber meines Erachtens auch nicht höher, als bei Perl. Skripte, die man ausführt, laufen immer erstmal unter dem Nutzer, der das macht. Augenscheinlich nicht sonderlich kritisch, weil der Apache meist als nobody oder wwwrun rennt, der eh nix weiter darf. Allerdings sollte man drauf achten, daß auch wwwrun schon ein lokaler Nutzer ist. Und eine Shell, die ein Angreifer unter dem Nutzer bekommt, kann er als "Sprungbrett" nutzen, um bespielsweise einen Local Root Exploit zu plazieren. Daher sollte man auch diese Sicherheitslücken IMMER schließen, auch wenn sie augenscheinlich nicht so dringend sind. Aber ich glaub, langsam gehört das nicht mehr in die Skriptsprachen, sondern schon eher in Richtung Sicherheit Tschau, Andreas

Nein, das ist in 99% der Anwendungsfälle vollkommen unsinnig. Ein Interpreter, was das PHP als Kommanozeilenversion ist, muß bei jedem Skript-Aufruf neu geladen werden, führt das Skript aus und beendet sich wieder. Das Apache-Modul kann nahezu direkt mit der Ausführung der Skripte anfangen. Schätz mal, wieviel schneller die 2. Variante sein kann. Das ist übrigens auch einer der Vorteile, den PHP gegenüber Perl bei der dynamischen Webseitengestaltung hat. Aber auf der Kommandozeile würde ich dropsdem immer noch zu Perl raten. So unterschiedlich sind die Sprachen nicht, die kleinen Eigenheiten kriegt man schnell gebacken. Tschau, Andreas

Nimm einen Webcrawler deiner Wahl. Unter Linux geht das mit wget, unter Windows hab ich das mal mit Websnake oder so gemacht. Weiß nimmer genau, ob der Name stimmt, weil es schon Ewigkeiten her ist. Tschau, Andreas

ich gehe im folgenden mal davon aus, daß die Freenet6-Verbindung auch als Point-to-Point-Verbindung aufgebaut wird, wie es bei einem Tunnel normalerweise ist. Testen kann ich das Freenet6 leider nicht, weil ich selber meinen Tunnel woanders habe. Dafür brauchst du auch nicht wirklich einen Tunnel. DNS für v6 kann auch ein v4-Server machen. route -A inet6 add default dev sit1 Vergibt Freenet6 dynamische v6-Adressen? Frag mich, was der Unsinn soll. Such dir einen Broker, bei dem du gleich ein gescheites Netz statisch bekommst. Dann brauchst du keinen DynDNS für v6. Tschau, Andreas

deswegen. Wenn du ein Linux wärest, wo würdest du die Pakete hinschicken wollen? Zur Erklärung: Linux routet ein Paket immer zur speziellsten Route, die es findet. Hast du also eine Route für 172.16.0.0/16 und eine für 172.16.0.0/24, die jeweils ein anderes Ziel haben, so wird für ein Paket an 172.16.0.1 immer die zweite genommen, es sei denn, es gibt eine noch speziellere. In deinem Fall sind die Routen allerdings vollkommen gleichwertig, d.h. es wird die erste genommen, die auftritt. Demnach geht dein Ping zu eth0 raus, wo dein Windows-Rechner aber garnich dran hängt. Die Erklärung ist stark vereinfacht, eigentlich spielt noch eine ganze Menge mehr rein, aber das ist für deinen Fall eher unerheblich. Auf jeden Fall hast du durch das Ändern der einen IP-Adresse eine der beiden Routing-Zeilen geändert, weil Linux das automatisch entsprechend den Interfaces macht. Damit existiert für 172.16.0.0/16 nur noch der richtige Eintrag. Und dein DSL-Interface bräuchte eigentlich garkeine IP, deswegen konntest du die einfach ändern, ohne daß was nicht mehr funktioniert. Tschau, Andreas

Also ist eth0 demnach die Karte, über die dein DSL läuft, richtig? Dann weise der Karte mal eine IP aus einem vollkommen anderen Netz zu, aus 192.168.0.0/24 zum Beispiel. Für DSL sollte es unerheblich sein, und dein Problem mit dem Ping sollte es lösen. eth1 bleibt, wie sie ist. Tschau, Andreas

Und an welchem der Interfaces hängt dein Windows-Rechner? Tschau, Andreas

Beide Netzwerkkarten sind im selben Netz, ich vermute, dein Ping wird zum falschen Interface rausgehen. Also schau mal deine Routing-Tabelle an. Außerdem ist bei beiden Netzwerk-Interfaces die Netzmaske falsch. Laut RFC1918 ist 172.16.0.0/12 ein privates Netz, nicht 172.16.0.0/16. Dürfte allerdings keinen Einfluss auf dein Problem haben. Tschau, Andreas

Hallo, sei dir im Klaren: ein Linux ist kein Windows. Du würdest dich also auf was einlassen, was in einigen Teilen grundlegend andere Konzepte hat, als Windows. Wenn dich das trotzdem nicht abschreckt, dann fang möglichst schnell zuhause an, damit ein bissl rumzuspielen, und stell hier konkrete Fragen zu Problemen. Evtl. kann man dann auch dazu Doku-Links posten. Mir persönlich wäre es aber zu heiß, mit sowas mein Projekt aufs Spiel zu setzen. Mach was, was du im Fachgespräch auch angemessen vertreten kannst. Tschau, Andreas

Hallo, solch eine IP gibts immer dann, wenn Windows keinen DHCP-Server erreichen konnte, aber so eingestellt ist, daß es seine IP davon bezieht. Jetzt wäre interessant zu wissen, wieso das so ist. Wichtig ist in meinen Augen der Umstand, daß DCHP-Requests Broadcast-Anfragen sind. Dein Rechner "brüllt" also ins Netz, ob jemand eine IP für ihn hat. "Hört" dies der DHCP-Server, so weißt er per Unicast direkt dem Client eine IP zu. SChau mal, ob beide Teile der Zuweisung bei dir auch über das VPN hinweg möglich sind. Hilfe kann dir dabei sicher ein Sniffer leisten, wo du siehst, wer was wohin schickt und welche Antworten kommen. Tschau, Andreas