Bash : Prüfen ob Remote File vorhanden ist

Überprüfen ob ein Remote File vorhanden ist oder nicht.
if ssh USER@HOST "test -e DATEI_INCL_PFAD"; then
    echo "remote file ist DATEI_INCL_PFAD vorhanden"
else
    echo "remote file DATEI_INCL_PFAD ist NICHT vorhanden"
fi

Bash : SSH Skript mit eigener known_hosts

Problem : Wir arbeiten hier auf einem Server mit mehreren Usern, es kommt immer wieder vor das jemand die known_hosts überschreibt. Den Schuldigen haben wir noch nicht gefunden ;-) Also verwenden wir jetzt in unseren Skripts eigene known_hosts files.

Lösung :
Ich habe mir angewöhnt im Skript Ordner einen Ordner ssh anzulegen in dem dann die known_hosts liegt.
Somit bin ich unabhängig von anderen.
Setzen einer Variable im Skript
SSH_KNOWN_HOST="-o ConnectTimeout=30 -o UserKnownHostsFile=$(dirname $(readlink -f ${0}))/ssh/known_hosts"
Im Skript selbst kann man das so verwenden.
ssh ${SSH_KNOWN_HOST} USER@HOSTNAME
Da sftp und ssh die selben Parameter kennen kann man diese Variable beim Aufruf von ssh und sftp verwenden.

AWS : Mount eines S3 Buckets unter Debian

Installation des benötigten Packetes auf der Debian Kiste.
apt install s3fs
Erstellen einer Passwort Datei im Home Directory
touch ~/.passwd-s3fs
echo "accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Wenn mehrere Amazon S3 Buckets verwendet werden müssen kann auch der Name des Buckets vor den Zugangsdaten hinzugefügt werden.
echo "bucketName:accessKeyId:secretAccessKey" > ~/.passwd-s3fs
Da hier sensible Zugangsdaten in der Datei stehen müssen die Rechte auf 600 geändert werden !
chmod 600 ~/.passwd-s3fs
Wenn alles richtig ist kann das Amazon S3 Buckets gemountet werden
s3fs [BUCKET-NAME] [MOUNT-POINT]
Der Eintrag für /etc/fstab sieht dann so aus, hier ist debug noch aktiv. Das sollte für einen Betrieb in der Produktion deaktiviert werden.
# MOUNT S3 MIT DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other,dbglevel=dbg,curldbg 0 0
# MOUNT S3 OHNE DEBUG
[BUCKET-NAME] [MOUNTPOINT] fuse.s3fs _netdev,allow_other 0 0

Quellen :
https://cloud.netapp.com/blog/amazon-s3-as-a-file-system
https://github.com/s3fs-fuse/s3fs-fuse/wiki/Fuse-Over-Amazon

Debian 9 : hohe CPU Last durch systemd-journald

Problem : Ein Server mit Debian 9 hat eine durchgehend hohe Systemlast. Beim prüfen der Last fällt auf das "systemd-journald" der Grund ist. Nachdem ich mit journalctl -xe nachgeschaut habe woran das liegen könnte sind mir die folgenden Zeilen aufgefallen die sich immer wieder wiederholen.
Sep 08 14:33:27 HOSTNAME sh[293]: /sbin/dhclient-script: 28: .: Can't open /usr/share/sendmail/dynamic
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPDECLINE on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPDECLINE on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPREQUEST of XXX.XXX.XXX.XXX on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPREQUEST of XXX.XXX.XXX.XXX on eth0 to 255.255.255.255 port 67
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPOFFER of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPOFFER of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME sh[293]: DHCPACK of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME dhclient[302]: DHCPACK of XXX.XXX.XXX.XXX from XXX.XXX.XXX.XXX
Sep 08 14:33:27 HOSTNAME sh[293]: RTNETLINK answers: File exists

Der Grund für den andauernden Neustart Wahn des dhclient war diese Zeile
Sep 08 14:33:27 HOSTNAME sh[293]: /sbin/dhclient-script: 28: .: Can't open /usr/share/sendmail/dynamic
Lösung : In meinem Fall lief ein Skript Amok.
/etc/dhcp/dhclient-exit-hooks.d/sendmail
Da ich hier sowieso auf eine andere Art der Überwachung setzte hab ich das Skript einfach mit folgenden Befehl gelöscht
rm /etc/dhcp/dhclient-exit-hooks.d/sendmail
seitdem ist die Systemlast wieder auf dem gewohnten Stand unterwegs. Wenn man das allerdings benötigt kann man auch diesen Befehl in den Terminal hämmern.
mkdir -p /usr/share/sendmail && touch /usr/share/sendmail/dynamic

AWS : automatisierter start der aws instanzen

Problem : Automatisches Starten der Instanzen bei AWS
Lösung : Man lässt dieses Skript auf einer Maschine/Instanz laufen auf der die aws cli konfiguriert ist.
#!/bin/bash
set -o nounset
set -o pipefail
# Script startet alle definierten Maschinen
AWS_PATH="/root/.local/bin/"
# -----------------------------------------------------------
# Definieren der Maschinen die gestartet werden müssen
# -----------------------------------------------------------
# z.B. declare -a TO_START=("i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx" "i-xxxxxxxxxxxxxxxxx")
declare -a TO_START=("")
# ------------------------------------------------------------
# nichts mehr ändern
# ------------------------------------------------------------
LOG_PATH="$(dirname $(readlink -f $0))/logs"
LOG_FILE="$(date +%Y%m%d)-awscli.log"
# ------------------------------------------------------------
# Funktionen
# ------------------------------------------------------------
function logger () {
        mkdir -p ${LOG_PATH}
        if [ -z ${2} ]; then
                STATI="INFO"
        else
                STATI="${2}"
        fi
        echo "$(date +%Y-%m-%d) | $(date +%R) | ${STATI} | ${1}" >> ${LOG_PATH}/${LOG_FILE}
}
# ------------------------------------------------------------
logger "Starte -> ${0##*/}" "INFO"
cnt=${#TO_START[@]}
for ((i = 0 ; i < cnt ; i++ )); do
        logger "${TO_START[i]} wird gestartet" "INFO"
        ${AWS_PATH}aws ec2 start-instances --instance-ids ${TO_START[i]} > /dev/null 2>&1
done
logger "Beende -> ${0##*/}" "INFO"
exit 0
“Wenn du dir die Anwender deiner Programme als Idioten vorstellst, werden auch nur Idioten deine Programme verwenden.”
Linus Torvalds