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
Der Fehler tritt auch manchmal auf wenn der Linux Server in QEMU installiert ist und die lokale Firewall Einstellung das forwarding nicht zulässt.

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

SSH : Tunneln zu Maschine hinter Jumphost

Da ich mir das nie merken kann schreib ich das hier mal auf ;-)
Ich möchte die Status Seite eines haproxys in einem Netz anzeigen das nur über einen Jumphost erreichbar ist. Dafür braucht man 2 Tunnel einen auf den Jumphost und dann von Jumphost auf das Zielsystem. Der Jumphost und das Zielsystem müssen mit Key verbunden sein das ein Tunnel möglich ist. ( SSH Login mit authorized_keys )
ssh -L 9090:localhost:9090 USERNAME@JUMPHOST -i SSHKEY ssh -L 9090:localhost:9090 -N USERNAME@TARGETSYSTEM

Ubuntu ( 16.04 / 18.04 ) : SQL Developer von Oracle installieren

Ich bin seit langem nur noch auf Linux unterwegs und habe jetzt den SQL Developer von Oracle gebraucht. Unter Windows ist das ja nur eine setup.exe doppelklicken und durchklicken unter Ubuntu gibt es ein bisschen mehr das man beachten sollte.
So habe ich den SQL Developer unter Ubuntu 16.04 und Ubuntu 18.04 installiert.
Als erstes patchen wir das Ubuntu durch und installieren das openjdk-8-jdk (noch ist der Oracle SQL Developer nur bis Java 9.1 stable)
sudo apt update && sudo apt dist-upgrade -y && sudo apt install openjdk-8-jdk
Dann laden wir die gewünschte Version der Oracle SQL Developers von dieser Seite : Oracle SQL Developer (Other Platforms)
Jetzt installieren wir das Tool durch diese Befehle.
sudo unzip ~/Downloads/sqldeveloper/sqldeveloper-18.4.0-376.1900-no-jre.zip -d /usr/local/bin/
sudo ln -s /usr/local/bin/sqldeveloper/sqldeveloper.sh /bin/sqldeveloper
sudo sed -i 's#"`dirname $0`"#/usr/local/bin/sqldeveloper#g' /usr/local/bin/sqldeveloper/sqldeveloper.sh
Jetzt sollte der sqldeveloper einfach starten wenn man ihn im Terminal startet (durch sqldeveloper).Eventuell werdet ihr beim starten des SQL Developers nach der JDK Installation gefragt dann könnt ihr diesen Pfad angeben
/usr/lib/jvm/java-8-openjdk-amd64
sollte hier etwas schief gehen könnt ihr den Pfad direkt in den Configdateien überprüfen. [ username ] ist hier natürlich euer Benutzername.
  /home/[ username ]/.sqldeveloper/18.4.0/product.conf
  /usr/local/bin/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf
Ich persönlich möchte den SQL Developer nicht immer aus dem Terminal starten deswegen habe ich mir noch eine .desktop datei angelegt.
sudo -s
echo -e "[Desktop Entry]\nName=Oracle SQL Developer\nExec=/usr/local/bin/sqldeveloper/sqldeveloper.sh\nIcon=/usr/local/bin/sqldeveloper/icon.png\nCategories=Development;Office;Science\nType=Application\nStartupNotify=false" > /usr/share/applications/sqldeveloper.desktop
Oracle SQL Developer
Quellen:
https://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html

AWS : Cloudwatch Agent & collectd

Cloudwatch liefert ja schon von Haus aus viele Metriken will man jedoch "tiefer" ins System schauen empfiehlt es sich einen anderen Agent zu verwenden (zusätzlich oder den Cloudwatch Agent nur als Bridge)

Ich habe mich für den Weg entschlossen die Metriken von collectd üder den cloudwatch agent in Cloudwatch zu reporten. Dort können dann wie gewohnt Alarme definiert werden.

Als erstes braucht man einen IAM User (Programmatic access) und eine IAM Role die das Recht besitzen in Cloudwatch zu reporten.
IAM UserIAM Role

Die Role "ServerMonitoring" weißt man dann den EC2 Instanzen zu die in das Monitoring aufgenommen werden müssen.

attach iam role
attach iam role to instance

Jetzt müssen die benötigten Packete heruntergeladen & installiert werden. Mein Beispiel ist für Debian 8 und Debian 9 geeignet. Bei anderen Linux Systemen ist der Ablauf etwas anders. Der Cloudwatch Agent kann auf der Seite ( Install Cloudwatch Agent ) für andere Systeme heruntergeladen werden. Das Github Repo für die collectd-cloudwatch Bridge ist hier GitHub - awslabs
mkdir -p ~/downloads
cd ~/downloads
wget https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
wget https://github.com/awslabs/collectd-cloudwatch/archive/master.zip
dpkg -i amazon-cloudwatch-agent.deb
unzip master.zip
Unter Debian muss man das setup.py script leicht abändern ;-)
cd collectd-cloudwatch-master/src/
vi setup.py
dort suchen nach
DISTRIBUTION_TO_INSTALLER = {
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}
ersetze mit
DISTRIBUTION_TO_INSTALLER = {
    "Debian GNU": APT_INSTALL_COMMAND,
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}
Dann muss collectd installiert werden und die aws cli konfiguriert werden
apt install collectd
aws configure (AWS Key & Security Key von monitoring user angeben)
jetzt installieren wir noch die bridge
chmod u+x ~/downloads/collectd-cloudwatch-master/src/setup.py 
~/downloads/collectd-cloudwatch-master/src/setup.py 
jetzt wird das alles noch konfiguriert
/opt/aws/amazon-cloudwatch-agent/amazon-cloudwatch-agent-config-wizard
vi /etc/collectd/collectd.conf
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s
dann alles neu starten
systemctl restart amazon-cloudwatch-agent
systemctl restart collectd
es gibt im plugin cloudwatch-collectd zwei Dateien die jetzt steuern was bei cloudwatch ankommt und was nicht. In der Datei /opt/collectd-plugins/cloudwatch/config/blocked_metrics sind alle aktuell erkannten Metriken gelistet. Möchte man jetzt z.B. das der Speicher (memory) an cloudwatch reportet wird so muss dieser in der Datei whitelist.conf eingetragen werden. z.B. für Speicher (memory--.*) ob eure Werte ankommen oder nicht seht ihr nach einer Tasse Kaffee oder Tee hier in cloudwatch AWS Collectd Metriken
die cloudwatch metriken liefern normalerweise
df-root-percent_bytes-used
memory--percent-used
swap--percent-used
cpu--percent-active
Das Ergebnis seht ihr hier :AWS_MEMORY Cloudwatch collectd
für das debugen sollte dieses Log verwendert werden.
less /var/log/collectd.log

Quellen :
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-first-instance.html
https://github.com/awslabs/collectd-cloudwatch
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz