Krain

Hi Phillipp, diese Meldung für "invoke-rc.d networking restart" kommt daher, dass das init-script grundsätzlich alle interface runter fährt über ein "ifup -a" und danach alle in /etc/networking/interfaces konfigurierten interface wieder hochfährt. Damit würden natürlich manuelle anbindungen von interfacen gelöscht werden, welche nicht in die /etc/networking/interfaces eingetragen wurden. Um nur ein spezielles interface neu zu starten hilft auch ein ifdown eth0 && ifup eth0 Je nachdem welches interface du neu starten willst. Gruß Markus

Kleine Anmerkung noch meinerseits. Mit der allow-hotplug direktive hatte ich speziell in virtuellen Maschinen manchmal meine Problemchen, welche ich über die direktive auto lösen konnte, also: [B]auto[/B] eth0 iface eth0 inet static [INDENT]address 192.168.2.184 broadcast 192.168.2.255 netmask 255.255.255.0 gateway 192.168.2.249[/INDENT]

Generell sollten alle Themen aus dem LPIC-1 für die Grundlagen sinnvoll sein. Ich selbst lege meinen Azubis nahe sich mit diesen Themen zu beschäftigen und auch zumindest den LPIC-1 abzulegen. Für einen Linux-Server-Admin sind das die absoluten Basics, die man einfach beherrschen sollte. Gruß Markus

Hallo zusammen, Debian-version: squeeze Eventuell kann mir jemand aus der Gemeinde der Debian-Jünger bei meinem kleinen Problem weiterhelfen, ich versuche das eben mal so gut als möglich zu erklären. Ich habe ein CVS-Repository mit etlichen Scripts, Daemon etc... theoretisch also mehrere Debian-Pakete - Aufgrund der Vereinfachung für unser Operations-team wollen wir nun anstatt über CVS-checkouts/updates unsere Software in debian Paketen ausliefern. Dabei wollen wwir allerdings vermeiden das Repository zu splitten. Dazu habe ich folgende adaptierte Verzeichnis-Struktur: projekt [common] [debian] - control - changelog - rules - etc... [perl] [util] [web] Meine debian-control Source: projekt Maintainer: test <test@test.tst> Section: misc Priority: optional Standards-Version: 3.9.2 Build-Depends: debhelper (>= 8) Package: paket1 Architecture: all Depends: ${misc:Depends} Description: Paket 1 Paket 1 Package: paket2 Architecture: all Depends: ${misc:Depends}, paket1 Description: Paket2 Paket2 Über das debian control-file kann ich den source wunderschön in mehrere Pakete splitten. Mein Problem ist allerdings momentan, dass ich jedem Paket eine eigene Versionierung geben möchte. Leider lässt sich nach meinem bisherigen Wissenstand nur die Source selbst versionieren über das debian/changelog (debchange / dch). Eventuell habe ich da auch irgendwo einen Denkfehler in meiner Strukturierung. Könnte mir bei dieser Problemstellung mal jemand auf die Sprünge helfen? Danke im Voraus Markus

Hallo zusammen, Das Problem habe ich inzwischen behoben. Folgendes war der "Fehler": Mein Setup war auf einem ESX virtualisiert und ich habe vergessen auf den vSwitches den "Allow Promiscuous" flag zu setzen. Der Link könnte anderen bei Problembehebung weiterhelfen: OpenVPN bridge and VMWare ESX 3.5 /dev/BioS Gruß Markus

openvpn1:~# brctl show br0 bridge name bridge id STP enabled interfaces br0 8000.000c298bd6b4 no eth2 tap0 openvpn2:~# brctl show br0 bridge name bridge id STP enabled interfaces br0 8000.000c29c11404 no eth2 tap0 Das hab ich alles schonmal überprüft. Sollte auch imho so passen. Aber vielleicht fällt dir ja nochwas auf. Ich vermute, dass client1 einfach nicht die MAC von client2 kennt und dadurch die Replies ins Nirvana gehen. Aber ich such halt eine Möglichkeit, genau das Problem noch zu beheben. Gruß Markus

openvpn2: br0 Link encap:Ethernet HWaddr 00:0c:29:c1:14:04 inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::708c:a5ff:fe8f:4e38/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:827456 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:38036394 (36.2 MiB) TX bytes:748 (748.0 eth0 Link encap:Ethernet HWaddr 00:0c:29:c1:14:f0 inet addr:10.2.130.224 Bcast:10.2.130.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fec1:14f0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:179114 errors:3 dropped:3 overruns:0 frame:0 TX packets:15842 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15409884 (14.6 MiB) TX bytes:3247252 (3.0 MiB) Interrupt:18 Base address:0x1400 eth1 Link encap:Ethernet HWaddr 00:0c:29:c1:14:fa inet addr:10.254.0.2 Bcast:10.254.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fec1:14fa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39169 errors:1 dropped:1 overruns:0 frame:0 TX packets:861468 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3006438 (2.8 MiB) TX bytes:119190319 (113.6 MiB) Interrupt:19 Base address:0x1480 eth2 Link encap:Ethernet HWaddr 00:0c:29:c1:14:04 inet6 addr: fe80::20c:29ff:fec1:1404/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:826074 errors:0 dropped:0 overruns:0 frame:0 TX packets:10573 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:49564706 (47.2 MiB) TX bytes:529918 (517.4 KiB) Interrupt:16 Base address:0x1800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:145 errors:0 dropped:0 overruns:0 frame:0 TX packets:145 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:14330 (13.9 KiB) TX bytes:14330 (13.9 KiB) tap0 Link encap:Ethernet HWaddr 00:ff:33:ef:42:74 inet6 addr: fe80::2ff:33ff:feef:4274/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:6214 errors:0 dropped:0 overruns:0 frame:0 TX packets:827467 errors:0 dropped:520 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:345444 (337.3 KiB) TX bytes:49622632 (47.3 MiB)[/code] openvpn1: [code]br0 Link encap:Ethernet HWaddr 00:0c:29:8b:d6:b4 inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::4401:4cff:fecf:e939/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:831459 errors:0 dropped:0 overruns:0 frame:0 TX packets:3841 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:38329262 (36.5 MiB) TX bytes:324862 (317.2 KiB) eth0 Link encap:Ethernet HWaddr 00:0c:29:8b:d6:a0 inet addr:10.2.130.223 Bcast:10.2.130.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe8b:d6a0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:197276 errors:5 dropped:5 overruns:0 frame:0 TX packets:26821 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15383871 (14.6 MiB) TX bytes:4862480 (4.6 MiB) Interrupt:18 Base address:0x1400 eth1 Link encap:Ethernet HWaddr 00:0c:29:8b:d6:aa inet addr:10.254.0.1 Bcast:10.254.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe8b:d6aa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:861539 errors:0 dropped:0 overruns:0 frame:0 TX packets:39179 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:119745621 (114.1 MiB) TX bytes:2463304 (2.3 MiB) Interrupt:19 Base address:0x1480 eth2 Link encap:Ethernet HWaddr 00:0c:29:8b:d6:b4 inet6 addr: fe80::20c:29ff:fe8b:d6b4/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:6982 errors:2 dropped:3 overruns:0 frame:0 TX packets:835448 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:502102 (490.3 KiB) TX bytes:50119988 (47.7 MiB) Interrupt:16 Base address:0x1800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1327 errors:0 dropped:0 overruns:0 frame:0 TX packets:1327 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:126232 (123.2 KiB) TX bytes:126232 (123.2 KiB) tap0 Link encap:Ethernet HWaddr 00:ff:6b:e8:6f:e5 inet6 addr: fe80::2ff:6bff:fee8:6fe5/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:827544 errors:0 dropped:0 overruns:0 frame:0 TX packets:6783 errors:0 dropped:841 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:49627468 (47.3 MiB) TX bytes:370242 (361.5 KiB) Hier die ifconfig - bitte ignoriert eth0 (das interface verwende ich fürs management). Aber imho passt hier auchj alles auf tap0 und eth2 promisc-mode. Gruß Markus

Ja die ARP-Anfragen kommen an. Der TCPdump zeigt auf der gegenseite: 12:19:03.436962 arp who-has 192.168.1.11 tell 192.168.1.12 12:19:03.436992 arp reply 192.168.1.11 is-at 00:0c:29:e6:77:18 (oui Unknown) 12:19:04.437733 arp who-has 192.168.1.11 tell 192.168.1.12 12:19:04.437763 arp reply 192.168.1.11 is-at 00:0c:29:e6:77:18 (oui Unknown) Der ARP-Reply geht aber nicht an den openvpn1 zurück.

Ja genau, Für mein Projekt ist es notwendig einen Serverraum ohne Ausfallzeiten möglichst einfach von Nürnberg nach Dänemark zu migrieren. Deshalb hab ich mir gedacht einfach die beiden Rechenzentren über OpenVPN zu bridgen wie in diesem Beispeil dargestellt: OpenVPN Bridging und dann alle meine Failover-Nodes einfach nach Dänemark zu schicken. Gruß Markus

Hallo Experten, Ich habe ein Problem mit meinem OpenVPN bridging setup. Folgende komponenten sind dabei im Spiel: Host bridgeclient1: IP 192.168.1.11 (netzwerksegment 1) Host openvpn1: IP: 192.168.1.254 (bridged mit openvpn tap0 Netzwerksegment 1) IP: 10.254.0.1 (IP im simulierten Pub-Netzwerk – openvpn peer IP) Host openvpn2: IP: 192.168.1.253 (bridged mit openvpn tap0 Netzwerksegment 2) IP: 10.254.0.2 (IP im simulierten Pub-Netzwerk – openvpn peer IP) Host bridgeclient2: IP 192.168.1.12 (netzwerksegment 2) Openvpn-config beiderseits ist folgendermaßen: openvpn2:~# cat /etc/openvpn/openvpn.conf remote 10.254.0.1 dev tap0 secret /etc/openvpn/static.key verb 7 Mein Problem ist jetzt folgendes – ich lasse von bridgclient2 einen ping auf bridgclient1 laufen. Ich sehe auch die arp-requests sauber auf dem tunnel und tap-devicen durchgereicht bis bridgeclient1: Dort zeigt mir der tcpdump aber folgendes: 12:19:03.436962 arp who-has 192.168.1.11 tell 192.168.1.12 12:19:03.436992 arp reply 192.168.1.11 is-at 00:0c:29:e6:77:18 (oui Unknown) 12:19:04.437733 arp who-has 192.168.1.11 tell 192.168.1.12 12:19:04.437763 arp reply 192.168.1.11 is-at 00:0c:29:e6:77:18 (oui Unknown) Kann mir einer von euch weiterhelfen an diesem Punkt? Die Arp-replies kommen nicht mehr zum openvpn1 zurück. Wenn noch weitere Details benötigt werden, stelle ich die natürlich gerne zur Verfügung. Gruß Markus

Entschuldige meine Unverschämtheit, aber darf ich fragen, wie lange du nach der Lösung gesucht hast? Und wie lange hast du eventuell selbst mal über die Aufgabenstellung nachgedacht? Weißt du eventuell schon, was ein Struktogramm ist? Falls nein hilft dir eventuell die folgende Erklärung weiter: Nassi-Shneiderman-Diagramm ? Wikipedia Mit dieser Erläuterung sollte die obige Aufgabenstellung von jedem innerhalb weniger Minuten zu lösen sein. Gruß Markus

Java 6 - com.sun.net.httpserver Vielleicht hilft der dir bei deinem vorhaben weiter. BR Markus

Ja, das sollte kein Problem sein - du schreibst dir lediglich ein paar Schnittstellen-Funktionen auf die du mit Ajax zugreifen kannst. Diese Funktionen müssen dann jeweils das Objekt aus der Session holen und dann kannst du ja innerhalb der Schnittstellenfunktion jederzeit auf alle Methoden des Objektes zugreifen und den Rückgabewert zurück senden. Wichtig ist halt nur, dass du dir eine (bzw. mehrere) Schnittstellenfunktionen schreibst, je nachdem auf welche Methoden bzw. Attribute du zugreifen willst. Gruß Markus

Dem würde ich so zustimmen. Setz dich einmal richtig mit OOP auseinander - imho ist Java dafür am besten geeignet. Es muss nur mal Klick machen und dazu musst du einfach Probieren. Programmier dir selbst ein paar kleine Applikationen, mit der Zeit kommst du ganz von selbst dahinter, wie es funktioniert. Gruß Markus

Bin mal gespannt auf das Ergebnis deiner Arbeit...