Alle Beiträge von Malte

Cinnamon 2.6 unter Debian Jessie ohne Suspend- und Hibernate-Modus

Gestern fand ich heraus, dass Cinnamon von Debian Jessie bereits gnadenlos veraltet ist (Version 2.2.16[1], aktuell 2.6) und installierte prompt das neue Repository (es gibt jetzt bereits LMDE 2 „Betsy“[2], ich hatte noch das Repo aus LMDE 1) und upgradete auf das neueste Cinnamon.

Nach der Installation funktionierte alles prima, bis auf die Suspend- und Hibernate-Buttons im „Herunterfahren“-Dialog. Und ich erinnere mich, solch problem schonmal zu Xfce-Zeiten gehabt zu haben. Behoben hatte ich das damals mit einer radikalen Neuinstallation – worauf ich bei meinem aktuellen System aber nun wirklich keine Lust habe.

Cinnamon 2.6 unter Debian Jessie ohne Suspend- und Hibernate-Modus weiterlesen

icinga2 und icingaweb2 „icinga is currently not up and running“ unter Raspbian (Debian Jessie)

Gerade mal wieder einen interessanten Bug gefunden. Bei icinga2 unter dem aktuellsten Raspbian (Jessie) sorgt ein klitzekleiner Fehler dafür, dass das komplette icinga2 mit icingaweb2-Interface nach der Einrichtung nicht funktioniert. Vermutlich passiert das auch nur, wenn man MySQL als Backend verwendet.

Erscheint der in der Überschrift genannte Text, liegt das möglicherweise daran, dass die Datei „ido-mysql.conf“ aus dem Verzeichnis /etc/icinga2/features-available nicht automatisch nach /etc/icinga2/features-enabled verschoben wurde.

EDIT: Wie auch andere Anwendungen (z. B. der Apache-Webserver unter Debian) beinhaltet icinga2 eine Symlink-Funktion, damit die Datei nicht kopiert werden muss. Mittels

icinga2 feature enable ido-mysql

wird das Feature ido-mysql aktiviert, indem ein Symlink in /etc/icinga2/features-enabled angelegt wird. (Quelle)

icinga2 und icingaweb2 „icinga is currently not up and running“ unter Raspbian (Debian Jessie) weiterlesen

Bei Kolab 3.4 über Roundcube externe Mailadressen auswählbar machen

Im letzten Beitrag „Bei Kolab 3.4 Mails mit fremdem Absender versenden“ habe ich erklärt, wie man externe Mailadressen, die im Kolab-Webadmin-Panel hinzugefügt wurden, im Postfix zur Angabe als „Sender“ autorisiert. Am Ende habe ich geschrieben, dass man das noch weiterführen und Benutzern in Roundcube erlauben kann, externe Mailadressen auszuwählen.

In der Datei /etc/roundcubemail/kolab_auth.inc.php befindet sich unter „$config[‚kolab_auth_addressbook‘]“ ein untergeordnetes Array, welches so aussieht:

Bei Kolab 3.4 über Roundcube externe Mailadressen auswählbar machen weiterlesen

Bei Kolab 3.4 Mails mit fremdem Absender versenden

Möchte man mit dem Postfix der Kolab Groupware Mails mit einem Absender verschicken, der nicht der wirkliche Absender ist, kommt es standardmäßig zu einer Fehlermeldung. Mit relativ geringem Aufwand kann man via Kolab den Postfix dazu bringen, bestimmte Absender dennoch zuzulassen.

Doch zuerst: Obacht! Das senden mag dann zwar möglich sein, es kann aber passieren, dass der Server auf der Gegenseite die Mails im Zuge einer Schutzmaßnahme abweist – das können wir nicht umgehen.

Änderung der kolab.conf unter /etc/kolab/kolab.conf

Bei Kolab 3.4 Mails mit fremdem Absender versenden weiterlesen

Bei Kolab 3.4 (Multidomain-Setup) Domains richtig löschen

Möchte man bei Kolab Domains löschen, markiert man diese im Kolab-Webadmin-Panel als „deleted“. Damit werden Sie ausgegraut. Recherchen zufolge sollte nach einiger Zeit ein Cronjob ablaufen, der diese Domains dann entgültig aus dem LDAP-Server löscht.

Auch wenn die Kombination von Debian und Kolab nicht „so toll“ ist, habe ich diese im Einsatz. Unter Debian funktioniert dieser Cronjob nicht – sei auch dahin gestellt, ob er überhaupt existiert.

Bei Kolab 3.4 (Multidomain-Setup) Domains richtig löschen weiterlesen

Automatisch immer das „beste“ Debian-Repository verwenden

Das ist die Aufgabe des Redirectors unter deb.debian.org.

Der Redirector beurteilt die Quellen nach mehreren Faktoren und wirft die beste zurück, damit von dort eure Updates oder neue Pakete heruntergeladen werden.

Ich setze den Redirector jetzt ein. Vorher habe ich immer die Quellen eingetragen, die geografisch am nächsten waren. Zumeist ist das bei lokalen Angelegenheiten die TU Chemnitz und bei Dingen auf den Servern etwas in der Nähe von Düsseldorf.

Automatisch immer das „beste“ Debian-Repository verwenden weiterlesen