Disk Konfiguration und Kopano to grommunio HowTo: Unterschied zwischen den Seiten

Aus Neobikers Wiki
(Unterschied zwischen Seiten)
Zur Navigation springen Zur Suche springen
 
 
Zeile 1: Zeile 1:
= RAID Setup =
= Installation auf Debian 12 =
Mein RAID<ref>https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm</ref> Setup mit unterschiedlichen Disks.
Eine fertige grommunio Appliance ist auf Basis von S.u.S.E. erstellt und steht u.a. als ISO download zur Verfügung. Da ich derzeit ausschliesslich Debian basierte Systeme verwende, bevorzuge ich eine grommunio Installation auf Debian 12 (bookworm).


Anforderungen:
Im grommunio Forum findet sich ein Diskussionsthread für die [https://community.grommunio.com/d/447-debian-11-clean-install-script grommunio Installation auf Debian 12 durch ein Script]. Diese läuft auf einer neu erstellten VM auf Proxmox Server fehlerfrei durch. In einem LXC Container gab es Probleme, u.a. klemmte der POP3 Service.
# Eine Disk kann ausfallen, ohne Datenverlust (bis auf den "Verschnitt" in ''vg_single'' -> Backup)
# Eine Volume Group ''vg_single'' nimmt die Partitionen auf, die in kein RAID mehr passen ("Verschnitt")
# Alle Daten auf mindestens drei unterschiedlichen Disks, soweit möglich
# Alle Daten (Dokumente und VM's) sind verschlüsselt (md3_crypt), oder
# im RAID5 (Medien: Musik und Filme) über mindestens drei Disks verteilt (vg_disk) (''cryptdisk'' möglich, aber nicht notwendig)
# Alle aktiven VM's liegen auf der einzigen verschlüsselten SSD (sdf3_crypt)
# Alle VM's haben ein Snapshot auf einer verschlüsselten Disk (md3_crypt)
# Der XEN-Host und alle VM'S können im Notfall von allen Disks (md0 oder md1) gebootet werden (auf einem beliebigen anderem Rechner, sofern ein USB-Stick mit dem dem LUKS-Key verfügbar ist)


Mein Bootscript liest den [[LUKS|LUKS-Schlüssel zum Booten meines XEN-Servers auf mehreren Devices]] (USB-Sticks oder Festplatten).
Im Anschluss an das Installationsskript habe ich noch folgendes Script unter '''Additions''' - ''Fix Grommunio Admin Live Status page'' ausgeführt, welches ebenfalls funktionierte und die entsprechende Seite im Web Interface reparierte.


[[Bild:XEN-Disk-Setup.jpg]]
= Konfiguration =
Kopano Core ist bei mir als Applikation auf meinem UCS File- und Mailserver installiert. Die Benutzerkonten und deren Konfiguration werden von UCS verwaltet und stehen per LDAP zur Verfügung.


= Austausch der 2 TB Disk durch eine neue 8 TB Disk =
<pre># mein UCS-Kopano Server
kopano_server=ucsmail
echo "kopano_server=ucsmail" >> ~/.bashrc


Wo wird die 2TB Disk verwendet?
# ssh connections without prompts
ssh-keygen
ssh-copy-id $kopano_server


'''Welche Disk und welche RAID Verbunde sind betroffen?'''
# mount /var/lib/kopano/attachments per sshfs
<pre>
if [ -e /etc/debian_version ] then
# fdisk -l /dev/sdb
    apt install sshfs screen
Disk /dev/sdb: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
else
Disk model: WDC WD20EFRX-68A
     zypper in sshfs         # (grommunio app/iso installation)
Units: sectors of 1 * 512 = 512 bytes
fi
Sector size (logical/physical): 512 bytes / 4096 bytes
mkdir -p /mnt/kopano_attachments
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
sshfs $kopano_server:/var/lib/kopano/attachments /mnt/kopano_attachments
Disklabel type: gpt
Disk identifier: 1FB146D4-AEFD-1C4B-90AF-315105C08C34
 
Device          Start        End    Sectors  Size Type
/dev/sdb1        2048      4095      2048    1M BIOS boot
/dev/sdb2        4096    514047    509952  249M Linux RAID
/dev/sdb3      514048 1049090047 1048576000  500G Linux RAID
/dev/sdb4  1049090048 2097666047 1048576000  500G Linux RAID
/dev/sdb5  2097666048 3907029134 1809363087 862,8G Linux RAID
 
# cat /proc/mdstat | grep sdb | sort
md0 : active raid1 sda2[2] sdb2[1] sdf2[0]
md3 : active raid1 sde3[2](S) sda3[0] sdb3[1]
md4 : active raid5 sde4[5] sdd4[3] sdc4[2] sda4[0] sdb4[1]
md6 : active raid5 sde6[3] sda6[0] sdb5[1]
</pre>
 
== Disk aus RAID Verbund lösen ==
=== RAID 1===
==== md0 ====
<pre>
### md0 : active raid1 sda2[2] sdb2[1] sdf2[0]
###      254912 blocks [3/3] [UUU]
 
# mdadm /dev/md0 --fail /dev/sdb2 --remove /dev/sdb2
mdadm: set /dev/sdb2 faulty in /dev/md0
mdadm: hot removed /dev/sdb2 from /dev/md0
 
# mdadm --grow /dev/md0 --raid-devices=2
raid_disks for /dev/md0 set to 2
 
### md0 : active raid1 sda2[1] sdf2[0]
###      254912 blocks [2/2] [UU]
 
### console (dmesg)
[436568.811061] md/raid1:md0: Disk failure on sdb2, disabling device.
                md/raid1:md0: Operation continuing on 2 devices.
</pre>
 
==== md3 ====
<pre>
### md3 : active raid1 sde3[2](S) sda3[0] sdb3[1]
###      524287936 blocks [2/2] [UU]
###      bitmap: 0/4 pages [0KB], 65536KB chunk
 
# mdadm /dev/md3 --fail /dev/sdb3 --remove /dev/sdb3
mdadm: set /dev/sdb3 faulty in /dev/md3
mdadm: hot removed /dev/sdb3 from /dev/md3
 
 
### md3 : active raid1 sde3[2] sda3[0]
###      524287936 blocks [2/1] [U_]
###      [>....................]  recovery =  0.2% (1372800/524287936) finish=50.7min speed=171600K/sec
###      bitmap: 0/4 pages [0KB], 65536KB chunk
 
### console (dmesg)
[437831.642672] md/raid1:md3: Disk failure on sdb3, disabling device.
                md/raid1:md3: Operation continuing on 1 devices.
[437831.681725] md: recovery of RAID array md3
[440886.670057] md: md3: recovery done.
</pre>
 
=== RAID 5 ===
Zuerst ein Spare Device hinzufügen, bevor der RAID 5 Verbund aufgelöst wird, anschliessend die Disk entfernen.
 
VolumeGroup '''vg_single''' hat 1x 500GB Platz um den Spare für md4 aufzunehmen.
<pre>
# vgs
  VG        #PV #LV #SN Attr  VSize  VFree
  ssd        1  17  0 wz--n- 232,62g  12,62g
  vg_disk     4  2  0 wz--n-  9,38t <291,20g
  vg_single  2  5  0 wz--n-  3,77t    1,03t
  vm          1  8  0 wz--n- 499,98g  46,98g
 
# pvs
  PV                    VG        Fmt  Attr PSize  PFree
  /dev/mapper/md2_crypt  vg_disk  lvm2 a--  499,98g <291,20g
  /dev/mapper/md3_crypt  vm        lvm2 a--  499,98g  46,98g
  /dev/mapper/sda7_crypt vg_single lvm2 a--  68,71g  68,71g
  /dev/mapper/sde7_crypt vg_single lvm2 a--  <3,71t <986,73g
  /dev/mapper/sdf3_crypt ssd      lvm2 a--  232,62g  12,62g
  /dev/md4              vg_disk  lvm2 a--    1,95t      0
  /dev/md5              vg_disk  lvm2 a--  <5,26t      0
  /dev/md6              vg_disk  lvm2 a--    1,68t      0
 
# lvcreate -L 500G vg_single -n spare_md4
 
# fdisk -l /dev/vg_single/spare_md4
Disk /dev/vg_single/spare_md4: 500 GiB, 536870912000 bytes, 1048576000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 
# fdisk -l /dev/vg_single/spare_md4
### 1048576000 sectors
# fdisk -l /dev/sdb4
### 1048576000 sectors
</pre>
 
==== md4 ====
Braucht es eigentlich nicht: Zuerst ein Spare Device hinzufügen, bevor der RAID 5 Verbund aufgelöst wird, anschliessend die Disk entfernen.
 
Das Spare in den RAID hängen, bevor die neue Disk reinkommt bringt hier nix, denn sobald ich die alte Disk aus dem RAID5 nehme, fängt der SPARE an zu syncen. D.h. bis der Sync fertig ist, ist das RAID online, und bekommt ein Problem wenn eine weitere Disk ausfällt. Also kann ich auch gleich den RAID auf die neue Disk syncen - der RAID Verbund ist damit genauso lange ohne Redundanz wie mit einem Spare.
 
<pre>
### md4 : active raid5 sde4[5] sdd4[3] sdc4[2] sda4[0] sdb4[1]
###      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
###      bitmap: 0/4 pages [0KB], 65536KB chunk
 
# mdadm /dev/md4 --add /dev/vg_single/spare_md4
mdadm: added /dev/vg_single/spare_md4
 
### md4 : active raid5 dm-37[6](S) sde4[5] sdd4[3] sdc4[2] sda4[0] sdb4[1]
###      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
###      bitmap: 0/4 pages [0KB], 65536KB chunk
 
# mdadm /dev/md4 --fail /dev/sdb4 --remove /dev/sdb4
 
### md4 : active raid5 dm-37[6] sde4[5] sdd4[3] sdc4[2] sda4[0]
###      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [U_UUU]
###      [>....................]  recovery =  0.0% (157824/524155904) finish=331.9min speed=26304K/sec
###      bitmap: 0/4 pages [0KB], 65536KB chunk
</pre>
 
==== md6 ====
<pre>
## machen wir nicht, aber wenn's nötig gewesen wäre ein LV zu verkleinern (2T -> 1.5T):
## lvresize --resizefs --size 1.5T /dev/vg_single/media3
 
 
### md6 : active raid5 sde6[3] sda6[0] sdb5[1]
###      1809098752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
###      bitmap: 0/7 pages [0KB], 65536KB chunk
 
 
# mdadm /dev/md6 --fail /dev/sdb5 --remove /dev/sdb5
 
 
### md6 : active raid5 sde6[3] sda6[0]
###      1809098752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
###      bitmap: 0/7 pages [0KB], 65536KB chunk
</pre>
 
== Neue Disk dem RAID Verbund hinzufügen ==
Alte 2TB (ziehe den richtigen SATA-Stecker) ausbauen, neue 8TB Disk einhängen und entsprechend partitionieren (analog der vorhandenen 8TB Disk).
 
=== Disk Partitionieren <ref>https://wiki.ubuntuusers.de/gdisk/</ref>===
<pre>
## Partitionslayout prüfen
# sgdisk -p /dev/sde
Disk /dev/sde: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EFAX-68L
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 9142152D-B739-404A-8FD0-B8053DBDAB6A
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5056 sectors (2.5 MiB)
 
Number  Start (sector)    End (sector)  Size      Code  Name
  1            2048            4095  1024.0 KiB  EF02
  2            4096          514047  249.0 MiB  FD00
  3         514048      1049090047  500.0 GiB  FD00
  4      1049090048      2097666047  500.0 GiB  FD00
  5      2097666048      5860533134  1.8 TiB    FD00
  6      5860534272      7669897358  862.8 GiB  FD00
  7      7669899264    15628053134  3.7 TiB    8300
 
 
## sicherstellen dass die neue Disk wieder sde ist:
# cat /proc/mdstat | grep sde
# pvs | grep sde
# fdisk -l /dev/sde
Disk /dev/sde: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: WDC WD80EFAX-68K
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 
 
## Disk Partition Layout kopieren und mit neuer GUID versehen
# sgdisk -R /dev/sde /dev/sdb
The operation has completed successfully.
 
 
# sgdisk -p /dev/sde
Disk /dev/sde: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EFAX-68K
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 9142152D-B739-404A-8FD0-B8053DBDAB6A
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5056 sectors (2.5 MiB)
 
Number  Start (sector)    End (sector) Size      Code  Name
  1            2048            4095  1024.0 KiB  EF02
  2            4096          514047  249.0 MiB  FD00
  3          514048      1049090047  500.0 GiB  FD00
  4      1049090048      2097666047  500.0 GiB  FD00
  5      2097666048      5860533134  1.8 TiB    FD00
  6      5860534272      7669897358  862.8 GiB  FD00
  7      7669899264    15628053134  3.7 TiB    8300
 
 
# sgdisk -G /dev/sdb
 
 
# sgdisk -p /dev/sdb | grep GUID
Disk identifier (GUID): 996B3469-25F8-4D4E-B815-755FCF7D0BAD
</pre>
 
=== Vorhandenen RAID Verbund erweitern ===
Die Partitionen wieder den RAID hinzufügen:
==== vorherige RAID 1 und RAID 5 wieder herstellen ====
<pre>
# mdadm /dev/md6 --add /dev/sdb6
# cat /proc/mdstat
md6 : active raid5 sdb6[4] sde6[3] sda6[0]
      1809098752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
      [>....................]  recovery =  0.0% (286044/904549376) finish=105.3min speed=143022K/sec
      bitmap: 2/7 pages [8KB], 65536KB chunk
 
 
# mdadm /dev/md4 --add /dev/sdb4
# cat /proc/mdstat
md4 : active raid5 sdb4[7](S) dm-35[6] sdd4[3] sdc4[2] sda4[0] sde4[5]
      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
      bitmap: 0/4 pages [0KB], 65536KB chunk
 
# mdadm /dev/md4 --fail /dev/vg_single/spare_md4 --remove /dev/vg_single/spare_md4
mdadm: set /dev/vg_single/spare_md4 faulty in /dev/md4
mdadm: hot removed /dev/vg_single/spare_md4 from /dev/md4
 
 
# cat /proc/mdstat
md4 : active raid5 sdb4[7] sdd4[3] sdc4[2] sda4[0] sde4[5]
      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [U_UUU]
      [>....................]  recovery =  1.2% (6544540/524155904) finish=62.0min speed=138952K/sec
      bitmap: 0/4 pages [0KB], 65536KB chunk
 
 
# mdadm /dev/md3 --add /dev/sdb3
mdadm: hot added /dev/sdb3
 
# mdadm /dev/md0 --add /dev/sdb2
mdadm: hot added /dev/sdb2
 
# mdadm --grow /dev/md0 --raid-devices=3
raid_disks for /dev/md0 set to 3
 
 
# cat /proc/mdstat
md0 : active raid1 sdb2[2] sda2[1] sdf2[0]
      254912 blocks [3/3] [UUU]
 
# dmesg
[24027.083101] md: recovery of RAID array md0
[24028.592467] md: md0: recovery done.
 
# cat /proc/mdstat | grep sdb | sort
md0 : active raid1 sdb2[2] sda2[1] sdf2[0]
md3 : active raid1 sdb3[2](S) sda3[0] sde3[1]
md4 : active raid5 sdb4[7] sdd4[3] sdc4[2] sda4[0] sde4[5]
md6 : active raid5 sdb6[4] sde6[3] sda6[0]
</pre>
 
==== Disk-Kapazität eines RAID erweitern ====
 
Jetzt habe ich noch 2x Partitionen der 8TB Disk frei, die ich den vorhandenen Bereichen noch zurodnen kann:
* sdb5 mit 1.8 TB kann dem RAID md5 hinzugefügt werden -> zusätzliche '''1.8 TB''' Nettokapazität in RAID 5
* sdb7 mit 3.71 TB kann mit der Partition sde7 jetzt ein RAID 1 md7 erzeugen -> 3.71 TB jetzt durch '''RAID 1''' gesichert
 
 
Der einfache Teil:
<pre>
# pvs | grep md5
  /dev/md5              vg_disk  lvm2 a--  <5,26t      0
 
### md5 : active raid5 sdd5[2] sda5[0] sdc5[1] sde5[4]
###      5643902976 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
###      bitmap: 0/15 pages [0KB], 65536KB chunk
 
 
# mdadm --grow /dev/md5 --add /dev/sdb5 --raid-devices=5
mdadm: hot added /dev/sdb5
 
### md5 : active raid5 sdb5[5] sdd5[2] sda5[0] sdc5[1] sde5[4]
###      5643902976 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
###      [>....................]  reshape =  0.8% (16784524/1881300992) finish=776.2min speed=40029K/sec
###      bitmap: 0/15 pages [0KB], 65536KB chunk
 
[100928.214940] md: reshape of RAID array md5
[154854.879387] md: md5: reshape done.
[154856.021848] md5: detected capacity change from 5779356647424 to 7705808863232
 
 
# pvresize /dev/md5
  Physical volume "/dev/md5" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
 
# pvs | grep md5
  /dev/md5              vg_disk  lvm2 a--  <7,01t    1,75t
</pre>
</pre>


==== Verschlüsseltes RAID erstellen ====
== Zertifikate ==
Etwas aufwendiger:
Falls ein Server Zertifikat von UCS für den grommunio server erzeugt wurde kann das verwendet werden.
sde7 ist verschlüsselt (sde7_crypt) in der Volume Group sg_single eingebunden. Zusammen mit sdb7 soll ein RAID  1 erstellt werden. Da wir mit 2 Disks kein RAID 5 erstellen wollen, soll das neue RAID '''md7''' verschlüsselt (md7_crypt) werden, bevor wir es der vorhandenen Volume Group '''vg_disk''' hinzufügen. Dabei müssen die auf sde7 vorhandenen Dateien auf das neue RAID umgezogen werden.
Damit funktioniert die LDAP Verbindung auch zum einloggen mit starttls.
<pre>
<pre>
### md7 erzeugen als RAID 1 mit einer Disk (sde7 fügen wir später hinzu, nachdem wir sie freigeräumt haben)
cd /etc/grommunio-common/ssl
# mdadm --create /dev/md7 --level=1 --raid-devices=2 /dev/sdb7 missing
scp $kopano-server:/etc/univention/ssl/grommunio/cert.pem server-bundle.pem
mdadm: Note: this array has metadata at the start and
scp $kopano-server:/etc/univention/ssl/grommunio/private.key server.key
    may not be suitable as a boot device.  If you plan to
chown gromox:gromox server*
    store '/boot' on this device please ensure that
chmod 660 server*
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md7 started.
 
### md7 : active raid1 sdb7[0]
###      3978944832 blocks super 1.2 [2/1] [U_]
###      bitmap: 0/30 pages [0KB], 65536KB chunk
 
 
### md7_crypt erstellen: md7 mit LUKS verschlüsseln, und einen zusätzlichen Schlüssel hinterlegen (USB-Schlüssel)
root@corsair:~# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/md7
 
WARNING!
========
Hiermit werden die Daten auf »/dev/md7« unwiderruflich überschrieben.
 
Are you sure? (Type uppercase yes): YES
Geben Sie die Passphrase für »/dev/md7« ein:
Passphrase bestätigen:
 
### 2x USB Sticks können die Verschlüsselung öffnen
# cryptsetup luksAddKey /dev/md7 /etc/cryptkey/usb.FSC_MEMORYBIRD
Geben Sie irgendeine bestehende Passphrase ein:
# cryptsetup luksAddKey /dev/md7 /etc/cryptkey/usb.DELL_16M
Geben Sie irgendeine bestehende Passphrase ein:
 
 
### erstelle md7_crypt Eintrag
# echo "md7_crypt $(blkid | grep md7 | cut -d\  -f2 | tr -d \" ) /etc/cryptkey/usb.FSC_MEMORYBIRD luks,tries=3" >> /etc/crypttab
 
# # cryptdisks_start md7_crypt
[ ok ] Starting crypto disk...md7_crypt (starting)...md7_crypt (started)...done.
 
 
### md7_crypt in Volume Group vg_single ergänzen
# pvcreate /dev/mapper/md7_crypt
  Physical volume "/dev/mapper/md7_crypt" successfully created.
</pre>
 
==== Daten eines Logical Volume auf RAID migrieren ====
Die vorhandenen Daten im ungeschützten LV (ohne RAID) sollen auf das neue verschlüsselte RAID verschoben werden.
Dazu wird die Volume Group um das neue RAID erweitert, die Daten auf das RAID verschoben.
Anschliessend wird das bisher noch "degraded RAID" mit dem vorher geleerten Device erweitert, sodass der RAID-Schutz zukünftig gegeben ist.
<pre>
# vgextend vg_single /dev/mapper/md7_crypt
  Volume group "vg_single" successfully extended
 
# pvs | grep vg_single
  /dev/mapper/md7_crypt  vg_single lvm2 a--  <3,71t  <3,71t
  /dev/mapper/sda7_crypt vg_single lvm2 a--  68,71g  68,71g
  /dev/mapper/sde7_crypt vg_single lvm2 a--  <3,71t <486,73g
 
### sde7 freiräumen und aus Volume Group entfernen
# screen pvmove /dev/mapper/sde7_crypt /dev/mapper/md7_crypt
  /dev/mapper/sde7_crypt: Moved: 0,01%
 
 
# vgreduce vg_single /dev/mapper/sde7_crypt
  Removed "/dev/mapper/sde7_crypt" from volume group "vg_single"
 
 
### sde7_crypt auflösen
# cryptdisks_stop sde7_crypt
[ ok ] Stopping crypto disk...sde7_crypt (stopping)...done.
 
# cat /etc/crypttab | grep -v sde7_crypt > /etc/crypttab
 
### sde7 zu RAID md7 hinzufügen
# mdadm --add /dev/md7 /dev/sde7
mdadm: added /dev/sde7
 
# cat /proc/mdstat | grep md7 -A 4
md7 : active raid1 sde7[2] sdb7[0]
      3978944832 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.1% (4827840/3978944832) finish=483.9min speed=136862K/sec
      bitmap: 26/30 pages [104KB], 65536KB chunk
</pre>
 
==== RAID in andere Volume Group verschieben ====
Das RAID ''md7_crypt'' jetzt einen echten RAID Level erreicht und soll daher aus von ''vg_single'' nach ''vg_disk'' verschoben werden.
 
<pre>
# xen shutdown ucsmail
# lvchange -an vg_single
 
### md7_crypt aus Volume Group vg_single in Volume Group vg_disk verschieben
# vgsplit vg_single vg_disk /dev/mapper/md7_crypt
  Existing volume group "vg_disk" successfully split from "vg_single"
 
# vgs
  VG        #PV #LV #SN Attr  VSize  VFree
  ssd        1  17  0 wz--n- 232,62g 12,62g
  vg_disk    5  7  0 wz--n- <14,84t <3,00t
  vg_single  1  0  0 wz--n-  68,71g 68,71g
  vm          1  8  0 wz--n- 499,98g 46,98g


# lvchange -ay vg_disk
# Root CA
  7 logical volume(s) in volume group "vg_disk" now active
if [ -e /etc/debian_version ] then
 
    scp $kopano_server:/etc/univention/ssl/ucsCA/CAcert.pem /usr/local/share/ca-certificates/my-custom-ca/
# vorher: XEN Konfiguration anpassen vg_single -> vg_disk
else
# xen create ucsmail
    # SuSE appliance location
    scp $kopano_server:/etc/univention/ssl/ucsCA/CAcert.pem /etc/pki/trust/anchors/
fi
update-ca-certificates
</pre>
</pre>


Volume Group ''vg_disk'' ist um 3.71 TB gewachsen, während der Verschnitt in ''vg_single'' mit nur noch 68 GB vernachlässigbar ist. Sämtliche Daten sind jetzt in einem RAID gesichert, abgesehen von ''vg_single'', die ist jetzt unbenutzt.
== LDAP ==
 
Die LDAP Konfiguration kann mit dem UCS Template im Webinterface vorgenommen werden.
Sobald ich die nächste Disk ersetzen muss, wiederhole ich diese Prozedur.
Ich übernehme einige Kopano Werte:
Ob ich dann wieder 8 TB oder evtl. 12 TB oder 16 TB Disk kaufe wird sich zeigen, aber vermutlich reicht mir, wenn ich irgendwann 5x 8TB Bruttokapazität habe.
 
= Austausch der 8 TB Disk durch eine neue 8 TB Disk =
 
Meine ältere 8TB meldet seit ein paar Tagen defekte Sektoren. Da sie erst 1 Jahr alt ist schwupps die Amazon Bestellung rausgesucht und im Support Chat die Email des smartd eingestellt, mit der Bitte um Austausch. Nach 3 Minuten hatte ich meinen Rücksendeschein und volle Preiserstattung, also gleich eine Ersatzdisk bestellt.
Dabei habe ich erstmal wieder den c't Artikel rausgekramt, welchen Typ ich bestellen muss, da bei den WD RED Disks für ein SAN ja auf den CMR Typ geachtet werden muss.
 
<pre>
<pre>
This message was generated by the smartd daemon running on:
ssh $kopano_server grep -e ^ldap_uri -e ^ldap_bind -e ^ldap_search_base -e ^ldap_user_search -e ^ldap_group_search /etc/kopano/ldap.cfg


  host name: corsair
ldap_uri = ldap://ucsmail.domain.de:7389/
  DNS domain: friedrichnet.de
ldap_bind_user = cn=ucsmail,cn=dc,cn=computers,dc=domain,dc=de
ldap_bind_passwd = xxxxxxxxxxxxxx
ldap_search_base = dc=domain,dc=de
ldap_user_search_filter = (kopanoAccount=1)
ldap_group_search_filter = (&(kopanoAccount=1)(objectClass=kopano-group))


The following warning/error was logged by the smartd daemon:
# configure LDAP accordingly
grommunio-admin ldap configure


Device: /dev/sde [SAT], 7 Offline uncorrectable sectors
# test: list users
 
grommunio-admin ldap search
Device info:
ID                                    Type  E-Mail                  Name
WDC WD80EFAX-68LHPN0, S/N:2SGJYJWJ, WWN:5-000cca-27dc7b4d8, FW:83.H0A83, 8.00 TB
2222222222-11-10111-22222-3333333333  user  neobiker@neobiker.de    Neobiker
 
For details see host's SYSLOG.
</pre>
</pre>


Wo wird die 8TB alte Disk verwendet? -> überall ;-)
== Email Domains und User ==
Debian: das Anlegen einer Domain im Web-Interface schlägt direkt fehl - "Bad Request".<br>
Nicht schlimm, aber vielleicht nehme ich doch lieber die fertige Appliance auf Basis von S.u.S.E. ?


'''Welche Disk und welche RAID Verbunde sind betroffen?'''
Per Kommandozeile funktioniert es jedenfalls.
<pre>
<pre>
root@corsair:/etc# fdisk -l /dev/sde
domains=$(ssh $kopano_server ucr get mail/hosteddomains)
Disk /dev/sde: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
users=$(grommunio-admin ldap search)
Disk model: WDC WD80EFAX-68L
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9142152D-B739-404A-8FD0-B8053DBDAB6A


Device          Start        End    Sectors  Size Type
# create email domains
/dev/sde1        2048        4095      2048     1M BIOS boot
for domain in $domains; do
/dev/sde2        4096      514047     509952  249M Linux RAID
     u_cnt=$(echo "$users" | grep -c $domain)
/dev/sde3      514048  1049090047 1048576000  500G Linux RAID
     [ $u_cnt -gt 0 ] && echo grommunio-admin domain create -u $u_cnt $domain
/dev/sde4  1049090048  2097666047 1048576000  500G Linux RAID
done
/dev/sde5  2097666048  5860533134 3762867087  1,8T Linux RAID
/dev/sde6  5860534272  7669897358 1809363087 862,8G Linux RAID
/dev/sde7  7669899264 15628053134 7958153871  3,7T Linux filesystem


root@corsair:~# cat /proc/mdstat | grep 'sde' | sort
# import and sync LDAP users
md1 : active raid1 sdc2[0] sdd2[1] sde2[2]
grommunio-admin ldap downsync -c
md3 : active raid1 sda3[0] sdb3[2](S) sde3[1]
md4 : active (auto-read-only) raid5 sdc4[2] sdd4[3] sde4[5] sdb4[7] sda4[0]
md5 : active raid5 sdc5[1] sdd5[2] sde5[4] sdb5[5] sda5[0]
md6 : active raid5 sde6[3] sdb6[4] sda6[0]
md7 : active raid1 sde7[2] sdb7[0]
</pre>
</pre>
Der Import der User funktioniert jedenfalls auch über das Webinterface.


== Disk aus RAID Verbund lösen ==
=== Export - Import via Outlook .pst ===
 
Da ich nur 5 Konten habe, ist diese Methode auch nicht ganz abwegig:
=== RAID 1 ===
* Emails
==== md1 ====  
* Kalender
<pre>
* Kontakte
root@corsair:~# cat /proc/mdstat | egrep -A2 'md1'
* Notizen
md1 : active raid1 sdc2[0] sdd2[1] sde2[2]
* usw.
      254912 blocks [3/3] [UUU]
 
# mdadm /dev/md1 --fail /dev/sde2 --remove /dev/sde2
mdadm: set /dev/sde2 faulty in /dev/md1
mdadm: hot removed /dev/sde2 from /dev/md1


root@corsair:/etc# mdadm --grow /dev/md1 --raid-devices=2
<pre>gromox-pff2mt /tmp/neobiker_outlook.pst | gromox-mt2exm -u neobiker@neobiker.de
raid_disks for /dev/md1 set to 2
 
root@corsair:/etc# cat /proc/mdstat | egrep -A2 md1
md1 : active raid1 sdc2[0] sdd2[1]
      254912 blocks [2/2] [UU]
 
### console (dmesg)
md/raid1:md1: Disk failure on sde2, disabling device.
md/raid1:md1: Operation continuing on 2 devices.
</pre>
</pre>


==== md3 ====
=== Import von Emails aus Kopano ===
<pre>
Der Import landet (leider) in einem separatem Verzeichnis:
root@corsair:~# cat /proc/mdstat | egrep -A2 'md3'
[[Datei:Grommunio Import.jpg|mini]]
md3 : active raid1 sda3[0] sdb3[2](S) sde3[1]
      524287936 blocks [2/2] [UU]
      bitmap: 0/4 pages [0KB], 65536KB chunk
 
root@corsair:/etc# mdadm --grow /dev/md3 --raid-devices=3
raid_disks for /dev/md3 set to 3


root@corsair:/etc# cat /proc/mdstat | egrep -A2 'md3'
Das ist nicht ganz das was ich mir für einen Import vorstelle: Jeder User muss alle seine Inhalte manuell auf dem Server in die Hauptverzeichnisse verschieben ... ?
md3 : active raid1 sda3[0] sdb3[3] sde3[1]
      524287936 blocks [3/2] [UU_]
      [>....................]  recovery =  2.7% (14360320/524287936) finish=46.0min speed=184437K/sec


# mdadm /dev/md3 --fail /dev/sde3 --remove /dev/sde3
Ansonsten hat der Import prinzipiell für mein Neobiker Postfach funktioniert.
mdadm: set /dev/sde3 faulty in /dev/md3
mdadm: hot removed /dev/sde3 from /dev/md3


### console (dmesg)
<pre># gromox-kdb2mt — Utility for analysis/import of Kopano mailboxes
[437831.642672] md/raid1:md3: Disk failure on sdb3, disabling device.
# gromox-mt2exm — Utility for importing various mail items
                md/raid1:md3: Operation continuing on 1 devices.
[437831.681725] md: recovery of RAID array md3
[440886.670057] md: md3: recovery done.
</pre>


mkdir -p /mnt/kopano_attachments
sshfs $kopano_server:/var/lib/kopano/attachments /mnt/kopano_attachments


==== md7 ====
# detach (CTRL-A d) the SSH tunnel to SQL server (who only accepts localhost conections)
<pre>
screen ssh -L 12345:localhost:3306 "root@${kopano_server}"
root@corsair:~# cat /proc/mdstat | egrep -A2 'md7'
md7 : active raid1 sde7[2] sdb7[0]
      3978944832 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk


# mdadm /dev/md7 --fail /dev/sde7 --remove /dev/sde7
# EXAMPLE for user neobiker = neobiker@neobiker.de
mdadm: set /dev/sde7 faulty in /dev/md7
# ------------------------------------------------
mdadm: hot removed /dev/sde7 from /dev/md7
# ENVIRONMENT variable is used for SQL password
</pre>
# either EXPORT it or write in one line with cmd
export_mbox="gromox-kdb2mt --sql-host 127.0.0.1 --sql-port 12345 --src-attach /mnt/kopano_attachments"
SQLPASS=$(ssh $kopano_server cat /etc/mysql.secret)


SQLPASS=$SQLPASS $export_mbox --mbox-mro neobiker | gromox-mt2exm -u neobiker@neobiker.de


=== RAID 5 ===
kdb2mt: No ACLs will be extracted.
==== md4 ====
kdb Server GUID: xxxxxxxxxxxxxxxxxxxxxxxxxxx
<pre>
Database schema is kdb-118
root@corsair:~# cat /proc/mdstat | egrep -A2 'md4'
Store GUID for MRO "neobiker": xxxxxxxxxxxxxxxxxxxxxxxxx
md4 : active (auto-read-only) raid5 sdc4[2] sdd4[3] sde4[5] sdb4[7] sda4[0]
Processing folder "" (7 elements)...
      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
Processing folder "IPM_SUBTREE" (19 elements)...
      bitmap: 0/4 pages [0KB], 65536KB chunk
Processing folder "Posteingang" (791 elements)...
 
Processing folder "Postausgang" (0 elements)...
# mdadm /dev/md4 --fail /dev/sde4 --remove /dev/sde4
Processing folder "Gelöschte Objekte" (1 elements)...
mdadm: set /dev/sde4 faulty in /dev/md4
Processing folder "Gesendete Objekte" (1 elements)...
mdadm: hot removed /dev/sde4 from /dev/md4
Processing folder "Kontakte" (0 elements)...
Processing folder "Kalender" (1 elements)...
Processing folder "Entwürfe" (0 elements)...
Processing folder "Journal" (0 elements)...
Processing folder "Notizen" (0 elements)...
Processing folder "Aufgaben" (0 elements)...
Processing folder "Junk E-Mail" (44 elements)...
Processing folder "RSS Feeds" (0 elements)...
Processing folder "Konversationseinstellungen" (0 elements)...
Processing folder "Quickstep Einstellungen" (0 elements)...
Processing folder "Vorgeschlagene Kontakte" (0 elements)...
Processing folder "Spambox" (0 elements)...
Processing folder "Junk-E-Mail" (0 elements)...
Processing folder "Gelöschte Elemente" (0 elements)...
Processing folder "Gesendete Elemente" (0 elements)...
Processing folder "IPM_COMMON_VIEWS" (2 elements)...
Processing folder "IPM_VIEWS" (0 elements)...
Processing folder "FINDER_ROOT" (0 elements)...
Processing folder "Verknüpfung" (0 elements)...
Processing folder "Schedule" (0 elements)...
Processing folder "Freebusy Data" (1 elements)...
</pre>
</pre>


== Import aller Email Konten ==


==== md5 ====
<pre>
<pre>
root@corsair:~# cat /proc/mdstat | egrep -A2 'md5'
export_mbox="gromox-kdb2mt --sql-host 127.0.0.1 --sql-port 12345 --src-attach /mnt/kopano_attachments"
md5 : active raid5 sdc5[1] sdd5[2] sde5[4] sdb5[5] sda5[0]
SQLPASS=$(ssh $kopano_server cat /etc/mysql.secret)
      7525203968 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
      bitmap: 0/15 pages [0KB], 65536KB chunk


# mdadm /dev/md5 --fail /dev/sde5 --remove /dev/sde5
# LOOP over all email accounts (except SYSTEM)
mdadm: set /dev/sde5 faulty in /dev/md5
# --------------------------------------------
mdadm: hot removed /dev/sde5 from /dev/md5
users=$(ssh $kopano_server "kopano-admin -l | tail -n +4 | awk '{print $1}' | grep -v SYSTEM")
</pre>


==== md6 ====
for user in ${users}; do
<pre>
root@corsair:~# cat /proc/mdstat | egrep -A2 'md6'
md6 : active raid5 sde6[3] sdb6[4] sda6[0]
      1809098752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/7 pages [0KB], 65536KB chunk


# mdadm /dev/md6 --fail /dev/sde6 --remove /dev/sde6
  details=$(ssh $kopano_server kopano-admin --details $user)
mdadm: set /dev/sde6 faulty in /dev/md6
  email=$(echo "${details}" $user | awk '/Emailaddress:/ {print $2}')
mdadm: hot removed /dev/sde6 from /dev/md6
  guid=$(echo "${details}" $user | awk '/Store GUID:/ {print $3}')
</pre>


== Ersatz Disk wieder in RAID Verbund einfügen ==
  SQLPASS=$SQLPASS $export_mbox --mbox-guid $guid | gromox-mt2exm -u $email
Die Partitionen wieder den RAID hinzufügen: Rechner ausschalten, alte Disk ausbauen und neue Disk einsetzen.


=== RAID 5: md4 neu starten ===
done
Ein RAID (md4) kam nach dem booten nicht hoch. Ich starte es neu, ein resync war nicht notwendig.
<pre>root@corsair:~# cat /proc/mdstat | egrep -A2 'md4'
md4 : inactive sdc4[2](S) sdd4[3](S) sda4[0](S) sdb4[7](S)
      2096623616 blocks super 1.2


root@corsair:~# mdadm --stop /dev/md4
# stop ssh tunnel -> exit ssh on kopano server
mdadm: stopped /dev/md4
screen -r


root@corsair:~# mdadm --assemble /dev/md4
# unmount kopano attachments
mdadm: /dev/md4 has been started with 4 drives (out of 5).
umount /mnt/kopano_attachments
 
root@corsair:~/xen# cat /proc/mdstat | egrep -A2 'md4'
md4 : active (auto-read-only) raid5 sda4[0] sdd4[3] sdc4[2] sdb4[7]
      2096623616 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [UUUU_]
      bitmap: 0/4 pages [0KB], 65536KB chunk
</pre>
</pre>


=== vorherige Disk Partitionierung wieder herstellen ===
== Postfix ==
Übernehme die Formatierung der anderen 8TB (sdb) Disk
Mail Delivery Agent (MDA) Konfiguration
* zum versenden von Emails
* Mailaddress rewritings


Sicherstellen dass wir nichts kaputt machen, ist die neue Disk (sde) wirklich wieder auf dem alten Platz (sde) gelandet?
<pre>domains=$(ssh ucsmail ucr get mail/hosteddomains)
<pre>
root@corsair:~/xen# cat /proc/mdstat | grep sde
root@corsair:~/xen# pvs | grep sde
root@corsair:~/xen# fdisk -l /dev/sde
Disk /dev/sde: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: WDC WD80EFBX-68A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
</pre>
</pre>


====Partitionstabelle sichern====
== Mail Relay Server ==
<pre>
Postfix can use a mail relay server.
root@corsair:~/xen# sgdisk -b ~/Backup_sdb.GPT /dev/sdb 


root@corsair:~/xen# sgdisk -p /dev/sdb
<pre>ssh $kopano_server ucr get mail/relayhost</pre>
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EFAX-68K
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 996B3469-25F8-4D4E-B815-755FCF7D0BAD
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5056 sectors (2.5 MiB)


Number  Start (sector)    End (sector)  Size      Code  Name
<pre># authentification on relay host
  1            2048            4095  1024.0 KiB  EF02
/etc/postfix/smtp_auth
  2            4096          514047  249.0 MiB  FD00
# format
  3          514048      1049090047  500.0 GiB  FD00
# FQDN-Relayhost username:password
  4      1049090048      2097666047  500.0 GiB  FD00
  5      2097666048      5860533134  1.8 TiB    FD00
  6      5860534272      7669897358  862.8 GiB  FD00
  7      7669899264    15628053134  3.7 TiB    8300
</pre>


====Partitionstabelle von sdb nach sde übertragen und neue Datenträger-GUID zuweisen====
postmap /etc/postfix/smtp_auth
<pre>
postmap /etc/postfix/tls_policy
root@corsair:~/xen# sgdisk -R /dev/sde /dev/sdb
service postfix reload
root@corsair:~/xen# sgdisk -G /dev/sde
 
root@corsair:~# sgdisk -p /dev/sde | grep GUID
Disk identifier (GUID): EF58D3BB-5B53-4A33-B005-B734D9000B1D
</pre>
</pre>


=== vorherige RAID 1 und RAID 5 wieder herstellen ===
== Fetchmail ==
Binde die Partitionen der neuen Disk in die entsprechenden RAID wieder ein.
Fetchmail Konfiguration zum abholen der Emails von meinem Email Provider.
Emails werden entweder von UCS '''oder ''' grommunio abgeholt und and Postfix übergeben!


<pre>
Auf UCS für jeden Benutzer deaktivieren <br>
root@corsair:~# mdadm /dev/md1 --add /dev/sde1
-> ''Advanced settings ‣ Remote mail retrieval (single)''<br>
mdadm: added /dev/sde1
oder Postfix auf UCS zur weiterleitung an grommunio konfigurieren.
root@corsair:/etc# mdadm --grow /dev/md1 --raid-devices=3
raid_disks for /dev/md1 set to 3
root@corsair:~# cat /proc/mdstat | grep -A2 md1


root@corsair:~# mdadm /dev/md3 --add /dev/sde3
<pre>systemctl stop fetchmail
mdadm: added /dev/sde3
systemctl disable fetchmail
root@corsair:/etc# mdadm --grow /dev/md3 --raid-devices=3
ucr set fetchmail/autostart=false
raid_disks for /dev/md3 set to 3
root@corsair:~# cat /proc/mdstat | grep -A2 md3


root@corsair:~# mdadm /dev/md4 --add /dev/sde4
# fetchmail config and passwords
mdadm: added /dev/sde4
cat /etc/fetchmailrc
root@corsair:~# cat /proc/mdstat | grep -A2 md4
 
 
root@corsair:~# mdadm /dev/md5 --add /dev/sde5
mdadm: added /dev/sde5
root@corsair:~# watch "cat /proc/mdstat | grep -A2 md5"
Every 2,0s: cat /proc/mdstat | grep -A2 md5                                  corsair: Sun Apr 25 08:27:20 2021
 
md5 : active raid5 sde5[6] sdc5[1] sdd5[2] sdb5[5] sda5[0]
      7525203968 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [UUU_U]
      [=>...................]  recovery =  6.9% (131484148/1881300992) finish=233.0min speed=125120K/sec
 
root@corsair:~# mdadm /dev/md6 --add /dev/sde6
mdadm: added /dev/sde6
root@corsair:~# cat /proc/mdstat | grep -A2 md6
 
root@corsair:~# mdadm /dev/md7 --add /dev/sde7
mdadm: added /dev/sde7
root@corsair:~# cat /proc/mdstat | grep -A2 md7
</pre>
</pre>
<pre>
</pre>
Verweise:

Version vom 4. Januar 2024, 13:29 Uhr

Installation auf Debian 12

Eine fertige grommunio Appliance ist auf Basis von S.u.S.E. erstellt und steht u.a. als ISO download zur Verfügung. Da ich derzeit ausschliesslich Debian basierte Systeme verwende, bevorzuge ich eine grommunio Installation auf Debian 12 (bookworm).

Im grommunio Forum findet sich ein Diskussionsthread für die grommunio Installation auf Debian 12 durch ein Script. Diese läuft auf einer neu erstellten VM auf Proxmox Server fehlerfrei durch. In einem LXC Container gab es Probleme, u.a. klemmte der POP3 Service.

Im Anschluss an das Installationsskript habe ich noch folgendes Script unter Additions - Fix Grommunio Admin Live Status page ausgeführt, welches ebenfalls funktionierte und die entsprechende Seite im Web Interface reparierte.

Konfiguration

Kopano Core ist bei mir als Applikation auf meinem UCS File- und Mailserver installiert. Die Benutzerkonten und deren Konfiguration werden von UCS verwaltet und stehen per LDAP zur Verfügung. 

# mein UCS-Kopano Server
kopano_server=ucsmail
echo "kopano_server=ucsmail" >> ~/.bashrc

# ssh connections without prompts
ssh-keygen
ssh-copy-id $kopano_server

# mount /var/lib/kopano/attachments per sshfs
if [ -e /etc/debian_version ] then
    apt install sshfs screen
else
    zypper in sshfs          # (grommunio app/iso installation)
fi
mkdir -p /mnt/kopano_attachments
sshfs $kopano_server:/var/lib/kopano/attachments /mnt/kopano_attachments

Zertifikate

Falls ein Server Zertifikat von UCS für den grommunio server erzeugt wurde kann das verwendet werden. Damit funktioniert die LDAP Verbindung auch zum einloggen mit starttls. 

cd /etc/grommunio-common/ssl
scp $kopano-server:/etc/univention/ssl/grommunio/cert.pem server-bundle.pem
scp $kopano-server:/etc/univention/ssl/grommunio/private.key server.key
chown gromox:gromox server*
chmod 660 server*

# Root CA
if [ -e /etc/debian_version ] then
    scp $kopano_server:/etc/univention/ssl/ucsCA/CAcert.pem /usr/local/share/ca-certificates/my-custom-ca/
else
    # SuSE appliance location
    scp $kopano_server:/etc/univention/ssl/ucsCA/CAcert.pem /etc/pki/trust/anchors/
fi
update-ca-certificates

LDAP

Die LDAP Konfiguration kann mit dem UCS Template im Webinterface vorgenommen werden. Ich übernehme einige Kopano Werte: 

ssh $kopano_server grep -e ^ldap_uri -e ^ldap_bind -e ^ldap_search_base -e ^ldap_user_search -e ^ldap_group_search /etc/kopano/ldap.cfg

ldap_uri = ldap://ucsmail.domain.de:7389/
ldap_bind_user = cn=ucsmail,cn=dc,cn=computers,dc=domain,dc=de
ldap_bind_passwd = xxxxxxxxxxxxxx
ldap_search_base = dc=domain,dc=de
ldap_user_search_filter = (kopanoAccount=1)
ldap_group_search_filter = (&(kopanoAccount=1)(objectClass=kopano-group))

# configure LDAP accordingly
grommunio-admin ldap configure

# test: list users
grommunio-admin ldap search
ID                                    Type  E-Mail                   Name
2222222222-11-10111-22222-3333333333  user  neobiker@neobiker.de     Neobiker

Email Domains und User

Debian: das Anlegen einer Domain im Web-Interface schlägt direkt fehl - "Bad Request".
Nicht schlimm, aber vielleicht nehme ich doch lieber die fertige Appliance auf Basis von S.u.S.E. ?

Per Kommandozeile funktioniert es jedenfalls. 

domains=$(ssh $kopano_server ucr get mail/hosteddomains)
users=$(grommunio-admin ldap search)

# create email domains
for domain in $domains; do
    u_cnt=$(echo "$users" | grep -c $domain)
    [ $u_cnt -gt 0 ] && echo grommunio-admin domain create -u $u_cnt $domain
done

# import and sync LDAP users
grommunio-admin ldap downsync -c

Der Import der User funktioniert jedenfalls auch über das Webinterface.

Export - Import via Outlook .pst

Da ich nur 5 Konten habe, ist diese Methode auch nicht ganz abwegig:

  • Emails
  • Kalender
  • Kontakte
  • Notizen
  • usw.
gromox-pff2mt /tmp/neobiker_outlook.pst | gromox-mt2exm -u neobiker@neobiker.de

Import von Emails aus Kopano

Der Import landet (leider) in einem separatem Verzeichnis:

Das ist nicht ganz das was ich mir für einen Import vorstelle: Jeder User muss alle seine Inhalte manuell auf dem Server in die Hauptverzeichnisse verschieben ... ?

Ansonsten hat der Import prinzipiell für mein Neobiker Postfach funktioniert. 

# gromox-kdb2mt — Utility for analysis/import of Kopano mailboxes
# gromox-mt2exm — Utility for importing various mail items

mkdir -p /mnt/kopano_attachments
sshfs $kopano_server:/var/lib/kopano/attachments /mnt/kopano_attachments

# detach (CTRL-A d) the SSH tunnel to SQL server (who only accepts localhost conections)
screen ssh -L 12345:localhost:3306 "root@${kopano_server}"

# EXAMPLE for user neobiker = neobiker@neobiker.de
# ------------------------------------------------
# ENVIRONMENT variable is used for SQL password
# either EXPORT it or write in one line with cmd
export_mbox="gromox-kdb2mt --sql-host 127.0.0.1 --sql-port 12345 --src-attach /mnt/kopano_attachments"
SQLPASS=$(ssh $kopano_server cat /etc/mysql.secret)

SQLPASS=$SQLPASS $export_mbox --mbox-mro neobiker | gromox-mt2exm -u neobiker@neobiker.de

kdb2mt: No ACLs will be extracted.
kdb Server GUID: xxxxxxxxxxxxxxxxxxxxxxxxxxx
Database schema is kdb-118
Store GUID for MRO "neobiker": xxxxxxxxxxxxxxxxxxxxxxxxx
Processing folder "" (7 elements)...
Processing folder "IPM_SUBTREE" (19 elements)...
Processing folder "Posteingang" (791 elements)...
Processing folder "Postausgang" (0 elements)...
Processing folder "Gelöschte Objekte" (1 elements)...
Processing folder "Gesendete Objekte" (1 elements)...
Processing folder "Kontakte" (0 elements)...
Processing folder "Kalender" (1 elements)...
Processing folder "Entwürfe" (0 elements)...
Processing folder "Journal" (0 elements)...
Processing folder "Notizen" (0 elements)...
Processing folder "Aufgaben" (0 elements)...
Processing folder "Junk E-Mail" (44 elements)...
Processing folder "RSS Feeds" (0 elements)...
Processing folder "Konversationseinstellungen" (0 elements)...
Processing folder "Quickstep Einstellungen" (0 elements)...
Processing folder "Vorgeschlagene Kontakte" (0 elements)...
Processing folder "Spambox" (0 elements)...
Processing folder "Junk-E-Mail" (0 elements)...
Processing folder "Gelöschte Elemente" (0 elements)...
Processing folder "Gesendete Elemente" (0 elements)...
Processing folder "IPM_COMMON_VIEWS" (2 elements)...
Processing folder "IPM_VIEWS" (0 elements)...
Processing folder "FINDER_ROOT" (0 elements)...
Processing folder "Verknüpfung" (0 elements)...
Processing folder "Schedule" (0 elements)...
Processing folder "Freebusy Data" (1 elements)...

Import aller Email Konten

export_mbox="gromox-kdb2mt --sql-host 127.0.0.1 --sql-port 12345 --src-attach /mnt/kopano_attachments"
SQLPASS=$(ssh $kopano_server cat /etc/mysql.secret)

# LOOP over all email accounts (except SYSTEM)
# --------------------------------------------
users=$(ssh $kopano_server "kopano-admin -l | tail -n +4 | awk '{print $1}' | grep -v SYSTEM")

for user in ${users}; do

  details=$(ssh $kopano_server kopano-admin --details $user)
  email=$(echo "${details}" $user | awk '/Emailaddress:/ {print $2}')
  guid=$(echo "${details}" $user | awk '/Store GUID:/ {print $3}')

  SQLPASS=$SQLPASS $export_mbox --mbox-guid $guid | gromox-mt2exm -u $email

done

# stop ssh tunnel -> exit ssh on kopano server
screen -r

# unmount kopano attachments
umount /mnt/kopano_attachments

Postfix

Mail Delivery Agent (MDA) Konfiguration

  • zum versenden von Emails
  • Mailaddress rewritings
domains=$(ssh ucsmail ucr get mail/hosteddomains)

Mail Relay Server

Postfix can use a mail relay server. 

ssh $kopano_server ucr get mail/relayhost
# authentification on relay host
/etc/postfix/smtp_auth
# format
# FQDN-Relayhost username:password

postmap /etc/postfix/smtp_auth
postmap /etc/postfix/tls_policy
service postfix reload

Fetchmail

Fetchmail Konfiguration zum abholen der Emails von meinem Email Provider. Emails werden entweder von UCS oder grommunio abgeholt und and Postfix übergeben!

Auf UCS für jeden Benutzer deaktivieren
-> Advanced settings ‣ Remote mail retrieval (single)
oder Postfix auf UCS zur weiterleitung an grommunio konfigurieren. 

systemctl stop fetchmail
systemctl disable fetchmail
ucr set fetchmail/autostart=false

# fetchmail config and passwords
cat /etc/fetchmailrc
Abgerufen von „http://neobiker.de/wiki/index.php?title=Disk_Konfiguration&oldid=2048“