Upgrade auf UCS 4 mit Kolab

SirTux · November 9, 2015, 12:40pm

Hallo,

ich würde gerne demnächst das Upgrade auf UCS 4 durchführen. Problematisch ist dabei ja leider Kolab, da es im AppCenter keine gemeinsame Version gibt. Auf die BuildService-Version möchte dabei nicht wechseln. Daher bleiben eigentlich nur noch zwei mögliche vorgehensweisen.

Möglichkeit A:
[ol]
[li] Blacklisten von Kolab[/li]
[li] Upgrade auf UCS 4[/li]
[li] Upgrade von Kolab[/li][/ol]

Möglichkeit B:
[ol]
[li] Deinstallation von Kolab[/li]
[li] Upgrade auf UCS 4[/li]
[li] Reinstallation von Kolab[/li][/ol]

Momentan präferiere ich Möglichkeit A. Aber bei welcher habe ich mit weniger Problemen zu rechnen?

Viele Grüße,
SirTux

SirTux · November 28, 2015, 11:16am

Ich hab mich jetzt doch für Möglichkeit B entschieden. Auf dem Master bin ich inzwischen auf 4.0-1 gekommen, leider hängt er nun beim Update auf 4.0-2:

Found initrd image: /boot/initrd.img-3.10.0-ucs139-amd64
Found linux image: /boot/vmlinuz-3.10.0-ucs114-amd64
Found initrd image: /boot/initrd.img-3.10.0-ucs114-amd64
Found memtest86+ image: /memtest86+.bin
grub-probe: error: unknown filesystem.
rmdir: failed to remove `/var/lib/os-prober/mount': Device or resource busy
Found Univention Corporate Server 4.0-0 errata0 (Walle) (4.0-0 errata0) on /dev/mapper/vg_ucs-rootsnapshot
done
menu.lst already exists. This typically happens if you have updated from UCS 2.4
and haven't converted from chain loading

SirTux · November 28, 2015, 11:41am

Ich hab mich entschieden das Upgrade mit dem Abschießen von dpkg abzubrechen. Danach das übliche Verfahren:

# dpkg --configure -a
memtest86+ (4.20-1.1.21.201502271253) wird eingerichtet ...
grub.cfg wird erstellt …
Hintergrund gefunden: /boot/grub/uniboot.png
Found background image: /boot/grub/uniboot.png
Linux-Abbild gefunden: /boot/vmlinuz-3.16-ucs109-amd64
initrd-Abbild gefunden: /boot/initrd.img-3.16-ucs109-amd64
Linux-Abbild gefunden: /boot/vmlinuz-3.16-ucs102-amd64
initrd-Abbild gefunden: /boot/initrd.img-3.16-ucs102-amd64
Linux-Abbild gefunden: /boot/vmlinuz-3.10.0-ucs139-amd64
initrd-Abbild gefunden: /boot/initrd.img-3.10.0-ucs139-amd64
Linux-Abbild gefunden: /boot/vmlinuz-3.10.0-ucs114-amd64
initrd-Abbild gefunden: /boot/initrd.img-3.10.0-ucs114-amd64
Found memtest86+ image: /memtest86+.bin
grub-probe: Fehler: Unbekanntes Dateisystem.
Univention Corporate Server 4.0-0 errata0 (Walle) (4.0-0 errata0) auf /dev/mapper/vg_ucs-rootsnapshot gefunden
erledigt
Generating legacy menu.lst from current kernels

Da hängt er jetzt wieder. Warum hält der sich immer mit der überflüssigen menu.lst auf?

SirTux · November 28, 2015, 12:54pm

So ich habs hingekriegt durch Bearbeiten des Postinstscriptes von memtest86. Seltsam ist, daß update-grub manuell aufgerufen einwandfrei durchläuft. Aber ich bin auf dem master nun auf 4.0-4

SirTux · November 28, 2015, 2:00pm

Jetzt habe ich leider Probleme mit dem Legacy-Kolab-Schema, was er mir bei der Reinstallation entfernen will. Die SDB hilft mir momentan leider auch nicht so richtig weiter.

zash · November 29, 2015, 1:13pm

Ich habe zumindest den Update von UCS4 nach UCS 4.1 per Blacklisting von Kolab gemacht.

Welche Version von Kolab ist denn überhaupt installiert? Im Appcenter ist ja die Version Kolab Enterprise 14 verfügbar???

SirTux · November 29, 2015, 1:47pm

Momentan ist keine Version installiert. Zuletzt installiert war die aus dem AppCenter von UCS 3.

zash · November 29, 2015, 2:30pm

Die neue Version im Appcenter ist Kolab Enterprise 14

Läuft hier und bei 2 Kunden!

SirTux · November 29, 2015, 2:52pm

Also ich habs jetzt schon mal geschafft Kolab zu installieren. Zuerst habe ich die ganzen Überreste entfernt. Das Paket mußte ich anschließend unbedingt vorher mit “dpkg -P” entfernen. Allerdings läuft der Cyrus leider nicht.

SirTux · November 29, 2015, 3:39pm

Leider gibts auch keine Logs Installiert ist übrigens cyrus-imapd-2.4

SirTux · November 29, 2015, 4:04pm

Der cyrmaster stirbt wohl sofort:

# rm /var/run/cyrmaster.pid
root@ucsmaster:~# /etc/init.d/cyrus-imapd start
root@ucsmaster:~# cat /var/run/cyrmaster.pid 
10852
# ps aux|grep 10852
root     10928  0.0  0.0   9908  1960 pts/1    S+   16:59   0:00 grep 10852

Vor der erfolgreichen Kolab-Installation habe ich übrigens die univention-Konfiguration von cyrus installiert gehabt. Danach lief er einwandfrei wie immer.

EDIT: Logs gibts schon, wenn man an der richtigen Stelle guckt:

Nov 29 15:10:58 udsmaster cyrus/cyr_expire[9892]: DBERROR: critical database situation
Nov 29 17:13:39 udsmaster master[12951]: can't open configuration file /etc/imapd/cyrus.conf: No such file or directory

Anscheinend erwartet er die Konfiguration an der falschen Stelle.

SirTux · November 29, 2015, 4:34pm

So ich hab jetzt cyrus-imapd (also 2.5) installiert. Der startet schon mal. Einloggen kann ich mich aber nicht

EDIT: Jetzt rächt sich wohl die Löschaktion. In der UMC kann ich zwar unter Account Kolab aktivieren, gesetzt wird aber nur die Objektklasse kolabInetOrgPerson und nicht das anscheinend erforderliche Attribut KolabEnabled.

zash · November 29, 2015, 4:44pm

Der soll ja gegen LDAP autorisieren? Zumindest ist das Standard bei Kolab.

Poste doch mal die imapd.conf

Dort sollte der Zugriff auf das LDAP Directory konfiguriert sein.

SirTux · November 29, 2015, 4:51pm

Bitte sehr:

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus-admin 

sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
sasl_pwcheck_method: auxprop saslauthd
sasl_mech_list: PLAIN LOGIN
allowplaintext: no
tls_server_cert: /var/lib/imap/cert.pem
tls_server_key: /var/lib/imap/private.key

tls_session_timeout: 1440
tls_cipher: 
auth_mech: pts
pts_module: ldap
ldap_servers: ldap://ucsmaster.top2.top1:7389
ldap_sasl: 0
ldap_base: dc=top2,dc=top1
ldap_bind_dn: cn=ucsmaster,cn=dc,cn=computers,dc=top2,dc=top1

ldap_password: jhdsfkjshfkjhdfsjkhfssdfdsfsdfsdfsdfblbla

ldap_filter: (|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=%U))(&(|(uid=%U)(mail=%U@%d)(mail=%U@%r))(objectclass=kolabinetorgperson)))
ldap_user_attribute: mail
ldap_group_base: dc=top2,dc=top1

ldap_group_filter: (&(cn=%u)(objectclass=univentiongroup))
ldap_group_scope: sub
ldap_member_base: dc=top2,dc=top1
ldap_member_method: filter
ldap_member_filter: (|(member=%u)(uniquemember=%D))
# Needs to be set, even though the method is filter,
# for assert(target!=NULL) in openldap get_values()
ldap_member_attribute: member
ldap_restart: 1
ldap_timeout: 10
ldap_time_limit: 10
unixhierarchysep: 1
virtdomains: userid
annotation_definitions: /etc/imapd.annotations.conf
sieve_extensions: fileinto reject envelope body vacation imapflags notify include regex subaddress relational copy
allowallsubscribe: 0
allowusermoves: 1
altnamespace: 1
hashimapspool: 1
anysievefolder: 1
fulldirhash: 0
sieveusetop2dir: 0
sieve_allowreferrals: 0
lmtp_downcase_rcpt: 1
lmtp_fuzzy_mailbox_match: 1
username_tolower: 1
deletedprefix: DELETED
delete_mode: delayed
expunge_mode: delayed
# Univention's special user
postuser: univentioninternalpostuser

EDIT: Hier die passenden Logs vom Authenfizierungsversuch:

Nov 29 17:55:13 udsmaster imap[32031]: ptload completely failed: unable to canonify identifier:test@top2.top1
Nov 29 17:55:13 udsmaster imap[32031]: SASL bad userid authenticated

EDIT2: Der erste Teil von hier klappt, der Rest nicht (ldap, pam ,kerberos5).

zash · November 29, 2015, 5:30pm

haben denn die User überhaupt das LDAP-Attribut

kolabinetorgperson

danach wird ja im LDAP gefilter. IMO wird das Attribut standardmäßig NICHT nachträglich auf die bestehnenden User verteilt!

Hat die UMC zum Erstellen der neuen User ein Groupware template?

Erstelle doch mal einen neuen User per Template und schau ob sich der anmelden kann. Wenn JA ist das ein Problem mit dem bestehenden LDAP Filter

SirTux · November 29, 2015, 5:37pm

Ja haben sie:

# univention-ldapsearch uid=test|grep kol
objectClass: kolabInetOrgPerson

Mit einem neu angelegtem User klappt es aber tatsächlich. Der einzige Unterschied:

# univention-ldapsearch uid=neu|grep kol
kolabForwardKeepCopy: FALSE
kolabForwardUCE: FALSE
objectClass: kolabInetOrgPerson

Kann das nicht doch irgendwie an den Mailboxen liegen? Die sind ja noch von cyrus 2.4

zash · November 29, 2015, 5:38pm

tls_session_timeout: 1440
tls_cipher: TLSv1:SSLv3:SSLv2:!NULL:!EXPORT:!DES:!LOW:@STRENGTH
auth_mech: pts
pts_module: ldap
ldap_servers: ldap://odin.phoenix-datentechnik.de:7389
ldap_sasl: 0
ldap_base: dc=phoenix-datentechnik,dc=de
ldap_bind_dn: cn=odin,cn=dc,cn=computers,dc=phoenix-datentechnik,dc=de

ldap_password: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ldap_filter: (|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=%U))(&(|(uid=%U)(mail=%U@%d)(mail=%U@%r))(objectclass=kolabinetorgperson)))
ldap_user_attribute: mail
ldap_group_base: dc=phoenix-datentechnik,dc=de

ldap_group_filter: (&(cn=%u)(objectclass=univentiongroup))
ldap_group_scope: sub
ldap_member_base: dc=phoenix-datentechnik,dc=de
ldap_member_method: filter
ldap_member_filter: (|(member=%u)(uniquemember=%D))
# Needs to be set, even though the method is filter,
# for assert(target!=NULL) in openldap get_values()
ldap_member_attribute: member
ldap_restart: 1
ldap_timeout: 10
ldap_time_limit: 10
unixhierarchysep: 1
virtdomains: userid
annotation_definitions: /etc/imapd.annotations.conf
sieve_extensions: fileinto reject envelope body vacation imapflags notify include regex subaddress relational copy date index
allowallsubscribe: 0
allowusermoves: 1
altnamespace: 1
hashimapspool: 1
anysievefolder: 1
fulldirhash: 0
sieveusehomedir: 0
sieve_allowreferrals: 0
lmtp_downcase_rcpt: 1
lmtp_fuzzy_mailbox_match: 1
username_tolower: 1
deletedprefix: DELETED
delete_mode: delayed
expunge_mode: delayed
# Univention's special user
postuser: univentioninternalpostuser

zash · November 29, 2015, 5:42pm

Ich habe bisher noch keine Kolab-Installation hinbekommen, bei der die bestehenden user NACHTRÄGLICH die richtigen Attribute bekommen haben.

Daher habe ich bisher Kolab immer zuerst installiert, dann die User angelegt.

Der Inhalt der bestehenden Mailboxen sollte sich ja aber in die betreffenden Ordner der neuen User kopieren lassen. Danach Index und Header der Mails neu generieren und sie sollten sichtbar sein.

Wäre ja auch ein Weg.

Ich habe hier auch noch ein Anleitung von Kolab, die nachträglich die Attribute verleihen soll. Darf ich aber nicht im Forum posten.
Morgen mal per PM ??

SirTux · November 29, 2015, 5:44pm

An der imapd.conf liegts wohl eher nicht. Die scheinen mir äquivalent zu sein.

EDIT: Ja sehr gerne. Danke für deine Hilfe

SirTux · November 29, 2015, 6:52pm

Falls das auch nicht funktionieren sollte morgen, werde ich mich von Kolab verabschieden müssen. Der ganze Ärger immer damit ist das nicht Wert. Als Alternative gibts dann aber nur den Standard-Mailstack, oder kann man auch z.B. OX privat kostenlos nutzen?