Hope This Helps

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.

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.


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

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

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

Quellen:
https://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html

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.


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




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
die cloudwatch metriken liefern normalerweise

df-root-percent_bytes-used
memory--percent-used
swap--percent-used
cpu--percent-active

Das Ergebnis seht ihr hier :
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

Mein Thunderbird Lightning konnte nach dem Update meiner Server und der Nextcloud nicht mehr auf die Kontakte und dem Kalender in der Nextcloud zugreifen. Nachdem ich etwas recherchiert habe konnte ich den Fehler lösen indem ich network.cookie.same-site.enabled auf false gesetzt habe.
Dazu geht ihr in Thunderbird auf Edit -> Preferences -> Advanced -> Config Editor dort sucht ihr network.cookie.same-site.enabled und setzt den Wert auf false. Nach einem Neustart von Thunderbird sollte alles wieder funktionieren. So wie es aussieht wird das auch erst in Nextcloud 15 gefixt. (NC15 - Fix)
https://github.com/nextcloud/server/issues/10134
https://bugzilla.mozilla.org/show_bug.cgi?id=1468912