Schlagwort-Archive: Arch Linux

BitBastelei

BitBastelei #277 – PXE: PCs ohne HDD über Netzwerk starten (Arch, ISOs, etc)

Schreibe einen Kommentar
BitBastelei #277 - PXE: PCs ohne HDD über Netzwerk starten (Arch, ISOs, etc)

(311 MB) 00:41:34

2018-03-25 10:00 🛈

Wenn man einen PC startet lädt dieser das Betriebssystem von der internen Festplatte oder SSD – oder bei Installationen von einer CD bzw. einem USB-Stick. Fast alle modernen PCs beherrschen aber noch eine Methode: PXE. Hiermit lassen sich Rechner ganz ohne lokale Medien von einem zentralen Server starten. Dies kann z.B . eine NAS oder ein OpenWRT-Router sein. Mit passenden Menüs hat man so alle gängigen Rettungssysteme und Installationsmedien immer zur Hand und muss nicht die passenden Sticks suchen.

Weiterführende Links:

Restmüll, Software

Linux: Gerät wacht nach Suspend sofort wieder auf

Ein Kommentar

Narf. Akku leer. Nur warum?
Tja, mein Laptop hatte sich entschieden nach meinem Klick auf „Suspend“ sofort wieder aus dem Standby-Modus aufzuwachen. Reproduzierbar. Erste Vermutung: Die GUI ist Schuld. Wie immer. Aber auch ein systemctl suspend zeigt nicht wirklich eine Besserung. Auch die Logs zeigen nichts verwertbares. Na dann graben wir etwas tiefer:

Erst mal zur Klarstellung: Standby funktioniert – der Laptop schaltet die Geräte aus, die Power-LED blinkt wie erwartet, doch nach knapp einer Sekunde wacht wer direkt wieder auf. Entsprechend des Fehlers dürfte also die Aufwachquelle am ehesten Verantwortlich sein. Eine Liste aller Quellen findet sich in /proc/acpi/wakeup:

# cat /proc/acpi/wakeup
LID	  S4	*enabled  platform:PNP0C0D:00
SLPB	  S3	*enabled   platform:PNP0C0E:00
IGBE	  S4	*enabled   pci:0000:00:19.0
EXP2	  S4	*disabled  pci:0000:00:1c.1
XHCI	  S3	*enabled   pci:0000:00:14.0
EHC1	  S3	*enabled   pci:0000:00:1d.0

Die Liste sieht natürlich je nach Verbauter Hardware anders aus, hier die Zuordnung meines Gerätes: 

LID -> Laptop-Deckel
SLPB/SBTN -> Standby-Button
IGBE -> Integrated Gigabit Ethernet
EXP2 -> ??
XHCI -> USB3
EHC1 -> USB(1/2)

Wie wir sehen können diverse Geräte ein Aufwachen verursachen, lediglich EXP2 ist nicht aktiv. Um das Ganze einzugrenzen heißt es also nun: Aufwachquelle abschalten, Suspend testen und hoffen, dass es was bringt. Über ein gezieltes echo kann der Zustand zwischen enabled und disabled gewechselt werden:

echo LID > /proc/acpi/wakeup

In meinem Fall stellte sich USB als Fehlerteufel heraus. Offenbar störte sich das System an einem USB-Stick – egal ob gemountet oder nicht. Wie auch immer, USB brauche ich ohnehin nicht zum aufwachen, Deckel und/oder Power-Button sollten ausreichen. Den „bösen“ USB schalte ich beim Boot per Script nun ab.

AVR

Arch Linux / Arduino: libtinfo.so.5 fehlt

Ein Kommentar

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/archarduino-300×58.pngBei der Nutzung der Arduino-IDE kommt es zur Zeit unter Arch Linux zu Problemen in Zusammenhang mit AVR-Boards. Ursache ist, dass Arduino seit einigen Versionen nicht mehr die Tools des System nutzt, sondern auf vorkompilierte Binärdateien setzt. Diese Alles-dabei-Conteiner versprechen auf den ersten Blick eine Vereinfachung, fliegt aktuell leider etwas auseinander: Die beigelegten Programme sind an vielen Stellen gegen überholte Bibliotheken gebaut. Dies verschafft zwar Kompatibilität mit trägen Systemen wie z.B. Debian, macht eine Nutzung mit aktuellen Systemen umständlich.

Schaut man sich die Fehlermeldung genauer an findet man schnell heraus, dass der beigelegte avrdude die Probleme auslöst:

avrdude: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or director

Libtinfo wurde zwischenzeitlich wohl in Ncurses übernommen, zudem benötigt Arduino/avrdude eine ältere, normalerweise nicht mehr installierte API der ncurses-Library.

Wer die Libraries passend haben möchte muss zuerst ncurses5-compat-libs installieren um die alten API-Versionen nachzurüsten, im Anschluss sorgt das Dummy-Paket libtinfo dafür die alten Dateinamen auf ncurses umzubiegen.

Software

Arch Linux/Aur: stcgal zur Programmierung von STC 8051-Klonen

Schreibe einen Kommentar

stcgal ist ein in Python geschriebenes Tool um 8051-Nachbauten der Firma STCMicro zu programmieren. Die MCUs verfügen über einen seriellen Bootloader und kommen vor allem in Produkten und Bausätzen aus Fernost als günstige Zentraleinheit zum Einsatz.

Da mit sdcc und MCU 8051 IDE bereits ein großer Teil des Toolsets im Repo und auf AUR rumfliegt habe ich stcgal nun auch mal hinzugefügt, so kann man ohne großes Gefummel eine komplette Bastelumgebung aufsetzen.

Software

virt-manager/libvirt: Installation nicht möglich: virtlogd-sock

Schreibe einen Kommentar

Beim Erstellen einer neuen VM über virt-manager erhielt ich heute folgende Meldung:

Installation konnte nicht fertiggestellt werden: «Socket-Erstellung zu '/var/run/libvirt/virtlogd-sock' fehlgeschlagen: Datei oder Verzeichnis nicht gefunden»

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line 2288, in _do_async_install
guest.start_install(meter=meter)
File "/usr/share/virt-manager/virtinst/guest.py", line 461, in start_install
doboot, transient)
File "/usr/share/virt-manager/virtinst/guest.py", line 396, in _create_guest
self.domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python2.7/site-packages/libvirt.py", line 3777, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Socket-Erstellung zu '/var/run/libvirt/virtlogd-sock' fehlgeschlagen: Datei oder Verzeichnis nicht gefunden

Ursache ist das Logging, welches in einen eigenen Dienst ausgelagert wurde. Neben libvirtd muss nun auch virtlogd vor dem Start der VM geladen werden. Für systemd-Nutzer heißt das also…

systemctl start virtlogd
systemctl enable virtlogd

 

Software

Now fail already! Wenn der Browser über Umwege XOrg lahmlegt

Schreibe einen Kommentar

Ugh. Schon wieder. Das Rattern in der Ecke hat meist eine recht konstante Ursache: Die CPU meines Laptops läuft auf 100% und sorgt für ordentliche Lüfterdrehzahlen. Gehen wir mal auf Ursachensuche:

Bei CPU-Last ist erster Anlaufpunkt natürlich top/htop. In meinem Fall aber leider nicht sehr Hilfreich: Xorg sei der Verursacher. Weites Feld. Aus meiner Erfahrung geht dann der Blick erst mal auf die laufenden Programme. Nicht selten hat sich auf einer geöffneten Webseite eine Flash-Werbung, ein HTML5-Video oder sonstige zappelnde Dinge mit Nervfaktor versteckt und bringen das Rendering in Gang. Leider konnte ich dieses mal nichts finden. Auch der interne Taskmanager von Google Chrome zeigt – anders als in solchen Fällen üblich – keine auffällig hohen Lasten. Um sicher zu gehen halte ich per SIGSTOP alle UI-Programme kurz an – keine Änderung. Es ist also mit hoher Wahrscheinlichkeit keine Grafikausgabe, welche die Probleme auslöst.

Zurück zum Start. Wir wissen, dass Xorg die Last bringt, allerdings vermutlich nicht im Grafikbereich. Schauen wir uns top nochmal genauer an. Die Browser sind noch in SIGSTOP und entsprechend verschwunden. Hinter XOrg macht sich nun dbus breit. Dbus? Kurze Lastspitzen OK, aber Dauerlast? Ein Blick mit dbus-monitor bringt eine Wall-of-log zum Vorschein:

method call time=1462212788.744495 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744507 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=6 reply_serial=6
method call time=1462212788.744535 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gtk.vfs.Daemon'"
method return time=1462212788.744544 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=7 reply_serial=7
method call time=1462212788.744600 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0
method return time=1462212788.744611 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=8 reply_serial=8
   uint32 2
method call time=1462212788.744748 sender=:1.1259306 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.gtk.vfs.Daemon"
method return time=1462212788.744761 sender=org.freedesktop.DBus -> destination=:1.1259306 serial=9 reply_serial=9
   string ":1.1258771"
method call time=1462212788.744895 sender=:1.1259306 -> destination=:1.1258771 serial=10 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=LookupMount
   struct {
      array of bytes "/NAME@DOMAIN.org" + \0
      array [
         dict entry(
            string "query"
            variant                array of bytes "subject=blabla&body=blabla" + \0
         )
         dict entry(
            string "type"
            variant                array of bytes "mailto" + \0
         )
      ]
   }
error time=1462212788.745079 sender=:1.1258771 -> destination=:1.1259306 error_name=org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code15 reply_serial=10
   string "Der angegebene Ort wird nicht unterstützt"

…und das in Endlosschleife. Uhm, ja. mailto? Das sind üblicherweise Links in Webseiten oder Dokumenten um E-Mails zu versenden. Stimmt, ich hatte vor einigen Stunden auf einer Webseite einen Mail-Link angeklickt. Ohne Reaktion.

Offenbar hat sich die DE an eben diesem Maillink festgefressen. „Der angegebene Ort wird nicht unterstützt“. Kein Wunder, denn in den „Standardprogrammen“ ist für E-Mails nichts hinterlegt. Anstatt das Ganze aber einfach als Fehlschlag einzuordnen und abzubrechen wird die Aktion in Endlossschleife ständig wiederholt. Da auch Xorg an Dbus hängt (und offenbar nicht sonderlich effizient auf dessen Events reagiert) geht auch dieser in die Knie. Da ich auf die Schnelle keine Möglichkeit fand das dbus-event rauszuwerfen musste ein Dummy-Mailprogramm hinhalten. Event geht rein, Returncode kommt, Dbus gibt Ruhe. Warum nicht gleich so?

PC-Kram

[nvidia/qt5/kdenlive] Segfault on various KDE-software using NVIDIA 361.16

Schreibe einen Kommentar

Uhm crap. The last system update just pulled a new beta version of NVIDIAs binary driver. Usually not that much of a deal, I went for testing due to a bug in their stable driver some years ago and never ran into a problem. Well, at least until now.  This time the testing-curse found its way into my system and I found myself no longer able to start my video editor kdenlive. Segmentation Fault. I suspected my setup first since I am running a rather unusual multihead configuration but could also with just one monitor I ran into the same problem. Well, looks like I have to dig deeper. Some gdb later at least a clue:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
109	int XScreenCount(Display *dpy) { return (ScreenCount(dpy)); }
(gdb) bt
#0  0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
#1  0x00007fffea7f50da in glXGetClientString () from /usr/lib/libGLX.so.0
#2  0x00007ffff7fed3b3 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#3  0x00007ffff7fed5b1 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#4  0x00007ffff686fc7b in QSGRenderLoop::instance() () from /usr/lib/libQt5Quick.so.5
#5  0x00007ffff68a19e5 in QQuickWindowPrivate::init(QQuickWindow*, QQuickRenderControl*) () from /usr/lib/libQt5Quick.so.5
#6  0x00007ffff694b68d in QQuickView::QQuickView(QWindow*) () from /usr/lib/libQt5Quick.so.5
#7  0x00000000006bd190 in ?? ()
#8  0x00000000006c3d7b in ?? ()
#9  0x00000000007af3cc in ?? ()
#10 0x000000000046346b in ?? ()
#11 0x00007ffff188e610 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x0000000000463949 in _start ()

So XScreenCount or libGLX is the suspect. In my case GLX is provided by NVIDIAs binary driver (nouveau had limited multihead support last time I checked). Also some QT5-stuff is mentioned in the backtrace.

A bit of search engine voodoo later it turns out NVIDIA already acknowledged the problem. Aaron Plattner writes:

I reproduced the problem and tracked it down to this buggy code in Qt5’s qxcbglxintegration.cpp:

static bool vendorChecked = false;
    static bool glxPbufferUsable = true;
    if (!vendorChecked) {
        vendorChecked = true;
        const char *glxvendor = glXGetClientString(glXGetCurrentDisplay(), GLX_VENDOR);
        if (glxvendor && !strcmp(glxvendor, "ATI"))
            glxPbufferUsable = false;
    }

When this code is called during sddm-greeter startup, there’s no current GLX context, so this gets called with a NULL argument.

While here SDDM is not the problem I think kdenlive, which uses similar libraries, runs into the same problem. He also pushed a corresponding patch to NVIDIAs GIT-repository. Sadly the current HEAD is not 100% ABI compatible with the official driver release. Also I really didn’t want to get into my distributions xorg-packaging-foo. Ultimately I reverted to the current NVIDIA stable version 358.16 to get back into business. So – lesson confirmed: Beta releases can fix problems or cause problems. But who doesn’t like a bit of stability-gambling, right?

BitBastelei

BitBastelei #178 – HTTPs-Zertifikate mit Let’s Encrypt und Apache

Ein Kommentar
BitBastelei #178 - HTTPs-Zertifikate mit Let's Encrypt und Apache

(33 MB) 00:15:45

2016-01-03 11:00 🛈

Über den Dienst „Let’s Encrypt“ lassen sich seit einigen Wochen von allen Interessierten kostenlose X.509-Zertifikate anfordern. Diese können z.B. zum Betrieb von HTTPS-Webseiten genutzt werden. So lässt sich z.B. die heimische Owncloud-Installation schnell und einfach absichern.

Software

ArchLinux: Update sperrt root-Login per SSH

Schreibe einen Kommentar

Ouch – nicht schön. Nach dem Update einer remote-Kiste war der Login per SSH nicht mehr möglich. Schuld ist offenbar eine Änderung der SSH-Defaults: Während bisher der root-Login auch ohne explizite Angabe in der Konfiguration erlaubt war, muss dies nun in der Konfiguration mit einem PermitRootLogin yes manuell zugelassen werden. Sofern kein anderes Konto besteht heißt das nach einem Update dann: KVM oder Remote-Hands müssen her um den Eintrag zu setzen und den Server so wieder verwaltbar zu machen. Ein Hinweis vorab wäre natürlich einfacher gewesen :/.

Edit: Zu früh gemault: Im Announcement der OpenSSH-Leute ist die Änderung beschrieben, RTFM hätte also geholfen…

Potentially-incompatible Changes
—
[…]
* The default for the sshd_config(5) PermitRootLogin option has
changed from „yes“ to „prohibit-password“.

Software

Squid als Proxy-Server

Schreibe einen Kommentar

„Mein Internet ist kaputt“ – ich denke jeder 1st-Leveler kennt diese Aussagen. Bauchschmerzen bereiten sie spätestens dann, wenn auch man selbst nicht mehr ins Netz kommt. Proxy weg. In solchen Situationen muss schnelle Hilfe her. Mein erster Blick: Da steht noch ne Testkiste – zwar ist Arch Linux nicht unbedingt die erste Wahl für Produktivserver, welche möglichst wartungsarm sein sollen, aber besser als nichts. Bauen wir mal einen Proxy.

1. Squid installieren

Die Platzhirsch unter den Proxys dürfte ohne Frage Squid sein. Die GPL-Software kann sowohl als Caching als auch Reverse Proxy eingesetzt werden. Ich nutze nur die erste Funktion – Zugriffe der Benutzer sollen zwischengespeichert werden. Die Installation ist unter nahezu allen Distributionen mit wenigen Schritten über den Paketmanager möglich. In meinem Fall reicht ein „pacman -S squid“.

2. Zugriffs- und Speicherkonfiguration

Neben der Software wird auch eine Standardkonfiguration installiert, welche unter /etc/squid/squid.conf zu finden ist. Standardmäßig wird den privaten IPv4-Bereichen erlaubt auf die üblichen Ports für HTTP, FTP, Gopher, Wais und HTTPs zu verbinden. Sofern man keine restriktive Webzugriffslinie besitzt können diese Beispiele also übernommen werden. Einige Änderungen und Ergänzungen können allerdings Hilfreich sein:

# Keine Verbindung zu localhost - schuetzt ggf. falsch eingerichtete Webanwendungen auf dem Server
http_access deny to_localhost

#E-Mail-Adresse des Admins - so kommen die Beschwerden der Nutzer an die richtige Stelle
cache_mgr info@ad....fo

#Beim Stoppen des Dienstes 10 Sekunden darauf warten laufende Uebertragungen abzuschliessen
shutdown_lifetime 10 seconds

#Im RAM werden bis zu 4 GB als Cache genutzt
cache_mem 4096 MB

#Objekte mit mehr als 50MB werden nicht gecached
maximum_object_size 50 MB

# Bis 95% Fuellstand des Caches werden keine Objekte ersetzt
cache_swap_low 95

# Je naeher wir an 98% kommen desto aggressiver werden alte Objekte ersetzt
cache_swap_high 98

#Alles ueber 512kb wird nicht im RAM sondern nur auf HDD gespeichert
maximum_object_size_in_memory 512 KB

# HDD-Cache Typ aufs (async), Ordnerangabe, 32GB, Ordner erste Ebene, Ordner zweite Ebene
cache_dir aufs /var/cache/squid 32768 32 256

#Eyecandy
visible_hostname proxy.lan.adlerweb.info

#Boese Seiten
acl bad_url dstdomain "/etc/squid/bad-sites.acl"
http_access deny bad_url

#Interne IP des Clients nicht nach draussen senden
forwarded_for off

In meinem Fall musste auch der Standardport dran glauben, stattdessen wird nun 8080 verwendet, welches dem Altsystem entspricht und lästiges Umkonfigurieren erspart:

http_port 8080

3. Diktator-Modus

In der Konfiguration schimmert es schon etwas durch: I aim to misbehave. Da es sich um mein Netz handelt greifen auch meine Zensurrichtlinien. Unter /etc/squid/bad-sites.acl liegt eine Liste mit Domains, welche vom Proxy gesperrt werden. Dies kann z.B. sinnvoll sein um Werbung oder die Ziele quasselfreudiger Programme auszusperren. Dabei solltet ihr natürlich das alte Credo beherzigen: With great power comes great responsibility.

.facebook.com
.facebook.de
.google-analytics.com
.googleadservices.com
[...]

4 Minuten Später
…ist der Proxy installiert und das Internet läuft wieder. Job erledigt, wenden wir uns wieder den Katzenvideos zu.

Und sonst?
Wer es etwas weiter treiben möchte: SquidGuard oder Dansguardian können Webseiten nach Themenbereichen sperren. SquidClamav kann die aufgerufenen Webseiten auf Viren prüfen. Sarg verwandelt das Log in einen praktischen HTML-Report mit Top-Usern und den Beliebtesten Webseiten. Ansonsten hat auch sicher die Suchmaschine der Wahl noch genügend Ideen zur Freizeitvernichtung.