Hope This Helps

Ü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

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.

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:
Nachdem ich einen externen Benutzer von Exchange 2007 auf Exchange 2013 umgezogen hatte, hat dieser die Öffentlichen Ordner nicht mehr angezeigt bekommen. Der Zugriff erfolgt in der Migrations-Phase über die Discovery-Mailbox-Methode auf den Exchange 2007 (Erklärung siehe TechNet-Quelle unten). Von den intern Outlook-Clients funktioniert der Zugriff problemlos.
Nach einiger Recherche mittels Fiddler habe ich herausgefunden, dass bei dem Client ein zweiter Autodiscover läuft und hier auf die interne Domäen abgefragt wird (https:\\autodiscover.domäne.intern/autodiscover/autodiscover.xml).
Warum der zweite Autodiscover?

Lösung:
Des Rätsels Lösung ist ganz einfach. Dadurch, dass der Client auf die alten Öffentlichen Ordner auf dem Exchange 2007 über das Discovery-Postfach zugreift, läuft für dieses Postfach ebenfalls noch ein Autodiscover. Da ich dem Discovery-Postfach keine öffentliche Mail-Adresse zugewiesen habe (warum auch??), versucht der Client mittels Domäne der primärer Mail-Adresse (die ja intern ist) auf die Autodiscover-URL zuzugreifen (Erklärung wie der Client die Autodiscover-URL ermittelt finden Sie unten in den Quellen).

Die Lösung ist simpel:
Vergeben Sie der Public-Folder-Discovery-Mailbox eine öffentliche Mail-Adresse als Primäre Mail-Adresse und das Autodiscover wird vom externen Client erfolgreich sein.

Quellen/Hilfen:
Hope-This-Helps: Exchange Autodiscover: Wie wird die Autodiscover-URL ermittelt?

https://technet.microsoft.com/de-de/library/dn690134(v=exchg.150).aspx

Problem:
Für mich hat sich die Frage gestellt, wie der Outlook-Client (gerade außerhalb der Organisation über Outlook Anywhere) den Autodiscover FQDN bekommt, die er anfragt um seine Autodiscover-Informationen zu bekommen.

Lösung:
Der Outlook-Client geht hier nach einem fest definierten Schema vor, dass man wissen sollte, da man sonst nicht versteht, warum der Client keine Autodiscover-Informationen erhält.

WICHTIG VORWEG: Als Mail-Domäne nimmt der Client nicht die Windows-Domäne sondern die Mail-Domäne der PRIMÄREN Mail-Adresse des Benutzers
Das kann Probleme machen, wenn man einem Benutzer nur eine interne Mailadresse gibt oder dieser verschiedene externe Mail-Adresse zugewiesen bekommen hat. Vor allem, wenn der Benutzer per Outlook Anywhere zugreift und keinen SCP erreichen kann und somit die Autodiscover-URLS abklappert.

Folgenden Ablauf durchläuft der Client für das Autodiscover-Ermittlung:
1.) Abfrage SCP (Service Connection Point) aus dem AD (ClientAccessServer AutodiscoverServiceInternalURI)
2.) Anfrage auf https://mail-domäne/autodiscover/autodiscover.xml
3.) Anfrage auf https://autodiscover.mail-domäne/autodiscover/autodiscover.xml
4.) Anfrage auf http://autodiscover.mail-domäne/autodiscover/autodiscover.xml
5.) Abfrage eines SRV-Records
6.) Verwendung der lokalen autodiscover.xml, soweit bereits vorhanden

Quelle: SebastianHetzel.net: Exchange Autodiscover