Quantcast
Channel: Univention Support Database - Latest FAQs
Viewing all 78 articles
Browse latest View live

How to enable core dumps on UCS systems

$
0
0

To enable system wide core dumps:

Produktlogo UCS Version 4

To analyse segfaults in processes it might be of need to allow them to dump their state into a core file.

To enable system wide core dumps you may use the following commands:

ulimit -c unlimited
grep -Flq 'ulimit -c unlimited' /etc/default/rcS || echo "ulimit -c unlimited" >>/etc/default/rcS
ucr set security/limits/user/*/soft/core=unlimited security/limits/user/*/hard/core=unlimited
install -d -m2733 /var/tmp/core
cat >/etc/sysctl.d/core.conf <<__CONF__
kernel.core_pattern = /var/tmp/core/core-%e-%p-%t
kernel.core_uses_pid = 1
fs.suid_dumpable = 2
__CONF__
sysctl -q -p /etc/sysctl.d/core.conf

A reboot is needed to apply the new ulimit to all processes.

Please not that core dumps may take up alot of disk space! You shoul monitor /var/tmp/core especially if it is held on the root filesystem.

To disable system wide core dumps:

To disable the system wide core dumps, use the following commands:

ulimit -c 0
grep -Flq 'ulimit -c unlimited' /etc/default/rcS && sed -i "/^ulimit -c unlimited$/d" /etc/default/rcS
ucr unset security/limits/user/*/soft/core security/limits/user/*/hard/core
rm -f /etc/sysctl.d/core.conf
sysctl -q -w kernel.core_uses_pid=0 fs.suid_dumpable=1

A reboot it needed to apply the default ulimit to all processes.

You may also delete already created dumps:

rm -f /var/tmp/core/*


Recreate listener cache

$
0
0

Produktlogo UCS UCS 4 
Problem:

The univention directory listener fails with I/O errors in the /var/log/univention/listener.log - no further replication is done (see also sdb #1303). The reason is corrupt listener cache - this can happen if the filesystem ran out of free space for example.

Example snip from listener.log:
17.01.15 13:45:18.851  LISTENER    ( ERROR   ) : database error: unable to create/retrieve page 3462
17.01.15 13:45:18.851  LISTENER    ( ERROR   ) : database error: PANIC: Input/output error
17.01.15 13:45:18.851  LISTENER    ( ERROR   ) : database error: c_get: Input/output error 

Solution:

You can recreate/invalidate the listener cache.

1. Stop the listener:
/etc/init.d/univention-directory-listener stop
sleep 5
pkill -9 -f /usr/sbin/univention-directory-listener


2. Restart the listener with additional paramters:
eval "$(ucr shell)"
/usr/sbin/univention-directory-listener -F -b $ldap_base \
-m /usr/lib/univention-directory-listener/system \
-c /var/lib/univention-directory-listener -d $listener_debug_level \
-x -ZZ -D cn=admin,$ldap_base -y /etc/ldap.secret \
-g >/var/log/univention/listener.log 2>&1 &


The initial resync could take a while - the follwing commands help you by monitoring the replication status (see also sdb #1303):

DC Master:
tail -1 /var/lib/univention-ldap/notify/transaction

DC Slave:
cat /var/lib/univention-directory-listener/notifier_id

3. If the resync is finished stop the listener and restart via init:
pkill -f /usr/sbin/univention-directory-listener
sleep 5
/etc/init.d/univention-directory-listener start

Configure SAML Single Sign-On as single server solution

$
0
0

Problem

The default UCS Single Sign-On setup consists of an additional DNS Record that is shared between master and backup servers to provide a failsafe setup.
That default DNS Record is ucs-sso.<domainname>.
In certain setups, e.g. when operating UCS in a cloud scenario, only one external DNS Record is available for a server.

Solution

The following commands have to be executed to configure the single sign-on identity provider for a different DNS Record.

FQDN=externaldns.ucsmaster.example

ucr set ucs/server/sso/autoregistraton=no \
        saml/idp/entityID="https://${FQDN}/simplesamlphp/saml2/idp/metadata.php" \
        saml/idp/certificate/privatekey="/etc/simplesamlphp/${FQDN}-idp-certificate.key" \
        saml/idp/certificate/certificate="/etc/simplesamlphp/${FQDN}-idp-certificate.crt" \
        ucs/server/sso/fqdn=$FQDN \
        umc/saml/sp-server=$FQDN \
        ucs/server/sso/virtualhost=false \
        apache2/ssl/certificate=/etc/univention/ssl/${FQDN}/cert.pem \
        apache2/ssl/key=/etc/univention/ssl/${FQDN}/private.key
       
echo "ServerName $FQDN" >>/etc/apache2/ucs-sites.conf.d/servername

univention-run-join-scripts --force --run-scripts 91univention-saml.inst
ucr set umc/saml/idp-server=https://${FQDN}/simplesamlphp/saml2/idp/metadata.php
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst

The server can now be accessed by its external DNS Name, in this example https://externaldns.ucsmaster.example.

Warning

This configuration will enable an apache wide suexec configuration for the single sign-on. Webpages and Apps that require cgi scripts to be executed will run into problems, check /var/log/apache2/suexec.log. These programs need to be adapted seperately.

Single Sign On setup failed or Single Sign On link on UMC login page is crossed out

$
0
0

Problem

The hyperlink 'Single Sign On' on the Univention Management Console login page is crossed out. It does not take the browser to the single sign-on login page.

Solution overview

The hyperlink appears crossed out if the browser is unable to connect to the domain wide single sign-on server.

This server is by default available at https://ucs-sso.<domainname>/.

The following points should be checked to narrow down the problem:
* Is the client using a UCS domain nameserver as its nameserver? If not, the client should be configured to use the UCS domain nameservers. This can be configured manually on each client or e.g. via a DHCP policy.
* Is the browser able to resolve the http URI http://ucs-sso.<domainname>? The single sign-on is available on this virtual host. Accessing the address with a browser should present a page with the Univention logo.
* Is the correct SSL certificate available in the browser? Can https://ucs-sso.<domainname> be visited in the browser? If not, the correct CA certificate from the ucs-overview site should be installed, and the wrong certificate removed
* Is the apache2 site correctly configured? Does https://ucs-sso.<domainname>/simplesamlphp/blank.json show a small json status document in the browser? If not, the following joinscripts should be re-executed on the master and all backup servers: 91univention-saml.inst, 92univention-management-console-web-server.inst.

Fail-safe domain setup

$
0
0
Produktlogo UCS UCS 4

 

 

Ways to establish a fail-safe domain setup and to increase reliability

UCS can be used for single server environments as well as for a domain with hundreds of UCS servers. So, the default configuration does not match every scenario. The following sections will describe how to configure the different services in order to increase reliability.

Most settings are either configurable with UCR (at each system at local shell) or via domain wide policies in UMC. For general instructions on how to work with policies please see the manual section on policies.
If domain wide policies are already in use you won't be able to override such settings via UCR - for example:
root@member:/# ucr set ldap/server/addition="backup1.domain.com"
Setting ldap/server/addition
W: ldap/server/addition is overridden by scope "ldap" 

You can adjust the existing policy via UMC then (see manual link above).

 

LDAP

The use of additional LDAP servers if the primary LDAP server is unreachable, is configurable via UCR:
root@master:~# ucr search ldap/server/addition
ldap/server/addition:  Several LDAP servers can be operated in a UCS domain. The primary one is specified with 'ldap/server/name'. Further servers are automatically managed by a Listener module through this variable.


To increase reliability additional servers can be configured, which will automatically be used if the primary LDAP server breaks:
root@master:~# ucr set ldap/server/addition='backup1.domain.com backup2.domain.com slave1.domain.com'

The list should contain space separated fully qualified domain names.
The use of additional LDAP servers is also configurable via a LDAP server policy (see manual section on LDAP servers).

 

Kerberos

The server which replies to kerberos requests (so called kdc) is also configurable via UCR:
root@master:~# ucr search kerberos/kdc
kerberos/kdc: 127.0.0.1
A list of Kerberos KDC servers can be configured here. The host names should be specified in FQDN form. Multiple values need to be separated by a blank. If the variable is unset, the KDC is queried from DNS service records (see 'kerberos/defaults/dns_lookup_kdc'). 

 root@master:~# ucr search kerberos/defaults/dns_lookup_kdc
kerberos/defaults/dns_lookup_kdc: <empty>
If this variable is set to 'true' or unset, the KDC(s) used by the system are read from DNS service records. This can be disabled by setting the variable to 'false', is which case the KDC(s) must be set through the variable 'kerberos/kdc'.

You can set the variables like this to use DNS lookup:
 root@master:~# ucr set kerberos/defaults/dns_lookup_kdc=true
root@master:~# ucr unset kerberos/kdc 

 

DNS

Different name servers can be configured via UCR:
root@master:~# ucr search nameserver
nameserver1: 10.200.11.240 The first DNS server to be used.
nameserver2: 10.200.11.1 The second DNS server to be used.
nameserver3: <empty> The third DNS server to be used. 

To improve reliability additional name servers in the domain can be used - for example:
root@master:~# ucr set nameserver1=<ip of master> nameserver2=<ip of backup1> nameserver3=<ip of backup2> 

UCR settings can also be applied domain wide via UCR policies.

If a DHCP server is in use, it should be configured to send its clients the list of all available DNS servers.

 

Active Directory-compatible Domain Controller

Overall reliability can be improved by adding multiple Active Directory-compatible Domain Controllers. This can be accomplished by installing additional UCS systems with a system role of "Domain Controller Backup" or "Domain Controller Slave" (see manual section on system roles) with the "Active Directory-compatible Domain Controller" software component (see manual section on selecting software components). Existing UCS backup or slave domain controllers just have to install the app from the AppCenter (see manual section on installing Samba4 app).

Samba 4 domain controllers replicate their data automatically by DRS (see SDB#1235 for further information).

 

DHCP

Clients, Access Points and other devices are often dependent on the availability of a DHCP service to receive a network configuration. If the service were down due to an error or maintenance, they would not work properly. Raising the availability of the DHCP service is simple in a UCS domain. All it takes is another UCS system in the same subnet on which to install the "DHCP server" app.

During installation the new DHCP server will automatically be added to the DHCP service entry for its domain. When the installation has finished, the DCHP module should be visited to verify that (see manual section on DHCP service). If the app was installed on a domain controller slave or backup, the join script has to be run manually (see manual section on running join scripts).

How to deal with s4-connector rejects

$
0
0
Produktlogo UCS UCS 4

 

 

S4-Connector Rejects

Rejects

You can use the following command to have a look at the current S4-Connector replication status:

univention-s4connector-list-rejected

If you see rejected objects in the output it is recommended to have a look at the relevant log files to determine the reason for the reject. The relevant log file is /var/log/univention/connector-s4.log.

UCS rejected refers to object modifications that have been detected in UCS/OpenLDAP and could not be synchronized to the Samba/AD directory service. S4 rejected on the other hand refers to object modifications that have been detected in Samba/AD and could not be synchronized to the UCS/OpenLDAP directory service.

In most cases you will find a corresponding traceback which you can hand over to your supporter if in doubt.
If the shown reason is not obvious (or not accurate) it could be suggestive to compare the rejected object in Samba 4 and LDAP. You can use the following commands:

univention-ldapsearch -b "objectdn"
univention-s4search -b "objectdn"

for example:
univention-ldapsearch -b "uid=administrator,cn=users,dc=domain,dc=de"
univention-s4search -b "cn=administrator,cn=users,dc=domain,dc=de"

If the objects are equal and you are sure about this, the reject perhaps is already resolved. This can happen if discrepancies are resolved apart from the connector. In these cases the rejects can be removed. This could also be the case if you removed unwanted objects with ldbdel for example.
Rejects are saved in a sqlite database. Therefore you have to remove the rejects in the database. There are helper tools for this task - for example:

Remove S4 reject:
root@master:~# /usr/share/univention-s4-connector/remove_s4_rejected.py \
                              CN=Administrator,CN=Users,DC=domain,DC=de

Remove UCS/LDAP reject:
root@master:~# /usr/share/univention-s4-connector/remove_ucs_rejected.py \
                              uid=Administrator,cn=users,dc=domain,dc=de

 

You can also try to sync changes from one directory service to the other - for example trigger a resync from one Samba/AD object to OpenLDAP.

Trigger S4 resync:
root@master:~# /usr/share/univention-s4-connector/resync_object_from_s4.py --filter cn=Administrator
resync triggered for CN=Administrator,CN=Users,DC=domain,DC=de
Estimated sync in 50 seconds.

Trigger UCS resync:
root@master:~# /usr/share/univention-s4-connector/resync_object_from_ucs.py --filter uid=Administrator
resync triggered for uid=Administrator,cn=users,dc=domain,dc=de

Samba 4 Troubleshooting

$
0
0
Produktlogo UCS UCS 4

 

 

Samba 4 Troubleshooting Guide

DRS Replication

samba-tool drs showrepl

To get an overview of the current drs replication status you can use this command at every UCS Samba 4 DC which is joined to the domain:

samba-tool drs showrepl

Sitename\Servername
DSA Options: 0x00000001
DSA object GUID: ffad9f19-0e90-457b-b733-469e4b2280a1
DSA invocationId: 908dbb52-12a6-47a2-ae03-1a71014cc4f4

==== INBOUND NEIGHBORS ====

DC=domain,DC=base
    Sitename\Servername via RPC
        DSA object GUID: 397575b4-23c7-4ceb-8114-166a1d7a1bfe
        Last attempt @ Tue Jun 18 03:30:23 2013 MDT was successful
        0 consecutive failure(s).
        Last success @ Tue Jun 18 03:30:23 2013 MDT

CN=Schema,CN=Configuration,DC=domain,DC=base
    Sitename\Servername via RPC
        DSA object GUID: 397575b4-23c7-4ceb-8114-166a1d7a1bfe
        Last attempt @ Tue Jun 18 03:30:31 2013 MDT failed, result 2 (WERR_BADFILE)
        14 consecutive failure(s).
        Last success @ NTTIME(0)

CN=Configuration,DC=domain,DC=base
    Sitename\Servername via RPC
        DSA object GUID: 397575b4-23c7-4ceb-8114-166a1d7a1bfe
        Last attempt @ Tue Jun 18 03:30:34 2013 MDT failed, result 2 (WERR_BADFILE)
        14 consecutive failure(s).
        Last success @ NTTIME(0)

==== OUTBOUND NEIGHBORS ====

==== KCC CONNECTION OBJECTS ====

Connection --
    Connection name: facd713f-869d-4672-ad9b-b694e7c53cd8
    Enabled : TRUE
    Server DNS name : Servername
    Server DN name : CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=domain,DC=base
    TransportType: RPC
    options: 0x00000001
Warning: No NC replicated for Connection!

The output shows four sections. The header shows the GUID of the local directory service agent (DSA), which can be thought of as an ID for the local DC. The second section shows inbound connections. The local domain controller replicates directory objects from the inbound neighbors. Each directory partition is replicated separately. The section outbound neighbors lists remote domain controllers that are replicating objects from the local domain controller. In this case, the output shows a situation directly after the join of the local domain controller, where it replicated from the neighbor DC it joined to, but no other DC has replicated any objects from the local DC yet. The third section shows a summary of the connections to neighbor DCs.

The output will always show "Warning: No NC replicated for Connections" as last line. This Warning is expected and completely harmless.

samba-tool drs kcc (-UAdministrator <fqdn of remote dc>)

This command can be used to manually trigger the Samba 4 "Knowledge Consistency Checker" (KCC) to update its current knowledge about connections to neighbor DCs. The command can also conveniently e used to trigger the KCC on a remote host by adding -UAdministrator <fqdn>.
This can be useful in case DC objects are absend in the output of samba-tool drs showrepl or are showing consecutive failures.

It is always recommend to also have a look in /var/log/samba/log.samba for further hints when facing drs replication issues. 

samba-tool drs replicate <destination dc> <source dc> <nc>

You can trigger the drs replication with the help of this command. Most likely you will get specific hints and error messages directly when used during an in depth analysis of DRS replication issues.
An example would be:
samba-tool drs replicate destinationhost sourcehost dc=domain,dc=base 

Comparing msDS-KeyVersionNumber

For a given user, computer, or built-in account, this attribute specifies the Kerberos version number of the current key for that account.
Therefore it can be used to compare the replication status of systems:

 root@master:~# univention-s4search cn=master msDS-KeyVersionNumber
root@backup:~# univention-s4search cn=master msDS-KeyVersionNumber
 

The values have to be equal - otherweise the replication seems to be broken. If a system uses another value in comparison to the master, then it has to be rejoined.

Example:
root@master:~# univention-s4search cn=master msDS-KeyVersionNumber
dn: CN=MASTER,OU=Domain Controllers,DC=test,DC=domain
msDS-KeyVersionNumber: 7
root@backup:~# univention-s4search cn=master msDS-KeyVersionNumber
dn: CN=MASTER,OU=Domain Controllers,DC=test,DC=domain
msDS-KeyVersionNumber: 1
Here the system backup is obviously out of sync and a rejoin should be considered.

DNS

For a complete overview of the relevant dns records you have the possibility to check the output of the following script:
/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

 

Sysvol Replication

Removal of Domain Controllers

The best way to completely remove a DC object would be the following steps:

1. samba-tool dbcheck --fix (see LDB Tools)
2. /usr/share/univention-samba4/scripts/purge_s4_computer.py --computername=hostname 
3. Checking for references in the LDB and eventually remove them. You can use the objectGUID of the DC object for these searches to determine objects with remaining references, for example:
ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs | grep -A10 f5031d0e-86a7-4b60-ad6b-1ff8108a3e2a

Rejoin of an existing DC 

It should be sufficient to use univention-join If this does not succeed, there could be old references in the ldb. You can use the steps underneath "LDB Tools" or use the following:

The next commands have to be executed at the dc which has to be rejoined
1. invoke-rc.d samba4 stop
2. rm -r /var/lib/samba/private
3. univentioin-join

In case this does not work either, the DC account can be removed first by logging into the UCS domain controller running the S4 Connector (usually the DC Master) and executing the steps described in the section "Removal of Domain Controllers" (see above). After that, the join process can be started again using the three steps above (samba4 stop, move directory, univention-join).

LDB Tools

In some cases a deeper inspection of the Samba database backend (sam.ldb) is required.
Searching within the LDB: ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs [-b <dn> ] [<ldap-filter>]
ldbdel can be used to remove objects. This could be needed e.g. if removed computer objects left reference objects underneath cn=configuration,$ldap_base: ldbdel -H /var/lib/samba/private/sam.ldb  <dn>
The other way to determine such inconsistent references (and automatically fix them) is the usage of samba-tool dbcheck. samba-tool dbcheck [--cross-ncs --fix --yes]

FSMO Roles

You can use the following command to have a look at the current fsmo roles:

samba-tool fsmo show

InfrastructureMasterRole owner: CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=sec,DC=lan
RidAllocationMasterRole owner: CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=sec,DC=lan
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=sec,DC=lan
DomainNamingMasterRole owner: CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=sec,DC=lan
SchemaMasterRole owner: CN=NTDS Settings,CN=Servername,CN=Servers,CN=Sitename,CN=Sites,CN=Configuration,DC=sec,DC=lan

S4-Connector

Please see SDB#1302

Re-Provisioning Samba4 on a UCS@school DC Master

$
0
0
Produktlogo UCS UCS 4

 

This article describes the re-provision of a Samba 4 on a UCS@school DC Master. For a non-UCS@school environment http://sdb.univention.de/1282 should be used.

 

Problem:

Several Samba 4 data is either lost or or corrupt

The LDB-Data of  Samba 4 (z.B. /var/lib/samba/private/sam.ldb) is corrupted/broken/lost and Samba 4 has to be re-provisioned.

 

Solution:

Samba 4 can be re-provisioned with the help of the existing LDAP data

The following steps will describe the needed procedure:

 

 

1. Stop Samba 4 on all connected in the environment

If there are other Samba 4 systems available, samba 4 has to be stopped there - the nameing of the init scripts changed to UCS 4 - both variants are explained:

# UCS 4:
invoke-rc.d samba stop
# UCS 3:
invoke-rc.d samba4 stop

2. Sync time on DC Master:
rdate ptbtime1.ptb.de
3. Save RID Pools on DC Master:

ldbsearch -H /var/lib/samba/private/sam.ldb CN="RID Set" \
-b CN="$(ucr get hostname),OU=Domain Controllers,$(ucr get ldap/base)" > /root/ridpool.ldif

4. Stop Samba 4 and S4-Connector on DC Master:

# UCS 4:
invoke-rc.d samba stop
invoke-rc.d univention-s4-connector stop
# UCS 3:
invoke-rc.d samba4 stop
invoke-rc.d univention-s4-connector stop

5. Move/Delete Samba 4 and S4-Connector data on DC Master:
find /etc/univention/connector/ \( -name "s4*.sqlite" -o -name "lockingdb.sqlite" \) -exec mv "{}" "{}.bak_$(date +%s)" \;
rm -f /var/lib/univention-connector/s4/*
mv /var/lib/samba/private "/var/lib/samba/private.bak_$(date +%s)"
6. Remove Samba 4 and S4-Connector packages on DC Master:

univention-remove univention-samba4 univention-s4-connector

7. Set UCS variables for re-provision on DC Master:

ucr set connector/s4/allow/secondary='true' \
samba4/provision/primary='true'

8. Install Samba 4 and S4-Connector packkages on DC Master:

univention-install univention-s4-connector univention-samba4

9. Correct newly created RID-Pool with the help of the saved data on DC Master:

A new RID-Pool was created by re-provision - it has to be corrected with the help of tha saved data - see pt.3:

ldbedit -H /var/lib/samba/private/sam.ldb CN="RID Set" \
-b CN="$(ucr get hostname),OU=Domain Controllers,$(ucr get ldap/base)"

The following attributes has to be corrected:

rIDAllocationPool
rIDPreviousAllocationPool
rIDNextRID

Please also see SDB-Artikel  Samba 4 - RID Pool renewal

 

After the steps 1-9 the (test)-system should be rebooted and tested.

If there were other systems using samba 4 in this environment, all of them have to be re-joined! These systems can be found by using the following search:

univention-ldapsearch -b cn=dc,cn=computers,$(ucr get ldap/base) \
    '(&(univentionService=Samba 4)(!(cn='$(ucr get hostname)')))' \
    cn | sed -ne 's|cn: ||p

 


Re-Provisioning Samba4 on a DC Master

$
0
0
Produktlogo UCS UCS 4

 

This article describes the re-provision of a Samba 4 DC Master. Please see http://sdb.univention.de/1353 if a UCS@school environment is used.

 

Problem:

Several Samba 4 data is either lost or or corrupt

The LDB-Data of  Samba 4 (z.B. /var/lib/samba/private/sam.ldb) is corrupted/broken/lost and Samba 4 has to be re-provisioned.

 

Solution:

Samba 4 can be re-provisioned with the help of the existing LDAP data

The following steps will describe the needed procedure:

 

 

1. Stop Samba 4 on all connected systems in the environment

If there are other Samba 4 systems available, samba 4 has to be stopped there - the nameing of the init scripts changed to UCS 4 - both variants are explained:

# UCS 4:
invoke-rc.d samba stop
# UCS 3:
invoke-rc.d samba4 stop

2. Sync time on DC Master:
rdate ptbtime1.ptb.de
3. Save RID Pools on DC Master:

ldbsearch -H /var/lib/samba/private/sam.ldb CN="RID Set" \
-b CN="$(ucr get hostname),OU=Domain Controllers,$(ucr get ldap/base)" > /root/ridpool.ldif

4. Stop Samba 4 and S4-Connector on DC Master

# UCS 4:
invoke-rc.d samba stop
invoke-rc.d univention-s4-connector stop
# UCS 3:
invoke-rc.d samba4 stop
invoke-rc.d univention-s4-connector stop

5. Move/Delete Samba 4 and S4-Connector data on DC Master
find /etc/univention/connector/ \( -name "s4*.sqlite" -o -name "lockingdb.sqlite" \) -exec mv "{}" "{}.bak_$(date +%s)" \;
rm -f /var/lib/univention-connector/s4/*
mv /var/lib/samba/private "/var/lib/samba/private.bak_$(date +%s)"
6. Remove Samba 4 and S4-Connector packages on DC Master

univention-remove univention-samba4 univention-s4-connector

7. Set needed UCR-Variables for re-provision on DC Master

ucr set connector/s4/mapping/group/grouptype='false' \
connector/s4/mapping/sid_to_s4='true' \
samba4/provision/primary='true'

8. Install Samba 4 and S4-Connector packkages on DC Master

univention-install univention-s4-connector univention-samba4

9. Remove UCR variables which were set for re-provision on DC Master

ucr unset samba4/provision/primary \
connector/s4/mapping/sid_to_s4

10. Correct newly created RID-Pool with the help of the saved data on DC Master

A new RID-Pool was created by re-provision - it has to be corrected with the help of tha saved data - see pt.3:

ldbedit -H /var/lib/samba/private/sam.ldb CN="RID Set" \
-b CN="$(ucr get hostname),OU=Domain Controllers,$(ucr get ldap/base)"

The following attributes has to be corrected:

rIDAllocationPool
rIDPreviousAllocationPool
rIDNextRID

Please also see SDB-Artikel  Samba 4 - RID Pool renewal

 

After the steps 1-10 the (test)-system should be rebooted and tested.

If there were other systems using samba 4 in this environment, all of them have to be re-joined!

 

Timeout Änderung für den Univention Directory Manager bzw. für die Univention Management Console

$
0
0
Produktlogo UCS Version 4.x 

 

Problem:

 

Standardmäßig beträgt der Timeout für den Univention Directory Manager und für die Univention Management Console 300 Sekunden. Wie kann der Timeout verändert werden?

 

Lösung:

 

Auf der Kommandozeile können die Timeouts durch setzen der folgenden Univention Configuration Registry-Variablen angepasst werden (Die Zeitangaben müssen in Sekunden erfolgen):

 

Für den Univention Directory Manager, z.B. eine Stunde

ucr set directory/manager/timeout=3600 bis Version 3.x

ucr set directory/manager/cmd/timeout=3600

 

Für die Univention Management Console, z.B. eine Stunde

ucr set umc/web/timeout=3600 bis Version 3.x

ucr set umc/http/session/timeout=3600

 

Die Timeout Werte können auch mit der Univention Management Console über das Modul "Univention Configuration Registry" - mit einem Klick auf die entsprechenden Variablen - angepasst werden.

GRUB Error: "Disk filter writes are not supported in boot"

$
0
0

UCS 4.1 Erratum #82 and UCS 4.0 Erratum #396 added/activated the "savedefault" option by default. This requires GRUB to write to the disk, which is not supported for every type of device (e.g. mdadm-software-RAID)

If GRUB can not write to the disk it displays the message
"Disk filter writes are not supported in boot"
and requires a key press to continue the boot.

As the function does not work if GRUB can not write, the "savedefault" option can be disabled by executing the following command:
ucr set grub/savedefault=false

Configure SAML Single Sign-On as single server solution

$
0
0

Produktlogo UCS UCS 4
Problem

The default UCS Single Sign-On setup consists of an additional DNS Record that is shared between master and backup servers to provide a failsafe setup.
That default DNS Record is ucs-sso.<domainname>.
In certain setups, e.g. when operating UCS in a cloud scenario, only one external DNS Record is available for a server.

Solution

The following commands have to be executed to configure the single sign-on identity provider for a different DNS Record.

FQDN=externaldns.ucsmaster.example

ucr set ucs/server/sso/autoregistraton=no \
        saml/idp/entityID="https://${FQDN}/simplesamlphp/saml2/idp/metadata.php" \
        saml/idp/certificate/privatekey="/etc/simplesamlphp/${FQDN}-idp-certificate.key" \
        saml/idp/certificate/certificate="/etc/simplesamlphp/${FQDN}-idp-certificate.crt" \
        ucs/server/sso/fqdn=$FQDN \
        umc/saml/sp-server=$FQDN \
        ucs/server/sso/virtualhost=false \
        apache2/ssl/certificate=/etc/univention/ssl/${FQDN}/cert.pem \
        apache2/ssl/key=/etc/univention/ssl/${FQDN}/private.key
       
echo "ServerName $FQDN" >>/etc/apache2/ucs-sites.conf.d/servername

univention-run-join-scripts --force --run-scripts 91univention-saml.inst
ucr set umc/saml/idp-server=https://${FQDN}/simplesamlphp/saml2/idp/metadata.php
univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server.inst

The server can now be accessed by its external DNS Name, in this example https://externaldns.ucsmaster.example.

Warning

This configuration will enable an apache wide suexec configuration for the single sign-on. Webpages and Apps that require cgi scripts to be executed will run into problems, check /var/log/apache2/suexec.log. These programs need to be adapted seperately.

Boot UCS system via Super GRUB2 Disk

$
0
0

UCS uses GRUB2 as bootloader. If the installation of GRUB2 is inconsistent, the UCS system might not boot or GRUB2 shows a rescue shell. In some cases the UCS system can be started by booting the Super GRUB2 Disk.

The Super GRUB2 Disk is available at http://www.supergrubdisk.org/super-grub2-disk/ and may be used on i386, amd64 and UEFI systems. For booting the UCS system, usually the following steps have to be performed:

  • Download the latest ISO file
  • In virtualization environments the ISO file may be directly added as CD-ROM drive to a virtual machine. On hardware systems it is required to write the ISO file to a USB stick or CDROM/DVD.
  • Boot the system from ISO/USB stick/CDROM. After booting the Super GRUB2 Disk shows a text menu.
  • If RAID or LVM is used for the UCS system, the menu entry "Enable GRUB2's RAID and LVM support" has to be selected. Activating the RAID/LVM support may take a moment. This step may be omitted and can be catched up on later if neccessary.
  • Select the entry "Detect and show boot methods". Please note: depending on the complexity of your setup, this might take a moment. A black screen is shown while detecting.
  • The next menu shows all available boot options. Select an appropriate entry containing the text "Univention Corporate Server".
  • Now, the existing GRUB configration from /boot is automatically used to boot the UCS system.

If the boot of the UCS system was successful, the GRUB configuration should be fixed.
The SDB article http://sdb.univention.de/1356 contains information on how to (re)configure GRUB.

Booting from the wrong device, GRUB displays "symbol 'grub_term_highlight_color' not found"

$
0
0

If GRUB is installed on a different device than the one that the BIOS boots from, the system may still boot as long as the device-installed GRUB is compatible with the OS-installed GRUB.
But once they diverge, GRUB may display messages like
"symbol 'grub_term_highlight_color' not found"

This does not apply systems booting via UEFI, only systems booting via BIOS can be affected.

On affected systems this problem becomes visible with UCS 4.1 Erratum #101, because it updates GRUB.

To correct this problem the BIOS boot order must match the GRUB configuration. This can be achieved by changing the BIOS boot order to boot from the disk that GRUB is installed on.
To achieve this, consult your devices BIOS configuration manual.

It can also be corrected by changing the disk(s) that GRUB is installed on.
To achieve this, boot the UCS system via an external boot CDROM/USB stick as described in SDB article 1358.
Afterwards run the command
 dpkg-reconfigure grub-pcas user "root".

Answer the questions shown by dpkg-reconfigure as follows:

  • Question for "Linux command line":
    Press <Return> to keep the value as-is
  • Question for "default command line for Linux":
    Press <Return> to keep the value as-is
  • Question for "devices for GRUB installation":
    select the correct device(s) (i.e. the device(s) the BIOS is configured to boot from) to install GRUB on.
    Multiple devices can be selected.
    Please note:
    Select only devices (e.g. /dev/sda), not partitions (e.g. /dev/sda1).
    Do not select device mapper devices (e.g. /dev/dm-0).
  • Question for changed configuration file "/etc/default/grub"
    Press <Return> to keep the configuration file as-is.

Using dpkg-reconfigure ensures that future GRUB updates will not lead to the same problem, as the device selection is saved for future GRUB updates to use.

Finally run
ucr commit /etc/default/grubto make sure that file is correct.

This fix can be done before or after installing UCS 4.1 Erratum #101.


If the machine was rebooted after installing UCS 4.1 Erratum #101 and the system hangs with the aforementioned message, it should be possible to temporarily change the BIOS boot order to the disk that GRUB is installed on to boot into the system (e.g. by pressing F8 during the boot sequence).

Update of UCS 3.2 UEFI systems to UCS 4.0

$
0
0

With UCS 4.0 the UEFI components of UCS have been updated. After updating UCS 3.2 UEFI systems a number of steps have to be performed as user root to make sure the UCS system remains bootable:

A few new packages have to be installed and one outdated package has to be removed (if still installed).
univention-install shim-signed grub-efi-amd64-signed
univention-remove delo

Next the file /etc/fstab has to be modified. Instead of the suggested editor vim any other editor may be used.
Please modify the entry for /boot/grub. The partition has to be mounted on /boot/efi instead.
vim /etc/fstab
Finally, the new mountpoint has to be created and the GRUB installation updated:
mkdir /boot/efi
mount /boot/efi
find /boot/efi/ -mindepth 1 -xdev -delete
grub-install
update-grub


Disable console blanking

$
0
0

By default, the kernel activates a console blanking timeout of 600 seconds. After reaching the timeout, the hardware terminal turns black. In case of a kernel OOPS, important debugging information may not be visible/accessible.

To disable console blanking, add consoleblank=0 to the UCR variable grub/append and reboot your system:

ucr set grub/append="$(ucr get grub/append) consoleblank=0"

 

Management Console Login not possible - Leap Year

$
0
0

It is possible, that the Login in the Management Console is not possible at the 29th of February (that is a "leap day"). In the management-console-log the following traceback appears (solution below):


29.02.16 00:42:31.533  MAIN        ( PROCESS ) : SessionClient(0x4478f50):
_authenticated: success=True  status=200  message=None
29.02.16 00:42:31.534  MAIN        ( ERROR   ) : Traceback (most recent call
last):
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cprequest.py", line 656, in
respond
    response.body = self.handler()
  File "/usr/lib/python2.7/dist-packages/cherrypy/lib/encoding.py", line 188,
in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/cherrypy/_cpdispatch.py", line 34, in
__call__
    return self.callable(*self.args, **self.kwargs)
  File "/usr/sbin/univention-management-console-web-server", line 1010, in
default
    return self._auth_request(req, sessionid)
  File "/usr/sbin/univention-management-console-web-server", line 1035, in
_auth_request
    self.set_session(sessionid, username)
  File "/usr/sbin/univention-management-console-web-server", line 699, in
set_session
    self.set_cookies(('UMCSessionId', sessionid), ('UMCUsername', username))
  File "/usr/sbin/univention-management-console-web-server", line 678, in
set_cookies
    expires = expires.replace(year=expires.year + 5)
ValueError: day is out of range for month

 


There is an errataupdate released that fixes this behaviour. The errata are as follows:

UCS 3.2: 403

UCS 4.0: 403

UCS 4.1: 122

Solution via errataupdate (3.2):

# Login to your affected Server
ssh root@YOUR_AFFECTED_SERVER

# Update UCS to the newest Erratum (while staying in current minor version)
univention-upgrade --updateto=3.2-99

Solution via errataupdate (4.0):

# Login to your affected Server
ssh root@YOUR_AFFECTED_SERVER

# Update UCS to the newest Erratum (while staying in the current minor version)
univention-upgrade --updateto=4.0-99

Solution via errataupdate (4.1):

# Login to your affected Server
ssh root@YOUR_AFFECTED_SERVER

# Update UCS to the newest Erratum (while staying in the current minor version)
univention-upgrade --updateto=4.1-99


Workaround UCS 3.2 and 4.0 (without Update):

# Login to your affected Server
ssh root@YOUR_AFFECTED_SERVER

# Modify the univention-management-console-web-server
sed -i 's|expiration.year + 5)|expiration.year + 4)|' /usr/sbin/univention-management-console-web-server

# Restart Management Console
/etc/init.d/univention-management-console-web-server restart


Workaround UCS 4.1 (without Update):

# Login to your affected Server
ssh root@YOUR_AFFECTED_SERVER

# Modify the univention-management-console-web-server
sed -i 's|expires.year + 5)|expires.year + 4)|' /usr/sbin/univention-management-console-web-server

# Restart Management Console
/etc/init.d/univention-management-console-web-server restart


Analyze boot problems

$
0
0

Produktlogo UCS UCS 4 
Problem:

A system does not boot and seems to freeze at bootsplash.

Solution:

It is possbile to edit the boot options for the UCS system within GRUB. You can disable the splashscreen and raise the loglevel - by that you can see what happens when the system freezes:

1. Press button "e" in GRUB bootloader
2. Find the follwing line:
linux ... /vmlinuz-... ... ro quiet loglevel=0 rootdelay=5 splash3. Edit the line: Remove "quiet" and change "slpash" to "nosplash" - also set "loglevel" to 5
the line should now look like this:
linux ... /vmlinuz-... ... ro loglevel=5 nosplash4. Boot by pressing F10

These changes are temporaliy and are re-set at next boot. You can make that change permanent by booting into the working UCS system, logging in as root, and setting the following UCR variables:

ucr set grub/bootsplash=nosplash grub/quiet=no grub/loglevel=5

Advanced options:

The default text console only has 80 columns and 25 rows, so some important output might scroll of. You can configure a serial console to capture that output.

Note 1: Many USB serial converters don't work reliably.

Note 2: Many high-end servers support serial console re-direction over network, for example over IPMI.

# Re-direct GRUB input/output to serial console:
cat >>/etc/univention/templates/files/etc/default/grub <<__GRUB__
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
__GRUB__
ucr commit /etc/default/grub

# Optional: Re-direct Linux kernel input/output to serial console:
ucr set grub/append='console=tty0 console=ttyS0,115200,8,N,1'
# This makes the serial console the default console (/dev/console), as ttyS0 is given last.
# By moving console=tty0 to the end, the VGA console will remain the main console.

# Optional: Start a login getty on the serial console:
sed -i -re '/^#?T0:/s/#//' /etc/inittab

Migration of Cyrus 2.4 to Dovecot

$
0
0
Produktlogo UCS UCS 4 

Disclaimer

Due to the vast variety of mail appliances and differing structures of environments, we recommend to analyze the feasibility of this migration process in your very own environment beforehand. We strongly recommend to try the entire migration in a test environment to check for possible intolerances and incompatibilites with your productive environment. We also strongly recommend to create a backup before this migration,

Introduction

This article describes the migration of a Cyrus mail spool into a Dovecot mail spool. The migration keeps mail flags and users' mail folders. Shared folders are also migrated to Dovecot. We utilize the script “Cyrus2Dovecot” by Freie Universität Berlin, because it allows to automate the migration well with several start parameters.

It is important for the migration to change the LDAP attribute univentionMailHomeServer, which defines the server to redirect incoming mails to in the domain. It exists in every user object with a mail address by default. Assuming that we have a machine that we install Dovecot, and thus uninstall Cyrus, on, the listener-notifier mechanism will automatically create new dovecot mailboxes for all users, that have this server set as Mail home server. If we set Mail home server to another machine’s hostname, the mailboxes will be created there as soon as Dovecot is installed.

The users' mail addresses are obtained with univention-ldapsearch and handed to cyrus2dovecot, which determines where the to-be-migrated files are and where they shall be migrated to with its start parameters.

Note that the migration script does not delete Cyrus’ mail spool. Therefore two mail spools (Cyrus’ and Dovecot’s) exist on the machine after the migration is finished. If this would result in a capacity problem, make according arrangements! This also gives you the possibility to fallback onto the old Cyrus-Appliance.

Important notes

Note that a downtime might occur, depending on your execution of the migration process. If you plan to do the migration on one single machine, a downtime is unavoidable. In an environment with more than one machine there is the possibility to change the mailHomeServer attributes of the affected users with a script in a way that incoming mails are redirected to the old Cyrus mailboxes until the creation of the according new Dovecot mailbox succeeded. The migration will then migrate all mails from the Cyrus mailboxes to the new Dovecot mailboxes. This is also a possibility, if you want to change servers with migrating or if your environment does not allow a downtime.

Additionally it might be required, that users change their usernames in their mail clients (Thunderbird, Outlook, mobile devices, etc.). Dovecot does only allow logins with the full mail address (user1@example.org) while Cyrus also allows only the UID (user name) as login user.

In-place migration (replacing Cyrus with Dovecot on the same server)

During an in place migration all steps are executed as user “root” on the mailserver (the system running Cyrus at the moment). It might be that clients connecting to the mail server find a completely empty mailbox, when the mailbox has been created but mails have not already been migrated into it.

Preparation

Downloading the script

First, you should download the migration script onto the server. The md5 checksum as of the creation of this article is as follows: 506bb048473ccdb44191d88130606f1d

wget -nv https://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

If you run into a certificate error, execute this command:

wget -nv --no-check-certificate http://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

The downloaded script has to be made executable:

chmod +x ./cyrus2dovecot

Installing Dovecot

To install Dovecot and uninstall Cyrus at the same time, this command can be executed. (/var/spool/cyrus and /var/lib/cyrus won’t be touched by this):

univention-install univention-mail-dovecot

Checking the creation of Dovecot mailboxes

During the installation of Dovecot, mailboxes are created for all mail users. You have to wait for the completion of this process. This process can take a long time, depending on how many users' mailboxes have to be created.

To observe the creation of mailboxes by the listener, execute this command:

tail -f /var/log/univention/listener.log

The process is completed once you see the following line in the file “listener.log”:

LISTENER    ( WARN    ) : finished initializing module dovecot

Migrating the mail files

After all mailboxes have been created in Dovecot, the actual file migration can be started. After this point in time all incoming mails will be redirected to the new Dovecot mailboxes.

Checking the needed directories

The following directories need to be accessible on the system for the migration script: /var/spool/cyrus, /var/lib/cyrus.

They contain all mails as well as the Cyrus database und have to be accessible on the system that you want to migrate to. Thus, take care that mail spool and Cyrus database are accessible.

Executing the script “cyrus2dovecot”

Important note: The migration can take A LOT of time. It strongly depends on how many users have to be moved and how big their mailboxes are. In addition all of the users’ mail data is copied from /var/spool/cyrus to /var/spool/dovecot. Take care that you have free space of at least twice the size of the old Cyrus mail spool on the system for this operation, since the old Cyrus mail spool can only be removed after the migration is completed!

Since the paths for the users beginning with a number are located at a different location than all other users in Cyrus, we provide you with two different commands with different parameters. First all users, whose mail address begins with a number, are migrated. Afterwards all other users are migrated. The paths in the command are the default path names used by Cyrus and Dovecot in UCS.
Unless these paths are not at a different place than in the following command, we recommend to use it, since different variables, ensuring a complete, successful migration, are used.

Migrating all users, whose mail addresses begin with a number

Command to migrate all users, whose mail addresses begin with a number:

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/q/user/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot-numbers.log

Migrating all users, whose mail addresses do not begin with a number

Command to migrate all users, whose mail addresses do not begin with a number:

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/%1u/user/%U -U /var/lib/cyrus/domain/%g/%d/user/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot.log

Migrating all shared folders, whose mail addresses do not begin with a number:

Command to migrate all shared folders, whose mail addresses do not begin with a number:

/cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/%1u/shared/%U -U /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot_shared-numbers.log

Migrating all shared folders, whose mail addresses do begin with a number

Command to migrate all shared folders, whose mail addresses do begin with a number

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/q/shared/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot_shared.log

Testing migration and finishing

You can find a detailed view on how many mails of which user have been migrated in which time in the files cyrus2dovecot.log and cyrus2dovecot-numbers.log aswell as the standard output.

Once the migration is completed, we recommend to grant Dovecot the rights on the migrated files:

chown -R dovemail /var/spool/dovecot/

Cleaning up

Once the migration has finished successfully and the new mail stack’s functionality aswell as the existence of all old mails in the mailboxes has been validated, the old Cyrus mail spool can be deleted from the machine. Additionally the Cyrus packages can be cleaned up:

Uninstalling the cyrus packages

Obsolete Cyrus components can be deleted now:

apt-get purge cyrus-admin-2.4 cyrus-common cyrus-common-2.4 cyrus-imapd-2.4 cyrus-pop3d-2.4 libcyrus-imap-perl24
apt-get autoremove

Deleting Cyrus mail data

Cyrus’ old mail data can be deleted by simply deleting /var/spool/cyrus and /var/lib/cyrus:

rm -rf /var/lib/cyrus /var/spool/cyrus

Migrating Cyrus to Dovecot and switching machines

It is possible to perform the migration of Cyrus to Dovecot to a new server. The executable script does not change. We only changed the commands a bit. In addition the folders containing Cyrus mail data have to be mounted on the new system (using NFS shares for example).

In the first step we will prepare the new mail server and create the Dovecot mailboxes for all users on the new server. Afterwards we will describe how to mount Cyrus’ old mail data onto the new server via NFS. Then a migration command has to be executed, that is slightly different to the upper ones in the in-place migration part. All commands have to be executed as user “root” on the NEW mail server.

Preparation

Downloading the script

First the migration script has to be downloaded to the machine:

wget -nv https://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

If you run into a certificate error, execute this command:

wget -nv --no-check-certificate http://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

Make the downloaded script executable:

chmod +x ./cyrus2dovecot

Installating Dovecot

Install the app “Mail server” via the App Center on the UCS system. Alternatively, you can do that with the following command on the command line on the new mailserver:

univention-app install mailserver

Additionally, you should execute the new join scripts:

univention-run-join-scripts

Mount needed directories via NFS

The migration script needs the following diretories to operate: /var/spool/cyrus, /var/lib/cyrus.
They contain all mails aswell as the Cyrus database and have to be accessible on the system, you are migrating TO. For the migration onto a new system, make the directories available via a NFS share on the destination host for example. Create a NFS share on the old mailserver via the UMC for /var/spool/cyrus and /var/lib/cyrus.
Important note: Deactivate root squashing (untick the option “Modify user ID for root user (root squashing)” below the option “NFS” in the “Add” dialog). Then you can mount the shares onto the destination host with the following commands:

mkdir /var/spool/cyrus
mkdir /var/lib/cyrus
mount <OLD MAILSERVER>:/var/spool/cyrus /var/spool/cyrus
mount <OLD MAILSERVER>:/var/lib/cyrus /var/lib/cyrus/

Creating Dovecot mailboxes / changing univentionMailHomeServer attribute

To create new mailboxes for all mail users in Dovecot on the new server, the mailHomeServer attribute has to be set to the new machine. You can do this by editing the users in the UMC (mass edit) or with the following command.

Execute this command on the UCS master.
Replace <FQDN old mailserver>, as well as <FQDN old mailserver> with the FQDNs of your servers.

while read i; do udm users/user modify --dn "${i}" --set mailHomeServer="<FQDN new mailserver>"; done< <(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=<FQDN old mailserver>)(mailPrimaryAddress=*))" dn mailPrimaryAddress | grep ^dn | cut -f2 -d" ")

The command’s execution will take some time depending on how many users have to be changed.

Checking the new Dovecot mailboxes

During the modification of the mailHomeServer attribute new Dovecot mailboxes are created for all mail users on the new mailserver. This process can take a long time, depending on how many users' mailboxes have to be created. It has to be completed before the migration of the mail data.

To observe the creation of mailboxes by the listener, execute this command:

tail -f /var/log/univention/listener.log

Migrating Cyrus’ mail data

After all mailboxes have been created in Dovecot, you can begin with the actual data migration. After this point in time all incoming mails will be redirected into the new Dovecot mailboxes. Execute the following commands on the new mailserver:

Executing the script “cyrus2dovecot”

Important note: The migration can take A LOT of time. It strongly depends on how many users have to be moved and how big their mailboxes are. In addition all of the users’ mail data is copied from /var/spool/cyrus to /var/spool/dovecot. Take care that you have enough free space on the system for this operation!

Since the paths for the users beginning with a number are located at a different location than all other users in Cyrus, we provide you with two different commands with different parameters. First all users, whose mail address begins with a number, are migrated. Afterwards all other users are migrated. The paths in the command are the default path names used by Cyrus and Dovecot in UCS.
Unless these paths are not at a different place than in the following command, we recommend to use it, since different variables, ensuring a complete, successful migration, are used.

We recommend to change the “host basename” of the mails during the migration. The commands come with according start parameters.
Note that it is just about the “normal” hostname (host2) and NOT the FQDN (host2.domain.org).

Migrating all users, whose mail addresses begin with a number

Command to migrate all users, whose mail addresses begin with a number:

./cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/q/user/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot-numbers.log

Migrating all users, whose mail addresses do not begin with a number

Command to migrate all users, whose mail addresses do not begin with a number:

./cyrus2dovecot  --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/%1u/user/%U -U /var/lib/cyrus/domain/%g/%d/user/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot.log

Migrating all shared folders, whose mail addresses do not begin with a number:

Command to migrate all shared folders, whose mail addresses do not begin with a number:

/cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/%1u/shared/%U -U /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot_shared-numbers.log

Migrating all shared folders, whose mail addresses do begin with a number

Command to migrate all shared folders, whose mail addresses do begin with a number

./cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/q/shared/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot_shared.log

Testing migration and finishing

You can find a detailed view on how many mails of which user have been migrated in which time in the files cyrus2dovecot(_shared).log and cyrus2dovecot(_shared)-numbers.log aswell as the standard output.

Once the migration is completed, we recommend to grant Dovecot the rights on the migrated files:

chown -R dovemail /var/spool/dovecot/

The NFS share can be removed via UMC and unmounted:

umount /var/lib/cyrus /var/spool/cyrus

Cleaning up

Once the migration has been completed successfully and the functionality of the new mail stack, aswell as the existence of all old mails in the new mailboxes has been validated, the old Cyrus’ mail spool can deleted from the machine. Additionally, the Cyrus packages can be removed:

To enable mail users to access their mails/mailboxes, the new mailserver has to be configured in their clients and web apps. The DNS name of the old mailserver might be pointed to IP address of the new mailserver, to simplify this process.

Uninstallig Cyrus on the old mailserver

On the old mailserver, you can remove Cyrus be uninstalling the app “Mail server” via the App Center or by executing this command on the command line:

univention-app remove mailserver

Deleting Cyrus mail data

Cyrus’ old mail data can be deleted by simply deleting /var/spool/cyrus and /var/lib/cyrus:

rm -rf /var/lib/cyrus /var/spool/cyrus

Migration von Cyrus 2.4 nach Dovecot

$
0
0
Produktlogo UCS UCS 4 

Disclaimer

Aufgrund der Vielfalt an verschiedenen Mail-Appliances und strukturell unterschiedlichen Umgebungen, geben wir keine Gewähr auf den folgenden Artikel. Wir empfehlen die Migration zuvorderst immer in einer Testumgebung durchzuführen und eventuelle Unverträglichkeiten und Inkompatibilitäten mit Ihrer Produktivumgebung auszuschließen sowie ein Backup anzufertigen!

Einführung

Dieser Artikel beschreibt das Migrieren eines Cyrus Mail-Spools in einen Dovecot Mail-Spool. Diese Migration behält Mail-Flags und eigene Mail-Ordner bei. Ebenso werden geteilte Ordner (sog. Shared Folders) nach Dovecot migriert. Wir verwenden hierzu das Skript “cyrus2dovecot” der Freien Universität Berlin, da dieses es erlaubt durch verschiedene Startparameter die Migration gut zu automatisieren.

Für die Migration wichtig ist das LDAP-Attribut univentionMailHomeServer, welches festlegt an welchen Server in der Domäne eingehende Mails zugestellt werden. Es ist an jedem Benutzer mit Mail-Adresse standardmäßig vorhanden. Haben wir eine Maschine auf welcher Dovecot installiert und somit Cyrus deinstalliert wird, werden automatisch neue (Dovecot-)Mailboxen für alle Nutzer, die diesen Server als mailHomeServer eingetragen haben, durch den Listener-Notifier-Mechanismus erstellt. Wird der univentionMailHomeServer auf eine andere Maschine gesetzt, werden dort Mailboxen erstellt, sofern dort Dovecot installiert ist.

Bei der Migration werden per univention-ldapsearch die Mail-Adressen aller betroffenen Nutzer abgerufen und an cyrus2dovecot übergeben, welches mit den Startparametern feststellt, wo sich die zu migrierenden Daten befinden und wohin sie migriert werden sollen.

Beachten Sie, dass das Migrationsskript den Mailspool von Cyrus nicht löscht und somit nach einer Migration auf der Maschine sowohl der neue Dovecot-Spool als auch die alten Daten von Cyrus vorhanden sind. Sollte dies ein Kapazitätsproblem darstellen, sind entsprechende Vorkehrungen zu treffen. Gleichzeitig besteht aber so auch die Möglichkeit eines Fallbacks auf die alte Cyrus-Appliance.

Wichtige Hinweise

Beachten Sie, dass es je nach ihrer Durchführung zu einer Downtime kommen kann. Sollten sie die ganze Migration nur auf einer Maschine vollziehen, ist eine Downtime unvermeidlich, in einer Umgebung mit mehreren Maschinen besteht die Möglichkeit vor der eigentlichen Migration die mailHomeServer-Attribute der betroffenen Nutzer skriptbasiert so zu ändern, dass eingehende Mails bis zur erfolgten Erstellung der neuen Mailbox noch in die alten Cyrus-Boxen gehen und danach in die neuen Dovecot-Boxen. Die danach erfolgende Migration migriert dann alle Mails aus dem Cyrus-Spool in die neuen Dovecot-Boxen. Dies ist entsprechend auch eine geeignete Methode, falls neben der Migration von Cyrus zu Dovecot auch ein Wechsel des Server vollzogen werden soll oder keinerlei Wartungsfenster besteht.

Zudem ist es möglicherweise notwendig, dass die Benutzernamen an Mailclients (Thunderbird, Outlook, Mobil-Devices, etc.) geändert werden müssen. Dovecot lässt nur Anmeldungen mit der vollen Mail-Adresse zu (user1@example.org) während Cyrus sowohl die UID (Benutzername) als auch die Mail-Adresse (user1@example.org) als Anmeldenamen akzeptiert.

In Place Migration (ersetzten von Cyrus durch Dovecot auf dem gleichen Server)

Bei der In Place Migration werden alle Schritte auf dem Mailserver (also auf dem System, wo bisher Cyrus installiert ist) als root-Benutzer ausgeführt.
Während der Migration kann es sein, dass die Clients, welche sich mit dem Mail-Server verbinden, eine völlig leere Mailbox vorfinden, wenn selbige zwar angelegt aber die Mails noch nicht hinein migriert wurden.

Vorbereitung

Skript herunterladen

Zunächst sollte das Migrationsskript auf den Server heruntergeladen werden. Die MD5-Prüfsumme zur Erstellung des Artikels lautete: 506bb048473ccdb44191d88130606f1d

wget -nv https://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

Sollten Sie eine Fehlermeldung bzgl. des Zertifikats bekommen führen Sie folgenden Befehl aus:

wget -nv --no-check-certificate http://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

Das heruntergeladene Skript muss noch ausführbar gemacht werden:

chmod +x ./cyrus2dovecot

Installation Dovecot

Um Dovecot zu installieren und gleichzeitig Cyrus zu entfernen, kann folgender Befehl ausgeführt werden. /var/spool/cyrus und /var/lib/cyrus bleiben hiervon unberührt:

univention-install univention-mail-dovecot

Prüfen der erstellten Dovecot-Mailboxen

Während der Installation von Dovecot werden für alle Mailuser neue Mailboxen in Dovecot angelegt. Diesen Prozess müssen Sie vor der Migration der Maildaten abwarten.

Um dem Prozess des Erstellens der Mailboxen durch den Listener zu prüfen, kann folgender Befehl genutzt werden:

tail -f /var/log/univention/listener.log

Der Prozess ist abgeschlossen, wenn Sie im listener.log folgende Zeile sehen:

LISTENER    ( WARN    ) : finished initializing module dovecot

Der Vorgang dauert je nach Anzahl der Mailbenutzer einige Minuten.

Migration der Maildaten

Nachdem alle Mailboxen in Dovecot erstellt worden sind, kann mit der eigentlichen Datenmigration fortgefahren werden. Ab diesem Zeitpunkt werden auch alle neu eingehenden Mails in die neuen Dovecot-Mailboxen zugestellt.

Prüfen der notwendigen Verzeichnisse

Für das Migrationsskript müssen diese Verzeichnisse vorhanden sein: /var/spool/cyrus, /var/lib/cyrus.
Sie enthalten alle Mails, sowie die Cyrus-Datenbank und müssen auf dem System, auf das migriert werden soll, vorhanden sein. Stellen Sie also sicher, dass der Mail-Spool und die Cyrus-Bibliothek vorhanden sind.

Ausführen des Skripts cyrus2dovecot

Wichtiger Hinweis: Die Migration kann lange dauern. Es ist stark davon abhängig um wie viele User es sich handelt und wie groß deren Mailboxen sind. Außerdem wird die gesamten Maildaten der Benutzer auf dem System von einem Ort (/var/spool/cyrus) an einen anderen Ort kopiert (/var/spool/dovecot). Achten Sie daher auf genügend freien Speicherplatz auf dem System.

Da die Pfade für User, welche mit Zahlen beginnen in Cyrus anders sind als für alle anderen gibt es zwei Befehle mit unterschiedlichen Startparametern. Zuerst werden die Benutzer, deren Mail-Adresse mit einer Zahl beginnt, migriert. Im Anschluss alle weiteren Benutzer. Die Pfade im Befehl sind an die Standard-Pfade für Cyrus und Dovecot unter UCS angelehnt. Sofern sich diese Pfade nicht an einem anderen Ort befinden als in folgenden Befehl beschrieben, empfehlen wir diesen zu nutzen, da er verschiedene Variablen verwendet, welche eine vollständige, erfolgreiche Migration sicherstellen.

Migration aller User, deren Mail-Adresse mit einer Zahl beginnt

Für die Migration aller User, deren Mail-Adresse mit einer Zahl beginnt:

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/q/user/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot-numbers.log

Migration aller User, deren Mail-Adresse nicht mit einer Zahl beginnt

Für die Migration aller User, deren Mail-Adresse nicht mit einer Zahl beginnt:

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/%1u/user/%U -U /var/lib/cyrus/domain/%g/%d/user/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot.log

Migration aller Shared Folder, deren Mail-Adresse nicht mit einer Zahl beginnt

Migrations-Befehl für Shared Folder, deren Mail-Adresse mit einer Zahl beginnt:

/cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/%1u/shared/%U -U /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot_shared-numbers.log

Migration aller Shared Folder, deren Mail-Adresse mit einer Zahl beginnt

Migrations-Befehl für Shared Folder, deren Mail-Adresse nicht mit einer Zahl beginnt:

./cyrus2dovecot -C /var/spool/cyrus/mail/domain/%g/%d/q/shared/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot_shared.log

Migration prüfen und abschließen

In den Dateien cyrus2dovecot.log und ggf. cyrus2dovecot-numbers.log sowie auf der Standardausgabe finden Sie eine detaillierte Aufzählung wie viele Mails von welchem Benutzer in welcher Zeit migriert wurden.

Ist die Migration abgeschlossen empfiehlt es sich noch die Rechte der migrierten Dateien anzupassen:

chown -R dovemail /var/spool/dovecot/

Nachbereitung

Ist die Migration erfolgreich abgeschlossen worden und die Funktionalität des neuen Mailstacks sowie das Vorhandensein der alten Mails in den neuen Mailboxen validiert worden, kann der alte Cyrus Mailspool von der Maschine entfernt werden. Zudem kann eine Bereinigung der Cyrus-Pakete durchgeführt werden.

Deinstallation der Cyrus Paket

Die nicht mehr benötigten Cyrus Komponenten können entfernt werden:

apt-get purge cyrus-admin-2.4 cyrus-common cyrus-common-2.4 cyrus-imapd-2.4 cyrus-pop3d-2.4 libcyrus-imap-perl24
apt-get autoremove

Löschen der Cyrus Maildaten

Die alten Cyrus-Maildaten können Sie entfernen indem Sie /var/spool/cyrus und /var/lib/cyrus löschen:

rm -rf /var/lib/cyrus /var/spool/cyrus

Migration von Cyrus zu Dovecot mit einem Serverwechsel

Es ist möglich, die Migration von Cyrus zu Dovecot auf einen neuen Server durchzuführen. Das ausführbare Skript ändert sich nicht, lediglich die Befehle werden leicht verändert. Außerdem müssen die Verzeichnisse mit den Maildaten von Cyrus auf dem neuen System eingebunden werden (z.B. per NFS-Freigabe).

Im ersten Schritt wird der neue Mailserver vorbereitet und die Dovecot-Mailboxen für alle Benutzer auf dem neuen Server erstellt. Anschließend wird beschrieben, wie man die Maildaten von Cyrus auf dem neuen Server per NFS einbindet. Daraufhin muss ein etwas anderer Migrationsbefehl ausgeführt werden, als bei der In Place Migration.

Vorbereitung

Skript herunterladen

Zunächst sollte das Migrationsskript auf den Server heruntergeladen werden:

wget -nv https://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

Sollten Sie eine Fehlermeldung bzgl. des Zertifikats bekommen führen Sie folgenden Befehl aus:

wget -nv --no-check-certificate http://raw.githubusercontent.com/a-schild/cyrus2dovecot/master/cyrus2dovecot

Das heruntergeladene Skript muss noch ausführbar gemacht werden:

chmod +x ./cyrus2dovecot

Installation Dovecot

Installieren Sie über das App Center den Mailserver auf dem neuen UCS System. Alternativ können Sie dies mit folgendem Befehl auf der Kommandozeile auf dem neuen Mailserver durchführen:

univention-app install mailserver

Zudem sollten die neuen Join-Skripte ausgeführt werden, falls dies während der Installation nicht geschah.

univention-run-join-scripts

Benötigte Verzeichnisse per NFS einbinden

Für das Migrationsskript müssen diese Verzeichnisse vorhanden sein: /var/spool/cyrus, /var/lib/cyrus.
Sie enthalten alle Mails, sowie die Cyrus-Datenbank und müssen auf dem System, auf das migriert werden soll, vorhanden sein. Für die Migration auf ein neues System, machen Sie die beiden Verzeichnisse bspw. durch eine NFS Freigabe auf dem Zielsystem verfügbar. Erstellen Sie auf dem alten Mailserver jeweils eine NFS Freigabe über die UMC für die Verzeichnisse /var/spool/cyrus und /var/lib/cyrus. Wichtig: stellen Sie bei der NFS Freigabe das Root-Squashing aus (Haken bei “User-ID für Root-Benutzer ändern (Root-Squashing)” entfernen). Anschließend können die Freigaben mit folgenden Befehlen auf dem neuen Server eingebunden werden:

mkdir /var/spool/cyrus
mkdir /var/lib/cyrus
mount <ALTER MAILSERVER>:/var/spool/cyrus /var/spool/cyrus
mount <ALTER MAILSERVER>:/var/lib/cyrus /var/lib/cyrus/

Dovecot Mailboxen erstellen / mailHomeServer-Attribut umstellen

Um für alle Mailuser eine neue Mailbox in Dovecot auf dem neuen Server zu erstellen, muss das mailHomeServer-Attribut auf den neuen Mailserver gesetzt werden. Dies können Sie durch das Editieren der Benutzer in der UMC (Mass-Edit) oder durch folgenden Befehl durchführen.

Führe Sie diesen Befehl auf dem UCS Master aus.
Ersetzten Sie <FQDN neuer Mailserver>, sowie <FQDN alter Mailserver> entsprechend durch die FQDNs der Server.

while read i; do udm users/user modify --dn "${i}" --set mailHomeServer="<FQDN neuer Mailserver>"; done< <(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=<FQDN alter Mailserver>)(mailPrimaryAddress=*))" dn mailPrimaryAddress | grep ^dn | cut -f2 -d" ")

Der Befehl wird je nach Anzahl der Mailuser einige Zeit benötigen.

Prüfen der erstellten Dovecot-Mailboxen

Während der Umstellung des mailHomeServer-Attributs werden für alle Mailuser neue Mailboxen in Dovecot auf dem neuen Mailserver angelegt. Diesen Prozess müssen Sie vor der Migration der Maildaten abwarten.

Um dem Prozess des Erstellens der Mailboxen durch den Listener zu prüfen, kann folgender Befehl genutzt werden:

tail -f /var/log/univention/listener.log

Der Vorgang dauert je nach Anzahl der Mailbenutzer einige Minuten.

Migration der Maildaten

Nachdem alle Mailboxen in Dovecot erstellt worden sind, kann mit der eigentlichen Datenmigration fortgefahren werden. Ab diesem Zeitpunkt werden auch alle neu eingehenden Mails in die neuen Dovecot-Mailboxen zugestellt. Die weiteren Befehle führen Sie auf dem neuen Mailserver aus.

Ausführen des Skripts cyrus2dovecot

Wichtiger Hinweis: Die Migration kann lange dauern. Es ist stark davon abhängig um wie viele User es sich handelt und wie groß deren Mailboxen sind. Außerdem wird die gesamten Maildaten der Benutzer auf dem System von einem Ort (/var/spool/cyrus) an einen anderen Ort kopiert (/var/spool/dovecot). Achten Sie daher auf genügend freien Speicherplatz auf dem System.

Da die Pfade für User, welche mit Zahlen beginnen, in Cyrus anders sind als für alle anderen, gibt es zwei Befehle mit unterschiedlichen Startparametern. Zuerst werden die Benutzer, deren Mail-Adresse mit einer Zahl beginnt, migriert. Im Anschluss alle weiteren Benutzer. Die Pfade im Befehl sind an die Standard-Pfade für Cyrus und Dovecot unter UCS angelehnt. Sofern sich diese Pfade nicht an einem anderen Ort befinden als in folgenden Befehl beschrieben, empfehlen wir diesen zu nutzen, da er verschiedene Variablen verwendet, welche eine vollständige, erfolgreiche Migration sicherstellen.

Es empfiehlt sich während der Migration noch den “Host-Basename” der Mails zu modifizieren, dies ist in den folgenden Befehlen mit umgesetzt. Beachten Sie, dass es sich nur um den einfachen Hostname geht also “host2” und nicht den FQDN (host2.domäne.org).

Migration aller User, deren Mail-Adresse mit einer Zahl beginnt

Für die Migration aller User, deren Mail-Adresse mit einer Zahl beginnt:

./cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/q/user/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot-numbers.log

Migration aller User, deren Mail-Adresse nicht mit einer Zahl beginnt

Für die Migration aller User, deren Mail-Adresse nicht mit einer Zahl beginnt:

./cyrus2dovecot  --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/%1u/user/%U -U /var/lib/cyrus/domain/%g/%d/user/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/user/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(!(objectClass=univentionMailSharedFolder)))" dn mailPrimaryAddress | grep ^mailPrimaryAddress | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot.log

Migration aller Shared Folder, deren Mail-Adresse nicht mit einer Zahl beginnt

Migrations-Befehl für Shared Folder, deren Mail-Adresse mit einer Zahl beginnt:

/cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/%1u/shared/%U -U /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/%1u/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[^0-9]") | tee ./cyrus2dovecot_shared-numbers.log

Migration aller Shared Folder, deren Mail-Adresse mit einer Zahl beginnt

Migrations-Befehl für Shared Folder, deren Mail-Adresse nicht mit einer Zahl beginnt:

./cyrus2dovecot --dovecot-host=$(hostname) -C /var/spool/cyrus/mail/domain/%g/%d/q/shared/%U -U /var/lib/cyrus/domain/%g/%d/user/q/%U.sub -S /var/lib/cyrus/domain/%g/%d/shared/q/%U.seen -D /var/spool/dovecot/private/%d/%P/Maildir -u $(univention-ldapsearch -LLLo ldif-wrap=no "(&(univentionMailHomeServer=$(hostname -f))(mailPrimaryAddress=*)(objectClass=univentionMailSharedFolder))" dn cn | grep ^cn | cut -f2 -d" " | grep "^[0-9]") | tee ./cyrus2dovecot_shared.log

Migration prüfen und abschließen

In den Dateien cyrus2dovecot(_shared).log und ggf. cyrus2dovecot(_shared)-numbers.log sowie auf der Standardausgabe finden Sie eine detaillierte Aufzählung wie viele Mails von welchem Benutzer in welcher Zeit migriert wurden.

Ist die Migration abgeschlossen empfiehlt es sich noch die Rechte der migrierten Dateien anzupassen:

chown -R dovemail /var/spool/dovecot/

Die NFS Freigabe können Sie wieder entfernen und vorher die Freigaben aushängen:

umount /var/lib/cyrus /var/spool/cyrus

Nachbereitung

Ist die Migration erfolgreich abgeschlossen worden und die Funktionalität des neuen Mailstacks sowie das Vorhandensein der alten Mails in den neuen Mailboxen validiert worden, kann der alte Cyrus Mailspool von der Maschine entfernt werden. Zudem kann eine Bereinigung der Cyrus-Pakete durchgeführt werden.

Damit die Mailuser wieder an ihre Mails/Postfächer kommen, müssen in den Clients und Webanwendungen der neue Mailserver eingetragen werden. Ggf lässt sich der DNS Name des alten Mailservers auf die IP Adresse des neuen Mailserver übertragen.

Deinstallation der Cyrus Paket auf dem alten Mailserver

Auf dem alten Mailserver kann über das App Center die Mailstack entfernt werden. Alternativ können Sie auf dem Server folgendes aufrufen:

univention-app remove mailserver

Löschen der Cyrus Maildaten

Die alten Cyrus Maildaten entfernen Sie wie folgt von der Maschine. Dazu einfach /var/spool/cyrus und /var/lib/cyrus löschen:

rm -rf /var/lib/cyrus /var/spool/cyrus
Viewing all 78 articles
Browse latest View live


Latest Images