Posts Tagged ‘Migration’

Samstag, 14. Oktober 2017

Wenn eth0 plötzlich enp1s0 oder ähnlich kryptisch heisst

Link zu diesem Artikel

Heute habe ich einen meiner Lenovo-„Server“ ausgetauscht: T400 raus, T420 rein. Dabei habe ich die SSD vom alten Server in den neuen Server eingebaut — bei Windows ein Ding der Unmöglichkeit, bei Linux: Läuft bei mir (fast).

Leider gab es ein gravierendes Problem, was die Downtime etwas verlängert und an meinem Ehrgeiz gekratzt hat: Die Netzwerk-Interfaces kamen nicht hoch, weshalb das Gerät ohne Intra- und Internet-Verbindung dastand.

Dank Laptop-Tastatur und -Bildschirm fiel immerhin das Debugging leicht.

Die Ausgabe von ifconfig zeigte, dass nur das Loopback-Interface vorhanden war. Was zum Teufel? Den Ethernet-Netzwerkanschluss sah ich mit meinen eigenen Augen vor mir, ein Kabel war eingesteckt und er blinkte auch fröhlich vor sich hin.

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 184819  bytes 33744666 (32.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 184819  bytes 33744666 (32.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mit dem Befehl ip a dann die Gewissheit, dass die erwarteten Schnittstellen auch tatsächlich da waren:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.10/24 brd 10.10.10.255 scope global enp1s0
       valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Wie sich herausstellte, hiess auf dem T420 die Netzwerkschnittstelle nicht wie erwartet und üblich eth0, sondern enp1s0.

Der Grund (bitte nicht lachen): Predictable Network Interface Names. Verursacht durch die Datei /etc/udev/rules.d/70-persistent-net.rules, welche bei der Installation auf dem T400 erstellt worden war. Linux fand die darin definierten Interfaces auf dem T420 nicht mehr.

Die Lösung des Problems fand sich in einem Benutzerforum zum Thema How to rename network interface in 15.10?.

An der Originaldatei …

...
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:11:11:11:11:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
...

… nahm ich folgende Anpassung vor:

...
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth0"
...

Wichtig: 11:11:11:11:11:11 ist die MAC-Adresse des Ethernet-Interfaces auf dem T400, 00:00:00:00:00:00 ist die MAC-Adresse des Ethernet-Interfaces auf dem T420. Als ich zuerst nur die MAC-Adresse geändert habe, kam die Netzwerkschnittstelle nicht hoch. Erst die Verschlankung des Eintrags auf die obige Form funktionierte: Nach dem nächsten Reboot war eth0 wieder vorhanden und alle Netzwerkdienste kamen hoch.

Nachtrag

Die Herleitung des kryptischen Namens ist hier erläutert: Why is my ethernet interface called enp0s10 instead of eth0?.

enp1s0 bedeutet also:

  • en Ethernet
  • p1 Bus (hier: 1)
  • s0 Slot (hier: 1)

Nachtrag 2

Auf einem jungfräulichen Debian 11 Bullseye System musste ich gestern /etc/udev/rules.d von Hand erstellen.

Dementsprechend fehlte auch /etc/udev/rules.d/70-persistent-net.rules. Obwohl im Internet stand, dass man mit dem Befehl

# /lib/udev/write_net_rules

die benötigte Datei erstellen könne, fehlt auf meinem System dieser Befehl (ich konnte das Script auch in keinem Debian-Paket finden — komisch). Ich erstellte deshalb /etc/udev/rules.d/70-persistent-net.rules kurzerhand von Hand, startete das System neu, und es funktionierte.

Übrigens: Die Verwendung deterministischer Interface-Namen könnte man auch mit einem Kernelbefehl in /etc/sysctl.conf verhindern: net.ifnames=0

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 5. Februar 2016

Einen UniFi Controller von einem Server auf einen anderen migrieren

Link zu diesem Artikel

Mit Blick auf den Mitte Januar 2016 bestellten Glasfaser-Anschluss von Fiber7 habe ich mich entschieden, das heimische WLAN aufzurüsten (nicht zuletzt, weil ich den Router wegen des Glasfaseranschlusses in der Stube nicht am selben Ort betreiben möchte wie den Wireless Access Point). Hierzu habe ich die WLAN-Funktionalität meines Asus RT-AC66U deaktiviert und mir danach einen Ubiquiti UniFi AP-Pro n450 angeschafft, mitsamt eines PoE-Switches von TP-Link.

Eine Besonderheit des UniFi-Access Points ist es, dass er selber keine Web-Oberfläche zur Konfiguration anbietet, wie es Consumer-Geräte sonst tun (auch eine Router-Funktionalität sucht man vergebens). Stattdessen benötigt man den sog. UniFi Controller, eine auf Java und MongoDB basierende Software, die auf einem Rechner im heimischen LAN installiert werden muss. Die Software muss übrigens nicht ständig laufen — wenn man die Konfiguration des APs abgeschlossen hat, benötigt der AP keine ständige Verbindung mehr zum Controller. Ich entschied mich gegen diese Lösung, da ich den Controller jederzeit zugriffsbereit und funktionstüchtig haben möchte — man weiss ja nie. Ausserdem zeichnet die Software in dem Modus Vitalparameter des APs und der WLAN-Netzwerke auf.

Zuerst hatte ich den UniFi Controller auf meiner „Workstation“, einem Mac mini, installiert, welcher ständig läuft. Da mir dabei nie wirklich wohl war, entschied ich mich, den alten Raspberry Pi 1 auszugraben und den Controller darauf zu installieren. Das ist insofern etwas weniger trivial als bei einem x86-Server, weil die ARM-CPU andere Softwarepakete benötigt (insbesondere MongoDB). Ich habe es dank Anleitungen im Internet trotzdem hingekriegt (das Material wird dereinst zu einem eigenständigen Blog-Artikel verwurstet). Da ich anschliessend auch Smokeping auf dem Raspberry Pi installierte und mir die Performance zur Generierung der RRDtool-Graphen überhaupt nicht mehr reichte, entschied ich mich diese Woche, auf einen (gebrauchten) Intel Next Unit of Computing NUC DC3217IYE zu migrieren. Mitkommen sollte auch der UniFi Controller.

Da ich das Spielchen bereits einmal gemacht hatte, hier die im Grunde recht triviale Anleitung (Kurzfassung):

  1. In den alten UniFi-Controller einloggen und unter Settings > Maintenance > Backup > Download Backup ein aktuelles Backup herunterladen
  2. Den neuen UniFi-Controller auf dem neuen Server installieren (Anleitungen für Raspberry Pi und Debian folgen dereinst)
  3. Mit dem Browser auf den neuen UniFi-Controller verbinden
  4. Auf dem Homescreen des neuen UniFi-Controllers im Abschnitt „Alternatively you can restore from a previous backup“ die soeben generierte Backup-Datei auf „Choose File“ ablegen und warten (auf dem Raspberry Pi dauerte das Einlesen des Backups mehrere Minuten, unter dem NUC wenige Sekunden)
  5. Login auf den neuen UniFi-Controller — WLAN sollte Rot leuchten
  6. Login auf den Server des alten UniFi-Controllers und diesen Controller stoppen (service stop unifi)

UniFi Controller Import Backup

Soweit so gut. Als nächstes muss man sich per SSH auf den Access Point verbinden — bei mir völlig ohne Interaktion, da ich den Access Point mit meinem SSH Public Key ausgestattet habe:

$ ssh unifi

Anschliessend startet man das CLI des lokalen Management Utility:

# mca-cli

Dort gibt man folgenden Befehl ein:

$ set-inform http://10.0.1.12:8080/inform

Wechselt man nun in den Browser zur Web-Oberfläche des neuen UniFi-Controllers, leuchtet WLAN grün — der Access Point wurde in der Zwischenzeit erkannt.

Voila, that’s it!

PS Eins: In Anleitungen im Netz liest man gelegentlich, dass man den AP im Web-GUI noch „adoptieren“ und danach noch einmal den set-inform-Befehl ausführen müsse — bei mir klappte dies auch ohne.

PS Zwei: Der alte UniFi-Controller lief unter 4.7.6, der neue läuft unter 4.8.12. Beim Import der Backup-Konfiguration gab es keine Probleme.

Tags: , , , , , , , ,
Labels: IT

5 Kommentare | neuen Kommentar verfassen

Donnerstag, 15. August 2013

libapache2-svn unter Apache 2.4 zum Laufen bringen

Link zu diesem Artikel

Da führt man zu Monatsbeginn auf dem heimischen Linux-Server vor lauter Blödheit ein

# apt-get dist-upgrade

durch und sieht sich plötzlich mit Apache 2.4 konfrontiert.

Nachdem man die Zugriffsprobleme mit IP- und Host-basierten Regeln in allen .htaccess-Dateien behoben hat, realisiert man erst, dass der Web-Server nicht starten will, weil das DAV-Modul „svn“ nicht mehr gefunden wird:

Unknown DAV provider: svn

Was zum Geier?

Die Ursache des Problems ist rasch gefunden: Das Paket libapache2-svn hat eine Abhängigkeit vom Paket apache2.2-common, doch mit Apache 2.4 hat letzteres Paket seine Daseinsberechtigung verloren und ist folglich nicht mehr auf dem System vorhanden. Zu allem Unglück hinzu unterstützt Subversion in der Debian-Version 1.6.17dfsg-4+deb7u3 Apache 2.4 gar nicht.

Nach längerem Herumsuchen im Internet komme ich zum Schluss, dass wirklich nichts an der auf Stackoverflow herumgebotenen Lösung vorbeiführt: Ich muss Subversion doch tatsächlich in der derzeit aktuellen Version 1.7.9 (Debian: 1.7.9-1+nmu3) aus der Quelle kompilieren und danach auf dem System installieren. Diese Version kennt und unterstützt Apache 2.4.

Nachfolgend eine rudimentäre Anleitung, welche sich an den Stackoverflow-Artikel anlehnt.

Anleitung

Zuerst benötigen wir folgende Pakete, um Subversion gegen das aktuell installierte Apache 2.4 kompilieren zu können:

# apt-get install apache2-dev
# apt-get build-dep subversion

Bei mir war anschliessend noch manuell die Installation von folgendem Paket nötig:

# apt-get install libserf1 libserf-dev

Jetzt geht es an das Herunterladen des Subversion-Quellcodes:

$ cd /tmp
$ apt-get source --compile subversion
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
... (Ctrl+C)

Richtig gelesen: Während das Teil vor sich hinkompilieren will, bricht man die Durchführung mittels Ctrl+C ab. Denn zuerst sind noch einige kleinere Anpassungen an den Kompilierungseinstellungen nötig, damit man am Ende nicht nur mit Subversion, sondern auch mit einem Paket libapache2-svn dasteht.

In /tmp/subversion-1.7.9/debian/rules ändert man dazu folgenden Wert:

ENABLE_APACHE        := yes

Und in /tmp/subversion-1.7.9/debian/control fügt man zuunterst folgenden Text ein:

...

Package: libapache2-svn
Section: httpd
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: db5.1-util
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Schlussendlich startet man die Kompiliererei erneut, verzichtet dieses Mal aber mit dem Attribut DEB_BUILD_CONFIG, dass nach der Kompilierung stundenlang Tests durchgeführt werden, diese scheitern und man nach dem Warten auf Godot ohne .deb-Pakete dasteht (via DEB_BUILD_OPTIONS=nocheck):

$ cd /tmp/subversion-1.7.9/
$ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -b -uc

Anschliessend installiert man die folgenden drei Pakete:

# dpkg -i /tmp/libsvn1_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/libapache2-svn_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/subversion_1.7.9-1+nmu3_i386.deb

Schlussendlich muss man in Apache unter /etc/apache2/mods-enabled noch die folgenden Module aus /etc/apache2/mods-available symlinken, wenn sie nicht schon dort sind:

  • authz_svn.load
  • dav_svn.conf
  • dav_svn.load

Dann noch das obligate …

# /etc/init.d/apache2 restart

… und gut is!

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. August 2010

Rückschaffungs-Leerlauf

Link zu diesem Artikel

Wer sich bezüglich der Ausländer- und Migrationspolitik der Schweiz eher zum rechtsbürgerlichen Lager zählt, sollte sich zwingend moussemans Blog abonnieren. Da liest man zum Wochenende dann Dinge wie die hier:

Es wäre vermutlich billiger, eine alte C-130 Hercules zu kaufen und so umzurüsten, dass der Pilot, sobald er über dem Zielland ist, einfach die Ladeklappe aufmachen kann und dann alle auszuschaffenden Ausländer abwerfen kann, samt den alten T10-Fallschirmen, die dank der fürsorglichen Pflege in der Schweizer Armee noch perfekt funktionieren sollten. Da die T10-Fallschirme auch locker 200 Kilo Last sicher nach unten bringen, kann man mit einem solchen Fallschirm auuch zwei Personen runterbringen und so noch weiter Geld sparen.

Quelle: Für solche Passagiere gibts die Heckladerampe und T10-Fallschirme | Snoop InfoSystems

Nun, ob das die Lösung unserer Ausschaffungsprobleme ist, muss jeder Bürger für sich selber beurteilen.

Wobei ich mich sogar als Sozialdemokrat fragen muss, wieso unsere Bundesbeamte a) ein Flugzeug chartern, b) die Auszuschaffenden darin festzurren, c) nach Gambia fliegen — um dann von den dortigen Behörden keine Landeerlaubnis zu kriegen und in der Luft wieder umzukehren. Da tun die verpufften Steuergelder sogar mir weh.

Übrigens: Ein Bekannter, mit der Materie etwas besser vertraut, hat denn auch prompt vorgeschlagen, statt den Asylbewerbern die Abreise mit 5000 CHF zu versüssen das Geld doch besser auf das Konto eines korrupten Beamten vor Ort zu überweisen. Das wirke — wohl auch bezüglich Landeerlaubnissen — Wunder …

Tags: , , ,
Labels: Politik, Schweiz

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 10. Februar 2010

Deutsche Secondos in der Schweiz

Link zu diesem Artikel

Der Anpassungsdruck – und da streifen wir die aktuelle Diskussion – ist für Deutsche einiges grösser als für die Einwanderer siehe oben. Zumindest war der Anpassungsdruck in den fünfziger und sechziger Jahren recht stark.

Meine Lederhosen, mit denen ich eingewandert bin, wurden bald einmal entsorgt und gegen schwarze kurze Hosen aus Manchester getauscht, was wiederum meinen Vater irritierte, hatte er doch dieses Modell in der Hitlerjugend getragen.

Quelle: arlesheimreloaded-manfred-messmer – Deutscher Secondo

Und das Lustige wird bald einmal Ernst, wenn man dann hier vorbeikommt:

Nein, wir Deutsche sind anders. Wir haben andere Familiengeschichten, sind auf eine ganz andere Art Europäer. Nämlich nicht mit Abseitsstehen, sondern immer mitten drin in der Geschichte.

Ehrlich und direkt — das gibt ihm gleich ein paar zusätzliche Imagepunkte, diesem Mani Messmer.

Tags: , , ,
Labels: Funny, Schweiz

Keine Kommentare | neuen Kommentar verfassen

Freitag, 13. November 2009

Köppel ist definitiv reif für den Vaterschaftsurlaub

Link zu diesem Artikel

Köppels Editorial in der Weltwoche 46.09 kann man ja nun wirklich kaum ernst nehmen — ich würde es als klaren Tiefpunkt in der Geschichte der Köppelschen Weltwoche klassifizieren:

Die vielen Ausfälle, Pannen und Verspätungen der SBB in letzter Zeit sind nicht das Resultat von schlechtem Management, sondern werden durch Übernutzung und Überlastung verursacht.

Quelle: Editorial: Zuwanderung, Weltwoche 46.09, S. 5.

… … …?! Habe ich jetzt richtig gelesen? Köppel zeigt Verständnis für die SBB? Einen Staatsbetrieb?! Zugleich entlässt er das SBB-Management aus jeglicher Schuld — obwohl einige Medien in letzter Zeit darüber berichtet haben, dass es gerade dieses „Management“ verpasst habe, rechtzeitig und in ausreichendem Mass in den Werterhalt der Infrastruktur zu investieren?

Er erwähnt auch die Staus auf den Autobahnen, um zu folgern, dass das Land übervölkert sei. Nun, Staus und Komplikationen im Zugsverkehr gründen nicht zuletzt doch gerade darauf, dass Leute von Köppels Weltauffassung seit jeher den Steuerwettbewerb zwischen den Gemeinden und Kantonen loben. Dies führt konsequenterweise dazu, dass man eben nicht in der Stadt, sondern auf der grünen Wiese sein Häuschen errichtet, mindestens zwei PKWs anschafft und in Zukunft frisch-fröhlich 10-20 Kilometer auf die Arbeit in die Stadt pendelt.

Hat nicht die Weltwoche gerade in der letzten Ausgabe die 150 besten Gemeinden gekürt und dem Ranking eine möglichst tiefe Steuersatz als Hauptkriterium zu Grunde gelegt? Der Verkehrskollaps ist ein Resultat dieser unsinnigen optimalen Fokussierung auf Dinge, die wirklich zählen im Leben! Wer will schon in 5 Minuten auf der Arbeit sein, wenn er alleine in seinem 3 Meter langem, 2 Tonnen schweren Gefährt eine Stunde im Stau stehen kann? Hauptsache, er bezahlt weniger Steuern.

Thomas Held, Chefdenker des Think Tanks Avenir Suisse, verwies in einer Fernsehdiskussion zum Thema kürzlich auf die japanische Metropole Tokio. Will die Schweiz mit ihren sperrangelweit geöffneten Grenzen zum europäischen Pendant eines asiatischen Models werden?

Herr Köppel, schauen sie, ein Rat unter Freunden: Möchten Sie den Chefredaktorposten nicht lieber abgeben und künftig einen mittelmässigen Blog führen? Ihre Recherchefähigkeiten stempeln Sie zu einem völlig inkompetenten Journalisten.

Zugegeben, Tokio ist eine Millionenstadt — als Moloch würde ich die Hauptstadt Japans aber dann doch wieder nicht bezeichnen. Abgesehen davon sollte die japanische Migrationspolitik gerade Sie zu impulsiven Freudentänzen verleiten: Ist es nicht Allgemeinwissen, dass die Japaner in Asien wohl die rigideste Migrationspolitik verfolgen (abgesehen vielleicht von Nordkorea), um ihr Volk und ihre Kultur möglichst homogen zu halten?

Und hier hat Sie dann wohl ihr Baby vom Beenden des Satzes abgehalten:

… Trotz komfortablen Mehrspurtunneln staut sich der Verkehr. Da es an bebaubaren Zonen fehlt, wurden seelenlose Wohnquartiere. Thomas Held, …

Hä?

Tags: , , , ,
Labels: Medien, Politik

1 Kommentar | neuen Kommentar verfassen