Issue with restore

[Felix]

Hello Hestia community,

I’m facing an issue when restoring a user but I’m not sure if it’s a bug or miss-configuration from my side. Let me start with some important details

Backup from
Ubuntu 18.04 x64
Hestia VERSION=‘1.0.6’ (might have been updated from a previous release)
Nginx + Apache MultiPHP (–nginx yes --apache yes --phpfpm no --multiphp yes)

Restore to
Ubuntu 18.04 x64
Hestia VERSION=‘1.1.1’ (clean install)
Nginx + Apache MultiPHP (–nginx yes --apache yes --phpfpm no --multiphp yes)

The issue
When running v-restore-user I get these errors:

-- USER --
2020-05-02 16:43:12 [USERNAME]

-- WEB --
2020-05-02 16:43:13 [FQDN]
tee: /home/[USERNAME]/web/[FQDN]/stats/.htaccess: Permission denied
AuthUserFile /home/[USERNAME]/web/[FQDN]/stats/.htpasswd
tee: /home/[USERNAME]/web/[FQDN]/stats/.htaccess: Permission denied
AuthName "Web Statistics"
tee: /home/[USERNAME]/web/[FQDN]/stats/.htaccess: Permission denied
AuthType Basic
tee: /home/[USERNAME]/web/[FQDN]/stats/.htaccess: Permission denied
Require valid-user
tee: /home/[USERNAME]/web/[FQDN]/stats/.htpasswd: Permission denied
[STATS_USER]:[STATS_CRYPT].

-- DNS --
2020-05-02 16:43:20 [FQDN]

-- MAIL --

-- DB --
2020-05-02 16:43:20 [DB]

-- CRON --
2020-05-02 16:43:21 0 cron jobs

-- USER FILES --
2020-05-02 16:43:21 .bashrc
2020-05-02 16:43:22 .profile
2020-05-02 16:43:22 .bash_logout

The restored WordPress site (files + DB) seems to be working OK. I also checked the DNS entries and they seem fine. Awstats seem OK too.

It looks as though these issues appear only if the user does not exist on the destination server.

• When I run another v-restore-user (right after the 1st restore) using exactly the same backup file, I get no such issues.
• If I delete the user completely on the destination server and run v-restore-user again from the same backup file, I have the same issues again.
• If I run the restore once more, I get no issues.

One thing to note… Although the backup file was created by Hestia, it might be possible that this user has been restored from a Vesta installation (i.e. Vesta > Hestia 1.0.6 > Hestia 1.1.1). I don’t know if that’s related though.

If you think this could be a bug, please tell me and I’ll raise an issue on github.

[Felix]

Trying to figure out where the problem is…

In the log file /var/log/hestia/error.log I see the following errors:

2020-05-02 23:09:42 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]
2020-05-02 23:09:44 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]
2020-05-02 23:09:44 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]
2020-05-02 23:09:44 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]
2020-05-02 23:09:50 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]
2020-05-02 23:09:50 v-restore-user  '[USER]' '[BACKUP-FILE].tar' [Error 3]

Running v-restore-user through bash -x I get lots of results of course, but here are some interesting snips:

++ check_result 3 'user [USERNAME] doesn'\''t exist'
++ check_result 3 'IP [IP-OLD-SERVER] doesn'\''t exist'
++ check_result 3 'PHP-70 web template doesn'\''t exist'
++ check_result 3 ' backend template doesn'\''t exist'
++ check_result 3 'IP [IP-OLD-SERVER] doesn'\''t exist'
++ check_result 3 '[DNS-TEMPLATE] dns template doesn'\''t exist'

Which I guess correspond to the 6 errors of type Error 3 found in /var/log/hestia/error.log So I guess nothing interesting here.

About the Permission denied error I think this output of bash -x helps:

+ setpriv --groups 1003,999 --reuid [USER] --regid [USER] -- tee /home/[USER]/web/[FQDN]/stats/.htaccess
tee: /home/[USER]/web/[FQDN]/stats/.htaccess: Permission denied

That led me to line 403 of v-restore-user, where I see a call to the rebuild_web_domain_conf() function which is found in rebuild.sh line 167.

The rebuild_web_domain_conf() function is calling 7 user_exec functions with tee commands (2 if the WEB_SYSTEM is nginx, 4 if the WEB_SYSTEM is not nginx and one that applies to all cases).

In my case, I have 5 Permission denied errors. Of them, 4 are thrown by lines 315-318 and 1 from line 320, of rebuild.sh

To better understand what is going on, I placed a sleep 1000 command on line 321 of rebuild.sh to stop the execution of the restoration process, just right after the throwing of the Permission denied errors.

Then I went to check the permissions of the files

/home/[USERNAME]/web/[FQDN]/stats/.htaccess
/home/[USERNAME]/web/[FQDN]/stats/.htpasswd

Then I realized that no files existed in the directory /home/[USERNAME]/web/[FQDN]/stats/. And I think this is where the problem is! As far as I can understand, the script v-restore-user is trying to rebuild the vhost (line 403) before any data is extracted from the archive (line 412). But a part of the rebuild vhost process is trying to write to the non-existent files.

This must be why the restoration doesn’t throw any errors when run a second time. The files are already there, so the tee run without any issues.

I just noticed that the directory /home/[USERNAME]/web/[FQDN]/stats has permission mask of 0551, i.e. it’s not writable (done at line 227 in rebuild.sh). The directory is made writable at line 411 in v-restore-user, which comes after the rebuild process. This is why the tee command inside the rebuild process can’t create those new files.

Are my assumptions correct?

[Raphael]

Thanks for the awesome debuging and opening a issue on the right spot: https://github.com/hestiacp/hestiacp/issues/793

We’ll track it down and publish a fix for testing on github.

[Lupu]

Indeed great bug report @Felix!
Just checked your github PR and merged the fix.