Wie geht's mit dem Zarafa Package weiter?

[catweazle71]

Hi Andy
Verstehe ich grad nicht. Mit fetchmail habe ich keine Probleme. Das senden geht nicht.
Die Fehlermeldung bezieht sich eher auf postfix.

Oder meinst du was anderes?

 

[Andy+]

Prüf mal den Parameter, wenn der auf "no" steht gehts auch nicht. Das nächste wären die Einträge und der Port in der

/etc/zarafa4h/postfix/sasl_passwd

Prüfe mal, ob dort die Einträge iO. sind. Darin stehen Deine Relaydaten für den Emailversand, also

SMTPSERVER:25/587/465 BENUTZERNAMEASSWORT

Könnte ja sein, dass der Port 25 nicht mehr geht bei Deinem Provider, dann wäre ggf. das der Grund (steht da keine Port-Nr. ist Port 25 eingestellt).

Dann guck mal das durch.

 

[catweazle71]

Mache ich mal. Geht leider erst die Tage. Aktuell komme ich nicht auf die Konsole ran ��
Danke dir

 

[hrob]

Hallo,

ich habe mich mittlerweile dafür entschieden, die MySQL-Datenbank auf ein EXT4 Volume zu verschieben. Damit erreiche ich problemlos eine 3-4x größere Performance. Alles andere kann auch auf BTRFS laufen.

VG

 

[Andy+]

Weil das bei mir nicht so einfach geht, ohne das Volume platt zu machen, suche ich gerade eine schlüssige Vorgehensweise, die Anhänge zu exportieren. Daher wäre zunächst die Frage, ob es nicht besser wäre, die Anhänge zu exportieren. Dazu gibt es ein Script "db-convert-attachments-to-files", was die Anhänge aus der Datenbank in das Filesystem verschiebt. Das finde ich nur nicht. Beim Start soll noch die Option "--ignore-attachment-storage-conflict" mitgegeben werden. In der server.cfg ist dann umzustellen :

# Where to place attachments. Value can be 'database', 'files' or 's3'
attachment_storage = database

# When attachment_storage is 'files', use this path to store the files
# When attachment_storage is 's3', use this path to set a prefix to all
# attachment data of a certain cluster, for example 'attach'
attachment_path = /xxxx/xxxx/xxxx/xxxx

Zum Thema habe ich bislang das gefunden.

 

[FricklerAtHome]

Das Script liegt weiter an der alten Stelle im Docker Container

/usr/share/doc/zarafa bis zur Version 0.6.9

Ab der 0.7.1 ist es nicht mehr drin.
Zur Nutzung müsste man es sich aus einer Alt-Version rauskopieren. Oder Tosoboso kann das in der nächsten Version wieder hinzufügen.

Gruss der FricklerAtHome

 

[Andy+]

Ich habe nur "/usr/share", die weiteren Verzeichnisse habe ich nicht. Der danach folgende Neustart soll wohl so aussehen :

zarafa-server -c /etc/zarafa/server.cfg --ignore-attachment-storage-conflict

Kann das sein?

 

[Andy+]

Ich habe folgendes gefunden.

Aufruf :

perl db-convert-attachments-to-files <ysql_user>t <sql_password> <sql_datenbank> /volume1/zarafa_attachments

Das Script:

#!/usr/bin/perl -w

use strict;
use DBI;

my $L1 = 10;
my $L2 = 20;

sub do_error($) {
exit(1);
}

sub readable {
my $size = shift;
my @add = qw( B KB MB GB TB );
my $i ;
for ($i = 0; $i < 5;$i++) {
if ( int($size / 1024) > 0 ) {
$size = $size / 1024;
} else {
$size = 0.01*int(0.5+ $size/0.01) . " " . $add[$i];
- db-convert-attachments-to-files 1/137 0%
my $free = `df -P $basepath | tail -1 | awk '{print \$4}'`;
chomp($free);
print "Available space is: " . $free . " Bytes (" . readable($free) . ")\n";

if ( $dbsize >= $free ) {
print "Not enough space left on device.\n";
exit(0);
}


print "Finding all attachments...\n";
$sth = $db->prepare("SELECT distinct(instanceid) FROM lob WHERE tag=0x3701");
$sth->execute() || die $DBI::errstr;;

if ($sth->rows == 0) {
print "No attachments found.\n";
exit(0);
}

print "Processing ".$sth->rows." attachments\n";

while(@row = $sth->fetchrow_array()) {
my @data;
my $path = $basepath."/".($row[0] % $L1)."/".(($row[0] / $L1) % $L2);
my $filename = $path."/".$row[0];

system("mkdir -p ".$path) == 0 or die("Unable to create attachment direc

if ( -s $filename ) {
next;
}
open(AFILE, ">".$filename) or die("Unable to open new attachment file");

my $sth2 = $db->prepare("SELECT val_binary FROM lob WHERE instanceid=".$
$res = $sth2->execute();
if(!$res) {
print " Unable to extract attachment ".$row[0]."\n";
next;
}

while (@data = $sth2->fetchrow_array()) {
print AFILE $data[0] or die("Not all data could be retrieved fro
}
close(AFILE);
}

print "Done.\n";

if (defined($delete) && $delete) {
print "Deleting attachments from database...\n";
$sth = $db->prepare("DELETE FROM lob WHERE tag=0x3701");
$sth->execute() || die $DBI::errstr;
print "Done.\n";
}

print "Remember to correct the ownership of the files for Zarafa to access, when

$db->do("commit;");

 

[Andy+]

Bei Kopano finde ich vergleichbares in der Dokumentation, wie bei Zarafa :

5.6. Storing attachments outside the database

Since KC version 6.0 it is possible to save the attachments outside the database. KC 7.0.5 and higher will use the filesystem as default location for attachment storage.

For first time installations, the attachment storage method should be selected before starting the server for the first time as it is not easy to switch the attachment storage method later on.

To change the attachment storage location, edit the following option in the /etc/kopano/server.cfg.

attachment_storage = files
attachment_path = /var/lib/kopano/attachments

For upgrades, a script exists that copies the attachments from the database to the file storage. This script can be found in /usr/share/doc/kopano, and is named db-convert-attachments-to-files. This script can be used as follows:

db-convert-attachments-to-files <myuser> <mypass> <mydb> <dest path> [delete]

Note

The script can be executed while the kopano-server process is running.

It is only possible to convert from database storage to file storage. The <delete> switch is optional. If this parameter is given, the attachments are also removed from the database. Keep in mind that during the conversion the storage of the attachments on the harddisk will double. The amount of storage in MySQL used by KC can be looked up the with the following MySQL statements:

use kopano;
show table status;

Check the data_length column for the lob table. This contains the number of bytes needed for the attachment storage.

To select this new storage method, change the attachment_storage option in the server.cfg file and point the attachment_path option to the folder where the attachments should be stored. After changing this option kopano-server needs to be started once with the --ignore-attachment-storage-conflict parameter.

Advantages of attachments outside the database are:

MySQL does not save the large binary blobs in the database. This improves the general read and write access.
Attachments will not cause cache purges of MySQL.
Make use of deduplication techniques (for example filesystem capabilities or through hardlinking) to further reduce hard disk space.

Disadvantages of attachments outside the database are:

A MySQLdump of the database is not enough for a full recovery.
Remote storage of attachments requires a new system, like folder mounted through NFS or Samba.

Important

It is very important, when choosing to store the attachments outside the database, to update the backup strategy accordingly.

Important

When using NFS as storage backend for Attachment-Store or as WebApp TMP_PATH we recommend turning of NFS locking by using the -o nolock mount option as this potentially can cause severe performance penalties.

 

[FricklerAtHome]

Hallo Andy+

das ist das richtige Script und die Vorgehensweise ist in den Handbüchern erklärt. Wir verzichten auf die Ablage im Dateisystem. Die Vor- und Nachteile sind ja in der Anleitung beschrieben. Das muss jeder für sich entscheiden. Uns ist ein Disaster-Recovery bei dem wir auch noch auf das Attachment-Share achten müssen, zu kompliziert. Dateispeicherord und Datenbank müssen damit quasi immer syncron gesichert werden. Geht ----, uns aber zu viel Aufwand.
Den letzten dicken Fisch an Zarafa-Datenbank mit fast 9 GB Primär Größe (fast 6 Jahre Laufzeit, Migration von Julians ZARA auf Z4H, 8 Benutzer) haben wir, mit den schon von mir beschriebenen, Operationen an der Datenbank {Orphans, Defrag, Optimierung} auf 4,2 GB herunterbekommen. --- Ganz ohne auch nur eine Mail oder Anhang zu löschen ---
Dann haben wir die Benutzer gebeten (vor allem die Kinder mit etlichen Fun-Videos) ihre Postfächer mal streng nach Schrott abzusuchen. Hat nochmal 0,5 GB gebracht. Erneut defragmentier und optimiert: Siehe da aus lahmen 9 GB primär wurden angenehme 3,8 GB.

Das wir ansonsten immer restriktiver, mit den Benutzern umgehen, Quotas einsetzen und über ein "verregeltes" IMAP-OUTLOOK alle empfangenen und versendeten Mail kontinuierlich backupen, hat noch keiner in der eigenen oder in den fremdbetreuten Installation über einen Verlust von E-Mails klagen müssen. Kontakte / Kalender / Aufgaben etc. bleiben ja in der ZARA-Datenbank. Sie fressen aber auch nach Jahren nur sehr wenig Platz.

Gruss der FricklerAtHome

 

[Andy+]

......Nutzt bitte für die Optimierung eine der zahlreichen Anleitungen im Internet...........

Was ist da die geeignete?

.......... MyMaxPaket und InnoDB_Buffer........

In welcher Datei und wo liegen die? Empfohlene Parameter?

........Web-App deaktivieren wir im übrigen konsequent den Spell-Checker. Wir können es zwar nicht beweisen aber gefühlt wird das Ding dann geschmeidiger. ........

Das habe ich auch schon so eingerichtet und nehme auch einen Unterschied wahr.

Zur Zeit hat meine Datenbank 9.5 GB, wenn ich über den Client über Outlook im Offlinenmodus eine OST-Datei anlege, ist diese nicht ganz 8 GB gross. Da nehme ich mal an, dass ich da nicht viel erreichen kann mit Optimierungen. Die Performance allerdings ist manchmal nicht nachvollziehbar, insbesondere, wenn einige Minuten keine Zugriffe erfolgen über die WebAPP, dann sind erst mal wieder Ladezeiten angesagt und dann läuft es wieder besser.

Bringt da der Switch zu MariaDB10 etwas?

 

[Andy+]

Ich möchte mal testen, die Zarafa-Datenbank in die MariaDB 10 zu übernehmen, was ich am besten über das Zarafa-Backup machen könnte. Jedoch müsste ich im Script die my.cnf der MariaDB 10 ansprechen, ich weiss jedoch nicht sicher, ob ich den richtigen Pfad habe:

-----------------------------------------------------------------------------------------------------

Für MariaDB 5 ist dieser
/var/packages/MariaDB/etc/my.cnf

oder ersatzweise vielleicht
/volume1/@appstore/MariaDB/etc/mysql/my.cnf


Für MariaDB 10 wäre dieser dann doch (?)
/var/packages/MariaDB10/target/usr/local/mariadb10/etc/mysql/my.cnf

oder ersatzweise vielleicht (?)
/volume1/@appstore/MariaDB10/usr/local/mariadb10/etc/mysql/my.cnf


Wenn ich den Pfad in dem Zarafa-Backup-Script anpasse auf "/var/packages/MariaDB10/target/usr/local/mariadb10/etc/mysql/my.cnf" bekomme ich beim Restore einen Permission-Fehler und das Script stoppt mal in Line 47 oder auch mal 50. Ich kann mir da keinen Reim machen im Moment. Die Datenbank "zarafa4h" habe ich händisch angelegt in der MariaDB 10. Ist das ggf. der Fehler?

-----------------------------------------------------------------------------------------------------

Wenn ich dann später in der server.cfg den Part für MySQL anpasse in

##############################################################
# MYSQL SETTINGS (for database_engine = mysql)

# MySQL hostname to connect to for database access
mysql_host = localhost

# MySQL port to connect with (usually 3306, 3307)
mysql_port = 3307

# The user under which we connect with MySQL
mysql_user = zarafa4h

# Override the default MySQL socket to access mysql locally
# Works only if the mysql_host value is empty or 'localhost'
mysql_socket = /run/mysqld/mysqld10.sock

# Database to connect to
mysql_database = zarafa4h

##############################################################

sollte das doch laufen. Was meint ihr?

 

[Online78]

Hallo Liebe Experten

vielen Dank mal erst an Tobosco und alle, welche es mir ermöglichten, mein altes Zarafa von DSM 5.2 auf Zarafa4Home auf DS6.1.4 umzuziehen. Es läuft nun mit Handy und Client. Leider läuft ja die Webapp sehr langsam. Bin echt daran interessiert, diese zu beschleunigen. Die Hinweise von FricklerAtHome muss ich mal noch ausprobieren. Es ist jedoch sicher noch möglich, die DB sonst noch zu beschleunigen. Meint ihr, dass sie schneller läuft mit MariaDB10? Wäre echt toll, wenn wir hier eine gute Lösung für angenehme Anwendung der Webapp finden könnten.

was denkt ihr, könnten diese Hinweise helfen die Zarafa4home DB zu beschleunigen? Link: https://www.boernyblog.de/mariadb-auf-synology-diskstation-beschleunigen/

Übringens, zuerst versuchte ich zarafa4home auf der DSM5.2 laufen zu lassen. Da ging die webapp super fix. Nachdem ich auf DSM 6.1.4 und MariaDB5 gewechselt habe, ging es nur noch extrem langsam. Es hat also mit MariaDB5 und der DB zu tun.

also nochmals vielen Dank für alle Investition in dieses Projekt,
Domi

 

[chats]

LIZENZFRAGE.
Ich habe eine Lizenz für 10 Outlook Clients aus der vorherigen Zarafa Version von Julian Dohle.
Weiß jemand ob man die Lizenzen übernehmen kann oder muss ich eine neue kaufen?
Und wie werden diese in Zarafa4h eingebunden? Gena so wie bei der vorherigen Zarafa Version?
Kann ich mir die Lizenz irgendwo anzeigen lassen?

Hilfe wäre nett. Danke.

 

[Andy+]

Ich würde diese Frage an Kopano richten, welche den Support für Zarafa übernommen hat. Das Einbinden wird wohl nach deren Vorgabe laufen, im Einzelnen wird Tosoboso vlt. noch was sagen müssen.

 

[Andy+]

................Hinweise helfen die Zarafa4home DB zu beschleunigen? Link: https://www.boernyblog.de/mariadb-auf-synology-diskstation-beschleunigen/.............

Die Hinweise sind gut. Ich habe diese in die my.cnf eingebaut. Alle Vorgänge sind deutlich flinker. Zwar noch nicht so ganz, wie man sich das auch mit etwas Nachsicht vorstellen könnte, aber immerhin.

 

[Andy+]

Ich habe das mal weiter verändert und die Parameter teils deutlich erhöht. Damit flutscht Zarafa4h nun gut, wenn im Fluss gearbeitet wird. Ist das Fenster eine Weile offen und die Arbeit wird wieder aufgenommen, dauert es etwas, bevor es wieder weitergeht.

Ich denke, der Autor hatte ein 4 oder 8GB-System und daher mal schon von daher multipliziert und noch was draufgelegt. Ich rate da zum testen, mehr, als dass MariaDB nicht mehr startet, könnte eigentlich nicht passieren. Wie folgt, meine jetzigen Parameter, wobei ich nicht recht weiss, was zuviel oder noch zu wenig ist für ein 16GB-System :

------------------------------

[client]
port = 3306
socket = /run/mysqld/mysqld.sock

[mysqld]
bind-address = 0.0.0.0
port = 3306
socket = /run/mysqld/mysqld.sock
skip-external-locking
max_allowed_packet = 100M
table_open_cache = 1024
key_buffer_size = 1G
sort_buffer_size = 1G
read_buffer_size = 16M
read_rnd_buffer_size = 64M
net_buffer_length = 10K
thread_stack = 512K
thread_concurrency = 8
thread_cache_size = 8
innodb_data_home_dir = /var/packages/MariaDB/target/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/packages/MariaDB/target/mysql
innodb_buffer_pool_size = 4G
innodb_additional_mem_pool_size = 256M
#innodb_log_file_size = 20M
#innodb_log_buffer_size = 32M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
innodb_file_per_table = 1

[mysqldump]
quick
max_allowed_packet = 100M

[mysql]
query_cache_size = 512M
query_cache_type = 1
tmp_table_size = 1G
max_heap_table_size = 1G
no-auto-rehash

[myisamchk]
read_buffer = 128M
write_buffer = 128M
myisam_sort_buffer_size = 512M

[mysqlhotcopy]
interactive-timeout

# Please add your custom configuration to here:
!include /var/packages/MariaDB/etc/my.cnf

 

[Online78]

Hallo Andi+

vielen Dank fürs testen. Ich habe mein altes Zarafa mit diesen Threads beschleunigt. Vielleicht gibt das auch noch wertvolle Hinweise, oder?
Link: http://recover-email.blogspot.ch/2014/01/how-to-optimize-mysql-performance-in.html
Link: https://documentation.zarafa.com/zcp_administrator_manual/performance_tuning.html
Link: https://pietma.com/optimize-zarafa-and-mysql-mariadb/

Grüsse, Domi

 

[Andy+]

Ich habe nochmals angepasst und auch die server.cfg beim Cache angepasst :

--------------------------------------------------------------------------------------------------------

# Size in bytes of the 'cell' cache (should be set as high as you can afford to set it)
# syno-default b4 tuning 4 times smaller than zarafa default 64 vs. 256M etc. below
cache_cell_size = 4G

# Size in bytes of the 'object' cache
cache_object_size = 64M

# Size in bytes of the 'indexed object' cache
cache_indexedobject_size = 128M

--------------------------------------------------------------------------------------------------------

[mysqld]
bind-address = 0.0.0.0
port = 3306
socket = /run/mysqld/mysqld.sock
skip-external-locking
max_allowed_packet = 64M
table_open_cache = 1024
key_buffer_size = 512M
sort_buffer_size = 16M
read_buffer_size = 16M
read_rnd_buffer_size = 64M
net_buffer_length = 10K
thread_stack = 512K
thread_concurrency = 8
thread_cache_size = 8
innodb_data_home_dir = /var/packages/MariaDB/target/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/packages/MariaDB/target/mysql
innodb_buffer_pool_size = 4G
innodb_additional_mem_pool_size = 32M
#innodb_log_file_size = 1G
innodb_log_buffer_size = 256M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
innodb_file_per_table = 1

[mysqldump]
quick
max_allowed_packet = 64M

[mysql]
query_cache_size = 128M
query_cache_type = 1
tmp_table_size = 128M
max_heap_table_size = 128M
no-auto-rehash

[myisamchk]
read_buffer = 32M
write_buffer = 32M
myisam_sort_buffer_size = 128M

--------------------------------------------------------------------------------------------------------

Damit läuft das gegenüber dem Installationszustand richtig gut und vor allem der Client ist übers Internet auch im Offlinemodus richtig schnell. Ob da ein Umstieg auf die MariaDB 10 mehr bringt, ist die Frage. Zunächst müsste mal die Datenbank kopiert werden können. Ich denke, um Workbench oder HeidiSQL komme ich nicht herum, jedenfalls mit Bordmitteln oder MySQL-Tools sehe ich gerade keinen Weg.

 

[Online78]

Hey Andi+

toll dass du Erfolg hattest. Leider habe ich nicht 16GB RAM. Es wäre wirklich sehr spannend zu sehen, ob es mit MariaDB besser läuft. Welche Empfehlungen würdest du denn geben, wenn 8GB RAM zur Verfügung steht? Einfach die Hälfte deiner Einstellungen?

Gruss Domi