Unable to migrate from SME

I’ve just had another very frustrating attempt to migrate from an SME 9.2 server to Nethserver 7.6 (latest iso). In this instance, the migrate from backup failed, where last time it was the migration using rsync.

Has anyone got any current experience of successfully migrating from SME to Nethserver?

After installing the basic system, I added a local LDAP service, added mail, fail2ban and other services that I needed. I did not add the file server, since this is a gateway machine and has never used ibays for anything except a web page.

I then did a current backup of the SME machine. I use a package called Synbak for backing up SME machines, which is compatible with the internal SME backup, creates a compressed tar archive which I have used multiple times in the past to restore failed SME machines, so I know it works.

I followed the migration instructions - created /var/lib/migration and dumped the contents of the backup there. Then ran “signal-event migration-import /var/lib/migration”. That was almost 24 hours ago. Yesterday I had to leave the machine after a couple of hours. When I cam back this morning, it had still not completed and I had to kill the process.

Going through the logs, there are numerous errors. For example:

Feb 6 10:44:01 nethbox esmith::event[17889]: Action: /etc/e-smith/events/migration-import/S50nethserver-hosts-migrate SUCCESS [0.5315]
Feb 6 10:44:02 nethbox esmith::event[17889]: Version check failed. Got the following error when calling the ‘mysql’ command line client
Feb 6 10:44:02 nethbox esmith::event[17889]: ERROR 1049 (42000): Unknown database ‘mysql’
Feb 6 10:44:02 nethbox esmith::event[17889]: FATAL ERROR: Upgrade failed

Then there is this:

Feb  6 10:44:04 nethbox esmith::event[18513]: ts
Feb  6 10:44:04 nethbox esmith::event[18513]: NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
Feb  6 10:44:04 nethbox esmith::event[18513]:      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
Feb  6 10:44:04 nethbox esmith::event[18513]: Y!
Feb  6 10:44:04 nethbox esmith::event[18513]: In order to log into MariaDB to secure it, we'll need the current
Feb  6 10:44:04 nethbox esmith::event[18513]: password for the root user.  If you've just installed MariaDB, and
Feb  6 10:44:04 nethbox esmith::event[18513]: you haven't set the root password yet, the password will be blank,
Feb  6 10:44:04 nethbox esmith::event[18513]: so you should just press enter here.
Feb  6 10:44:04 nethbox esmith::event[18513]: ere.
Feb  6 10:44:04 nethbox esmith::event[18513]: Enter current password for root (enter for none):
Feb  6 10:44:04 nethbox esmith::event[18513]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

And there it sat - repeating that error over and over…

I have a number of SME machines that I would like to migrate to Nethserver, but my current success rate is zero and most of those SME machines are no practical to start again, so any help would be most appreciated…

There is a chapter at the documentation about migrating SME to NS. Did you try the way they described?

http://docs.nethserver.org/en/latest/migration.html

If you can’t get rid of it, I think @stephdl has some more SME experience.

I also have a bit of experience migrating from sme server. :slight_smile:
From the log file I can guess that mysql-server was not installed before starting the migration or it could not start.
We may need full log files to find the error.

1 Like

Looks like this is an authentication problem for mysql/mariadb
Did you deliberately skip filling in the mysql/mariadb root password? Or is it part of a script that fails to athenticate the root mysql/mariadb user?

I installed the mysql module before starting the migration. I’ve still got a copy of /var/log/messages if you need more information from it.

I had wondered if it might be due to the migration itself, since SME has a similar automatic login for mysql - could the password have been migrated and then the script tries to use it instead of the one created during the basic Nethseveer install?

I wasn’t offered an option to enter a mysql/mariadb root password. I am wondering if the migration itself attempted to use the hidden root mysql password from the SME system? If necessary (and if I can find out how to…) I can change the mysql password on the Nethserver box to match the password on the old SME box. I’m also wondering if that may have been what caused me problems with an earlier attempt to use the rsync migration script.

:slight_smile: Yes, I read the migration chapter several times… Was going on its suggestions.

If you can share it with me (at least) I would try to have a look.
I think that you did no mistakes, it may be a bug.

Its too big to post here, but I can certainly email it to you if that is ok?

You can always share it through a pastebin service… (or gist)

:frowning: Too big for that. Its complete from 4th of February (when the basic install was done) to the failed migration. Comes out at over 200 MB.
I’ve put it on Google drive, so it can be accessed at this link:

https://drive.google.com/open?id=1Ep7k9V92id0qnIs-Dso0F1l34rsLcl2u

Hope that is of some help.

I can’t figure the problem reading the log.
Could you please try running the mysql migration action alone to see why it fails?

sh -x /etc/e-smith/events/actions/nethserver-mysql-migrate migrate /var/lib/migration

I’ll be back on site on Monday, so I’ll try then. Since that log was generated, I’ve done a fresh install - didn’t think I could pick up where I left off once the problem was solved. If the mysql migration goes correctly on the new install, it would tend to suggest that the problem is that the script is attempting to use the mysql password brought over from /root on the SME server.

Looking at the log (after clearing out the huge number of repeated errors caused by the system sitting trying for somewhere over 12 hours), it looks as though everything went through correctly until it hit the mysql migration, at which point it failed, leaving that and the dnsmasq conversion to be done. I guess that would explain the lack of any DNS on the new system, as well as the fact that the DHCP server wasn’t giving out either DNS or gateway addressing when it granted a lease.

I’ll make sure I’ve got everything installed that I need (mysql support, local LDAP server) and try running the mysql migration on its own. I’ll post anything useful from messages after I’ve done so.

1 Like

Got back to the machine. I checked to make sure that everything needed was installed, then copied a fresh backup from the SME machine and ran the command…

root@nethbox ~]# sh -x /etc/e-smith/events/actions/nethserver-mysql-migrate migrate /var/lib/migration
+ event=migrate
+ sourceDir=/var/lib/migration
+ dbFile=/home/e-smith/db/configuration
+ mysqlDumpDir=/home/e-smith/db/mysql
+ mysqlPassFile=/root/.my.cnf
+ '[' '!' -d /var/lib/migration ']'
+ '[' x/var/lib/migration == x ']'
+ mysqlDumpDir=/var/lib/migration//home/e-smith/db/mysql
+ '[' '!' -d /var/lib/migration//home/e-smith/db/mysql ']'
+ mysqlPassFile=/var/lib/migration//root/.my.cnf
+ '[' '!' -f /var/lib/migration//root/.my.cnf ']'
++ /sbin/e-smith/config getprop mysqld status
+ status=enabled
+ '[' enabled = disabled ']'
+ /usr/bin/mysql -e 'drop database mysql'
++ ls /var/lib/migration//home/e-smith/db/mysql/horde.dump /var/lib/migration//home/e-smith/db/mysql/information_schema.dump /var/lib/migration//home/e-smith/db/mysql/mysql.dump /var/lib/migration//home/e-smith/db/mysql/test.dump
+ for db in '$(ls $mysqlDumpDir/*.dump 2> /dev/null)'
++ basename /var/lib/migration//home/e-smith/db/mysql/horde.dump .dump
+ /bin/cp /var/lib/migration//home/e-smith/db/mysql/horde.dump /etc/e-smith/sql/init/01_horde.sql
+ for db in '$(ls $mysqlDumpDir/*.dump 2> /dev/null)'
++ basename /var/lib/migration//home/e-smith/db/mysql/information_schema.dump .dump
+ /bin/cp /var/lib/migration//home/e-smith/db/mysql/information_schema.dump /etc/e-smith/sql/init/01_information_schema.sql
+ for db in '$(ls $mysqlDumpDir/*.dump 2> /dev/null)'
++ basename /var/lib/migration//home/e-smith/db/mysql/mysql.dump .dump
+ /bin/cp /var/lib/migration//home/e-smith/db/mysql/mysql.dump /etc/e-smith/sql/init/01_mysql.sql
+ for db in '$(ls $mysqlDumpDir/*.dump 2> /dev/null)'
++ basename /var/lib/migration//home/e-smith/db/mysql/test.dump .dump
+ /bin/cp /var/lib/migration//home/e-smith/db/mysql/test.dump /etc/e-smith/sql/init/01_test.sql
+ /etc/e-smith/events/actions/nethserver-mysql-init
Loading horde.sql into mysql                               [  OK  ]
Loading information_schema.sql into mysql                  [FAILED]
Loading mysql.sql into mysql                               [  OK  ]
Loading test.sql into mysql                                [  OK  ]
+ /usr/bin/mysql_upgrade
+ sed -n 's/.*password *= *\([^ ]*.*\)/\1/p' /var/lib/migration//root/.my.cnf
++ /sbin/e-smith/db /var/lib/migration//home/e-smith/db/configuration getprop mysqld status
+ status=enabled
+ /sbin/e-smith/config setprop mysqld status enabled
++ /sbin/e-smith/db /var/lib/migration//home/e-smith/db/configuration getprop mysqld LocalNetworkingOnly
+ localNetworking=yes
+ /sbin/e-smith/config setprop mysqld LocalNetworkingOnly yes
+ /sbin/e-smith/signal-event nethserver-mysql-update

Hope that is of some help…

I have experience on migrations from SME 8 to NethServer. I don’t know if 9.2 is supported. How many differences sme 8 and 9 have? I don’t think that mysql changed.

Maybe information_schema.sql has some errors, could you share it?
Or you can try to delete it before starting the migration.

Well, it’s CentOS 6 vs 7, just like NS 6 vs NS7. It certainly would be a different version of MySQL, but I don’t know what effect that would have (if any).

FWIW, I was able to migrate from SME 9.2 to NS 7.4 about a year ago without great difficulty.

I think that this is relevant, meaning that migration is supported.
So, probably, information_schema.sql has some weirdness.

I’ll stick it up on Google drive tomorrow when I get back there. I’m not sure what its function is, but I can certainly delete it before starting the migration, at least when I’m doing a migration from backup.

I’m assuming the fact that it was the only failure tends to support the idea that the full migrations that I’ve tried (both rsync and from backup) failed suggests that the system is attempting to use the /root/.my.cnf Mysql file from the SME system instead of the one that applies to the newly installed Nethserver?

I was also able to migrate a system a while ago without too many problems, not sure if it was 7.4 or 7.5 that I used at the time. Ended up stepping back and leaving SME in place at the time, but now I would really like to migrate all of the SME boxes I look after to Nethserver - development on SME 10 seems to have stalled and I have some concerns about security on 9.2.

I’ve put the file up on google drive. Here’s the URL:

https://drive.google.com/open?id=1mHDvfvHsYm7UF28Y5Dky9ViObPaIU2VR

1 Like