Springe zum Inhalt

Blog

Nach dem Update von Stretch auf Buster braucht OpenSSH, speziell auf VMs, schon mal gerne mehrere Minuten zum Starten. Grund dafür ist, dass systemd alle Dienste ziemlich parallel startet und für OpenSSH-Verschlüsselungsroutinen einfach noch nicht genug Entropie vorhanden ist. OpenSSH wartet deshalb erst einmal ab und lässt noch keine Verbindungen von außen zu. Erst wenn im Kernel-Log die Meldung "random: crng init done" auftaucht, ist die Initialisierung abgeschlossen und OpenSSH startet komplett.

Probleme beim Systemstart betreffend der noch nicht vohandener Entropie können auch bei Webservern auftreten, die wiederrum SSL-Bibliotheken verwenden und diese ebenfalls noch nicht initialisieren können.

Eine einfache Lösung für diese Probleme ist die Installation von haveged, einem User-Space-Daemon, welcher beim Systemstart Entropie liefert, sobald der "Füllstand" von /dev/random unter eine gewisse Grenze fällt.

Siehe hierzu auch:

Beim Hochfahren eines MariaDB-Galera-Cluster-Nodes muss dieser erst einmal synchronisiert werden. Standardmäßig sucht sich der Node einen anderen bereits synchronisierten Node des Clusters aus, von dem er anschließend synchronisiert. Bei der Synchronisation ist der Datenlieferant für die Zeit der Synchronisation komplett gesperrt und kann von Clients nicht verwendet werden. Um das zu verhindern kann ein eigener Node aufgesetzt werden, auf den keine Clientprogramme zugreifen. Dieser Node wird dann als bevorzugte Quelle für die Synchronisation bei allen anderen Nodes eingestellt.

In der MariaDB-Konfiguration muss dazu folgendes angegeben werden:

wsrep_sst_donor = "donornode,"

Zu beachten ist, dass als Name der Nodename und nicht der Hostname des bevorzugten Datenlieferanten angegeben werden muss. Dass Kommata am Schluß ist kein Schreibfehler, sondern sorgt dafür, dass bei nicht verfügbarem Datenlieferant dass Standardverfahren angewendet und ein zufälliger Node für die Synchronisation ausgewählt wird.

Bei der anschließenden Synchronisation des Nodes ist die Auswahl des bevorzugten Nodes auch im Logfile zu erkennen:

WSREP: Member 3.0 (node5) requested state transfer from 'node0,'. Selected 2.0 (node0)(SYNCED) as donor.
WSREP: 2.0 (node0): State transfer to 3.0 (node5) complete
WSREP: Member 2.0 (node0) synced with group.
WSREP: 3.0 (node5): State transfer from 2.0 (node0) complete.
WSREP: Member 3.0 (node5) synced with group.
WSREP: Synchronized with group, ready for connections

Im vorliegenden Beispiel war node0 as bevorzugter Node für die Synchronisierung eingestellt.

Da hier jemand nach einem einfachen Modem-Skript fragte, mit dem über die serielle Konsole AT-Befehle geschickt werden können und die Antworten vom TC35 angezeigt werden, poste ich das einfach mal hier.

Wichtig: seriellen Monitor auf 9600 Baud umstellen und jedes AT-Kommando mit Punkt abschließen! Sind Kommandos oder Antworten des TC35 länger als 64 Bytes, so muss vorher in der Serial-Library der Puffer entsprechend hoch gesetzt werden (_SS_MAX_RX_BUFF). Nach dem Hochsetzen muss das Skript natürlich nochmal kompiliert und auf den Arduino hochgeladen werden.

Verkabelung:

  • GND Arduino mit GND von TC35
  • Pin 8 des Arduino mit IGT des TC35
  • Pin 2 des Arduino mit RXD0 des TC35
  • Pin 3 des Arduino mit TXD0 des TC35
  1. #include <SoftwareSerial.h>
  2. #define rxPin 2
  3. #define txPin 3
  4.  
  5. SoftwareSerial gsmSerial(rxPin, txPin);
  6. char recu[150];    // Array for message
  7. String message = "";
  8. int i;
  9.  
  10. void setup() {
  11.   // initialize digital pin 13 as an output.
  12.   pinMode(13, OUTPUT);
  13.  
  14.   Serial.begin(9600);
  15.   while(!Serial) {}
  16.  
  17.   //--- turn on TC35 ---
  18.   // wire pin 8 Arduino to IGT pin on TC35
  19.   // ground pin for 100 ms - this is the same as pressing the button on the TC35 to start it up
  20.   pinMode(8, INPUT);
  21.   digitalWrite(8, LOW);
  22.   pinMode(8, OUTPUT);
  23.   delay(100);
  24.   pinMode(8, INPUT);
  25.  
  26.   gsmSerial.begin(9600);
  27.   delay(5000);
  28.   Serial.println("Bereit für Kommandos. Kommando beenden mit Punkt.");
  29. }
  30.  
  31. void loop() {
  32.   i = 0;
  33.   while (Serial.available() > 0) {
  34.     recu[i] = Serial.read();
  35.     if ((recu[i] != 46) && (recu[i] != 13) && (recu[i] != 10))
  36.     {
  37.       message += char(recu[i]);
  38.     }
  39.     i++;
  40.     // 46 is ASCII code for "."
  41.     if (recu[i - 1] == 46) {
  42.       SendCmdMessage();
  43.       ShowSerialData();
  44.       delay(1000);
  45.       message = "";
  46.       i = 0;
  47.     }
  48.   }
  49.   ShowSerialData();
  50. }
  51.  
  52. void SendCmdMessage() {
  53.   gsmSerial.println(message);
  54.   delay(500);
  55. }
  56.  
  57. void ShowSerialData() {
  58.   while(gsmSerial.available() > 0) {
  59.     Serial.write(gsmSerial.read());
  60.   }
  61. }

Wenn vorher alles (auch der TC35) ausgeschaltet war, dann blinkt ca. 5 Sekunden nach dem Start die LED neben R1 und R2 auf dem TC35. Das bedeutet, dass sich der TC35 ins GSM-Netz eingebucht hat. Im seriellen Monitor meldet sich das Skript dann wie im Bild dargestellt.

Danach können ganz normal AT-Kommandos an den TC35 geschickt werden. Zu beachten ist nur, dass jedes Kommando im seriellen Monitor mit einem Punkt abgeschlossen werden muss (welcher durch das Skript aber nicht an den TC35 weitergereicht wird). Es dient nur zur Kennung für "hier ist ein Kommando zu Ende". Anschließend werden die Ausgaben des TC35 gelesen und auch im seriellen Monitor angezeigt.

Viel Spaß damit!

Seit Mitte 2016 wurde hier ein eigenes Forum betrieben, welches als Erweiterung der Kommentare zu den Beiträgen dieses Blogs gedacht war. Besonders ein Beitrag mit über 100 Kommentaren verlangte nach einer Lösung, denn allein der Seitentext umfasste schon mehr als die durch den hier eingesetzten Seitencache maximal verarbeitbare Größe.

So mauserte sich das Forum 2016 zu einem sinnvollen Zusatz zum Blog.

Forum - Verlauf

Seit 2018 jedoch wurden die Kommentare weniger, die Bots waren auf das Forum aufmerksam geworden und registrierten oft mehrmals täglich neue Bot-User. Glücklicherweise hat es in der ganzen Zeit nur ein Bot ein einziges Mal geschafft, Spam zu posten. Die mit der Forensoftware SMF mitgelieferte Captcha-Lösung war für die Bots leider kein Problem. Besserung versprach das Einbinden von Googles reCaptcha zur Registrierung.

Leider wurden notwendige Aktualisierungen auf neue Versionen der Foren-Software oft auf die lange Bank geschoben. Die Wartung eines Forums verschlingt einfach zu viel Zeit und erfordert zeitnahes Handeln. Da ich beides nicht immer leisten kann habe ich mich dazu entschlossen, das Forum zu schließen.

Ein vielleicht erhaltenswerter Beitrag aus dem Forum wurde ins Blog übernommen. Bei den restlichen Beiträgen im Forum handelte es sich meist um Problemlösungen zu Individualkonfigurationen.

Zum Schluß noch eine kleine Statistik zum Forum:

Forum - Allgemeine Statistik

Ich möchte mich hier noch einmal herzlich bei allen Teilnehmern am Forum bedanken. Im Team Lösungen zu den dort angesprochenen Problemen zu finden hat mir sehr viel Spaß gemacht. Ich hoffe, den einen oder anderen auch hier in den Kommentaren wieder lesen zu dürfen.

5

Nach ein paar Lobgesängen auf LineageOS hier im Blog habe ich heute meine letzte Version mit einem Stock-ROM überschrieben. Leider hat sich LineageOS für meine Handy-Modelle nicht so entwickelt, wie ich es mir gewünscht hätte oder wie ich es von anderen OpenSource-Projekten gewohnt bin.

Nach dem fulminanten Start von LineageOS Anfang 2017 und der durch das Forken von CyanogenMod unmittelbar verfügbaren breiten Unterstützung von Handymodellen schien der weitere Betrieb meiner ohnehin schon auf CyanogenMod laufenden Handys weiter gesichert. Auch der im LineageOS-Wiki dokumentierte Support meines aktuellsten Handy-Modells durch gleich drei Entwickler ließ Gutes erwarten.

Anders als bei CyanogenMod gab und gibt es bei LineageOS noch keine offiziellen Versionen. Historisch gewachsen werden Nightlys, entgegen dem Namen, wöchentlich gebaut. Ich war bei den Nightlys immer an vorderster Front dabei und habe seit der Verfügbarkeit eines Bug- bzw. Regression-Trackers auch fleißig Tickets eingereicht.

Leider werden seit Mitte letzten Jahres von allen drei Entwicklern für mein Handymodell keine Bugs mehr behoben. Elementare Sachen wie z.B. die Anzeige des Energieverbrauchs durch einzelne Apps oder etwa ganz einfache Sachen wie die Anzeige des durch Videos verbrauchten Speichers (es wird immer 0 angezeigt) funktionieren nicht. Videos länger als 2 Minuten aufzunehmen ist sinnlos, da diese anschließend nur ruckeln. Dazu kommen tägliche Random-Reboots, welche sicherlich die ärgerlichsten der bisher nicht behobenen Fehler sein dürften. Verweise auf die volle Konzentration der Entwickler auf eine neue Version (Oreo) kann ich nicht nachvollziehen, da solch eine Version nach einem ganzen Jahr bisher nicht erschienen ist und auch in den entsprechenden Repositories keinerlei Commits dieser Art zu finden sind. Die bisher letzte Version von LineageOS für mein Handymodell strotzt leider nur so von Fehlern.

Das wieder auf das Stock-ROM zurückgesetzte Handy, welches nach wie vor tadellos funktioniert, wird morgen verschenkt. Mein aktuelles Handy hat von vornherein sein Stock-ROM behalten (der geneigte Leser findet sicherlich schnell heraus, welche Marke ich bevorzuge).

Schade für LineageOS, welche so ambitioniert und großartig gestartet ist, leider aber kein generelles Konzept für die Entwicklung durchsetzten konnte.