IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 34 von 49)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

ClamAV unter Sabayon Linux mit systemd installieren und einrichten​

Ich sitze hier gerade vor einem Sabayon mit XFCE und wundere mich darüber dass der ClamAV nicht nach der Installation „out of the Box“ funktioniert.

Folgende kurze Schritte sind nötig damit er bei mir die Basisarbeit in aktueller Form aufnimmt 🙂

$ equo install app-antivirus/clamav
$ cp /etc/freshclam.conf.sample /etc/freshclam.conf
$ systemctl enable freshclamd.service
$ systemctl enable clamd.service
$ systemctl start freshclamd.service
$ systemctl start clamd.service

So long…

PDS Programm + Datenservice GmbH: Rückblick auf innovative IT-Lösungen​

„Qualität in Software“ – diesen Slogan habe ich vor Kurzem wieder gelesen. Nicht im Zusammenhang mit der PDS GmbH, aber es erinnerte mich sofort daran. Na, da hat die „Werbung“ wohl ihren Zweck erfüllt. 😀

Ich habe früher beim Unternehmen Spohr EDV-Systeme mit den PDS-Systemen arbeiten dürfen. Wenn ich jetzt zurückblicke, muss ich sagen, dass die Jungs damals schon verdammt weit waren – was ich damals natürlich nicht so wahrgenommen habe!

Na gut, die Umsetzung mancher Dinge war … na, sagen wir mal, funktional. 😀

Es gab da die OSIcom Box, zunächst nur eine kleine Kiste mit irgendeinem Mini-PC, auf dem – ich glaube – Linux SuSE lief. Man konnte dort eine Ferrari Fax ISDN-Karte einbauen. Diese Kiste sorgte für den Internetzugang und dafür, die anderen Standorte per VPN (war es Openswan?) anzubinden. Sogar ISDN-Verbindungen, Punkt-zu-Netz und Netz-zu-Netz, waren möglich.

Die eigentliche Warenwirtschaft, das Zeitmanagement und das Lagerverwaltungsgedöns – die haben alles gemacht, außer abspülen – lief auf SCO UnixWare. Zuletzt sogar auf SCO UnixWare 7.1.4 und später auf einem SuSE Linux Server. Alles noch aus der Terminalzeit. Zunächst mit einem FET-32-Client für Windows-Rechner, später dann mit einem in Java geschriebenen FET/X-Client.

Oh ja, es gab auch einen FTP-Server! Ich meine: ftp://ftp.pds.de/. Dort lag zum Beispiel das UnixWare 7.1.4 Maintenance Pack – zuletzt wohl MP4 – und ein riesiger Haufen Dokumentation.

Was aber richtig cool war: Die hatten schon damals Tablets! Es war so ein Skeye.Pad für den mobilen Kundendienst, sogar mit einem Infrarotdrucker. Damit konnten die Handwerker ihre Aufträge direkt beim Kunden bearbeiten. Sie haben Material, Zeiten und die Unterschrift des Kunden „eingesammelt“, und die Rechnung konnte noch geschrieben werden, bevor der Mitarbeiter wieder in der Firma war. Ich glaube, das Ding kam in einer blau-schwarzen Neoprenhülle.

Puh, jetzt habe ich hier wohl ordentlich Werbung gemacht, oder? Mich würde echt interessieren, wie weit die Jungs inzwischen gekommen sind. Technisch waren die schon damals ziemlich weit vorne, und auch die Hotline für Techniker war okay. Einer der beiden, mit denen ich oft zu tun hatte, schrieb immer mal wieder Leserbriefe für die c’t. Leider sind die Namen inzwischen wohl nach /dev/null ausgelagert worden. Mann, ist das lange her!

Wenn du, lieber Leser oder liebe Leserin, noch aktuell mit PDS arbeitest, würde ich mich über einen kleinen Austausch sehr freuen!

Unsichere Protokolle und Prüfsummen am Apache2 deaktivieren

Im Grunde könnte es mir ja fast egal sein, welche Protokollversion und/oder Prüfsumme der Client verwendet um mit dem Server zu sprechen. Ist es denn noch nicht. Der Client verbindet sich mit dem Server. Dabei teilt der Client dem Server mit was er kann, der Server tut dieses ebenfalls. Dann einigen sich beide auf ein Protokoll und eine Prüfsumme. Dabei kann der Server wie auch der Client sagen welches ihm denn am liebsten wäre. Wenn sich nun beide für etwas unsicheres entscheiden, gehen die Daten unsicher über die Leitung 🙁

Warum also nicht dem Server sagen er soll nur die „sicheren“ Protokolle anbieten? Dieses lässt sich recht schnell erledigen, indem man in seine Apache 2 Serverkonfiguration folgendes aufnimmt:

SSLProtocol -ALL +SSLv3 +TLSv1  
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT

Die einzelnen Optionen sind so schön benannt, dass man sich nicht mal mehr erklären muss, oder? Denn noch verlinke ich natürlich gerne hier hin: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Nachteile hat das ganze natürlich auch… Ältere Clients oder Systeme welche dummerweise kein passendes Protokoll / Chipher unterstützen, können keine verschlüsselte Verbindung mehr aufbauen. Meine Erfahrung zeigt aber, wenn man den Menschen die Möglichkeit gibt einfach durch die Sache zu kommen, machen sie es auch! Ich meine damit: „Solange es irgendwie funktioniert.“ Kümmert sich kaum jemand um ein Upgrade auch die Entwickler komme nicht aus dem Quark. Natürlich darf man nicht nach der Verabschiedung des neusten Standards die vorherigen fallen lassen…. Nur klar unsichere und seit Jahren überholte, die darf man dann schon mal los lassen (Windows XP *hust*).

Ach ja, möchte man einen Server testen gibt es mehrere Möglichkeiten. Am einfachsten ist sicher: https://www.ssllabs.com/ssldb/index.html Wer es lieber selbst auf der Konsole machen möchter, der freut sich sicher über sslscan http://sourceforge.net/project/showfiles.php?group_id=204329

 

 

 

Davdroid ownCloud sync

Über ownCloud selbst muss ich ja keine großen Worte mehr verlieren. Auch dass der Kontakte und Kalender Abgleich / Sync ganz prima über CalDAV sowie CardDAV funktioniert ist bekannt. Bei einem Android Handy kauft man sich einfach für einen super geringen Betrag die Apps CalDAV-Sync sowie CardDAV-Sync und gleicht so seine Kalender- und Kontakteinträge mit den Daten im ownCloud ab. Ich mache dieses seit bestimmt 1,5Jahren und bin absolut zufrieden damit, vor allem da ich über den gleichen Weg die Daten auch mit meinem Mailclient Evolution problemlos abgeglichen bekomme.

Selbst das freigeben, share, teilen (wie man will) klappt so 1A. Ich kann auf den Kalender meiner Frau schauen und sie auf meinen. So kommt man sich bei Planungen eher selten in die Quere.

Vor kurzem ist mir nun http://davdroid.bitfire.at/what-is-davdroid davdroid als kostenlose Version unter die Füße gekommen. Getestet und funktioniert genauso wie gewünscht. Damit geht es also ebenfalls in kostenlos!!!

Internal Server Error

Mal wieder etwas zum Thema: „Wenn man zu doof ist!

Ich schaue auf meine Webseite und sehe nur:

The server encountered an internal error or misconfiguration and was unable to complete your request….

 

Und die Kiste hat recht. Ich Wurst habe Grütze in meine .htaccess geschrieben. Diese Grütze habe ich aber nicht weiter kontrolliert. Da ich andauernd etwas darin herumwurste. MAN jetzt ärgere ich mich gerade über mich selbst 🙁

 

Nun gut, solche kleinen Dinge holen mich immer mal wieder schnell auf den Boden der Tatsachen zurück *danke*

 

 

 

Solaris 11 Shut Down / Herunterfahren Terminal

Ich habe heute einen Anruf eines befreundeten Sysadmins bekommen. Der arme muss darf heute bei einem seiner Kunden den Serveraum umziehen… Dafür möchte er nun die Systeme abschalten. Jetzt steht dort ein Solaris 11 System und der zum System gehörende Admin ist krank (zufällig am Feiertag des Serverraumumzuges…)! Jetzt steht mein Bekannter also vor der Konsole und will die Kiste im Grunde nur abschalten. Folgendes Gespräch ergab sich:

Bekannter: init 0 geht nicht, beim shutdown -h now soll -h eine unknown option sein. Ich bin genervt… Wie geht das aus?
Ich: Solaris 11 im poduktiveinsatz? Dann habt ihr auch Support von Oracle; anrufen / chatte die helfen immer sofort.
Bekannter: Laber nicht rum, ich bin hier für die Microsoft Maschinen. Keine Ahnung wo ich weh anrufen kann. Du kannst das doch, oder?
Ich: Joar… Folgendes sollte dir helfen:

$ shutdown -y -i5 -g0

Bekanter: *Klacker Tipper*
Ich: Root Konsole hattest du schon oder?
Bekannter: *Klacker* japp *Klacker*
Ich: shutdown ist shutdown, -y ist damit du nicht gefragt wirst -i5 ist um die Kiste nach dem Shutdown auch aus zu machen und -g0 ist das es unverzüglich gemacht wird.
Bekannter: Warum ist das so kompliziert? Geht das nicht einfacher? Bei Linux ist das doch einfach shutdown -h now… Man… Ich will eine Maus! Ahh ich glaube er fährt runter!
Ich: Du hättest mit man shutdown den korrekten Befehl erlesen können.
Bekannter: Ach, das muss einfacher gehen!
Ich: Ok dann nimmer das nächste mal den Befehl poweroff
Bekannter: Du Sack! Danke..

Ich finde es schon sinnvoll unterschiedliche Arten eines shutdown zu haben. Vor allem mit verschiedenen Arten der Signalisierung.

Firefox Pipelining

Die Pipeliningfunktion vom Firefox ist ein alter Hut, ja. Es ist ein so alter Hut dass man es schon fast wieder vergessen hat. Einmal im Firefox aktiviert schiebt es die Webseiteninhalte „gleichzeitig“ auf den Computer und somit gefühlt etwas schneller. Jetzt sind die Meisten ja irgendwann mal beim Google Chrome hängen geblieben und man muss einfach neidlos anerkennen: Das Teil ist rattenschnell….
Google…. Google ist toll aber wer ist bei Google die Ware? Genau wir! Nun blocken einige Benutzer ganz freudig Cookies im Browser um zumindest ein klein bisschen etwas gegen die Datensammelwut und das einblenden der „personalisierten“ Werbung zu tun. Da kommt Google und baut (ganz schlau) einen Weg ein den Benutzer denn noch zu packen: http://bits.blogs.nytimes.com/2013/09/19/google-is-exploring-an-alternative-to-cookies-for-ad-tracking/

Also doch wieder Firefox oder Midori oder oder?!?!? Japp :-/ Dann aber bitte mit Pipelining, damit es etwas flotter geht. Ach ja, so geht es an:

In der Adresszeile vom Firefox die Seite: about: config aufrufen und die Meldung mit: „Ja ja, ich bin vorsichtig“ abnicken (nein, nicht das Reh). Nun in der Suche einfach folgenden Begriff einwerfen: „pipelining“. Nun Sollten sich in der Anzeige nur noch ca. 11 Einträge befinden. Hier bei den unten stehenden Einträgen durch einen Doppelklick dafür sorgen das aus false ein true wird. Firefox schließen und fertig ist.

network.http.pipelining – true
network.http.proxy.pipelining – true
network.http.pipelining.ssl – true

Wenn man jetzt noch möchte kann man unter: Bearbeiten Einstellungen Erweitert Allgemein den Sanften Bildlauf / smooth scrolling deaktivieren. Viel Erfolg!

Zeitumstellung Sommerzeit / Winterzeit

Ok ok, dass die Zeitumstellung sinnfrei ist, habe ich vor Jahren schon verstanden und ist wohl inzwischen auch bei den meisten anderen „Betroffenen“ angekommen. Wie nervig es sein kann ist mir erst als Vater klar geworden. Ich habe zwar lange versucht meiner 14 Monate alten Tochter das Thema näher zu bringen… Es wurde aber ignoriert. 5:30 Uhr ist nun Action in der Bude!

Können wir das Thema Zeitumstellung bitte abschaffen? Also jetzt? Bitte? Es nervt!

 

 

IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target
Illustration eines IPv6-Netzwerks mit Kernel-Logmeldung „rt6_redirect: source isn't a valid nexthop for redirect target“. Ein ICMPv6-Redirect verweist fälschlich von einer Link-Local-Adresse auf eine globale IPv6-Adresse als Next Hop, was vom System abgelehnt wird.

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

  • das Target (Zieladresse, für die das Redirect gilt)
  • den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

  • stammt das Redirect von einem Router, den ich bereits als Router kenne?
  • liegt der vorgeschlagene Next Hop auf demselben Link?
  • ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
  • passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

  • falschen Router-Konfigurationen
  • kaputten RA-Setups
  • Bridge-/VM-Konstrukten mit „kreativem“ IPv6
  • trivialen Redirect-Spoofing-Angriffen

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

  • Default- oder interne Routen ohne Link-Local-Next-Hop
  • Router, die globale Adressen in Redirects verwenden
  • Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑