Hope This Helps

Wir hatten hier das Problem das die RDP Session nicht mehr zu starten ist.

Es ist immer dieser Fehler aufgetreten.


Die Maschinen laufen in der AWS und leider war der Session Manager auch noch nicht am Start. z.G. war auf der Maschine der SSM-Agent bereits installiert, wenn nicht kann man das so erledigen, natürlich bevor RDP kaputt ist (Install SSM Agent on Windows)

Die Maschine muss natürlich in SSM aufgeführt sein. Sollte das nicht der Fall sein einfach mal überprüfen ob die richtigen IAM Rollen auf den Maschinen angewendet werden. Für eine schnelle Fehlerbehebung hatte ich kurzfristig SSMFullAccess verwendet.


Jetzt startet man den AWS System Manager und führt dort das Dokument "AWS-RunPowerShellScript" gegen die kaputte Maschine aus.


Unter Run a command kann man im Feld Command parameters kann man ein Powershell Script rein werfen das gegen die Maschine läuft.


hier das skript

$AllCertificates = (Get-ChildItem -Path 'Cert:\LocalMachine\My' |
Where-Object -FilterScript {
$_.Subject -Match $env:Computername } |
Select-Object Thumbprint, Subject, NotBefore, NotAfter, Issuer |
Sort-Object -Property NotAfter -Descending)
foreach ($Cert in $AllCertificates)
{
Write-Output $Cert
}

Alle folgenden Skript werden nach dem selben Muster ausgeführt.

1.) Auslesen des Zertifikates

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"

unter SSLCertificateSHA1Hash steht der Thumbprint

2.) Setzen des Zertifikates

$RDPGeneralSettings = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'")
Set-WmiInstance -path $RDPGeneralSettings.__path -argument @{SSLCertificateSHA1Hash = "NEUER THUMBPRINT"}

3.) Restart des RDP Dienstes

Restart-Service -Name TermService -force

Kurz noch zur Erklärung , mit diesem Powershell hab ich mir die Events angeschaut die mich auf die richtige Fährte gebracht haben.

Get-EventLog -LogName System -After 6/9/2021 -Before 9/9/2021 -EntryType Error | Format-List

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

Problem : beim Versuch ein Amazon Linux AMI erscheint diese Meldung

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib64/python2.7/dist-packages/pycurl.so: undefined symbol: CRYPTO_num_locks

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.12 (default, Nov  2 2017, 19:20:38) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)]

If you cannot solve this problem yourself, please go to 
the yum faq at:
  http://yum.baseurl.org/wiki/Faq

Lösung : Überprüfen auf welche libs curl verweist

ldconfig -p -N -X | grep curl

Output :

	libcurl.so.4 (libc6,x86-64) => /usr/lib64/libcurl.so.4

dann prüfen wir das selbe beim python modul

ldd /usr/lib64/python2.7/dist-packages/pycurl.so
	linux-vdso.so.1 =>  (0x00007ffe65d10000)
	libcurl.so.4 => /libs/test/libcurl.so.4 (0x00007f5edd1e7000) <----- GRUND !!
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f5edce0b000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5edcbef000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f5edc82b000)
	libssl.so.1.1 => /libs/test/libssl.so.1.1 (0x00007f5edc5bd000)
	libcrypto.so.1.1 => /libs/test/libcrypto.so.1.1 (0x00007f5edc153000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f5edbf4f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f5edbd39000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f5edbb31000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f5edb92e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f5edb62c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5edd65e000)

Die Pfade sind hier unterschiedlich, ich habe hier einfach die lib von dem Entwickler umbenannt und die andere rein gelinkt.

mv /libs/test/libcurl.so.4 /libs/test/libcurl.so.4.dev ; ln -s /usr/lib64/libcurl.so.4 /libs/test/libcurl.so.4

Dann ging YUM wieder durch.

Quelle : https://access.redhat.com/solutions/641093

Problem : Man benötigt bei einem Webserver hinter einem AWS Application Loadbalancer die RemoteIP des Clients. Das Vorgehen ist eigentlich für alle LBs gültig.

Lösung : Ich verwende hier Debian auf anderen Distries sollte es ähnlich sein.
Es wird das Modul remoteip_module benötigt.

a2enmod remoteip

Dann legt man eine neue config an und aktiviert diese.

vi /etc/apache2/conf-available/loadbalancer_remoteip.conf

dort diesen Inhalt einfügen

# Settings for mod_remoteip:
# the Header X-Forwarded-For comes from AWS Application Loadbalancer
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy xxx.xxx.xxx.xxx # 1.Loadbalancer IP Intern
RemoteIPInternalProxy xxx.xxx.xxx.xxx # 2.Loadbalancer IP Intern usw.
# dont log healthy checks
SetEnvIf User-Agent ELB-HealthChecker nolog

die config aktiviert man mit

a2enconf loadbalancer_remoteip

dann anpassen der apache2.conf

# mod_remoteip LogFormat
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

in der VHost der Website dann das CustomLog anpassen bzw. eintragen

CustomLog "/var/log/apache2/site/access.log" combined env=!nolog

jetzt kann man mal testen ob die config so läuft

apache2ctl configtest

der output sollte lauten

root@xxx.xxx.xxx.xxx:/> apache2ctl configtest
Syntax OK

dann den Apache neu starten und überprüfen ob alles so läuft wie es soll

systemctl restart apache2
less +F -S /var/log/apache2/site/access.log

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

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