Der angelegte User (User & Administrator) ist in der Benutzerverwaltung als KOBANO-User eintragen !
Dies ist doch so voreingestellt !
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 -lunivention-ldapsearch -LLL -o ldif-wrap=no 'kopano4ucsrole=*' kopano4ucsrole
Gruß
mosu
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:~#
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
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.
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 !
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
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
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, kannsabinelogischerweise 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.
-
sabinekann sich an Kopano nicht anmelden, weil es bei ihr weiterhin kein Kopano-LDAP-Attribut gibt. - Beim Bearbeiten von
sabinein 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
sabinedas LDAP-Attribut dran, Kopano sieht es und erkennt sie als Benutzerin, undsabinekann 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 neueklauskann 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:
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.
administratoroder falls man einen Account zum Durchsuchen des LDAPs anlegt oder oder doer).
Gruß
mosu
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.
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 …
Hey,
zeigen Sie doch mal Zeilen aus der /var/log/mail.log von einem fetchmail-Lauf.
Gruß
mosu
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
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.
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
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
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'
Hey,
standardmäßig holt fetchmail nur neue, noch nicht gesehene Mails ab. Das kann man ändern, indem man die Option fetchall ergänzt. Allerdings ist fetchall zusammen mit keep keine gute Idee.
Sprich: funktioniert alles wie gewollt; in den beiden Accounts gibt’s schlicht keine neuen Mails, die abgeholt werden könnten:
Gruß
mosu
Hallo RainerH,
würde mich einfach mal über das Webmail-Interface bei 1und1 einloggen,
und eine der dort liegenden Mails auf “Ungelesen/neu” setzen,
dann sollte Fetchmail diese Mail auch abholen.
Ist halt ein einfacher Test.
Gruß,
Oliver
Die Warnung in /var/log/mail.log
kann übrigens mit dem Kommado ‘postmap /etc/postfix/tls_policy’ unterdrückt werden.