Ein paar grundsaetzliche Fragen[endgueltig gekleart]

  • Themenstarter Themenstarter sw33tlull4by
  • Beginndatum Beginndatum
S

sw33tlull4by

Guest
Hi!
Also:
Ich habe ein paar grundsaetzliche Fragen bezueglich Linux:
1.
Was genau ist den nun der Unterschied zwischen einem Windowmanager und einer Desktopumgebung?
Sehe ich das richtig das ein Windowmanager in einer Desktopumgebung laeuft?
2.
Ich bekomme demnaechst einen netten kleinen 900Mhz PC, welchen ich zu testzwecken an meinen PC anschliessen will, mittels Router.
So Router angeschlossen,(ich gehe ueber Wlan ins Internet udn der Router haengt an eth0.
Nun wollte ich das eigentlich mittels IPtables regeln, bin dann aber ueber den Befehl
ip gestolpert.
Ich habe mir dazu mal die Manpagers ein bischen durchgelesen wurde daraus aber nicht so richtig draus schlau.
Wo genau setzt das dingen an?
iptablesschauen einfach nach ob bestimmte Packete durchduerfen und wo sie noch hin sollen,
ifconfig schaltet die eth0 und co an.
ip regelt das dann die Kernelrouteingtabelle?
Wo ist die Datei welche durch ip veraendert wird?
Ich wuerde naehmlich ganz gerne von dieser Datei ein Backup machen,d amit ich da nach herzenslust rumspielen kann ohne mir sorgen machen zu muessen.
mfg

sw33t
 
dm/wm:
das einfachste beispiel ist wohl gnome mit metacity. du kannst mal anstatt "gnome-session" einfach metacity starten, dann siehst du, daß es da "nix" gibt. metacity ist in dem fall der windowmanager (kann durch compiz oder sawfish ersetzt werden) und gnome der desktopmanager. metacity ist dem fall sozusagen für die verwaltung der fenster zuständig und gnome für den inhalt.

iptables:
iptable rules werden in keine datei geschrieben, sie sind entweder aktiv oder sie sind es nicht. man kann zwar seine regeln sichern (iptables-save) und diese per iptables-restore wieder laden, aber das ist nicht per default so. im klartext: einfach so gesetzte regeln müssen nach einem restart wieder neu gesetzt werden.

was ip anbelangt hab ich mich bisher davon fernhalten können, obwohl jeder danach schreit. routing mit ip soll wohl einfacher als mit iptables sein, aber dazu kann ich leider nichts sagen.
 
Das Routing mittels 'ip' hat den Vorteil, dass es sich an Cisco-Konventionen hält. Man kann damit z.B. mehrere Routen für verschiedene Netzwerkkarten legen, multiple Routing-Tabellen definieren u.ä. Ich setze iproute vor allem dann ein, wenn ich die Möglichkeit brauche Routen sehr fein abstimmen zu können um z.B. mehrere DSL-Leitungen zu nutzen u.ä. Wie auch bei iptables werden mittels ip festgelegte Regeln nur im RAM gehalten. Benötigt man eine feste Konfiguration, wird diese unter /etc/iproute2 abgelegt.
 
1. Der Windowmanager stellt nur das drumherum der Fenster(Titelleiste,...) dar und sorg für die bearbeitung grundlegender X11 Events (Fensterbewegung,...).

Die Desktopumgebung umfasst neben einem Fenstermanager auch Interprozesskommunikation, Dateimanager, Konfiigurationsmanagement etc....
 
Original von 01
1. Der Windowmanager stellt nur das drumherum der Fenster(Titelleiste,...) dar und sorg für die bearbeitung grundlegender X11 Events (Fensterbewegung,...).

Die Desktopumgebung umfasst neben einem Fenstermanager auch Interprozesskommunikation, Dateimanager, Konfiigurationsmanagement etc....

Ich dachte auch mal, dass man nach dieser Definition gehen kann, schaut man sich aber einen typische WM wie AfterStep, WindowMaker oder FVWM mal genauer an, stellt man fest, dass sie eben doch nicht ganz stimmt. Ein Konfigurationsmanagement bieten die 3 genannten WM z.B. auch. Hinzu kommt, dass sie APIs für Applets u.ä. bereitstellen, Programm-Menüs beinhalten u.ä., was weit über die grundlegenden X11-Events hinaus geht. Einige liefern sogar komplette Grafikbibliotheken mit. Seitdem hab ich für mich eine eigene Definition aufgestellt:

Desktop-Manager stellen neben den WM-Funktionalitäten wie Fenster-Dekoration, Fenster-Events und Menüs einen Dateimanager zur Verfügung, der die Funktionalitäten des Desktops wie Programm-Icons u.ä. steuern kann. Sie stellen damit einen um Dateifunktionalitäten erweiterten WM dar (wenn man mal davon ausgeht, dass Sockets, Verknüpfungen u.ä. im weitesten Sinn auch Dateien sind).
 
Weiterleitungsproblem

Endlich habe ich den PC bekommen, hat viel laenger gedauert als erwartet.
Ist aber 300MHZ schneller und hat noch eine SCSI-Platte*G*
Wie dem auch sei.
Gestern habe ich mich hingesetzt und angefangen damit rumzuspielen.
Nachdem ich mich auf Ewig aus meinem Router ausgesperrt hatte(fragt nicht)
habe ich eine 2. Ethernetkarte eingebaut und angefangen damit rumzuspielen.
Ich hatte es auch geschafft mein jetziges System als router so zu konfigurieren das ich mit meinem 2.rechner ueber ihn ins Internet kam.
Habe dann aber einen Stromausfall erlitten bevor ich alles sichern konnte.
Naja.
Nun habe ich es heute halt wieder versucht.

Die PC-s sehen sich auch. ping funktioniert aber ich bekomme es nicht mehr hin das die DNS-Anfrage weitergeleitet wird, bzw das der 2.PC grundsaetzlich ueber den ersten mit der Aussenwelt reden kann.
DNS funktioniert nicht(ja habe /etc/resolv.conf editiert) und anpingen ueber die IP ergibt die Fehlermeldung das das Netzwerk nciht erreichbar sei.
Route zu meinem 1.PC ist auch definiert.
Auf dem 2.PC laeuft Ubuntu-Server 7.04,
mein Hauptpc ist mit Fedora9 ausgeruestet.
Mein Vorhaben ist es ihn primaer als Backupserver einzusetzen und evtl spaeter ein Cluster, mein jetziges System sollte so transparent wie moeglich sein.
Einige Optionen habe ich schon ausprobiert und ich bin mit meiner kreativitaet am Ende.
Danke im Vorraus.

Fedora9(tracy)eth1:172.16.1.3/16
Ubuntu(tall)eth0:172.16.1.2/16

Ich habe folgende Befehle eingegeben.
tracy:

route add -net 172.16.0.0 netmask 255.255.0.0 eth1
iptables -A INPUT -i eth1 -s 172.16.0.0/16 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -s 172.16.0.0/16 -j ACCEPT
iptables -A FORWARD -d 172.16.0.0/16 -j ACCEPT
iptables -t nat -A POSTROUTING -d 172.16.0.0/16 -j MASQUERADE -o eth1
iptables -t nat -A PREROUTING -i ppp0 -j DNAT --to-destination 172.16.1.2
iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ohne wirkung(d.h. wieder entfernt) waren

iptables -t nat -A POSTROUTING -s 172.16.0.0/16 -j MASQUERADE -o ppp0
iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPT

tall:
route add -net default netmask 255.255.0.0 eth0


//edit
iptablesversion ist 1.4.1.1



//EDIT
Das Problem war nicht mein Router sondern, der Rechner tall

Folgende Befehlszeile behebt das Problem
route add -net default gw 172.16.1.3
 
Zurück
Oben