Migration from NethService/SME Server¶
No custom template is migrated during the migration process. Check the new template files before copying any custom fragment from the old backup.
Before running the migration procedure, read carefully all the sections of this chapter.
You should configure an accounts provider before starting the migration procedure.
- If the source system was joined to an Active Directory domain (Samba server role was ADS), configure a remote Active Directory accounts provider.
- If the source system was a NT Primary Domain Controller (Samba server role was PDC) install a local Active Directory accounts provider.
- If access to Shared Folders on the destination system requires user authentication, install a local Active Directory accounts provider.
- In any other case, install a local LDAP accounts provider.
If you choose a local Active Directory accounts provider, remember to fully
configure and start the DC before executing the
migration-import event. See
Furthermore, the following accounts are ignored by the migration procedure because they are already provided by Active Directory:
Before running NethServer in production, some considerations about the network and existing mail client configurations are required: what ports are in use, if SMTPAUTH and TLS are enabled. Refer to mail client configuration and Special SMTP access policies section for more information.
In a mail server migration, the source mail server could be on production even after the backup has been done, and email messages continue to be delivered until it is taken down permanently.
An helper script based on
rsync is provided by package
runs on the destination host and synchronizes destination mailboxes
with the source host:
Usage: /usr/share/doc/nethserver-mail-server-<VERSION>/sync_maildirs.sh [-h] [-n] [-p] -s IPADDR -h help message -n dry run -p PORT ssh port on source host (default 22) -s IPADDR rsync from source host IPADDR -t TYPE source type: sme8 (default), ns6
The source host at
IPADDR must be accessible by the
root user, through
ssh with public key authentication.
The SSL cipher suite configuration is not migrated automatically because the source system uses a weak cipher suite by default. To migrate it manually, execute the following commands:
MIGRATION_PATH=/var/lib/migration config setprop httpd SSLCipherSuite $(db $MIGRATION_PATH/home/e-smith/db/configuration getprop modSSL CipherSuite) signal-event nethserver-httpd-update
The ibay concept has been superseded by Shared folders. Supported protocols for accessing Shared folders are:
- SFTP, provided by the
- SMB file sharing protocol, typical of Windows networking, implemented by Samba
Starting from NethServer 7, Shared folders are not configurable for HTTP
migration-import event, old ibays could be migrated according
to the following rules of thumb:
If the ibay was a virtual host, install the “Web server” module from the Software center page. Copy the ibay contents to the virtual host root directory. Refer to Virtual hosts.
If the ibay access was restricted with a secret password (for instance, to share contents with a group of people across the internet), the Virtual hosts page still offers the same feature. Also the Nextcloud module could be a good replacement.
If the ibay contents were accessible with an URL like
http://<IP>/ibaynamethe easiest procedure to keep it working is moving it to Apache document root:
mv -iv /var/lib/nethserver/ibay/ibayname /var/www/html/ibayname chmod -c -R o+rX /var/www/html/ibayname db accounts delete ibayname signal-event nethserver-samba-update
After migration, ibays will retain a backward compatibile profile. To take advantage of new features, including Samba Audit, the ibay configuration must be switched to the new profile. From command line execute:
db accounts setprop ibay_name SmbProfileType default signal-event ibay-mody ibay_name
ibay_name is the name of the ibay to configure.
Migration from backup¶
In the source host, create a full backup archive and move it to the destination host.
In the destination host, install NethServer 7 using the most recent ISO, register it then apply all the latest core updates available.
In the destination host, install all packages that cover the same features of the source.
Explode the full backup archive into some directory; for instance, create the directory
In destination host, signal the event
signal-event migration-import /var/lib/migration
This step will require some time.
Check for any error message in
grep -E '(FAIL|ERROR)' /var/log/messages
Migration with rsync¶
The process is much faster than migrating from a backup.
Before starting make sure to have:
- a running NethService/SME installation, we will call it original server or source server
- a running NethServer 7 installation with all the latest updates installed and at least the same disk space of the source server, we will call it destination server
- a working network connection between the two severs
Please also make sure the source server allows root login via SSH key and password.
The synchronization script copies all data using rsync over SSH.
Files are saved inside
If the destination server doesn’t have any SSH keys, the script will also create a pair of RSA keys and copy the public key to the source server.
All directories excluded from the backup data will not be synced.
On the target machine, execute the following command:
screen rsync-migrate <source_server_name> [ssh_port]
source_server_nameis the host name or IP of the original server
ssh_portis the SSH port of the original server (default is 22)
screen rsync-migrate mail.nethserver.org 2222
When asked, insert the root password of the source server, make a coffee and wait patiently.
The script will not perform any action on the source machine and can be invoked multiple times.
Sync and migrate¶
If called with
rsync-migrate will execute a final synchronization and upgrade
the target machine.
Before executing the final migration, install all packages that cover the same features of the source.
screen rsync-migrate -m mail.nethserver.org 2222
The script will:
- stop every service on the source machine (except for SSH)
- execute the
pre-backupevent on the source machine
- sync all remaining data
- execute the
migration-importevent on the destination machine
At the end, check for any error message in
grep -E '(FAIL|ERROR)' /var/log/messages