September 2006 - Linux

Hardware übrig, 19"-disk-array (2 Stück)
by bowbow＠mail.uni-paderborn.de 24 Sep '06

24 Sep '06

Aloha Liste, es gibt mal wieder Hardware. Übrig sind zwei Stück 19" 4HE Compaq "fibre channel array", mit jeweils 2 Netzteilen. Die Platten sind in Einschubrahmen und hotplug-fähig. Nummer 1 mit 6 Stück 4,3 GB Wide-Ultra SCSI Nummer 2 mit 7 Stück 4,3 GB Wide-Ultra SCSI So wie es aussieht, fehlen allerdings die Glasfaseranschlüsse, die Hauptplatine ist montiert (kenne mich mit der Materie nicht aus). Zur Zeit bin ich unterwegs und könnte heute noch eins der Geräte mit nach Gt bringen (dafür Nachricht bis 17:30 Uhr), bzw. am Montag (bis Freitag) nach Pb. Gruß Matthias

1 0

Routing/ARP/ICMP: Ein bißchen kaputt
by Jan-Benedict Glaw 24 Sep '06

24 Sep '06

Hi! Ich hab' das ein lustig' Phänomen, das ich nicht verstehe... Router: eth0: 192.168.1.1/24 eth0:xx: 192.168.2.1/24 eth1: ADSL (-> ppp0) tun1: 192.168.2.2:192.168.100.19 # cat /proc/sys/net/ipv4/ip_forward /proc/sys/net/ipv4/conf/all/send_redirects 1 1 eth0 hat also zwei Netze konfiguriert, die aber auf einem Kabel laufen. Eine weitere Kiste ("backup") bekommt via OpenVPN Backups und ist via Switch mit eth0 vom Router verbunden: Backup: eth0: 192.168.2.3/24 ADSL | +---------eth1-----------+ | Router | +-----------------------+ | | | Backup | | eth0: 192.168.1.1/24| Switch | | | eth0:x:192.168.2.1/24|-----+-----------|eth0: 192.168.2.3/24 | | | | |GW: 192.168.2.1 | | tun: 192.168.2.2 | | +-----------------------+ | <-> 192.168.100.19| | +------------------------+ +----{Rest vom LAN, 192.168.1.0/24} Beim Pingen von Backup an den Router: backup:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:14:31.481817 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 18, length 64 11:14:32.481853 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 19, length 64 11:14:33.481918 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 20, length 64 11:14:34.481976 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 21, length 64 11:14:35.482037 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 22, length 64 11:14:36.482102 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 23, length 64 11:14:37.482162 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 24, length 64 11:14:38.482255 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 25, length 64 router:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:14:32.165733 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 19, length 64 11:14:33.164712 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 20, length 64 11:14:34.164852 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 21, length 64 11:14:35.164993 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 22, length 64 11:14:36.165123 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 23, length 64 11:14:37.165260 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 24, length 64 11:14:38.165399 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 25, length 64 backup:~# ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. --- 192.168.2.1 ping statistics --- 25 packets transmitted, 0 received, 100% packet loss, time 24011ms Auf der Backup-Maschine sieht man nur die requests, auf dem Router nur die replys?! Wtf! Lustig wird das, wenn der Router dann einer _anderen_ Maschine aus dem restlichen 192.168.1.0/24'er lan einen ICMP redirect schickt (ping von 192.168.1.7/24 an 192.168.2.3/24): backup:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:17:58.250713 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 21, length 64 11:17:59.250775 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 22, length 64 11:18:00.250835 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 23, length 64 11:18:00.614082 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64 11:18:00.614182 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 1, length 64 11:18:01.250905 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 24, length 64 11:18:01.625557 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64 11:18:01.625604 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 2, length 64 11:18:01.628229 arp who-has 192.168.2.3 tell 192.168.1.7 11:18:01.628278 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d 11:18:02.250970 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 25, length 64 11:18:02.624663 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64 11:18:02.624703 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 3, length 64 11:18:03.251025 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 26, length 64 11:18:04.251087 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 27, length 64 11:18:05.251154 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 28, length 64 11:18:05.613554 arp who-has 192.168.2.3 tell 192.168.2.1 11:18:05.613602 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d 11:18:05.615854 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 220 11:18:05.619146 arp who-has 192.168.1.3 tell 192.168.2.3 11:18:05.619364 arp reply 192.168.1.3 is-at 00:e0:81:03:74:51 11:18:06.251213 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 29, length 64 11:18:06.252697 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 29, length 64 11:18:06.252896 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 188 11:18:07.251279 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 30, length 64 11:18:07.252763 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 30, length 64 11:18:08.251339 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 31, length 64 11:18:08.252810 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 31, length 64 11:18:09.251400 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 32, length 64 11:18:09.252866 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 32, length 64 11:18:10.251465 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 33, length 64 router:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \) tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:17:58.950222 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 22, length 64 11:17:59.949291 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 23, length 64 11:18:00.311993 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64 11:18:00.312202 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64 11:18:00.950540 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 24, length 64 11:18:01.323636 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64 11:18:01.323734 IP 192.168.1.1 > 192.168.1.7: ICMP redirect 192.168.2.3 to host 192.168.2.3, length 92 11:18:01.323760 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64 11:18:01.326576 arp who-has 192.168.2.3 tell 192.168.1.7 11:18:01.950683 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 25, length 64 11:18:02.322781 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64 11:18:02.322908 IP 192.168.1.1 > 192.168.1.7: ICMP redirect 192.168.2.3 to host 192.168.2.3, length 92 11:18:02.322936 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64 11:18:02.950815 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 26, length 64 11:18:03.949890 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 27, length 64 11:18:04.951093 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 28, length 64 11:18:05.312076 arp who-has 192.168.2.3 tell 192.168.2.1 11:18:05.312646 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d 11:18:05.314206 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 220 11:18:05.318877 arp who-has 192.168.1.3 tell 192.168.2.3 11:18:05.951123 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 29, length 64 11:18:05.951246 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 29, length 64 11:18:05.951327 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 188 11:18:06.951260 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 30, length 64 11:18:06.951384 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 30, length 64 11:18:07.951391 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 31, length 64 11:18:07.951509 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 31, length 64 11:18:08.951531 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 32, length 64 11:18:08.951642 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 32, length 64 11:18:09.951669 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 33, length 64 11:18:09.951793 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 33, length 64 11:18:10.951817 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 34, length 64 Interessanterweise kommt der Redirect für meinen Arbeitsplatz-Rechner?! Das muß mir jetzt mal wer erklären... Ab da pingt es dann natürlich auch, auffälligerweise mit zwei recht unterschiedlichen RTTs: (backup->router) 64 bytes from 192.168.2.1: icmp_seq=673 ttl=64 time=1.44 ms 64 bytes from 192.168.2.1: icmp_seq=674 ttl=64 time=0.395 ms 64 bytes from 192.168.2.1: icmp_seq=675 ttl=64 time=1.46 ms 64 bytes from 192.168.2.1: icmp_seq=676 ttl=64 time=0.387 ms 64 bytes from 192.168.2.1: icmp_seq=677 ttl=64 time=1.44 ms 64 bytes from 192.168.2.1: icmp_seq=678 ttl=64 time=0.377 ms 64 bytes from 192.168.2.1: icmp_seq=679 ttl=64 time=1.44 ms 64 bytes from 192.168.2.1: icmp_seq=680 ttl=64 time=0.405 ms 64 bytes from 192.168.2.1: icmp_seq=681 ttl=64 time=1.44 ms 64 bytes from 192.168.2.1: icmp_seq=682 ttl=64 time=1.44 ms 64 bytes from 192.168.2.1: icmp_seq=683 ttl=64 time=0.379 ms Pinge ich vom Arbeitsplatz-Rechner, habe ich die Zeiten um 1.4ms, solange noch kein redirect gekommen ist. Ab dem Redirect die Zeiten um 0.3 bis 0.5 msec. Wenn die Backup-Maschine den Router anpingt, kann man mal den einen, mal den anderen Wert beobachten. MfG, JBG -- Jan-Benedict Glaw jbglaw(a)lug-owl.de +49-172-7608481 Signature of: The real problem with C++ for kernel modules is: the language just sucks. the second : -- Linus Torvalds

1 1

Grub auf Amilo M1437G installieren
by Gerhard Genuit 24 Sep '06

24 Sep '06

Hallo Liste, ich habe auf o. g. Laptop Linux neben Windows installiert. Nach einem Start von Windows ist der MBR aber überschrieben worden und es wird nur noch Windows gestartet. Kein Problem dachte ich, boote von einer Live-CD und installiere Grub neu. Da musste ich aber leider feststellen, dass bei dem Notebook die Festplatte nicht hda ist sondern sda. Das kann Grub aber leider nicht parsen und meldet einen Fehler. Kann mir vielleicht jemand einen Tip geben, wie ich das System booten kann und Grub wieder installiert bekomme? Viele Dank schon mal und Grüße von Gerd

1 1

[OT] SGI-Konsolenkabel zum Selberbasteln
by Maximilian Wilhelm 23 Sep '06

23 Sep '06

Hi! Ich habe hier zwei 8-pol mini-DIN Kabel (geschaetzt 3-5m) rumliegen, aus denen man sich schoene serielle Kabel fuer SGI-Kisten basteln kann. (Ich gehe mal stumpf davon aus, dass die voll durchgeleitet sind, getestet hab ichs aber nicht.) Falls wer Interesse hat, bitte melden. Ciao Max

1 0

Linux und USB-IrDA
by Dirk Dettmann 22 Sep '06

22 Sep '06

Hallo, ich suche einen mit Linux-Standard-Treibern lauffähigen USB-IrDA-Dongle und habe im Netz widersprüchliche Aussagen gefunden. Weiß jemand, ob ein ebay-1.99-Euro-USB-IrDA-Dongle in der Regel funktioniert ( debian etch ) oder muß es ein bei http://tuxmobil.org/ir_misc.html aufgeführter Dongle sein? Gruß Dirk

2 1

Schneller Bootvorgang / Schlanke Distribution
by frank-info＠gmx.de 20 Sep '06

20 Sep '06

Hallo, ich suche ein "schlankes" Linux fuer eine Surfstation am Netzwerk (Pentium 3 Rechner). D.h. primaer muss nur ein Browser laufen. Wichtig waere ein schneller Bootvorgang, aehnlich wie LinVDR fuer meinen Videorecorder. Ich moechte die Optimierung nicht unbedingt selber, z.B. an meinem Sarge machen. Vielleicht gibt es schon was fertiges ? Was ist mit "DammSmallLinux" z.B. ? Debian basierend waere fuer mich zum Pflegen allerdings vorteilhaft... Frank Wohlfahrt ----- Debian Sarge, Kernel 2.6.14, KDE 3.3.2 -----

8 15

Synchronisation Evolution <-> Nokia 9210i
by Dirk Dettmann 20 Sep '06

20 Sep '06

Hallo, ich möchte meinen Nokia 9210i mit einem PIM ( Evolution 2 ) synchronisieren und bin zu diesem Zweck seit Tagen auf der Suche nach freier Software. Bisher habe ich gerade mal EIN kommerzielles Produkt gefunden ( wen es interessiert: -> http://www.synthesis.ch ). Da der Communicator dem SyncML - Standard entspricht, sollten zumindest Opensync oder Multisync theoretisch für mein Vorhaben interessant sein. Bevor ich mich in die ganze Sache einarbeite, habe ich versucht, Aussagen über das 9210i zu finden; und dies war erfolglos. Hat jemand von Euch bereits mit den angesprochenen Projekten oder anderer Software eine Synchronisation unter Linux hinbekommen? davon gehört, das es gehen soll? oder kennt eine Kurzanleitung zu dem Thema? Danke für Eure Bemühungen viele Grüße Dirk

1 0

regex problem
by Thomas Balsfulland 20 Sep '06

20 Sep '06

hallo leute, ich habe ein regex-problem mit dem openser (sip proxy). in einer bedingung soll geprueft werden, ob: - die rufnummer eine deutsche ist (49 am anfang) - ein "+" davor ist, oder auch nicht - min 9 stellen und max 15 stellen hat. das mit der 49 und dem "+" ist ja nicht das problem, aber das pruefen der rufnummernlaenge. so siehts in der config aus: if (uri=~"^sip:\+?49[1-9][0-9]*{6,9}@.*") { route_call } else { print "b-rufnummer falsch" exit } aber dabei wird immer "route_call" ausgefuehrt. wenn ich stattdessen if (uri=~"^sip:\+?49[1-9][0-9]*\{6,9\}@.*") schreibe, wird immer in den else-zweig gesprungen. hier mal ein paar eingehende URIs, die geprueft werden soll: INVITE sip:495241335336@62.53.239.214 INVITE sip:4952412144911@62.53.239.214 INVITE sip:4952419087689@62.53.239.214 was mache ich falsch? in der doku steht: "openser supports only POSIX regular expression" gruss thomas -- thomas balsfulland tbals(a)ctrl-c.de zwischen mut und dummheit liegt nur ein grat der sich durch das vorbereitetsein unterscheidet

2 1

Firefox Netzwerkinstallation / Samba
by Marcus Sobchak 19 Sep '06

19 Sep '06

Moin, hat jemand eine Idee, wie man am geschicktesten vorgeht, um Firefox und Thunderbird vom einzelnen Windows Client auf einen zentralen Samba Server auszulagert. Ich möchte nicht ständig an jeden User Windows Client müssen, um dort Updates vornehmen zu müssen. Daher spiele ich mit der Idee, die Firefox und Thunderbird Programmdateien auf dem Samba abzulegen, evtl. auch die Profile. Sofern Updates nötig sind, werden diese einfach auf dem Samba Server hinterlegt. So ganz grob umrissen wäre das meine Idee. Vielleicht hat ja jemand schon mal etwas in dieser Richtung umgesetzt und kann mir ein paar Tipps geben. Ciao & Danke, Marcus

1 0

Drucker reagiert nach Neustart erst nach einem manuellen Druckertest aus KDE heraus
by Stefan Pump 16 Sep '06

16 Sep '06

Hallo Leute, ich kann es nicht viel besser formulieren als im Betreff. Hier läuft ein Suse 10.0 Server mit 2.6er Kernel der über Samba Drucker für die Arbeitsgruppe zur Verfügung stellen soll. Der USB Drucker, ein HP LJ 2300, werkelt ohne Probleme. Dazu läuft aber noch ein HP BusinessInkJet 2280 am Parallelport, der nach einem Serverneustart, das Drucken durch Clients verweigert. Druckaufträge häufen sich in der Queque, aber er hgibt sie nicht aus. Erst wenn ich KDE starte und dort aus der KDE-Druckerverwaltung einen Druckerttest ausführe fängt der Durcker an zu drucken (auch die alten Aufträge). Es taucht vor dem manuellen Druckertest auch keine Fehlermeldung in den Logs auf, es scheint, als wenn der Par.-Port einfach nicht loslegt und diese händische Initierung braucht. dmesg liefert folgendes nach dem Start: ... parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected parport0: Printer, HEWLETT-PACKARD HP BUSINESS INKJET 2280 lp0: using parport0 (polling). ... /var/log/messages: ... kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] ... kernel: parport0: irq 7 detected ... kernel: parport0: Printer, HEWLETT-PACKARD HP BUSINESS INKJET 2280 ... kernel: lp0: using parport0 (polling). Soweit siehts gut aus, oder? Wenn es ein Rechteproblem wäre, sollte doch ein Eintrag entweder im Samba-Log oder in /var/log/messages auftauchen. Hat jemand jetzt schon eine Idee, woran das liegen kann, respektive, welche Logs braucht es um das Problem ein zu kreisen? Achso: Die Drucker werkeln im cupsd. Danke, Stefan

2 1