I am migrating our Hestia deployment to a bigger server. The admin a/c contains the domains with mail setups. Everything restores correctly on all domains except those with a mail setup that uses SSL (Let’s Encrypt) - mail domains without SSL are OK.
The issue is that none of the SSL data is restored. This includes the Apache and nginx conf files that should be in /home/admin/conf/mail/DOMAIN and the SSL certificates themselves - both in the admin account and the mail.DOMAIN.* SSL files in the /hestia/ssl folder in the tar file. The files exist in the tar backup.
In the Hestia error log there are multiple Error 3’s for the restore command - I’ve no idea if that helps For each affected domain I received these errors on screen
chmod: cannot access '/usr/local/hestia/data/users/admin/ssl/mail.XXX.com.*': No such file or directory
cp: cannot stat '/usr/local/hestia/data/users/admin/ssl/mail.XXX.com.crt': No such file or directory
cp: cannot stat '/usr/local/hestia/data/users/admin/ssl/mail.XXX.com.key': No such file or directory
cp: cannot stat '/usr/local/hestia/data/users/admin/ssl/mail.XXX.com.pem': No such file or directory
/usr/local/hestia/bin/v-restore-user: line 645: /etc/dovecot/conf.d/domains/XXX.com.conf: No such file or directory
/usr/local/hestia/bin/v-restore-user: line 646: /etc/dovecot/conf.d/domains/XXX.com.conf: No such file or directory
/usr/local/hestia/bin/v-restore-user: line 647: /etc/dovecot/conf.d/domains/XXX.com.conf: No such file or directory
/usr/local/hestia/bin/v-restore-user: line 648: /etc/dovecot/conf.d/domains/XXX.com.conf: No such file or directory
/usr/local/hestia/bin/v-restore-user: line 649: /etc/dovecot/conf.d/domains/XXX.com.conf: No such file or directory
find: '/usr/local/hestia/ssl/mail': No such file or directory
ln: failed to create symbolic link '/usr/local/hestia/ssl/mail/mail.XXX.com.crt': No such file or directory
ln: failed to create symbolic link '/usr/local/hestia/ssl/mail/mail.XXX.com.key': No such file or directory
chmod: cannot access '/home/admin/conf/mail/XXX.com/ssl/*': No such file or directory
chown: cannot access '/home/admin/conf/mail/XXX.com/ssl/*': No such file or directory
chmod: cannot access '/usr/local/hestia/ssl/mail/*': No such file or directory
chown: cannot access '/usr/local/hestia/ssl/mail/*': No such file or directory
The notification message in HestiaCP (on the bell icon) says that the restore was successful when clearly it is not!
Given the messages about missing files I tried re-running v-restore-user with the optional MAIL switch. This time there were no on screen errors but again the SSL files failed to be restored.
I need to fix this quickly so I’m going to manually copy all the files from the backup tar.
for your issue above: this is on a fresh install I guess, so no user or domains have been there before the restore, right?
it looks a bit like some main folders are missing, like /usr/local/hestia/ssl/mail that maybe only get created the first time an mail ssl-cert is requested. thanks for your report anyway, I guess we need to investigate and try to reproduce…
it would be awesome if you could open an issue over at github with the same information, as this is much better trackable for the development team, thanks!
@falzo Yes fresh install but the admin account is created as part of that fresh install so technically I guess admin is an existing user.
The /usr/local/hestia/ssl/mail folder is on my server but I can’t tell you if it was put there by the first install or the 2nd attempt. It contains symlinks to 2 files in the /home/admin/conf/mail/DOMAIN/ssl that don’t exist.
My attempt at manually restore these files doesn’t work - nothing changes in the HestiaCP. So I ran v-rebuild-mail-domains admin thinking that this would correct whatever I’d missed and it wiped out all the SSL stuff I’d just restored!! So is there a flag/setting I’ve missed that tells the system that these domains have Let’s Encrypt SSL certs? Having to recreate these accounts all over again in HestiaCP will be a royal PIA and I’m nervous do this as in the past when working on a client’s Vesta rebuild recently Let’s Encrypt spat the dummy and refused to allocate new certificates even after I’d deleted them on the Let’s Encrypt website. All help gratefully received!
Will open a ticket on github now - didn’t start there in case I hadn’t found a bug but was being a numpty!
you can use this to activate ssl on your new instance for the domains WITHOUT ticking the letsencrypt checkbox there, but only pasting the copied text into the three boxes accordingly.
as the certs are valid this should work without the need to contact the letsencrypt server for a new certificate and you can change your A records later.
if everything works and the A records are switched you can then simply disable ssl and reactivate again including getting a new letsencrypt cert for each later on
Silly question - if I remove the Let’s Encrypt check box on the old server, does the relevant v-* binary communicate with Let’s Encrypt to get the certificate revoked or does the system assume that it will expire in a few months?
afaik if you remove that LE checkbox after having a certificate issued already, nothing will change other than that the certificate won’t be renewed automatically.
so no revocation or anything. and the cert itself will stay in the textboxes and kept running for those domains.
PS in the end it’s just a regular 3-month ssl cert. it did not cost anything and the process can be automated, however you can still use it (manually) for that time period as you would with every other cert as well, including multiple hosts etc.
That’s what I figured but I thought it was worth asking.
Given the hell I endured with the client over this, following your manual swap over idea and letting the certificates run down to about 10days to go will/should probably allow LE to issue new ones without issues seems to be the best game in town. Time will tell
@brackenhill-mob I was able to reproduce the issue, see github for more details
on a sidenote: I heavily recommend to not host any production stuff under the admin user. while it technically is possible and might make sense in certain test or development cases, this user has sudo rights and if your web page gets compromised, the risks are simply higher, that someone achieves elevated access through that and might be able to take over your box completely.
you don’t want that. and that’s why we have that warning banner there.
if you go through migration just now and move from one server to another, this would be the perfect opportunity to simple restore your backup to different username and account.
also if that one doesn’t exist before your restore will run through including mail ssl (see my github comment)
@falzo Sound advice as always. But it raises 3 questions for me
Are you saying that I you don’t need to have created a new user in order to be able to restore the admin domains etc to it and it will be created on the fly? Because one must supply a user name for the restoration app I assumed that the user had to exist (and when I last did this in Vesta several years ago it was mandatory if I remember correctly)
As I’ve now got the box up and running, should I delete the domains and mail and databases from the system and run the restore on a backup or would I be better off using v-change-domain-owner?
Regardless of the answer to 2, what happens to the ownership and name of each database? Does it remain as admin_XXX or is it changed on the fly
you can choose whatever old or new username you want the backup restored to.
it does not need to match the original one and it does not need to be an exsiting one.
good question and valid point I forgot to clarify on.
both, database and user will be changed to the prefix of that new user, otherwise it would not work properly and might interfere with existing stuff in other accounts (e.g. admin) - so you need to adjust the config of your webpage/afterwards.
I’d vouch for removing the existing stuff from the admin and run a clean restore to a new user.
I am not sure if v-change-domain-owner also migrates databases, so you would need to do that part manually anyway. I have to admit I never used the owner change v-script before, so can’t even tell how it handles mail
→ cleanup, fresh restore. adjust site config for db, done.
Because I’m trying to install from an admin backup, the user that is created is also an admin account. This meant that none of the databases or the mail server setups were restored and it clobbered apache. I’m now restoring to admin again and will move domains over one by one
huh, sorry, I obviously did not want to cause you more work and trouble. I don’t have an admin backup with actual data in it, so I can’t try and see what’s wrong. the actual difference between admin account and regular user is mainly their permissions in regards to sudo and that is nothing that a restore changes or creates.
so besides admin itself there can be no other account with those permissions created from the v-scripts unless you manually add it to sudo - and afaik the restore doesn’t do that. so I am a bit lost, what went wrong.
imagine the restore process actually doing the same steps you would do manually, creating a new regular user. creating the domain under that user, putting the files in, creating the mail domain, putting the mails in, creating the database and restoring from dumps etc.
there is no step where it would create a second admin account as such. however, what might not work is, if you have a domain already existing in another account, as that can only be there once. maybe you use the same hostname and that would be in the new admin account and conflict on the restore?
as said seems a bit unexpected… again sorry for the additional work caused
Don’t worry about it - I’m already back up and running. Now that I know how this works internally it was much easier to copy and rename files and change their permissions and ownership via ssh rather than cut and paste in the gui.
FYI there were no duplicate domains - I deleted everything that was about to be restored
Oh and I now realise that in my panic I saw that the new user had inherited the description from admin rather than the permissions - my bad
For each affected domain I received these errors on screen
