Debian/Ubuntu bootet nicht, da das Root Device nicht gefunden werden kann

Hallo,

häufig habe ich gesehen, dass User nach dem Kompilieren eines eigenen Kernels auf das Problem stoßen, dass das System nicht mehr bootet. Im speziellen tritt das Problem bei User auf, bei denen das Root device nicht auf einem SATA,SCSI oder SAS befindet, oder aber der Chipsatz spezielle Treiber braucht. So auch bei mir.

Mein Server bootet von einem USB3 Stick, so dass beim Booten schon das XHCI Modul verfügbar sein muss. Ein typischer Indikator ist die Meldung:

Dropping to shell!
modprobe: module ehci-orion not found in modules.dep

2016-03-04 13_18_41-Photo Station 6

Hierzu einfach beim Kompilieren die USB Module, oder aber Chipsatz-Module in den Kernel mit aufnehmen. Beim aus führen von make menuconfig einfach die benötigten Treiber mitkompilieren (als Beispiel USB Block Treiber).

Device Drivers –> USB Support

2016-04-10 11_40_0 2016-04-10 11_40_50 2016-04-10 11_41_15

 

[VIDEO-HOWTO] Windows 10 auf einem T60 mit ATI X1400 Mobility Grafikkarte

Heute gibt es ein Video von mir. Ich möchte Euch zeigen, dass Ihr auch auf alter Hardware immer noch Windows 10 laufen lassen könnt.  Im speziellen geht es um ein Thinkpad T60, welches die ungeliebte Grafikkarte ATI X1400 verbaut hat.

Hier könnt Ihr den gepatchen Treiber herunter laden. Bei der Installation müsst Ihr allerdings die Treibersignatur deaktivieren.

 

Falls Ihr, wie auch ich, Probleme nach dem Booten mit einem Schwarzen Bildschirm habt, müsst Ihr den “Fast Startup” abschalten. Eine detaillierte an Anleitung gibt es hier.

OpenmediaVault, J1900 und der Kernel 4.4

Nach vielen Problemen mit dem 3.16 er Debian Backport Kernel, hatte ich mich im Dezember 2015 dazu entschieden mein NAS auf den 4.x Kernel zu heben. Die war jetzt doch ein längerer Prozess, da es mir einfach nicht gelingen wollte einen Kernel zu bauen welcher von USB bootet.

Es gibt zwar einige Anleitungen wie man den Kernel baut, im speziellen auch für OpenMediaVault, doch leider beinhalten diese keinen USB ohci Treiber. Das System bleibt dann mit folgendem Fehler beim Booten hängen:

modprobe: module ehci-orion not found in modules.dep

2016-03-04 13_18_41-Photo Station 6

Das Problem liegt darin, dass das System das Root-Device nicht findet. Ich boote mein NAS von einem USB Stick am USB3 Port. Nachdem ich nun die USB Storage Module fest im Kernel mit-kompiliere bootet das System auch wieder.

Gerne Stelle ich Euch noch meine “Kernel” für OMV zur Verfügung!

linux-image-4.4.1-amd64_06+custom+fts_amd64.deb

linux-headers-4.4.1-amd64_06+custom+fts_amd64.deb

Installiert werden diese dann mittels des Befehls:

dpkg -i linux-image-4.4.1-amd64_06+custom+fts_amd64.deb linux-headers-4.4.1-amd64_06+custom+fts_amd64.deb

Hier noch ein link zu meinem Kernel-Ordner

Openmediavault Kernel

Bei Kernelversionen > 3.10 (Version 3) und Kernel Versionen > 4.1.6 musste ich mit dem Argument “intel_idle.max_cstate=1” arbeiten. Hierbei steigt jedoch die Stromaufnahme an. Das Setting muss in “/etc/default/grub” eingepflegt werden oder im Bios.

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

ersetzen mit:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"

anschließend
update-grub

 

 

Langsamer ssh login

Heute habe ich mich gefragt, warum der Login auf einem durchaus schnellen i5 ssh Server mehrere Sekunden benötigt, bis die Passwort abfrage kommt.

Zuerst einmal habe ich versucht herauszufinden woran es hackt:

ssh -vvv username@hostname
OpenSSH_5.8p1 Debian-1ubuntu3
...
...
...

Im Anschluss habe ich geschaut woran es hackt und habe dann auf dem Server den Versuch der Namensauflösung gesehen.
Als ich die Namensauflösung abgeschaltet hatte war es dann auch wieder schnell.

Hierzu einfach in die sshd_config folgendes eintragen:

UseDNS no

Im Anschluss dann noch ein

service ssh restart

Ab sofort sollte der Login wieder schnell sein!

bash –> Highlighting in der Konsole

Wenn man viel auf der Konsole unterwegs ist, ist es schön, wenn verschiedene Files hervorgehoben sind. Das ist einfach zu bewerkstelligen innerhalb der bash.

nano ~/.bashrc

Hier nun folgendes einfügen:

alias ls='ls --color=auto'

Neu einloggen und schon ist die Konsole nicht mehr so trist.

Postfix als Inbound Relay

Da ich aktuell einige Server auf IPv6 only umstelle kam ich nicht herum einen IPv4 to IPv6 Mail Gateway aufzusetzen. Um so wenig overhead zu habe als möglich, habe ich mich entschieden einen Postfix Server + RBL + Spamcheck aufzuseten.

Vorausgesetzt Ihr habt schon postfix installiert geht es dann wie folgt weiter:

nano /etc/postfix/main.cf

#am Anfang einfügen
#permit_auth_destination = yes
transport_maps = hash:/etc/postfix/transport
relay_domains = hash:/etc/postfix/transport
relay_recipient_maps = hash:/etc/postfix/recipients
unknown_relay_recipient_reject_code = 550
smtpd_client_restrictions = permit_sasl_authenticated,
        permit_mynetworks,
        reject_unauth_destination,
        reject_unlisted_recipient,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org

Im Anschluss werden dann die Transport-Regeln und Empfänger definiert.

nano /etc/postfix/transport

#Ip in Klammer sorgt für direkt Zustellung, Ohne Klammern wird ein MX lookup ausgeführt

liebeskleineshaus.de    smtp:[xxx.xxx.xxx.xxx]:14506
kindgerechte-grundschule-herrlingen.de  smtp:[xxx.xxx.xxx.xxx]:14506

nano /etc/postfix/recipients

#Inhalt der Datei
#@liebeskleineshaus.de OK     #accepts all 
info@liebeskleineshaus.de OK  #accepts only info@

Jetzt muss nur noch die für Postfix lesbare Datenbank erstellt werden:

postmap /etc/postfix/transport
postmap  /etc/postfix/recipients

service postfix reload

Jetzt fehlt nur noch der Spam check. Dieser wird wie folgt installiert & konfiguriert:

apt-get install spamassassin 

nano /etc/default/spamassassin
#Hier nun enabled=1

nano /etc/postfix/master.cf

#Unterhalb von 
#smtp      inet  n       -       -       -       -       smtpd
#folgendes einfügern:
   -o content_filter=spamassassin


service postfix restart

Das wars, das inbound relay funktioniert jetzt 🙂

CentOS, VestaCP und PHP7

Angesichts des Release von PHP7 habe ich mich heute spontan entschlossen, einen meiner Server auf PHP7 upzudaten.

Unter CentOS geht es mittels des REMI Repositories sehr einfach. Vorausgesetzt ihr habe PHP vorher auch damit installiert.

Kleiner Schweif zu Seite, falls Ihr das REMI Repsoitory noch nicht in euren Repositorys habt, hier ein HowTo in englisch.

So nun geht es aber los:

yum --enablerepo=remi update remi-release
yum --enablerepo=remi-php70 update php\*

Und das war es dann auch schon! Viel Spaß!

 

Cloudflare, ein kostenloser Reverse Proxy für IPv6 only Servers

512px-World_IPv6_launch_badge.svgAm 12. Januar 2012 war der offizielle “IPv6 launch day”. Seit nun fast 4 Jahre bieten immer mehr Provider IPv6 an. Der gorße Vorteil von IPv6 ist offensichtlich, so dass die Anzahl der Adressen gigantisch ist. Mit IPv6 fällt auch das altbekannte NAT (Network Address Translation) weg.

Jedes Gerät, kann jetzt eine eindeutige IPv6 Adresse erhalten. Diese Adresse kann dann auch im Router (ggf. Fritzbox) geroutet werden, so dass diese öffentlich im Internet verfügbar ist. Speziell wenn man zu Hause eine Webserver auf einer Raspberry Pi bertreiben möchte oder aber um Kosten zu sparen einen IPv6 Only VPS betreibt benötigt man eine preiswerte/kostenlose Lösung.

Alles in allem ist IPv6 ein saubere Sache, wären da nicht noch einige IPv4 ONLY Nutzer im Netz unterwegs. Jetzt beginnt das eigentliche Problem. Da die Webseite auch für diese Benutzer erreichbar sein muss bietet sich folgendes Setup an.

ipv4_ipv6_reverse_proxy

Um einen Reverse Proxy zu betreiben hat man nun die Wahl entweder einen Dienst in Anspruch zu nehmen, oder aber selbst auf einem Server eine nginx Server zu Hosten. Der Einfachheit halber möchte ich auf Cloudflare als Reverse Proxy & DNS Provider verweisen. Dieser Dienst ist kostenfrei und bietet zudem weitere Features wie kostenloses ssl Zertifikat, Auto Minify von Javascript …

[embedyt] http://www.youtube.com/watch?v=9SKrTDUM48A[/embedyt]