BATCH: Autoconnect SSH / Putty / Plink

Ich habe des Öfteren das Problem, das SSH Verbindungen über WLAN sporadisch abbrechen. Bei Backup’s ärgerlich – ich habe hier einen Tipp geschrieben – aber auch das verlieren von getunnelten RDP Verbindungen nervt. In Microsoft Windows Systemen nutze ich PuTTY für SSH Tunnel – mit Hilfe eines kleinen Batchfiles und dem Programm Plink aus dem PuTTY-Paket lässt sich das Problem elegant beheben.

Die Verbindungsparameter vereinbaren wir bequem im UI des Programms PuTTY und merken uns den Namen des gespeicherten Profils. Jetzt erzeugen wir ein Batchfile (Dateiendung .bat)

1
2
3
4
5
6
@echo off
:while
date /T
time /T
C:\Users\irgendwo\plink.exe -batch -N -load profil 
if %errorlevel% neq 0 ( goto :while )

Die Argumente für Plink sind analog zu PuTTY. Wenn im Profil Username, Zertifikat, Tunnel hinterlegt ist, kann man mit -batch -N die Shell und jede Nachfrage unterdrücken. Das Batchfile zeigt lediglich Datum und Zeit des Connects sowie Reconnect an.

Apache2: SAP webgui und mod_proxy

Das Apache2 Modul mod_proxy zur Anbindung des SAP ITS an die Aussenwelt funktioniert recht problemlos wenn es um WebDynpro’s geht.

Will man darüber hinaus auch die WebGUI Online nutzen, gibt es einen Stolperstein. Im Verbindungsaufbau zum WebGUI wird die Session ID (SSO) als POST in der URL ausgetauscht. Das sprengt die Direktive im Filter „/sap“ des Apache welcher dann das „/sap(“ nicht erkennt. Der Prozess bleibt für den User scheinbar stehen.

So funktioniert Verbindungsaufbau und Nutzung einwandfrei. Keine schöne Lösung – ich würde das nur für WebDynpro’s nutzen.

C: RND mit Millisekunden Seed

Das generieren von Zufallszahlen kann schwierig sein, wenn der Zyklus der Generierung mehrmals in einer Sekunde aufgerufen wird. Die Zufallszahl wird innerhalb der Sekunde gleich sein, benutzt man als rnd seed die Unixzeit.

Die Unixzeit ist eine 32Bit Zahl mit Vorzeichen und repräsentiert die Anzahl Sekunden seit 1.1.1970 00:00:00 Uhr. Im Klartext: 32Bit -1 Bit Vorzeichen = 31Bit. 2**31 = 2147483648 -1 (wir rechnen von 0 an) = 2147483647 als maximale Integer Zahl. Die Standardfunktionen srand und rand sind ebenfalls Funktionen welche eine 32Bit Zahl zurück geben. 32Bit Integer als rnd-seed ist die Unixtime, welche erst mit der Sekunde wechselt, weshalb die Vorgehensweise in dem Fall nicht empfehlenswert ist.

In der C Library stdlib.h existieren u.a. die Funktionen srand48 und lrand48. Für die Programmierung macht das keinen Unterschied: Das Seed bleibt 32Bit, genau so der Rückgabewert der Funktionen. Innerhalb der Funktion wird dem 32Bit Wert, 16Bit hinzu gefügt. Das Seed entspricht dann intern einem 13 stelligem Integer (mit Vorzeichen) – die drei zusätzlichen Stellen entsprechen den Millisekunden zur Unixzeit. Funktionsbeispiel:

1
2
3
4
5
6
7
8
9
10
11
12
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
 
int zufall(void)
{
  char zu;
  srand48((long int)time(NULL));
  zu = (lrand48()/rand()) %3 + 1;
  return zu;
}

So erhalte ich sehr schnell eine einstellige Zufallszahl zwischen 1 und 3.

Hat jemand eine andere Idee?

Nextcloud: Chat Bot Python

Meldungen automatisieren direkt in eine Talk Gruppe mit Python.

Unser Nextcloud Dienst wird produktiv genutzt und Gruppen tauschen sich über Gruppenchats in Talk aus. Über die API von Nextcloud läßt sich sehr einfach maschinell und automatisiert Nachrichten versenden. Servernachrichten, neue Tickets vom Kunden oder das Papier im Drucker muss nachgefüllt werden – alles ist denkbar.

Es empfiehlt sich einen eigenen Bot User einzurichten. In den Gruppen, in die Nachrichten gesendet werden sollen, muss dieser User hinzu gefügt werden. Hier ein Beispiel in Python:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import os
# Minimal lt Nextcloud API Beschreibung
server = "https://deinServer.de/nextcloud/"
username = "bot"
password = "meinPW"
 
def NextcloudTalkSendMessage(channelId, message):
    data = {
        "token": channelId,
        "message": message,
        "actorDisplayName": "Nachricht",
        "actorType": "",
        "actorId": "",
        "timestamp": 0,
        "messageParameters": []
    }
 
    url = "{}/ocs/v2.php/apps/spreed/api/v1/chat/{}".format(server, channelId)
    payload = json.dumps(data);
    headers = {'content-type': 'application/json', 'OCS-APIRequest': 'true'}
    resp = requests.post(url, data=payload, headers=headers, auth=(username, password))
    print(resp)
 
# Die Gruppe bekommt Test Meldung
output = 'Test'
NextcloudTalkSendMessage('ien9wbax', output)
# Diese Gruppe sieht die Uptime der Maschine
output = os.popen("uptime").read()
NextcloudTalkSendMessage('ien9wbrk', output)

Auf die Reaktion der Anwender bin ich gespannt, wie nützlich das ist. Welche Erfahrung habt ihr?

BASH: Wer hat was gemacht

Viele User die am System arbeiten: Nachher will es keiner gewesen sein, wenn das System Fehler produziert.

Eine Log-Datei, die den User und alle abgesetzten Befehle mit PID und Return-Value aufzeichnet, schafft Transparenz. Editieren wir zuerst die /etc/bash.bashrc und fügen

1
export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RETRN_VAL]"'

hinzu. Damit weisen wir an, alle eingeben Befehle dem „logger“ zu übergeben, an den rsyslog Channel „local6“ mit Username und Rückgabewert zu übergeben. sed beschneidet lediglich die lfd. Nummer aus der Historie. Jetzt leiten wir local6 in eine Datei um. Dazu editieren wir /etc/rsyslog.conf und fügen hinzu:

1
local6.*    /var/log/historie

Auch wenn der User innerhalb der Session wechselt, ist das jetzt nachvollziehbar. Wenn jemand andere Lösungen kennt, bitte mailen oder anrufen.

BASH: Auswertung Rückgabewert

Riesige TAR-Files und langsame Internetverbindungen sind der Garant für Frust und fehlerhafte Backups. Ein kleines Script sorgt für penetrante Neustarts bis die Aufgabe erledigt ist.

1
2
3
4
5
6
7
8
#!/bin/bash
ergebnis=1
 
until [ $ergebnis -eq 0 ]
do
	rsync -avP /Sicherung.tar  user@host:.
	ergebnis=$?
done

Der Prozess rsync gibt „return 0“ zurück, wenn er erfolgreich beendet wir. Bricht der Prozess aus irgendeinem Grund ab – zB. Verbindungsabbruch- wird der Prozess neu gestartet.

Ganz besonders fein, wenn man je nach return Wert, zum Beispiel eine EMail generieren lässt.

Apache2: BandWidth

Überwachungskameras in größerer Anzahl können das Netzwerk schon in die Knie zwingen.

Wenn 40 – 50 Kameras Livebilder produzieren, wird die Bandbreite des Internetanschlußes gerne mit ca. 250 MBit/s strapaziert. Es ist Unfug, wenn ein User alle Streams gleichzeitig nutzen will – kommt aber vor.

Das ist zu vermeiden. In einem Debian System kann das mod-bw bequem per Aptitude installiert werden.

In der conf des VHOSTs oder innerhalb der Location Konfiguration könnte es so aussehen:

Auch in dieser Konfiguration ist auf die Reihenfolge zu achten –> first match rules! In dem Fall begrenze ich die Bandbreite und die Anzahl der Verbindungen pro Session für das lokale Netztwerk nicht. Alle anderen Verbindungen haben nur eine Bandbreite von 1310762 Byte ( das sind 10 MBit ) auf 5 Verbindungen zur Verfügung. Im obigen iftop sieht man maximale 10 MBit/s für 5 Cams. Zum Vergleich, habe ich intern weitere 5 Cam Streams geöffnet:

30 MBit/s verbraucht die interne Verbindung. Selbe Anzahl an Streams, ist extern wirksam auf 10 MBit/s limitiert.

Weitere Verbindungsversuche enden mit dem Error 503