Alle Beiträge von adlerweb

Arch Linux/Systemd: Screen-Sitzung als Daemon

Nicht immer kann oder möchte man ein Linux-Programm als Daemon starten – fehlende Daemon-Funktion, die Möglichkeit direkt auf STDOUT/STDERR zu schauen, etc. In den meisten Fällen bemühe ich für diese Fälle den Terminal Multiplexer „screen“. Hiermit wir die Software mit komplettem Terminal gestartet, man kann jedoch die Verbindung trennen, sodass das Programm im Hintergrund weiter seinen Dienst tut. Bei einem späteren Reconnect sind alle vorherigen Ausgaben wieder sichtbar.

Bisher startete ich diese Programme von Hand, auf einem System habe ich nun aber ein Shell-Script, welches sinnigerweise direkt beim Boot gestartet werden soll – bauen wir uns einen passenden Systemd-Service:

[Unit]
Description=Dynamic DNS updater
After=network.target

[Service]
RemainAfterExit=yes
User=root
ExecStart=/usr/bin/screen -AdmS ddns /usr/local/sbin/ddns.sh
ExecStop=/usr/bin/screen -S ddns -X quit

[Install]
WantedBy=multi-user.target

Wie unschwer zu erkennen handelt es sich um einen DDNS-Update-Daemon. Zwar würde der auch direkt laufen, da jedoch ab und an mal manuell ein Befehl abgesetzt werden muss ist mir screen lieber. Die Bedingung nach network.target zu laufen ist rein durch die DNS-Funktion bedingt und für Screen nicht notwendig.
Interessant wird es in [Service] – Erst wird der Nutzer festgelegt, welcher den Screen starten soll – da der Daemon Systemeinstellungen ändert komme ich hier um root nicht herum. Unter ExecStart wird der passende Befehl angegeben – es wird eine screen-Sitzung mit dem Namen „ddns“ gestartet und dort das Script „/usr/local/sbin/ddns.sh“ ausgeführt. In der nächsten Zeile wird zum Stoppen der Screen mit dem Namen „ddns“ beendet.

Die Datei wird unter /etc/systemd/system/ddns.service abgelegt und ist danach wie jeder andere Dienst nutzbar. Ist er mit „systemd start ddns“ gestartet kann der Nutzer root sich mittels „screen -x ddns“ zur laufenden Sitzung verbinden. Mit der Tastenkombination „Ctrl-a d“ wird die Verbindung wieder getrennt.

Einige Warnungen noch:
– Die Sitzung hat ggf. nicht alle Umgebungsvariablen, die man von einer „normalen“ Shell-Sitzung gewohnt ist
– Bricht das Script ab wird der Screen beendet, in dem Fall ist die Ausgabe/Fehlermeldung nicht mehr sichtbar. Hier kann man ggf. eine interaktive Shell nach dem Script starten und so die Sitzung offen halten. Beispiel:

ExecStart=/usr/bin/screen -AdmS ddns sh -c '/usr/local/sbin/ddns.sh ; bash'

Denizbank: Gehen sie weiter, hier gibt es nichts zu sehen

Wieder einmal ein Kandidat für den Award „unsichere Bank“, diesmal jedoch mit ganz besonderer Note. Beworben hat sich dieses mal die Denizbank. Eigentich sehen die (technischen) Werte ihrer deutschen Niederlassung sowie der österreichischen Kontoseite weitestgehend OK aus – fehlendes Forward Secrecy beim Kontilogin, ein paar Kleinigkeiten, aber keine offensichtlichen Mängel. PFS ist inzwischen ja nicht mehr so kompliziert, also kann man es ja mal anregen – eine passende Mail ging also vor einigen Wochen raus.

Zurück kam eine E-Mail, welche mehr Disclaimer als Inhalt besaß – ein Traum für alle Spieler von Bullshit Bingo. Die Angaben wären als Meinungsäußerung des Mitarbeiters und nicht als Aussagen der Bank zu verstehen. Interessant, hatte ich nicht um eine Stellungnahme gebeten? Kommt die Mail nicht von einem offiziellen Bank-Account und ist es üblich, dass Mitarbeiter diesen für private Meinungsäußerungen nutzen? Wie auch immer: Man ließ mich wissen, dass die Server

die aktuellste OPEN SSL Version verwenden und somit eine Sicherheitslücke ausgeschlossen ist.

Tja, wir alle wissen: OpenSSL ist so sicher wie die Rente. Auf meine Frage zu PFS & Co ging man gar nicht ein. No further questions…

Arch Linux: Only console users are allowed to run the X server

Üblicherweise nutze ich an meinem Haupt-PC ein Multihead-Setup, also mehrere Monitore. Was zum Arbeiten praktisch ist bringt Spiele leider gerne aus dem Tritt. Um dem aus dem Weg zu gehen habe ich bisher über startx einen zweiten X-Server gestartet – direkt aus der GUI, somit war auch Pulseaudio & Co immer direkt nutzbar. Seit einem der letzten Updates, vermutlich die neue Rootless-Funktion von xorg 1.16, erscheint nur noch die Meldung „Only console users are allowed to run the X server“.

In einem Post auf Github wird empfohlen eine Datei /etc/X11/Xwrapper.config mit dem Text „allowed_users=anybody“ zu erzeugen. Generell ein Fortschritt, nun bricht jedoch beim Start der propritäre NVidia-Treiber wie folgt zusammen:

(EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
(EE) NVIDIA(GPU-0): Failed to allocate EVO core DMA push buffer
(EE) NVIDIA(0): Failing initialization of X screen 0

Leider konnte ich den genauen Auslöser nicht finden – die Rechte sinds nicht, setuid/setgid oder start als root zeigt keine Änderung. Auch ein Wechsel auf die freien Nouveau-Treiber zeigt keine Änderung, hier kann in der zweiten Sitzung kein DRI inizialisiert werden. Glücklicherweise hat der freie Treiber deutlich weniger Rendering-Bugs – nicht nur, dass Chromium endlich wieder nutzbar ist – auch Spiele laufen nun im Multi-Monitor-Modus. Zwar erscheint das Bild immer auf den linken Monitor, aber mit einem VGA-Umschalter als Hardware-Workarround kann ich mir da behelfen.

Farewell, LostLegion – L|L1 New Era abgeschaltet

Vor vielen Jahren wurde ich durch einen Azubi auf „yet another Egoshooter“ aufmerksam gemacht: ET. Zuvor war ich hauptsächlich im UT-Umfeld unterwegs, das Konzept verschiedener Klassen gepaart mit der aktiven Community und nativer Linux-Kompatibilität ließen es schnell in meiner Gunst steigen. Dies war im Jahr 2003 – 11 Jahre Später finde ich immer noch alle Nase lang ein stündchen Zeit – erst mit eigenem Server, in den letzten Jahren auf jenen der „Lost Legion“. Ihr Server „L|L1 New Era“ glänzte mit einer ausgewogenen Auswahl an custom Maps, guter Pflege und einer freundlichen Community.

Leider wurden die Server am 17.07. abgeschaltet – die schrumpfende Fangemeinde sorgten in Kombination mit der üblichen Sommerflaute oft für leere Server. Hier zur Kopie die News der inzwischen nicht mehr aufrufbaren Webseite:

Dear players, members, admins & HA !

As many of you already know cause i announce it already on L|L chat + public chat on the server, we gonna close the ET server „LL1 New Era“ this summer.
The official date is set : 17th July 2014.

So why now ?
Well first my objective was to make it run at least until the 10th anniversary of ET (in 2013). We succeed and even run it more than 1 year after that, cause of YOU : the players around <3 But nowadays as you notice, ET is dying slowly, there is no new „fresh players“ and only very few NQ servers can keep more than 20 ppl at evening.

With the summer incoming, the right time is come : it will be low ppl around and it’s better to close now than wait for the server reach zero player. And for any players & members it’s also better… you will enjoy more to play on populated server than try to keep an empty server every days & nights.

So i encourage you strongly to enjoy the server before we close (in a bit less than 1 month), cause after it will be to late :p

There is a lot of ppl to thanks, and which make the L|L adventure going so far 🙂 but i will do that in another post!
Just a very big thx to Letho, which start and hold contracts for L|L Servers since Bor3 disappear :p (2010?) and that, even if he doesn’t play ET anymore since long time : Without him, nothing would have been possible.

There is no need to send any donation anymore : a very big thank you to everyone who has send money in the past to support the server, it was a great help to make it run so far 🙂
[…]

Auch wenn ich sicher noch öfter die IP aus Gewohnheit in die Konsole einhämmern werde: Ich wünsche allen Unterstützern und Spielern alles Gute für die Zukunft – möge man sich auf den verbliebenen Servern wiedersehen.

VMWare ESXi 5.x – SSH aktivieren

VMWare ESXi basiert intern auf einem Unix-artigen System, entsprechend kann ab und an ein kleiner Schubs auf der Konsole recht hilfreich wirken. Zwar ist im System von Haus aus ein SSH-Server vorhanden, jedoch üblicherweise deaktiviert.

Um einen SSH-Zugang zu aktivieren klickt man im vSphere-Manager den Host an und wählt rechts den Tab „Konfiguration“ aus. In der linken Seite befindet sich unter „Software“ der Menüpunkt „Sicherheitsprofil“. Unter Dienste ist SSH bereits geführt, jedoch nicht gestartet – dies kann man über den kleinen Link „Einstellungen“ an der rechten Seite ändern. Unter SSH->Optionen lässt sich der Dienst dauerhaft aktivieren oder auch nur für einen kurzen Eingriff manuell starten.

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/07/vm1-300×196.png

Der zugehörige Artikel bei VMware wäre 2004746

Verschwundene Schriftarten in Microsoft Office Word

Immer mal etwas Neues: Auf einem Rechner ließen sich in Microsoft Word plötzlich nur nur eine Hand voll Schriften auswählen. Hinzu kam, dass die vorhandenen seltsam reagierten, so wurde z.B. der Text teilweise kleiner wenn man die Schriftgröße erhöhte. Ursache war die Auswahl eines unpassenden Druckers, nachdem dieser gewechselt wurde tauchten die Schriften wieder auf.

Attributfehler bei der Verwendung von PyGst

Bei der Verwendung der Python-Bindungen von GStreamer hagelte es auf einem System unverständliche Fehler nach dem Muster AttributeError: 'NoneType' object has no attribute 'get_static_pad_templates' – Auslöser war in diesem Falle ein fehlender GStreamer-Codec, die Installation der zugehörigen Plugins sorgte für Abhilfe

CURL & OpenSSL – Zertifikatsfehler

In den letzten Tagen hatte ich einige seltsame Ergebnisse bei CURL – einige URLs wurden wegen eines fehlerhaften Zertifikatsunterschrift abgelehnt:

Cannot connect to URL : Peer certificate cannot be authenticated with known CA certificates: SSL certificate problem, verify that the CA cert is OK. Details:
[…]routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Seltsamerweise ist manuell sowohl Zertifikat als auch CA fehlerfrei, letztere ist auch in /etc/ssl/certs/ korrekt hinterlegt. Laut diversen Posts handelt es sich wohl um einen Fehler in OpenSSL – um vorerst Ruhe zu bekommen habe ich curl nun unter Gentoo mit CURL_SSL=“gnutls“ oder CURL_SSL=“polarssl“ installiert und bisher keine Probleme mehr. Für Ubuntu wäre libcurl4-gnutls-dev der richtige Startpunkt.

Unsichere Verschlüsselungen die nächste: BigBank

Viele Banken haben sich schon drum gekümmert, doch Nachschub ist in Sicht: Die estnische BigBank glänzt üblicherweise mit hohen Zinssätzen und einer relativ guten Reputation. Leider kann sie Serverseitig dem Ruf nicht gerecht werden: 3DES und RC4 finden sich als bevorzugte SSL-Ciphers, obwohl TLS_RSA_WITH_AES_256_CBC_SHA bereits unterstützt wird und sich mit TLS_DHE_RSA_WITH_AES_256_CBC_SHA sogar Cipher mit Forward-Secrecy finden lassen. Leider geht diese Fehlkonfiguration der Cipher Suite Priority so weit, dass es teilweise sogar zu Protokollfehlern kommt und der Loginserver nicht mit jedem Browser fehlerfrei aufgerufen werden kann.

Wie üblich wurde die Bank von mir ausführlich – und mit Verweis auf BSI & Co – über meine Bedenken Informiert und um Stellungnahme gebeten. Mein Geld bekommen sie jedenfalls erst mal nicht.

VsFTPd 3.x und 64Bit-Server

Bein Aufsetzen eines FTP-Servers mittels VsFTPd kam es zu einem etwas anderen Problem: Der Server startete, beim Connect erhielt der Client jedoch lediglich die Meldung „500 OOPS: child died“. Im Log selbst war keine Meldung auffindbar.

Auslöser ist offenbar ein zu strikter Sicherheitsfilter in Verbindung mit 64Bit-Kerneln. Gentoo scheint nicht betroffen zu sein, dort lief die Version 3.0.2 fehlerfrei, selbige unter Arch Linux verursacht den Fehler. Als Workarround kann man die neuen Sicherheitsfunktionen durch setzen des Wertes „seccomp_sandbox=NO“ in der vsftpd.conf abschalten.