invis_server_wiki:bugs

Dies ist eine alte Version des Dokuments!


Bugs

Da wir derzeit keinen eigenen Bugtracker verwenden, wird diese Seite einen Überblick über bekannte Bugs im invis-Server liefern.

Wer einen Bug melden möchte sollte dies über unsere Users-Mailingliste tun: https://ml.invis-server.org/mailman/listinfo/invis-user

Beschreibung

Postfix kann nicht auf Informationen im Active-Directory zugreifen. Dies behindert interne und externe Email-Zustellung.

Version

invisAD Version 10.0

manuelle Beseitigung

In auf „.cf“ endenden Dateien im Verzeichnis

/etc/postfix

wurde jeweils beim darin angegebenen Zugangs-Account „ldap.admin@domain“ die Dummy-Domain „invis-net.loc“ nicht gegen die auf dem System tatsächlich verwendete Domain getauscht. Die Dateien sind einfach im Editor zu ändern. Danach sollte alles funktionieren.

Status

Ist in der unstable Version invisAD 10.1 bereits gefixt.

Beschreibung

Der Dienst zarafa-search startet nicht.

Version

invisAD Version 10.0

manuelle Beseitigung

Ursache ist, dass das zugehörige RPM-Paket scheinbar nicht alle Abhängigkeiten aufführt. Zur Beseitigung des Fehlers sind die Pakete „python-zarafa“ und „python-xapian“ nachzuinstallieren.

Weiterhin steht im init-Script des Dienstes ein falscher Pfad. In

/etc/init.d/zarafa-search

ist Zeile 21 wie folgt zu ändern:

SEARCHPROGRAM=/usr/bin/zarafa-search

Danach muss Systemd über diese Änderung informiert und der Dienst gestartet werden:

linux:~ # systemctl daemon-reload
linux:~ # systemctl restart zarafa-search.service

Status

Ist in der unstable Version invisAD 10.1 bereits gefixt.

Das Paket-Abhängigkeitsproblem wurde jetzt auch in den Zarafa-Paketen gefixt, dabei wurde allerdings das Paket „zarafa-search“ in „zarafa-search-plus“ umbenannt. Bei einer invis-Server Neuinstallation ist dies in der invis-Server Paketliste zu ändern. Nach der Installation des Pakets „invisAD-setup“ ist die Änderung in Datei

/var/lib/sine/zypper-package-list/zarafa

vorzunehmen.

Der fehlerhafte Pfad im zarafa-search init-Script ist leider noch vorhanden.

Beschreibung

Windows Clients synchronisieren Ihre Systemzeit nicht mit dem Domain-Controller.

Version

invisAD Version 10.0 & 10.1

manuelle Beseitigung

In invisAD Version 10.1 sind einige der Schritte bereits während der Installation vorgenommen worden.

Legen Sie zunächst das Verzeichnis

/var/lib/ntp/var/lib/samba/ntp_signd

an und versehen Sie dieses wie nachfolgend gezeigt, mit den entsprechenden Rechten:

linux:~ # mkdir -p /var/lib/ntp/var/lib/samba/ntp_signd
linux:~ # chown .ntp /var/lib/ntp/var/lib/samba/ntp_signd
linux:~ # chmod 0750 $sockdir /var/lib/ntp/var/lib/samba/ntp_signd

Tragen Sie anschließend in der Datei

/etc/samba/smb.invis.conf

folgende Zeile ein:

# socket fuer NTP-Server etablieren
ntp signd socket directory = /var/lib/ntp/var/lib/samba/ntp_signd

Tragen anschließend amm Ende der Datei

/etc/ntp

folgende Zeilen ein:

ntpsigndsocket /var/lib/samba/ntp_signd
restrict default mssntp

Ändern Sie jetzt in Datei

/etc/sysconfig/ntp

den Wert der Variable NTPD_RUN_CHROOTED von „no“ auf „yes“.

Status

Alle Schritte bis auf den Letzten sind in Version 10.1 bereits vorgenommen. Der letzte Schritt ist abhängig von einem openSUSE Bug und daher noch nicht automatisch behoben.

https://bugzilla.opensuse.org/show_bug.cgi?id=932456

Beschreibung

Das Script sine bricht bei der Installation der Zarafa-Pakete ab.

Version

invisAD Version 10.1 & 10.2

manuelle Beseitigung

Ursache ist eine Änderung der Paketnamen. Um das Problem manuell zu beheben mus in Datei

/var/lib/sine//zypper-package-lists/zarafa

die Zeile „zarafa-base“ in „zarafa“ geändert werden. Danach kann sine fortgesetzt werden.

Status

invisAD 10.1: fixed (ab rev. 14)

invisAD 10.2: fixed (ab rev. 10)

Beschreibung

invis Server arbeiten bei der Email-Zustellung mit internen und externen Email-Adressen und einem System zur Übersetzung der Adressen ineinander, je nach dem wohin eine Email gesendet wird. Absicht dahinter ist, dass Emails, die an lokale Empfänger gerichtet sind bei deren Zustellung nicht den Umweg über den Mailserver des Mail-Providers laufen sollen.

Das Problem dabei war bzw. ist, dass unter bestimmten Voraussetzungen externe Benutzer, die internen Adressen von invis-Server Nutzern zu Gesicht bekommen aber an diese natürlich keine Mails senden können, da sie im Internet keine Gültigkeit haben.

Im selben Kontext taucht in Verbindung mit Zarafa ein weiterer Fehler auf. Nach dem invis-Server Setup kennt Zarafa lediglich die interne Email-Adresse eines Users. Wird jetzt etwa ein Termin angelegt, welcher eine Termineinladung an einen externen Teilnehmer versendet, taucht beim Empfänger die interne Email-Adresse des Termin-Organisators in der Termineinladung auf. Ebenfalls kein sinnvoller Zustand.

Version

invisAD Version 10.1 & 10.2 und älter

manuelle Beseitigung

Um „interne Emailadressen“ vollständig vor den Augen der Benutzer zu verstecken, sie aber dennoch für die lokale Mailzustellung zu nutzen sind mehrere Schritte notwendig. Die folgende Anleitung bezieht sich auf invis-Server Active Directory mit Zarafa als Groupware. Die folgende Anleitung behebt beide beschriebenen Missstände.

1.

Das lokalisieren lokaler Postfächer muss angepasst werden. Erstellen Sie eine LDAP-Abfrage-Datei für Postfix mit folgendem Inhalt, angepasst an Ihre Umgebung:

server_host = ldap://localhost:389
search_base = cn=AdditionalUserInformation,cn=invis-server,DC=invis-net,DC=loc
version = 3
bind = yes
bind_dn = ldap.admin@invis-net.loc
bind_pw = ldap-admin-secret
query_filter = (name=%s)
result_attribute = fspLocalMailAddress

Speichern Sie die Datei unter dem Namen „ldap-users2.cf“ im Varzeichnis

/etc/postfix

ab und ergänzen Sie in der Datei

/etc/postfix/main.cf

die folgende Zeile so, dass die soeben erstellte Datei als erste berücksichtigt wird.

virtual_mailbox_maps = ldap:/etc/postfix/ldap-users2.cf,
                       ldap:/etc/postfix/ldap-users.cf

Die ursprüngliche Datei „ldap-users.cf“ muss erhalten bleiben, damit auch rein interne „Mailkonten“ funktionieren.

2.

Entfernen Sie den Verweis auf die Datei

/etc/postfix/ldap-aliases.cf

aus der Postfix Konfiguration (main.cf). Aus:

virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf,
                     ldap:/etc/postfix/ldap-groups.cf,
                     hash:/etc/postfix/virtual

wird:

virtual_alias_maps = ldap:/etc/postfix/ldap-groups.cf,
                     hash:/etc/postfix/virtual

3.

Abschließend muss dass Umschreiben der Empfängeradresse so abgeändert werden, dass lediglich die Empfänger-Adresse im Mail-Envelope, nicht aber im Mail-Header umgeschrieben wird.

Fügen Sie in der Datei

/etc/postfix/main.cf

die folgende Zeile ein:

recipient_canonical_classes = envelope_recipient

Damit wird die interne Adresse eines Email-Empfängers beim Adresstausch durch Postfix nicht mehr in den Mail-Header eingetragen, ist also für den Empfänger einer Mail, egal ob intern oder extern unsichtbar.

4.

Abschließend sollte noch die exterene Mailadresse, aller User als Haupadresse des Zarafa-Kontos eingetragen werden. Das geht am einfachsten mit Hilfe der Microsoft'schen Remote-Server-Tools, soweit dafür die Zarafa-AD Erweiterung dafür installiert ist. Hier ist im Reiter „Zarafa“ eines Benutzerkontos die interne Email-Adresse hinzuzufügen.

Alternativ kann die Änderung auch über phpLDAPAdmin vorgenommen werden. Es ist einfach die externe Email-Adresse für das Attribut „E-Mail“ (mail) zu setzen und die interne Adresse für das Attribut „otherMailbox“.

Dieser Schritt muss immer manuell vorgenommen werden, da die externen Mail-Adressen der User zum Zeitpunkt des invis-Server Setups ja noch unbekannt sind.

5.

Getestet wird das Setup mit dem Tool postmap auf der Kommandozeile des invis-Servers. Es sind folgende 4 Abfragen zu testen. Achten Sie bitte genau auf den jeweiligen Query-String (hinter -q) und die zu nutzende LDAP-Datei (hinter -f)! Die Abfragen sind sich sehr ähnlich, aber nicht identisch.

→ Abfrage 1:

invisad:~ # postmap -q stefan@intern-net.loc -f ldap:/etc/postfix/ldap-aliases.cf
stefan.schaefer@domain.tld

Die erste Abfrage muss die externe EMail-Adresse eines Benutzers liefern.

→ Abfrage 2:

invisad:~ # postmap -q stefan.schaefer@domain.tld -f ldap:/etc/postfix/ldap-users2.cf
stefan@intern-net.loc

Die zweite Abfrage muss die interne EMail-Adresse eines Benutzers liefern.

→ Abfrage 3:

invisad:~ # postmap -q stefan.schaefer@domain.tld -f ldap:/etc/postfix/ldap-users.cf
stefan.schaefer@domain.tld

Die dritte Abfrage muss die externe EMail-Adresse eines Benutzers bestätigen.

→ Abfrage 4:

invisad:~ # postmap -q stefan@intern-net.loc -f ldap:/etc/postfix/ldap-users.cf

Die vierte Abfrage darf keine Antwort liefern.

Status

Stand 25.07.2015: gefixt

Direkt nach der Installation des invis-Servers startet der Apache Webserver nicht.

Ursache ist, dass „phpMyAdmin“ die Konfigurationsdirektive „ifVersion“ verwendet. Voraussetzung dafür ist, dass das Apache Modil „mod_version“ geladen ist, was unter openSUSE 13.1 nicht per default der Fall ist.

Version

invisAD Version 10.1 & 10.2 und älter

manuelle Behebung

Das Modul „mod_version“ muss geladen werden:

linux:~ # a2enmod version

Danach kann der Apache Webserver ganz normal gestartete werden:

linux:~ # systemctl restart apache2.service

Status

Stand 25.07.2015: gefixt

Kurz nach Abschluss des sine Moduls „sysprep“ häufen sich Fehlermeldungen und das invis Setup lässt sich nicht fortsetzen.

Ursächlich dafür sind Probleme mit dem systemd, vermutlich bedingt durch Software-Updates.

Version

invis AD Version 10.3

manuelle Behebung

Neustart bzw. Reset des Systems. Danach läuft das System ohne Probleme.

Status

Offen. Lässt sich ohne genaue Kenntnis der Ursache nicht beheben.

Update Es scheint, dass der Fehler in der kommenden openSUSE Version 42.1 nicht mehr auftritt. (invis AD 10.4)

Beschreibung

Der Dienst zarafa-search lässt sich nicht stoppen und öffnete teilweise mehr Sockets als zulässig. Letzteres führt dazu, dass Zarafa insgesamt nicht mehr funktioniert.

Version

Alle invisAD Versionen bei denen Zarafa in Version 7.2.0 installiert ist.

manuelle Beseitigung

Um Zarafa-Search zu beenden müssen die laufenden Prozesse gefunden und manuell mit kill beendet werden. Auch das manuelle Löschen des Sockets

/var/run/zarafa-search

ist ggf. notwendig.

Sollte das nicht genügen ist ein Neustart des gesamten Servers erforderlich.

Status

In invisAD 10.0 bis 10.2: offen

In invisAD 10.3 gibt es mit killzsearch ein Script zum beenden des Dienstes. Wer regelmäßig das Problem mit zu vielen offenen Sockets hat, sollte das Script per cronjob einmal pro Nacht aufrufen und danach den Search-Dienst neu starten.

Mit Version 7.2.1 soll der Fehler angeblich behoben sein.

Beschreibung

Der Dienst sernet-samba-ad startet nach dem ersten Reboot im Anschluss an die invis-Server Installation nicht mehr. Ursache dafür ist das Security-Framework Apparmor. Diesem fehlt einfach ein entsprechendes Profil.

Version

invisAD 10.4 (openSUSE Leap 42.1)

manuelle Beseitigung

Bis es ein Apparmor Profil für Sernet-Samba gibt lässt sich Abhilfe nur dadurch schaffen, dass Apparmor deaktiviert wird.

linux:~ systemctl disable apparmor.service
linux:~ systemctl stop apparmor.service

Danach kann Sernet-Samba AD wieder gestartet werden.

linux:~ rcsernet-samba-ad start

Status

In invisAD 10.4: offen

Beschreibung

Apache2 startet nach Durchlauf des sine Moduls „webserver“ nicht mehr. Ursache dafür sind die Pakete „phpPGAdmin“ und „apcupsd-cgi“, deren Apache Konfigurationsdateien noch nicht an die neue Konfiguration von Zugriffsregeln in Apache 2.4 angepasst wurde. Dies ist allerdings kein Fehler des invis-Servers. Beide Probleme wurden von uns bereits als Bugs an openSUSE gemeldet.

Version

invisAD 10.4 (openSUSE Leap 42.1)

manuelle Beseitigung

zu apcupsd-cgi

Dieses Paket liefert eine Apache-Konfiguration mit, die so wie sie ausgeliefert wird vollkommen sinnfrei ist. Daher können Sie zur Beseitigung dieses Fehlers einfach alle aktiven Zeilen der Datei

/etc/apache2/conf.d/apcupsd.conf

auskommentieren. Ein Löschen der Datei hilft nur bedingt, da sie bei einem Update des Paketes wieder angelegt würde.

zu phpPGAdmin

Ändern Sie die Datei

/etc/apache2/conf.d/phpPgAdmin.conf

wie folgt ab:

...
<Directory /srv/www/htdocs/phpPgAdmin/libraries>
  #Order allow,deny
  #Deny from all
  Require all denied
</Directory>

Status

Offen, warten wir mal ab bis die Pakete durch Ihre Maintainer gefixt werden…

Beschreibung

Es kann vorkommen, dass unter openSUSE Leap 42.1 ohne erkennbaren Grund SSH-Logins sehr langsam (bis hin zu Timeouts) werden, gleichermaßen langsam werden Shell-Kommandos ausgeführt, die vom invis-Portal gestartet werden.

Ursache scheint ein Bug im systemd zu sein.

Version

invisAD 10.4 (openSUSE Leap 42.1)

manuelle Beseitigung

Es genügt bei Auftreten des seltsamen Verhaltens die „logind“ Komponente des Systemd neuzustarten:

linux:~ # systemctl restart systemd-logind.service

Beschreibung

Nachdem der Kernel-NFS-Server aktiviert wurde, startet nach einem Reboot Sernet-Samba nicht mehr. Ursache ist eine Zirkel-Abhängigkeit beim Start der Dienste. Das Problem für systemd dürfte daher kommen, dass Sernet-Samba noch über ein klassisches init-Script gestartet wird.

Version

invisAD 11.0 (openSUSE Leap 42.1)

manuelle Beseitigung

Im init-Script der Sernet-Samba-AD Dienstes

/etc/init.d/sernet-samba-ad

ist im Init-Info Block in der Zeile „Required-Start“ die Variable „$remote-fs“ zu entfernen.

...
### BEGIN INIT INFO
# Provides:       sernet-samba-ad ldap slapd
# Required-Start: $network
# Should-Start:   $syslog cupsd
# Should-Stop:    $syslog cupsd
# Required-Stop:
# Default-Start:  3 5
# Default-Stop:   0 1 2 4 6
# Description:    initscript for the SAMBA AD services
### END INIT INFO
...

Danach genügt ein Reload des systemd-Daemons um die Änderung zu aktivieren:

linux:~ # systemctl daemon-reload

Nach dem nächsten Reboot sollte Samba wieder ganz normal laufen.

Anmerkung

Samba benötigt die Abhängigkeit zu „$remote-fs“ nur dann, wenn eine am invis-Server eingebundene NFS-Freigabe wiederum per Samba freigegeben wird. Dieser Fall dürfte für invis-Server eigentlich nicht vorkommen.

Einen echten Fix hierfür wird es nicht geben, da wir denken, dass das Problem mit eigenen Samba-Paketen nicht mehr auftritt. … die eigenen Samba-Pakete sind bereits so gut wie fertig.

Kurz nach Abschluss des sine Moduls „sysprep“ häufen sich Fehlermeldungen und das invis Setup lässt sich nicht fortsetzen.

Ursächlich dafür sind Probleme mit dem systemd, vermutlich bedingt durch Software-Updates.

Version

invis Classic Version 9.3

manuelle Behebung

Neustart bzw. Reset des Systems. Danach läuft das System ohne Probleme.

Status

Offen. Lässt sich ohne genaue Kenntnis der Ursache nicht beheben.

  • invis_server_wiki/bugs.1544882885.txt.gz
  • Zuletzt geändert: 2018/12/15 14:08
  • von flacco