Patrick de Brabander wrote:

James Joseph wrote:

[quote]Patrick de Brabander wrote:

James,

Is the backup script also making a backup of the attachements ?

Only if you configured attachments to be in the database (by default it's set to be in files which is actually better for the database).

I recommend backing those up by either by rsync or rdiff-backup. I just do rdiff-backup for ONSITE backups as it backups up the whole server and that includes /var/lib/zarafa however if you just want to backup just the database and attachments maybe a zip or a tar.gz of the folder that's compressed to another location or backup drive.

Patrick de Brabander wrote:

James Joseph wrote:

[quote]Patrick de Brabander wrote:

James,

Is the backup script also making a backup of the attachements ?

Only if you configured attachments to be in the database (by default it's set to be in files which is actually better for the database).

I recommend backing those up by either by rsync or rdiff-backup. I just do rdiff-backup for ONSITE backups as it backups up the whole server and that includes /var/lib/zarafa however if you just want to backup just the database and attachments maybe a zip or a tar.gz of the folder that's compressed to another location or backup drive.

James Joseph wrote:

Patrick de Brabander wrote:

James,

Is the backup script also making a backup of the attachements ?

Only if you configured attachments to be in the database (by default it's set to be in files which is actually better for the database).

I recommend backing those up by either by rsync or rdiff-backup. I just do rdiff-backup for ONSITE backups as it backups up the whole server and that includes /var/lib/zarafa however if you just want to backup just the database and attachments maybe a zip or a tar.gz of the folder that's compressed to another location or backup drive.

Patrick de Brabander wrote:

James,

Is the backup script also making a backup of the attachements ?

James Joseph wrote:

IIRC system-mysql is not on the standard mysql port it is on 3308 instead you can check this by doing lsof -i:3308 or netstat -l -n -t |grep 3308

In the conf file you'll see this line: #CONFIG_mysql_dump_port=3306

un comment it and change the dump port to 3308 instead that should back up the zarafa database.

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

# MYSQL SETTINGS (for database_engine = mysql)



# MySQL hostname to connect to for database access

mysql_host = 127.0.0.1



# MySQL port to connect with (usually 3306)

mysql_port = 3308



# The user under which we connect with MySQL

mysql_user = zarafa



# The password for the user (leave empty for no password)

mysql_password = xxxxxxxxxxxxxxxxxxxxxxxxxxx

Patrick de Brabander wrote:

The configuration file is working, but not backing up my Zarafa.

I've check in phpmyadmin and there are 2 databases: 'Main Database' and 'System Database'
Zarafa is stored in the 'System Database'.

/usr/local/bin/automysqlbackup

Invoking backup method.



Parsed config file "/etc/automysqlbackup/automysqlbackup.conf"



# Checking for permissions to write to folders:

base folder /tmp ... exists ... ok.

backup folder /tmp/db ... exists ... writable? yes. Proceeding.

checking directory "/tmp/db/daily" ... creating ... success.

checking directory "/tmp/db/weekly" ... creating ... success.

checking directory "/tmp/db/monthly" ... creating ... success.

checking directory "/tmp/db/latest" ... creating ... success.

checking directory "/tmp/db/tmp" ... creating ... success.

checking directory "/tmp/db/fullschema" ... creating ... success.

checking directory "/tmp/db/status" ... creating ... success.



# Testing for installed programs

mysql ... found.

mysqldump ... found.



# Parsing databases ... done.

======================================================================

AutoMySQLBackup version 3.0

http://sourceforge.net/projects/automysqlbackup/



Backup of Database Server - 127.0.0.1

Databases - information_schema,mysql,performance_schema,spotweb,test

Databases (monthly) - information_schema,mysql,performance_schema,spotweb,test

The script is now only backing up the 'Main Database'


How to backupo the system-database ?

/usr/local/bin/automysqlbackup

Invoking backup method.



Parsed config file "/etc/automysqlbackup/automysqlbackup.conf"



# Checking for permissions to write to folders:

base folder /tmp ... exists ... ok.

backup folder /tmp/db ... exists ... writable? yes. Proceeding.

checking directory "/tmp/db/daily" ... creating ... success.

checking directory "/tmp/db/weekly" ... creating ... success.

checking directory "/tmp/db/monthly" ... creating ... success.

checking directory "/tmp/db/latest" ... creating ... success.

checking directory "/tmp/db/tmp" ... creating ... success.

checking directory "/tmp/db/fullschema" ... creating ... success.

checking directory "/tmp/db/status" ... creating ... success.



# Testing for installed programs

mysql ... found.

mysqldump ... found.



# Parsing databases ... done.

======================================================================

AutoMySQLBackup version 3.0

http://sourceforge.net/projects/automysqlbackup/



Backup of Database Server - 127.0.0.1

Databases - information_schema,mysql,performance_schema,spotweb,test

Databases (monthly) - information_schema,mysql,performance_schema,spotweb,test

Patrick de Brabander wrote:

James Joseph wrote:


You didn't put in the location of your sandbox mysql also as I stated make sure you do this in path:

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

Also did you link the mysql.conf file to the automysql backup script?

Sorry. I've copied the wrong config output.

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

# Testing for installed programs

WARNING: Turning off multicore support, since pigz isn't there.

mysql ... found.

mysqldump ... found.

How do you link mysql.conf to the autobackupscript ?

Patrick de Brabander wrote:

James Joseph wrote:


You didn't put in the location of your sandbox mysql also as I stated make sure you do this in path:

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

Also did you link the mysql.conf file to the automysql backup script?

Sorry. I've copied the wrong config output.

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

# Testing for installed programs

WARNING: Turning off multicore support, since pigz isn't there.

mysql ... found.

mysqldump ... found.

How do you link mysql.conf to the autobackupscript ?

James Joseph wrote:


You didn't put in the location of your sandbox mysql also as I stated make sure you do this in path:

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

Also did you link the mysql.conf file to the automysql backup script?

PATH=${PATH}:/var/lib/system-mysql:/usr/clearos/sandbox/usr/bin/mysqldump

# Testing for installed programs

WARNING: Turning off multicore support, since pigz isn't there.

mysql ... found.

mysqldump ... found.

Patrick de Brabander wrote:

Somehow the autobackup script is not working with Zarafa.
Backing up the other database is not working.

/usr/local/bin/automysqlbackup /etc/automysqlbackup/myser                                            ver.conf



# Checking for permissions to write to folders:

base folder /tmp ... exists ... ok.

backup folder /tmp/db ... exists ... writable? yes. Proceeding.

checking directory "/tmp/db/daily" ... exists.

checking directory "/tmp/db/weekly" ... exists.

checking directory "/tmp/db/monthly" ... exists.

checking directory "/tmp/db/latest" ... exists.

checking directory "/tmp/db/tmp" ... exists.

checking directory "/tmp/db/fullschema" ... exists.

checking directory "/tmp/db/status" ... exists.



# Testing for installed programs

WARNING: Turning off multicore support, since pigz isn't there.

mysql ... found.

mysqldump ... found.



# Parsing databases ... Note: Parsed config file /etc/automysqlbackup/myserver.c                                            onf.

Note: /etc/automysqlbackup/automysqlbackup.conf was not found - no global config                                             file.

Error: The mysql server is empty, i.e. no databases found. Check if something is                                             wrong. Exiting.



###### WARNING ######

Errors reported during AutoMySQLBackup execution.. Backup failed

Error log below..

ERROR 1045 (28000): Access denied for user 'zarafa'@'localhost' (using password:                                             YES)

#version=3.0_rc2

# DONT'T REMOVE THE PREVIOUS VERSION LINE!

#

# Uncomment to change the default values (shown after =)

# WARNING:

# This is not true for UMASK, CONFIG_prebackup and CONFIG_postbackup!!!

#

# Default values are stored in the script itself. Declarations in

# /etc/automysqlbackup/automysqlbackup.conf will overwrite them. The

# declarations in here will supersede all other.



# Edit $PATH if mysql and mysqldump are not located in /usr/local/bin:/usr/bin:/bin:/usr/local/mysql/bin

#PATH=${PATH}:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQL:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQLDUMP

PATH=${PATH}:/usr/clearos/sandbox/usr/bin/mysqldump



# Basic Settings



# Username to access the MySQL server e.g. dbuser

CONFIG_mysql_dump_username='zarafa'



# Password to access the MySQL server e.g. password

CONFIG_mysql_dump_password='ZARAFA_PASSWORD'



# Host name (or IP address) of MySQL server e.g localhost

#CONFIG_mysql_dump_host='127.0.0.1'



# "Friendly" host name of MySQL server to be used in email log

# if unset or empty (default) will use CONFIG_mysql_dump_host instead

#CONFIG_mysql_dump_host_friendly=''



# Backup directory location e.g /backups

#CONFIG_backup_dir='/var/backup/db'

CONFIG_backup_dir='/tmp/db'



# This is practically a moot point, since there is a fallback to the compression

# functions without multicore support in the case that the multicore versions aren't

# present in the system. Of course, if you have the latter installed, but don't want

# to use them, just choose no here.

#pigz -> gzip

# pbzip2 -> bzip2

#CONFIG_multicore='yes'



# Number of threads (= occupied cores) you want to use. You should - for the sake

# of the stability of your system - not choose more than (#number of cores - 1).

# Especially if the script is run in background by cron and the rest of your system

# has already heavy load, setting this too high, might crash your system. Assuming

# all systems have at least some sort of HyperThreading, the default is 2 threads.

# If you wish to let pigz and pbzip2 autodetect or use their standards, set it to

# 'auto'.

#CONFIG_multicore_threads=2



# Databases to backup



# List of databases for Daily/Weekly Backup e.g. ( 'DB1' 'DB2' 'DB3' ... )

# set to (), i.e. empty, if you want to backup all databases

CONFIG_db_names=()

# You can use

#declare -a MDBNAMES=( "${DBNAMES[@]}" 'added entry1' 'added entry2' ... )

# INSTEAD to copy the contents of $DBNAMES and add further entries (optional).

Backup with standard command is working

/usr/clearos/sandbox/usr/bin/mysqldump -u zarafa -pXXXXXXXXX --single-transaction zarafa | gzip > /var/tmp/zarafadump.sql.gz

/usr/local/bin/automysqlbackup /etc/automysqlbackup/myser                                            ver.conf



# Checking for permissions to write to folders:

base folder /tmp ... exists ... ok.

backup folder /tmp/db ... exists ... writable? yes. Proceeding.

checking directory "/tmp/db/daily" ... exists.

checking directory "/tmp/db/weekly" ... exists.

checking directory "/tmp/db/monthly" ... exists.

checking directory "/tmp/db/latest" ... exists.

checking directory "/tmp/db/tmp" ... exists.

checking directory "/tmp/db/fullschema" ... exists.

checking directory "/tmp/db/status" ... exists.



# Testing for installed programs

WARNING: Turning off multicore support, since pigz isn't there.

mysql ... found.

mysqldump ... found.



# Parsing databases ... Note: Parsed config file /etc/automysqlbackup/myserver.c                                            onf.

Note: /etc/automysqlbackup/automysqlbackup.conf was not found - no global config                                             file.

Error: The mysql server is empty, i.e. no databases found. Check if something is                                             wrong. Exiting.



###### WARNING ######

Errors reported during AutoMySQLBackup execution.. Backup failed

Error log below..

ERROR 1045 (28000): Access denied for user 'zarafa'@'localhost' (using password:                                             YES)

#version=3.0_rc2

# DONT'T REMOVE THE PREVIOUS VERSION LINE!

#

# Uncomment to change the default values (shown after =)

# WARNING:

# This is not true for UMASK, CONFIG_prebackup and CONFIG_postbackup!!!

#

# Default values are stored in the script itself. Declarations in

# /etc/automysqlbackup/automysqlbackup.conf will overwrite them. The

# declarations in here will supersede all other.



# Edit $PATH if mysql and mysqldump are not located in /usr/local/bin:/usr/bin:/bin:/usr/local/mysql/bin

#PATH=${PATH}:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQL:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQLDUMP

PATH=${PATH}:/usr/clearos/sandbox/usr/bin/mysqldump



# Basic Settings



# Username to access the MySQL server e.g. dbuser

CONFIG_mysql_dump_username='zarafa'



# Password to access the MySQL server e.g. password

CONFIG_mysql_dump_password='ZARAFA_PASSWORD'



# Host name (or IP address) of MySQL server e.g localhost

#CONFIG_mysql_dump_host='127.0.0.1'



# "Friendly" host name of MySQL server to be used in email log

# if unset or empty (default) will use CONFIG_mysql_dump_host instead

#CONFIG_mysql_dump_host_friendly=''



# Backup directory location e.g /backups

#CONFIG_backup_dir='/var/backup/db'

CONFIG_backup_dir='/tmp/db'



# This is practically a moot point, since there is a fallback to the compression

# functions without multicore support in the case that the multicore versions aren't

# present in the system. Of course, if you have the latter installed, but don't want

# to use them, just choose no here.

#pigz -> gzip

# pbzip2 -> bzip2

#CONFIG_multicore='yes'



# Number of threads (= occupied cores) you want to use. You should - for the sake

# of the stability of your system - not choose more than (#number of cores - 1).

# Especially if the script is run in background by cron and the rest of your system

# has already heavy load, setting this too high, might crash your system. Assuming

# all systems have at least some sort of HyperThreading, the default is 2 threads.

# If you wish to let pigz and pbzip2 autodetect or use their standards, set it to

# 'auto'.

#CONFIG_multicore_threads=2



# Databases to backup



# List of databases for Daily/Weekly Backup e.g. ( 'DB1' 'DB2' 'DB3' ... )

# set to (), i.e. empty, if you want to backup all databases

CONFIG_db_names=()

# You can use

#declare -a MDBNAMES=( "${DBNAMES[@]}" 'added entry1' 'added entry2' ... )

# INSTEAD to copy the contents of $DBNAMES and add further entries (optional).

/usr/clearos/sandbox/usr/bin/mysqldump -u zarafa -pXXXXXXXXX --single-transaction zarafa | gzip > /var/tmp/zarafadump.sql.gz

Patrick de Brabander wrote:

James Joseph wrote:

[quote]Patrick de Brabander wrote:

i've managed to change de LDAP settings with ApacheDirectoryStudio.

Thanks James.


Now trying to get the migration-tool working.

Glad it's working, if you ever get time I'd consider testing backing up and restoring with mysql instead of PST files. This is the backup script I use for mysql: http://sourceforge.net/projects/automysqlbackup/

It's much easier then you think it is and for an administrator and company it saves an massive amount of downtime especially if something bad goes wrong it pays to have backups of the database for things like this .

Hope your migration goes well.

James Joseph wrote:

Patrick de Brabander wrote:

i've managed to change de LDAP settings with ApacheDirectoryStudio.

Thanks James.


Now trying to get the migration-tool working.

Glad it's working, if you ever get time I'd consider testing backing up and restoring with mysql instead of PST files. This is the backup script I use for mysql: http://sourceforge.net/projects/automysqlbackup/

It's much easier then you think it is and for an administrator and company it saves an massive amount of downtime especially if something bad goes wrong it pays to have backups of the database for things like this .

Hope your migration goes well.

Patrick de Brabander wrote:

i've managed to change de LDAP settings with ApacheDirectoryStudio.

Thanks James.


Now trying to get the migration-tool working.

James Joseph wrote:



Is this from zarafa to a zarafa server?

If it is why don't you do a mysqlpdump of the database import the database and rsync the attachments to the /var/lib/zarafa/attachments folder?

That should work perfectly fine and it's what I've used to move zarafa from one server to another.

If this is from a differen't e-mail server all together and not zarafa I use apache directory studio to access ldap on the server: https://directory.apache.org/studio/

do a ssh tunnel of secure ldap to your localhost :

ssh -vv -L 6366:127.0.0.1:636 root@server.domain.com

Then open up apache directory studio create a new ldap connection.

The server is: localhost
Connection security: SSL
port is: 636

Put in your bind username and then password, your clearos home should have those details in the directory information, click on test connection. Accept untrusted certificates and you should be connected. Click on finish and you'll have access to your ldap server.

Then go to your user account you want to enable zarafa admin rights to right click on a field and add attribute and search something like zarafaAdmin or something like that.

Set the value to: 1

Restart zarafa server and when you check out the details of the user:

zarafa-admin --details user 

You should get an output like this
Administrator: yes

Hope this helps. However I would strongly recommend doing the mysql dump and import and syncing the attachments folder if it is an zarafa server you are moving from it's the quickest and painless migration you will do.

You may need to unhook and re-hook mailboxes though as they may not be attached to the right users.

For that problem I simply go onto the old server and do zarafa-admin --details user and make sure it's the right size.

Publish policy         - Local Network

Account Access     - Anonymous

Nick Howitt wrote:

In your phpldapadmin.conf try changing your "Allow from 127.0.0.1" to "Allow from 127.0.0.1, your_LAN_subnet". Mine is "Allow from 127.0.0.1, 172.17.2.100/24". I think I also had to fiddle with /etc/phpldapadmin/config.php. Note I am still on 6.x so I don't know if 7.x is different.

Patrick de Brabander wrote:

Well, i've installed ClearOS 7 and purchased the Zarafa Home edition.
All is working, but importing the old-emails back in to the zarafa server is a bit difficult.
Since MAPI is not supported in the home edition (my mistake to choose this version) and copying the emails back form the .pst files using IMAP or EAS does not work properly.

All the mails form local users are misformed in the email address. for example john@mail.com (John Doe) is now in JohnDoe als email address.

Now i'm trying to use the migration-tool, but i don't have a user who is an Admin.

After spending hours getting this to work, i've found out that you need to install LDAPADMIN.
I've install LDAPADMIN, but when i'm trying to access this, i het the following error:

Forbidden

You don't have permission to access /phpldapadmin on this server.

made some changes to phpldapadmin.conf

#

#  Web-based tool for managing LDAP servers

#



Alias /phpldapadmin /usr/share/phpldapadmin/htdocs

Alias /ldapadmin /usr/share/phpldapadmin/htdocs



<Directory /usr/share/phpldapadmin/htdocs>

  <IfModule mod_authz_core.c>

    # Apache 2.4

    Require local

  </IfModule>

  <IfModule !mod_authz_core.c>

    # Apache 2.2

    Order Deny,Allow

    Deny from all

    Allow from 127.0.0.1

    Allow from ::1

  </IfModule>

</Directory>

and changed Deny from All in to Allow from All, etc...
Still no access

Who can help me to give a user admin privileges

ssh -vv -L 6366:127.0.0.1:636 root@server.domain.com

zarafa-admin --details user 

Forbidden

You don't have permission to access /phpldapadmin on this server.

#

#  Web-based tool for managing LDAP servers

#



Alias /phpldapadmin /usr/share/phpldapadmin/htdocs

Alias /ldapadmin /usr/share/phpldapadmin/htdocs



<Directory /usr/share/phpldapadmin/htdocs>

  <IfModule mod_authz_core.c>

    # Apache 2.4

    Require local

  </IfModule>

  <IfModule !mod_authz_core.c>

    # Apache 2.2

    Order Deny,Allow

    Deny from all

    Allow from 127.0.0.1

    Allow from ::1

  </IfModule>

</Directory>

Patrick de Brabander wrote:

James Joseph wrote:

[quote]Patrick de Brabander wrote:

I've tried yesterday to install the new ClearOS 7.1 on my test server and found out that you need pay for Zarafa yearly.

Does this mean that the payment i've alredy made for the previous version of zarafa expired ?
I thought this was one time payment for community users.

When I asked this in another thread it's a new change for ClearOS you need to pay a yearly fee even if you already have a subscription to Zarafa on clearos 6.

However you can still keep your version of zarafa and it won't stop working if you don't elect to pay, I assume it just means you will no longer get updates?

Personally we are a re-seller for zarafa so we only used the clearos version as it provided a nice app plugin and we updated zarafa ourselves manually. I'm happy for there to be a one off version which just does the initial install and configures the app in the web interface personally without having any further updates.

James Joseph wrote:

Patrick de Brabander wrote:

I've tried yesterday to install the new ClearOS 7.1 on my test server and found out that you need pay for Zarafa yearly.

Does this mean that the payment i've alredy made for the previous version of zarafa expired ?
I thought this was one time payment for community users.

When I asked this in another thread it's a new change for ClearOS you need to pay a yearly fee even if you already have a subscription to Zarafa on clearos 6.

However you can still keep your version of zarafa and it won't stop working if you don't elect to pay, I assume it just means you will no longer get updates?

Personally we are a re-seller for zarafa so we only used the clearos version as it provided a nice app plugin and we updated zarafa ourselves manually. I'm happy for there to be a one off version which just does the initial install and configures the app in the web interface personally without having any further updates.

Patrick de Brabander wrote:

I've tried yesterday to install the new ClearOS 7.1 on my test server and found out that you need pay for Zarafa yearly.

Does this mean that the payment i've alredy made for the previous version of zarafa expired ?
I thought this was one time payment for community users.

yum install zarafa-z-push