Docker & QEMU auf einem Rechner

Problem : Ich habe Docker und QEMU auf einem Rechner laufen. Nach der Docker Installation war es der virtuellen Maschine in QEMU nicht mehr möglich ins Internet zu zugreifen.

Lösung :
In meinem Fall waren die Default Einstellungen der Docker-CE Installation Schuld. Durch das korrigieren der IP-Tables konnte ich das Problem in meinem Fall beheben.
iptables -A FORWARD -i br1 -o br1 -j ACCEPT

Switch HP OfficeConnect 1920S: Telnet/SSH aktivieren

Problem:
Der Switch HP OfficeConnect 1920S ist ein sehr günstiger Full-Gigabit PoE Switch. Man muss ein paar Abstriche am Gerät machen, aber an sich ein sehr guter Switch. Für mich sind folgende Punkt etwas störend, aber für den Zweck der Switche akzeptabel:
- kein Consolen-Port (serieller Anschluss)
- Stromkabel kein Kaltgerätestecker - ist nur für den direkten Anschluss an der USV geeignet.
- Only Web-Managed

Mein Problem war, dass der Switch nur Web-Managed ist und keinen Zugriff per Telnet oder SSH bietet. Da ich kein Freund von GUIs bei Switchen bin wollte ich Telnet und/oder SSH-Zugriff haben um auf die CLI zugreifen zu können.
Per Default leider nicht möglich, aber man kann es über einen kleinen Umweg aktivieren!

Lösung:
1.) Firmware-Update auf die aktuelle Version über die GUI (bei mir PD.02.06)
2.) Eine aktuelle Start-Config exportieren über Maintenance -> Backup and Update Manage
3.) Die exportierte Config editieren und folgende Zeile VOR der Zeile "configure" setzen
ip telnet server enable
Beispiel Startup-Config von mir:
!Current Configuration:
!
!System Description "HPE OfficeConnect Switch 1920S 48G 4SFP PPoE+ (370W) JL386A, PD.02.06, Linux 3.6.5-a07f8920, U-Boot 2012.10-00118-g3773021 (Oct 11 2016 - 15:39:54)"
!System Software Version "PD.02.06"
!System Up Time "0 days 0 hrs 6 mins 39 secs"
!Additional Packages HPE QOS,HPE IPv6 Management,HPE Routing
!Current SNTP Synchronized Time: SNTP Client Mode Is Disabled
!
vlan database
exit
ip telnet server enable
configure
time-range Schedule-1
exit
time-range Schedule-2
exit
no username guest
line console
exit
line telnet
exit
line ssh
exit
!
exit

4.) Neue Startup-Config speichern und über die GUI als Startup-Config importieren (Maintenance -> Backup and Update Manage)
5.) Switch rebooten
6.) Telnet auf die Switch-IP ausführen (Default: Telnet 192.168.1.1)
7.) Mit folgenden Zeilen SSH aktivieren:
enable
configure
crypto key generate rsa
crypto key generate dsa
exit
ip ssh server enable
ip ssh protocol 2
write memory confirm
quit

8.) Wer möchte kann Telnet auch wieder deaktivieren mit dem Befehl:
ip telnet server disable


Kleiner Tipp am Rande: Wenn man die Startup-Config hochlädt, dann werden Kennwörter und sonstige Konfigurationen wieder verworfen! Also bitte erste Telnet/SSH aktivieren und dann Switch konfigurieren!

Quelle für die Hilfe:
Switches 'HPE OfficeConnect 1920S' - Enable SSH / TFTP Services

Websockets mit Apache hinter haproxy

Ich hab hier eine Anwendung die WebSocket verwendet und im HA Umfeld läuft (haproxy). Leider benötigt diese Anwendung auch Sessions (sticky) deswegen musste ich ein wenig basteln ;-) Bei mir läuft eine node.js Anwendung hinter dem haproxy , für andere Fälle muss man vermutlich noch etwas mit der Konfiguration spielen.

haproxy config websockets
Erstmal habe ich in der vhost des Apaches dafür gesorgt das ws auf den richtigen Server geleitet wird.

vhost
   RewriteEngine On
   RewriteCond %{HTTP:Connection} Upgrade [NC]
   RewriteCond %{HTTP:Upgrade} websocket [NC]
   RewriteRule /demoapp/(.*) ws://demo-srv-01:3030/$1 [P,L]

   RedirectMatch           ^/demoapp$   TARGET-URL/demoapp/
   ProxyPass               /demoapp/    http://demo-srv-01:3030/
   ProxyPassReverse        /demoapp/    http://demo-srv-01:3030/

Dann hab ich die haproxy Konfiguration auf die Anwendung zugeschnitten.

haproxy
listen demoapp:3030
  bind *:3030
  # EIO ist immer gesetzt wenn über Websocket
  acl IsStatus urlp(EIO) 3
  use_backend ws_demoapp if IsStatus
  use_backend default if !IsStatus

backend ws_demoapp
  mode http
  # eventuell gesetzte Header löschen
  rspdel ^Server:.*
  rspdel ^X-Powered-By:.*
  # und durch Server demoapp Header ersetzen
  rspadd Server:\ demoapp
  # diese Seite muss HTTP-Status 200 liefern damit der HA erkennt das alles ok ist
  option httpchk HEAD /lbhealth
  # check auf Status wenn der 200 ist ist alles ok
  http-check expect status 200
  # using the `io` cookie set upon handshake
  cookie io prefix indirect nocache
  # Server Endpunkte
  server wsdemoapp01 ws-demo-srv-01:8200 check cookie monitor01
  server wsdemoapp02 ws-demo-srv-02:8200 check cookie monitor02

backend default
  mode http
  # eventuell gesetzte Header löschen
  rspdel ^Server:.*
  rspdel ^X-Powered-By:.*
  # und durch Server demoapp Header ersetzen
  rspadd Server:\ demoapp
  # Server Endpunkte wird normal gebalancet
  balance leastconn
  server node01 ws-demo-srv-01:80 check cookie node01
  server node02 ws-demo-srv-02:80 check cookie node02
Quellen & Info :
https://de.wikipedia.org/wiki/WebSocket
https://load-balancer.info/themen/sticky-session-load-balancing/
https://nodejs.org/en/about/
https://www.haproxy.org/#desc
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

HP Notebook: Windows 10 Upgrade schlägt fehl - System reservierte Partition konnte nicht aktualisiert werden

Ich habe versucht ein neuinstalliertes HP Notebook auf die aktuelle Windows 10 Vesion 1809 zu aktualisieren. Dabei ist mit das Upgrade ständig abgebrochen mit dem Fehler "System reservierte Partition konnte nicht aktualisiert werden".
Es scheint so, dass die EFI-Partition zu klein ist. Nach etwas Recherche findet man heruas, dass HP hier eingie LOG-Files speichert und diese können die Partition vollschreiben. Resultat - Upgrade funktioniert nicht.

Wie bekommt die Logs gelöscht?
Folgendes vorgehen hierzu:
1.) cmd als Administrator öffnen
2.) EFI mounten mittles befehl
mountvol x: /s

3.) Den Inhalt des Verzeichnisses x:\EFI\HP\SystemDiags löschen
4.) Upgrade erneut durchführen - jetzt klappt es auch!

Quelle: HP: Creators Update: System reservierte Partition konnte nicht aktualisiert werden

APC Network Management Card: Someone is currently logged into the APC Management Web Server.

Wenn ich mich manchmal an meine APC UPS Network Management Card anmelden will um den Status der USV zu prüfen, erhalte ich folgende Fehlermeldung:
Someone is currently logged into the APC Management Web Server.
Scheinbar passiert das, wenn ich mich vergesse abzumelden und die Webseite einfach schließe.
Hierfür gibt es zwei Lösungswege:

1.) Lösung über Browser:
rufen Sie einfach folgende URL auf um das Logout zu "provozieren":
z.B: http://192.168.1.1/logoff.htm
Bitte passen Sie die IP oder den FQDN entsprechend an. Damit wird die laufende Session abgemeldet!

2.) Lösung per Telnet:

Öffnen Sie eine Command-Line und geben Sie folgenden Befehl ein (Telnet sollte installiert sein!):
telnet 192.168.1.1 23
Bitte passen Sie die IP oder den FQDN entsprechend an. Melden Sie sich mit Ihrem Username und Ihrem Passwort an. Auf der APC-Shell geben Sie dann einfach "quit" ein. Damit wird der Benutzer ebenfalls abgemeldet!
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz