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.
#!/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.
Das Urgestein des Computerjournalismus, Wolfgang Rudolph, darf nicht fehlen in unserem Newsletter, weshalb die Beiträge aus dem cc2.tv jetzt enthalten sind.
Wenn ich noch einen wichtigen und lesenswerten Feed vergessen habe, bitte ich um kurze Nachricht.
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
Neben der Entwicklung einer SAPUI5 Anwendung sowie einem SAP ABAP Projekt, lese ich mich in ein Langzeitprojekt ein. Programmierung auf IBM Servern in RGP. Eine Business-Anwendung soll um Free-RPG erweitert und Code geändert werden.
Haben sie auch spannende Aufgaben? Ich bin für Sie da!
Über mögliche Szenarien einer Datensicherung lassen sich Bücher füllen. Bei der Planung eines HALSYSTEM werden Sicherung der Dateien und die des Systems getrennt betrachtet. Letztendlich sieht der Kunde nur eine Übersicht über die Datensicherungen und verfügbaren Versionen veränderter Daten. Egal wie man es auch betrachten mag, ist eine Datensicherung nur dann sicher, wenn sie auch nach einem „undenkbaren Desaster“ die Möglichkeit der Wiederherstellung zulässt.
Für schnelle Lösungen und „mal eben zeigen“ in Workshops und Schulungen verwende ich schnell die unbedachte Kompilierung von Quellcode mit GCC, G++, COBC oder NASM. Das sollte man sich in größeren Projekten abgewöhnen. Compiler Option sind mächtig und bringen viel (Link).
Nehmen wir den berühmten „Hello World“ Code als Beispiel (Link). In C und C++ innerhalb der Funktion „main“ ein simples printf bzw. std::out und in COBOL, in der „Procedure Division“, ein „DISPLAY“. Übersetzen wir alle Sources in Assembler und erzeugen ein ausführbares Programm.
Ohne Optimierung fällt einiges auf. „helloc“ und „test-03.s“ sind die Produkte aus dem C Source Code. Das daraus generierte Assembler ist 8,2k gross. Das Assembler aus dem C++ Code wiegt 18k und 41k bringt das Assembler aus dem COBOL Source auf die Speicher-Waage. Fertig kompiliert sind alle drei ausführbaren Programme 22k bzw. 23k groß.
Schreiben wir „Hello World“ einmal in Assembler
und übersetzen, verlinken es mittels „nasm -felf64 helloa.asm && ld -o helloa helloa.o“
Wir sehen, da ist wahnsinniges Optmierungspotential. 352 Byte Quellcode und 4,8k für das ausführbare Programm. Ohne genaue Kenntnisse über den Compiler würde man in realen Projekten unter gehen – wir reden da durchaus über Mega- oder Giga-Byte die so verschwendet und zu einem Bottleneck in der Prozessierung werden kann.
Leitet man einen internen Dienst, der nur über eine interne IP erreichbar ist, über einen Apache2 Proxy weiter, kommt es bei Authentifizierungen zu Problemen. Einige Browser verweigern das senden der Authentifizierungsdaten, wenn die Empfängeradresse nicht der aktuellen Adresse entspricht. Das Einrichten einer Authentifizierung am Apache, der diese dann an den Proxy Endpunkt weiter leitet, bringt Abhilfe. Benutzername und Passwort sollte gleich lauten:
ProxyRequests On ProxyVia On <Proxy *> Order deny,allow Allow from all AuthType Basic AuthName „Passwort erforderlich“ AuthUserFile /etc/httpd/.passwdfile Require valid-user </Proxy> ProxyPassMatch ^/xxx/(.*)$ http://$1/cgi-bin/faststream.jpg?stream=full&html
Im Fall der Weiterleitung von MOBOTIX Cam Streams, funktioniert die Konfiguration. (Link)
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.