Hope This Helps

Erstmal was ist ntop eigentlich.

ntop (network top) ist eine quelloffene und freie Software, mit der Netzwerkverkehr mitgeschnitten und analysiert werden kann.

Quelle : https://de.wikipedia.org/wiki/Ntop

Diese Software kann schön genutzt werden um z.B. auf einem Gateway oder einer Firewall zu monitoren wo der Traffic so hin läuft. Es werden schon ein ganzer Pack Plugins mitgeliefert aber eigene Anwendungen werden nicht erkannt. Ich habe hier eine kleine Anwendung geschrieben die über udp Port 5404 Daten versendet. Jetzt möchte ich natürlich das auch in meinem Gateway angezeigt bekommen um zu beurteilen wieviel Traffic darüber läuft. Das kann man relativ einfach realisieren jedoch hat es mir auch etwas Arbeit gekostet diesen einfachen Weg zu finden

Erstellt eine Datei in der später die Protokolle hinzugefügt werden.

touch /usr/share/ntopng/httpdocs/protocol-app.txt

Jetzt füge ich meine Anwendung hinzu, das diese auch im Webfrontend nicht mehr unter UNKNOWN läuft.

echo "udp:5404 @MyApp" > /usr/share/ntopng/httpdocs/protocol-app.txt 

dann müssen wir noch dafür sorgen das diese Datei auch beim Start von ntopng gelesen wird dazu editieren wir das configfile unter /etc/ntopng mit dem Befehl.

echo "-p /usr/share/ntopng/httpdocs/protocol-app.txt" >> /etc/ntopng/ntopng.conf

Dann starten wir den Server neu mit dem Befehl

service ntopng restart

Wenn dann bei den Protokollen MyApp steht wurde alles richtig gemacht

Mehr Infos :
http://www.ntop.org/ndpi/configuring-ndpi-for-custom-protocol-detection/

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 : 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