Frische 4.3 Installation

RainerH · May 24, 2018, 10:28am

Ich habe mir ein aktuelles Installationspaket Version 4.3 installiert ( kein Update )
Meine Domain habe ich so angelegt:
intranet.firma.org [intranet.emailadresse]
server: ucs1234.intranet.firma.org
Dann erstmal nur AktiveDirectory ausgewählt und sonst nichts.
Die Installation verlief problemslos…
Dann Kobano Core, gefolgt von Kobano WebApp und Kobano Z-Sync installiert
Dann noch Fetchmail installiert.
.
Einen Benutzer angelegt.
.
Nun wollte ich zuerst WebApp probieren…
Keine Anmeldung möglich !!!
Im Log steht das der Benutzer im LDAP nicht gefunden werden konnte ???
.
Es handelt sich um einen frische Installation bei der “noch” nichts verändert wurde.

bytemine · May 24, 2018, 11:12am

Moin,

ist der angelegt Benutzer auch Kopano-User (oder Admin)?

RainerH · May 24, 2018, 11:29am

Beide haben keinen Zugriff !!!

RainerH · May 24, 2018, 11:31am

Der angelegte User (User & Administrator) ist in der Benutzerverwaltung als KOBANO-User eintragen !
Dies ist doch so voreingestellt !

Moritz_Bunkus · May 24, 2018, 11:40am

Huhu,

In der Editieren-Maske in der Univention Management Console ja, aber das bedeutet nicht zwangsläufig, dass Benutzer, die bereits existiert haben, als die Kopano-Pakete installiert wurden, auch automatisch so geflaggt werden. Daher zum Testen einfach beide Benutzer einmal editieren und speichern und schauen, ob das hilft.

Falls nicht, dann bitte mal die Ausgabe von den folgenden zwei Befehlen posten:

kopano-admin -l
univention-ldapsearch -LLL -o ldif-wrap=no 'kopano4ucsrole=*' kopano4ucsrole

Gruß
mosu

RainerH · May 24, 2018, 11:55am

root@ucs-6300:~# User list for Default(1):
-bash: Syntaxfehler beim unerwarteten Wort `('
root@ucs-6300:~#         Username        Fullname        Homeserver
-bash: Username: Kommando nicht gefunden.
root@ucs-6300:~#         ------------------------------------------
-bash: ------------------------------------------: Kommando nicht gefunden.
root@ucs-6300:~#         SYSTEM          SYSTEM          ucs-6300
-bash: SYSTEM: Kommando nicht gefunden.
root@ucs-6300:~#
root@ucs-6300:~# root@ucs-6300:~# univention-ldapsearch -LLL -o ldif-wrap=no 'kopano4ucsrole=*' k                                        opano4ucsrole
-bash: root@ucs-6300:~#: Kommando nicht gefunden.
root@ucs-6300:~# dn: cn=Kopano Account,cn=templates,cn=univention,dc=intranet,dc=fenestra,dc=org
-bash: dn:: Kommando nicht gefunden.
root@ucs-6300:~# kopano4ucsRole: user
-bash: kopano4ucsRole:: Kommando nicht gefunden.
root@ucs-6300:~# clear
root@ucs-6300:~# kopano-admin -l
User list for Default(1):
        Username        Fullname        Homeserver
        ------------------------------------------
        SYSTEM          SYSTEM          ucs-6300

root@ucs-6300:~# univention-ldapsearch -LLL -o ldif-wrap=no 'kopano4ucsrole=*' kopano4ucsrole
dn: cn=Kopano Account,cn=templates,cn=univention,dc=intranet,dc=fenestra,dc=org
kopano4ucsRole: user

root@ucs-6300:~#

Moritz_Bunkus · May 24, 2018, 12:03pm

Mit “posten” meinte ich jetzt nicht, dass die Ausgabe gleich im Terminal wieder eingefügt werden soll

Und ja, der ldapsearch-Befehl zeigt, dass die Benutzer eben noch nicht als Kopano-User geflaggt sind. Daher bitte das machen, was ich oben beschrieben habe: die Benutzer in der UMC einmal bearbeiten und wieder speichern.

Gruß
mosu

damrose · May 24, 2018, 12:18pm

Hallo,

es kann gut sein, dass das UCS hier in einen bekannten Bug gelaufen ist. Workaround hierfür ist, nach der Kopano App Installation den univention-s4-connector einmal neu zu starten, und dann den Benutzer einmal neu für Kopano zu aktivieren.

RainerH · May 24, 2018, 12:45pm

Ich muss das leider mal loswerden…

Ich habe gerade einmal unter Virtualbox das vorkonfigurierte Image der Webseite installiert.
Und wieder Kobano Core und WebApp installiert.
Auch in der Buntzerverwaltung auf Benutzer Administrator einmal auf speichern gedrückt!
Und schon wieder keine Anmeldung möglich !!!

Eigentlich wollte ich dieses Jahr meinen UCS Server mit Support erwerben ( Wir sind eine kleine Firma )…
Aber wenn die Entwickler schon an dieser kleinen Hürde scheitern…
Wie ich schon sagte - Installiert out of the box !
und nichts läuft !

fbartels · May 24, 2018, 3:14pm

Der oben gegebene Tipp mit dem öffnen und speichern mag vielleicht stimmen, wenn Daten aus einem Active Directory synchronisiert werden. Für den normalen Anwendungsfall müssen aber in jedem Fall über das Kopano Template Nutzer angelegt werden, oder in der Nutzerverwaltung Kopano für diesen aktiviert werden.

Der Admin ist hier nicht automatisch ein Kopano Nutzer.

PS: Kopano, nicht Kobano

vector · May 24, 2018, 3:28pm

Hallo RainerH,

ich habe deinen Fall mal nachgestellt. Dazu habe ich das VirtualBox Image genommen, das System aufgesetzt, dann einen Benutzer angelegt, dann Kopano und Kopano WebApp installiert und im Anschluss noch einen Benutzer angelegt.

Der Benutzer vor der Installation von Kopano kann sich nicht anmelden, beim Benutzer steht aber unter Kopano die Rolle “Kopano-Benutzer”. Kurz auf der Konsole geprüft, der Benuzter ist kein Kopano Nutzer, die Rolle wird am Benutzer falsch angezeigt.

Der Benutzer, den ich nach der Installation angelegt habe (mit der Kopano Benutzervorlage) kann sich direkt anmelden.

Lösung: ist hier wirklich das neu speichern. Ich habe dazu allerdings die Funktion genutzt um mehrere Benutzer gleichzeitig zu bearbeiten (einfach markieren und dann bearbeiten), da ich dort sagen kann, das Attribute überschrieben werden sollen. Das sollte bei dir auch zum gewünschten Ergebnis führen

Viele Grüße

Moritz_Bunkus · May 25, 2018, 1:15pm

Huhu,

Was hier genau passiert, dürfte das folgende sein:

Vor der Installation von Kopano existiert eine Benutzerin, nennen wir sie sabine. Da Kopano noch nicht installiert ist, kann sabine logischerweise keine Kopano-LDAP-Attribute gesetzt haben.
Kopano wird installiert. Bei der Installation werden Benutzer nicht verändert, wohl aber die Benutzervorlagen. In den Vorlagen wird das »Kopano-Rolle«-Attribut auf »Kopano-User« gesetzt.
sabine kann sich an Kopano nicht anmelden, weil es bei ihr weiterhin kein Kopano-LDAP-Attribut gibt.
Beim Bearbeiten von sabine in der UMC wird aber als »Kopano-Rolle« = »Kopano-User« angezeigt. Warum? Naja, weil die Drop-Down-Box schlicht den Fall »das Attribut ist im LDAP gar nicht gesetzt« nicht vorsieht. Daher wird sie auf ihren Standardwert gesetzt, was »Kopano-User« ist. In diesem Moment spiegelt die Anzeige in der UMC also nicht die Relität im LDAP-Baum wider.
Speichert man nur, ohne auch nur etwas manuell zu verändern, so sieht die UMC, dass Formularwert »Kopano-Rolle = Kopano-User« nicht mit LDAP-Wert »Attribut gar nicht gesetzt« übereinstimmt, sieht also eine Änderung, und fügt deshalb das LDAP-Attribut hinzu.
Ab sofort hat sabine das LDAP-Attribut dran, Kopano sieht es und erkennt sie als Benutzerin, und sabine kann sich in Kopano anmelden.
Legt man jetzt einen neuen Benutzer an, z.B. klaus, so wird hierbei die in Schritt 2 angepasste Benutzervorlage genommen. Dadurch wird beim Speichern das Attribut auf »Kopano-User« gesetzt. Der neue klaus kann sich somit sofort in Kopano anmelden, weil Attribut vorhanden und richtig gesetzt.

Dass das ganze sich so abspielt, belegt auch die Warnmeldung, die man in Schritt 4 beim Bearbeiten von sabine von der UMC angezeigt bekommt:

DeepinScreenshot_select-area_20180525151352

Letztlich ist das ein Bug, ja, in der UMC oder den Kopano4UCS-Paketen oder wo auch immer. Eigentlich müsste »Attribut nicht vorhanden« von der UMC so gewertet werden wie »Attribut vorhanden und auf Wert none gesetzt«, denn das ist die funktionale Entsprechung aus Sicht von Kopano. Aus funktionaler Sicht der UMC sind die beiden Szenarien aber durchaus unterschiedlich; rein LDAP-semantisch sind »Attribut nicht vorhanden« und »Attribut vorhanden und auf Wert XYZ gesetzt« sehr wohl sehr unterschiedlich.

Vermutlich wird man dieses Problem zwecks Rückwärtskompatibilität nicht in den Kopano4UCS-Paketen fixen können (meine Einschätzung als jemand, der kein Kopano4UCS-Entwickler ist).

Ein theoretischer Workaround wäre, bei Installation von Kopano das Attribut kopano4ucsRole für alle bereits existierenden Accounts hinzuzufügen und zu setzen. Das ist aber aus mehreren Gründen nur theoretisch eine tolle Idee, z.B.:

In UCS@school-Umgebungen und größeren Firmen kommen schnell mehrere 1000 Benutzer zusammen. Die alle zu modifizieren, dauert seine Weile.
Damit würden auch ein Haufen Funktionsaccounts zu Kopano-Postfächern, auch wenn man das oft gar nicht will (z.B. administrator oder falls man einen Account zum Durchsuchen des LDAPs anlegt oder oder doer).

Gruß
mosu

damrose · May 25, 2018, 1:51pm

Hallo, @Moritz_Bunkus beschreibt das Problem recht treffend, genau wie die Überlegungen, warum nicht jeder ISV automatisch alle Benutzer bei der App Installation für die Verwendung aktiviert. Bei seinem Punkt 5 gab es aber tatsächlich ein Problem. Wir haben vorhin ein Erratum veröffentlicht, dass das Verhalten korriegieren sollte.

RainerH · May 25, 2018, 2:34pm

Hallo zusammen ! Da bin ich wieder !
Ich muss noch einmal nerfen ! Aber wenn hier mal die richtigen Leute sind !
Das mit dem Zugriff auf WebApp klappt jetzt aber…

Ich behaupte mal das bei jeder kleineren Firma der Server nicht direkt mit INet verbunden wird, sondern über eine Router läuft (z.B. Fritzbox) - so wie bei uns.
Die Postfächer haben wir zusammen mit unserer Webseite z.B. bei 1und1, so wie bei fast jedem kleineren Unternehmen.

Mein Installationsverlauf:

Domainname ad.fenestra.org

Installation…

Zuerst UCS Software Update

Dann Kopano installieren
Dann Fetchmail
Dann Kopano WebApp
Dann Kopano Z-Push

Dann unter System / Installation überprüfen

Fehler gefunden - Samba
Fix angewendet
kein Fehler mehr… weiter

Dann in unter UCS/DNS die externe Domain eintragen: fenestra.org

Zuerst den Mailversand über relay aktivieren:

# Relay-Host aktivieren
ucr set mail/relayauth=yes
ucr set mail/relayhost=smtp.1und1.de:587

# eine Passwort-Datei für Postfix erzeugen:
vim /etc/postfix/smtp_auth
smtp.1und1.de ucs@csh-online.com:password

# Dateirechte anpassen:
chmod 755 /etc/postfix/smtp_auth

# Die Infos aus der smtp_auth in die Postfix-DB übernehmen:
postmap /etc/postfix/smtp_auth

in /etc/postfix/mail.cf eintragen:
unter helo: fenestra.org

Einträge kontrollieren:

relayhost = SMTP-Server des Providers
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth

service postfix restart

Getestet klappt alles super.
Mail wird versendet - alles fein !

Jetzt will ich noch fetchmail einrichten, damit die Postfächer beim Provider abgeholt werden.
Unter Benutzter/Erweitert/Fetchmail für jeden Benutzer alles eingetragen sprich:
1und1 Postfachname / Passwort / imap.1und1.de und SSL angeklickt !

Aber nichts kommt in den Postfächer an!
Im LOG (/var/log/mail.info) mail sieht man deutlich das z.B ein Fetchmail für ein Postfach 30 Mails geholt und zugestellt hat.
Aber diese werden nicht ins Kopano Postfach abgelegt oder sind nicht zu sehen !

Was ist das ???

Ich habe den alten Server genauso eingrichtet ( Version 4.1 ), da läuft es seit “Jahren” einbandfrei !
Ist nur leider etwas alterschwach, insbesondere die Festplatten …

Moritz_Bunkus · May 25, 2018, 2:36pm

Hey,

zeigen Sie doch mal Zeilen aus der /var/log/mail.log von einem fetchmail-Lauf.

Gruß
mosu

Moritz_Bunkus · May 25, 2018, 2:39pm

Huhu,

ach ja, noch was:

Das ist keine gute Idee, weil die main.cf automatisch aus Vorlagen erzeugt wird. Ihre Änderung wird dementsprechend recht bald wieder verschwunden sein.

Sie können eigene Einstellungen in der /etc/postfix/main.cf.local ergänzen und anschließend die main.cf mit folgendem Befehl neu bauen lassen, damit die Änderungen der main.cf.local übernommen werden:

ucr commit /etc/postfix/main.cf

Gruß
mosu

RainerH · May 25, 2018, 3:10pm

May 25 17:08:26 ucs-3344 postfix/local[6345]: 4CD118135A: to=<systemmail@ucs-3344.ad-fenestra-org.intranet>, orig_to=<root@ucs-3344.ad-fenestra-org.intranet>, relay=local, delay=0.06, delays=0.01/0.01/0/0
.05, dsn=2.0.0, status=sent (delivered to mailbox)
May 25 17:08:26 ucs-3344 postfix/qmgr[1771]: 4CD118135A: removed
May 25 17:09:31 ucs-3344 fetchmail[6320]: beendet mit Signal 15
May 25 17:09:31 ucs-3344 fetchmail[6521]: fetchmail 6.3.26 Dämon wird gestartet
May 25 17:09:31 ucs-3344 fetchmail[6521]: 132 Nachrichten (132 gesehene) für jh@fenestra.org bei imap.1und1.de.
May 25 17:09:31 ucs-3344 fetchmail[6521]: 157 Nachrichten (157 gesehene) für rh@fenestra.org bei imap.1und1.de.
May 25 17:09:48 ucs-3344 fetchmail[6521]: beendet mit Signal 15
May 25 17:09:48 ucs-3344 fetchmail[6579]: fetchmail 6.3.26 Dämon wird gestartet
May 25 17:09:48 ucs-3344 fetchmail[6579]: 157 Nachrichten (157 gesehene) für rh@fenestra.org bei imap.1und1.de.
May 25 17:09:48 ucs-3344 fetchmail[6579]: 132 Nachrichten (132 gesehene) für jh@fenestra.org bei imap.1und1.de.
May 25 17:09:49 ucs-3344 fetchmail[6579]: beendet mit Signal 15
May 25 17:09:49 ucs-3344 fetchmail[6606]: fetchmail 6.3.26 Dämon wird gestartet
May 25 17:09:49 ucs-3344 fetchmail[6606]: 157 Nachrichten (157 gesehene) für rh@fenestra.org bei imap.1und1.de.
May 25 17:09:49 ucs-3344 fetchmail[6606]: 132 Nachrichten (132 gesehene) für jh@fenestra.org bei imap.1und1.de.

RainerH · May 25, 2018, 3:16pm

Eine Fehlermeldung habe ich in /var/log/mail.err :

May 25 16:58:26 ucs-3344 fetchmail[1881]: konnte kanonischen DNS-Namen von imap.1und1.de (imap.1und1.de) nicht finden: Der Name oder der Dienst ist nicht bekannt
May 25 16:58:26 ucs-3344 fetchmail[1881]: konnte kanonischen DNS-Namen von imap.1und1.de (imap.1und1.de) nicht finden: Der Name oder der Dienst ist nicht bekannt

RainerH · May 25, 2018, 3:18pm

Und eine Warnung in /var/log/mail.warn

May 25 16:58:26 ucs-3344 fetchmail[1881]: konnte kanonischen DNS-Namen von imap.1und1.de (imap.1und1.de) nicht finden: Der Name oder der Dienst ist nicht bekannt
May 25 16:58:26 ucs-3344 fetchmail[1881]: konnte kanonischen DNS-Namen von imap.1und1.de (imap.1und1.de) nicht finden: Der Name oder der Dienst ist nicht bekannt
May 25 16:58:27 ucs-3344 postfix/smtp[1955]: warning: database /etc/postfix/tls_policy.db is older than source file /etc/postfix/tls_policy
May 25 17:00:23 ucs-3344 postfix/smtp[2861]: warning: database /etc/postfix/tls_policy.db is older than source file /etc/postfix/tls_policy

RainerH · May 25, 2018, 3:22pm

Dies ist der Inhalt den UCS in die fetchmailrc geschrieben hat:

set daemon 1200
set syslog
set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""
poll imap.1und1.de with proto IMAP auth password user 'rh@fenestra.org' there with password 'xxxxxxxx' is 'rh@fenestra.org' here keep ssl #UID='rh'
poll imap.1und1.de with proto IMAP auth password user 'jh@fenestra.org' there with password 'xxxxxxxx' is 'jh@fenestra.org' here keep ssl #UID='jh'