Category: network

refused notify from non-master – Fehlermeldung beim Starten von bind

Folgendes Phänomen: Beim Starten des named auf einem Secondary sieht man in den Logs Fehlermeldungen der Art refused notify from non-master: 1.2.3.4#port. Dabei ist 1.2.3.4 die IP-Adresse des Secondary.

Das liegt daran, daß bind beim Starten dem eigenen Daemon auf der gleichen Maschine notify-Nachrichten schickt um zu sehen, ob seine Zonen aktuell sind. Man muß in der Option allow-notify also zusätzlich zum Master auch dem eigenen Secondary Notifies zulassen.
Continue reading “refused notify from non-master – Fehlermeldung beim Starten von bind”

mutt und msmtp in einem disconnected/offline-Szenario

Folgendes Szenario: Ein Notebook das nicht immer Internet-Verbindung hat. Verwendet werden an Software msmtp, mutt und offlineimap. Gewünschter Zielzustand ist es, Mails für verschiedene Accounts offline schreiben zu können, in einer Queue zu halten und beim online-Gehen an die entsprechenden SMTP-Server abzuliefern.

Continue reading “mutt und msmtp in einem disconnected/offline-Szenario”

Mit dbus und NetworkManager im Script feststellen, ob Netzwerk verfügbar ist

Unter Linux kann man mit dem dbus-send-Tool wie folgt feststellen, ob aus Sicht des NetworkManager ein Netzwerk verfügbar ist:

dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager \
--type=method_call /org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.state

Ein Rückgabewert von 3 bedeutet "Netzwerk verbunden". Wie gesagt ist das die Sichtweise des NetworkManager, d.h. es muß nicht unbedingt IP-Konnektivität vorhanden sein. Im Speziellen wird der NetworkManager auch dann eine 3 zurückliefern, wenn das Netzwerkkabel eingesteckt ist, statische IP-Adressen konfiguriert sind, sich der Rechner aber im falschen LAN befindet.

Debugging Exchange IMAP sessions with openssl s_client

I was just curious about the fact that openssl s_client -connect exchangeserver:993 was not working the way I expected it to work. I saw the greeting of the server but wasn’t able to do send any commands such as A1 CAPABILITY. The same worked for all other servers in the past.

Interestingly enough telnet exchangeserver 143 worked, but for obvious reasons unencrypted connections are not an option.

The reason behind is that in fact IMAP and telnet protocol and uses CRLF as line endings and Exchange servers are a bit picky on this specific point. As openssl is not a native client like telnet it sends whatever the terminal uses.

However there is already an solution builtin openssl s_client. Just pass the additional crlf option:

$ openssl s_client -connect exchangeserver:993 -crlf