I have run the Migration Tool and the migration went very well expect for one part. I can no longer login to the SSH accounts that are associated with the websites we have created. * the syslog gives no leads * When I disable ufw thr problem still remains. * passwords ARE correct [EDIT: there are a few differences compared to the old installation and that is the firewall which now is ufw instead of bastille + it's Debian 9 instead of 8] Any ideas?
What is the exact error that you get on SSH login? Take a look into the passwd and shadow file if the SSH users that you use for login are there.
Hmmm... Thanks. This was interesting. It turned out that there was some error during the migration afterall. The user in question was available in ISPconfig, but not in /etc/passwd and then it is also associated with the right client id in ISPconfig (client ID 2) while on disk it's organized under client id 1 (when I recreate the user, it will be created under client id 1, despite that the client id for the website that it's associated with is client id 2). It also seems that the client id counter is not increased. After a fulfilled migration, the prefixes set under System > Interface > Main Config is supposed to be set back to what it was in the source server, huh?
The ssh user has a different name on the new server and on the old server? The prefixes are disabled during migration to avoid that, so that an SSH user always keeps the name, even when the clientID is changing during migration. Please note that the prefix of a user does not mean that it is associated with a specific client. So it is absolutely fine to have e.g. an ssh user c2test owned by client1. Yes, you can set the prefixes to their original values after the migration.
This would mean a mysql error because the ids are auto_increment columns in the database. Could you please post your migrate.log or send it to migsupport [at] ispconfig [dot] org?
I had the same 'problem' after using the migration tool. After changing the 'options' in the 'shell user' options, pointing to the new folders, ispconfig created the user in /etc/passwd, and everythign worked again.
Sorry for the delay. I decided to re-do the whole migration in order to secure that I haven't done any mistakes. Now I got the exact same results, so I guess it's not me (or it is ). This is really pity if it is like this. I also don't understand why it has to be like this. When I create a user in an installation of ISPconfig, it is created under the clientid (Linux group id) that is associated with the client id in ISPconfig (which has been the same IDs). For tracability issues this has also made it very clear to which ISPC client id a certain SSH account belongs. Structure and clarity, but after a migration this is gone. It would be better to have it created like it was in the source server.
Sorry for the delay. I decided to re-do the whole migration in order to secure that I hadn't done any mistakes. Now I got the exact same results, so I guess it's not me (or it is ). It's impossible to upload any files here so I have emailed it to you instead.
Could you please tell us the path for the non-working shell user that is in the options tab and the document root path of the parent website?
Actually it seems that none of the SSH accounts work. This is messed up. In for instance one of the accounts there is an association with the web directory /var/www/clients/client3/web27 while in /var/www/clients/client3/web27/home there is an entry for web37 (not web27). And more research shows that not only groups are changed compared to the source, but also the directories on disk. Why is it like that? Why not "just" make a complete copy (incl same naming of groups (pls see above)) so that the source and the target are identical (except for hostnames and IPs of course)? Here is one example of a Base Dir: /var/www/clients/client1/web37
The migration tool is a tool to import and merge servers, it uses the ISPConfig remote API to do this. When you import an item in ISPConfig, then this item gets the next free ID assigned. So when you deleted items on your old server in the past, the new items will get lower ID's as the gaps with free id's will get filled. So users and directories might change during an import and the migration tool handles this automatically by changing the paths. What @Croydon asked for is this: 1) The path of the website, you can find this on the options tab of the website. 2) The path of a non-working SSH user of this site, you can find it on the options tab of the shell user. Please post these two paths. And which exact error do you get in the Linux syslog when you try to login with the SSH user of the website? We are working on a tool to do an exact copy of a an ISPConfig system which will be part of the migration tool, but such a tool is a completely different approach and it is less flexible than the current migration tool, e.g. it is not able to merge servers nor to switch to a different operating system, change IP addresses etc.
Ok, got it! I can see why the IDs change. Website document root: /var/www/clients/client1/web21 SSH account: /var/www/clients/client1/web21 Aug 9 21:36:53 bs01 systemd[1]: Created slice User Slice of web22. Aug 9 21:36:53 bs01 systemd[1]: Starting User Manager for UID 5025... Aug 9 21:36:53 bs01 systemd[1]: Started Session 29374 of user web22. Aug 9 21:36:53 bs01 systemd[16271]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Aug 9 21:36:53 bs01 systemd[16271]: Reached target Timers. Aug 9 21:36:53 bs01 systemd[16271]: Listening on GnuPG cryptographic agent (access for web browsers). Aug 9 21:36:53 bs01 systemd[16271]: Listening on GnuPG cryptographic agent and passphrase cache. Aug 9 21:36:53 bs01 systemd[16271]: Reached target Paths. Aug 9 21:36:53 bs01 systemd[16271]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Aug 9 21:36:53 bs01 systemd[16271]: Reached target Sockets. Aug 9 21:36:53 bs01 systemd[16271]: Reached target Basic System. Aug 9 21:36:53 bs01 systemd[16271]: Reached target Default. Aug 9 21:36:53 bs01 systemd[16271]: Startup finished in 32ms. Aug 9 21:36:53 bs01 systemd[1]: Started User Manager for UID 5025. First there seem to be a change of passwords, which resulted in an "Access denied". After resetting the password I got this (please note the diff in userIDs (web21 resp web22): Could not chdir to home directory /var/www/clients/client1/web21/home/c2sxxxxxx: Permission denied -bash: /var/www/clients/client1/web21/home/c2sxxxxxx/.bash_profile: Permission denied web22@bs01:/$ Finally, I'll add what is in /etc/passwd for this user: c2sxxxxxx:x:5025:5007::/var/www/clients/client1/web21/home/c2sxxxxxx:/bin/bash I can of course start all over again and do a manual migration, but it's tedious. Only the resynch of the disks (RAID5 7*4 TB) takes 24 hours and I guess that copying everthing, creating databases, copy the data, setting up all the cron jobs etc will take about two times that. But I do have backups from when the server was fully installed with ISPconfig etc before the migration. Thank you for your help!
Ok, so the paths have been changed correctly but there is a problem with a UID. We will look into that issue today and contact you.
A new version of the migation tool has just been released that fixes this issue. As an alternative to doing the migration again, I wrote a small script to fix the imported SSH users. Upload the attached file to your server, unzip it and run 'php shelluser_fix.php' as root. This will correct the wrong UID's and GID's. But you will have to set a new password for the SSH users in ISPConfig afterward as there was a second issue which caused passwords of the shell users to be encrypted in wrong way. so there are two options: a) Redo the migration with the new Migration tool release. b) Use the script that I've attached to the post to correct the UID's and then set a new passwords for the shell users in ISPConfig.
I am afraid that there is still an issue: web22@bs01:~$ pwd /var/www/clients/client1/web21/home/c2sxxxxxx web22@bs01:~$
This is not an indication of a problem, these are just internal ID's and do not have to match. What matters is that when you login with a shell user of e.g. website domain1.tld that you get logged into the website domain1.tld.
