![[Home]](/wiki/kinderunix.png)
Wenn Du auch etwas zu diesem Blog beitragen willst, dann kannst Du das unter Comments on LinuxHaters machen, bei gefallen mache ich einen Artikel daraus.
So ein Flickwerk! Da war ich letztens an einer Maschine, die in den Singleusermode (SUM) gebootet hat, und hab da mal mount eingetippt. Und dann ist da alles rw gemountet, obwohl nichts gemountet war. Und warum? Weil ein simples mount einfach nur die /etc/mtab liest, die halt noch so war wie vor dem Reboot. Aufräumen konnte das ja keiner, weil / im SUM ro gemountet ist.
Anstatt dass man sich die Info einfach vom Kernel holt, der schreibt sie sogar in /proc/mounts. Ah, die Doku liefert Auskunft (ja, immerhin ist der Mist dokumentiert):
The programs mount and umount maintain a list of currently mounted file systems in the file /etc/mtab. If no arguments are given to mount, this list is printed. When the proc filesystem is mounted (say at /proc), the files /etc/mtab and /proc/mounts have very similar contents. The former has somewhat more information, such as the mount options used, but is not necessar- ily up-to-date (cf. the -n option below). It is possible to replace /etc/mtab by a symbolic link to /proc/mounts, and especially when you have very large numbers of mounts things will be much faster with that symlink, but some information is lost that way, and in particular work- ing with the loop device will be less convenient, and using the "user" option will fail.
HaHaHa. Man kann ln -s /proc/mounts /etc/mtab machen, aber dann geht die Hälfte nicht mehr!
Also wenn man wissen will, was gemountet ist, kann man sich mount schenken und macht stattdessen cat /proc/mounts. Was ein Flickwerk!
Wow. Also das Linux manchmal bizarr broken ist, ist ja eigentlich bekannt, aber heute habe ich eine ganz neue Dimension kennengelernt.
Es geht um eine Box mit einem physikalischen Interface und einem virtuellen (für OpenVPN). Das Ethernet hat IP 10.1.1.1/24, das OpenVPN-Interface 192.168.1.1/28. Nun hat Linux die bescheuerte Eigenschaft, auf jedem Interface ARP-Requests für alle IPs auf allen Interfaces zu beantworten. Was für ein Quark.
Im aktuellen Fall ist in dem Ethernet halt parallel noch ein zweites Netz mit einer Kiste auf 192.168.1.1 - Über den Sinn von zwei verschiedenen Netzen auf einem Ethernet kann man sich streiten, nur entzieht sich dieser Aspekt leider derzeit der Kontrolle (blöder ISP). Und da ist es natürlich eher kontraproduktiv, daß die Linux-Kiste unpassende ARPs verschickt.
Andere OSe (FreeBSD, *BSD, SunOS ...) machen es natürlich richtig, und schicken ARPs nur auf dem jeweils dazu passenden Interface raus.
Aber wartet, es kommt noch besser. :-)
Linux-Benutzer leben ja nicht hinter dem Mond, und drum ist das auch schon ein paar mal aufgefallen. In Google finden sich auch lauter Mails, besonders um 2003 rum, die das diskutieren. Fazit ist, daß TPTB das nicht ändern wollen und zwar weil, haltet euch fest:
Zusammengefasst also etwa: Unser Code ist scheiße, da kriegen wir das nicht sauber hin, es gibt auch Fälle da will man so ein kaputtes Verhalten, und außerdem erlaubt uns die RFC das. Achja, und arp_filter: Na gut, na gut, ihr habt so geschrieen, also haben wir es doch noch reingehackt.
Nur das arp_filter was ganz anderes tut, und komplett unbrauchbar ist. Es filtert eingehende ARP Anfragen. Kommt die Anfrage nach 192.168.1.1 auf dem Ethernet an und hat eine Source-IP von 192.168.1.2, wird sie nicht beantwortet, weil das Netz dazu ja auf das OpenVPN Interface geroutet wird. Kommt das Paket allerdings von 10.1.1.2, wird es beantwortet. Denn dann kommt es ja laut routing-Tabelle von der richtigen IP.
Häh? Was haben die denn da geraucht? Das hilft genau garnix. Nehmen wir an, die fremde Kiste mit der IP 192.168.1.1 hat als Netz ein /24 – Wir hatten (siehe oben) ja nur ein /28. Kommt die Anfrage nun von 192.168.1.250, beantworten wir sie plötzlich. Warum? Wir haben ja eine defaultroute auf dem Ethernet!
GnaGnaGnaGnaGna!
Und was freut man sich beim Googlen über all die Leute, die mit dem Verhalten auch ein Problem haben. Man findet FAQs zu dem Thema die dann auf lauter Patches verweisen, die es da dann brav für alle erdenklichen Kernelversionen gibt.
Hallo, ist euch das nicht peinlich?
Mit freundlicher Genehmigung von Sec
Auf einem RedHat Linux sollte ich ein Perlmodul für Remedy compilieren und installieren. Als ich fertig war, hatte ich im Arbeitsverzeichnis folgendes:
$ ls ARS ars lib tmp
ars, tmp und lib habe ich in diesem Verzeichnis nicht mehr gebraucht. Was macht man in so einem Fall? mv [a-z]* /woandershin natürlich (mv weil ich es vielleicht doch noch brauchen könnte). Erwartungsgemäß sollte alles, bis auf ARS in /woandershin landen.
Allerdings ist alles in /woandershin gelandet. Was zur Hölle macht diese Krüppelshell da?
$ touch A B C a b c $ ls A B C a b c $ echo a* a $ echo [a]* a $ echo [a-z]* A a B b C c $ echo [a-a]* a
Naja, ich hatte irgendwelche Locales im Verdacht. Warum meine Shell defaultmäßig LANG=en_US gesetzt hat, ist mir schleierhaft. Aber das war der Grund für dieses seltsame Verhalten. Allerdings kann man nicht einfach LANG auf 'C' setzen, und alles ist gut, nein, man muss die Shell dann nochmal neu starten.
$ echo [a-z]* A B C a b c $ LANG=C $ echo [a-z]* A a B b C c $ exec bash $ echo [a-z]* a b c
Wahnsinn, was ein Schrott. Mal ganz davon abgesehen, das solche Defaulteinstellungen gefährlich sind (Wenn ich zum Beispiel rm statt mv benutzt hätte)
Hier eine kleine Ueberraschungstuete, die Linux immer fuer uns bereit haelt.
Auszug aus man 1 chattr
A file with the `i' attribute cannot be modified: it can
not be deleted or renamed, no link can be created to this
file and no data can be written to the file. Only the
superuser can set or clear this attribute.
Nundenn, eigentlich eine sehr sinnvolle und nuetzliche Option. Man denke an einen unschuldigen, ich verwende Linux 8.0 das erste mal, Linuxuser, der sich ausversehen mal sein vmlinuz loescht und danach, weil seine Tastaturbelegung unter KDE3 im grip nicht auf deutsch ist, bootet... Anyway
pluto:/tmp # uname -r 2.4.20-4GB pluto:/tmp # touch tester pluto:/tmp # chattr +i tester pluto:/tmp # rm tester pluto:/tmp #
Woops, weg isses :( Ok man mag nun meinen der Kernel ist nicht mehr der Aktuellste, nur wird ihm das auch nicht viel helfen wenn er geloescht wurde.
So ist's richtig:
== mars:/home/danielt> nc -l -p 22222 & [1] 69983 == mars:/home/danielt> lsof -i:22222 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nc 69983 danielt 3u IPv4 0xc1f981c0 0t0 TCP *:22222 (LISTEN) == mars:/home/danielt> nc -l -s 127.0.0.1 -p 22222 & [2] 69997 == mars:/home/danielt> lsof -i:22222 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nc 69983 danielt 3u IPv4 0xc1f981c0 0t0 TCP *:22222 (LISTEN) nc 69997 danielt 3u IPv4 0xc3f381c0 0t0 TCP localhost:22222 (LISTEN) == mars:/home/danielt> kill %1 %2
Eine Verbindung zu 127.0.0.1:22222 landet auf dem nc mit der PID 69997, auf alle anderen konfigurierten IP-Adressen auf dem nc mit der PID 69983.
So macht es Linux, vielleicht nur defaultmaessig, wer weiss.
> nc -p 22222 -l & [1] 29605 > lsof -i:22222 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nc 29605 danielt 3u IPv4 -887727195 TCP *:22222 (LISTEN) > nc -s 127.0.0.1 -p 22222 -l Can't grab 127.0.0.1:22222 with bind > kill %1