I woke up this morning to having an issue with Roundcube receiving emails, last night it was working fine. It said that it was unable to make some directories because some user was missing the +w permission. Well, I decided to start with sudo apt-get update && sudo apt-get upgrade then I would start doing some research online about the problem and got stuck on this in terminal. Any help with this?
Hello @Nguyjohnathon,
Do you have composer.phar
in /var/lib/roundcube/
? Iām asking because Iām pretty sure the command v-add-sys-roundcube
is stuck because roundcube installation is asking interactively if you really want to run php composer.phar as root/super user and is waiting a yes or no but you canāt answer.
If that is the case you could kill the process v-add-sys-roundcube
that must be stuck so the Hestia upgrade can continue and finalize the roundcube installation manually (roundcube 1.6.3 should be already installed, but maybe you want to finish the roundcube installation or reinstall it again manually just in case).
Cheers,
sahsanu
I had the same issue on on of my servers how ever I am sure we donāt call composer self ā¦
Is not Hestia directly, composer.phar
is called when v-add-sys-rouncube
is executed during upgrade (this is the part):
$RC_INSTALL_DIR/bin/update.sh --version "$version" > /dev/null 2>&1
And that roundcube script executes composer.phar
if it is found in /var/lib/roundcube/
if ($composer_bin = find_composer()) {
echo "Executing " . $composer_bin . " to update dependencies...\n";
echo system("$composer_bin update -d " . escapeshellarg(INSTALL_PATH) . " --no-dev", $exit_code);
}
[...]
function find_composer()
{
if (is_file(INSTALL_PATH . 'composer.phar')) {
return 'php composer.phar';
}
foreach (['composer', 'composer.phar'] as $check_file) {
$which = trim(system("which $check_file"));
if (!empty($which)) {
return $which;
}
}
return null;
}
eris@web01:~$ which composer
/usr/bin/composer
Great ā¦
So composer.phar donāt even need to be present in the folder even /usr/bin/ is already enough
We need to fix this some howā¦
In my case I only had composer.phar
in /var/lib/roundcube/
so I renamed it.
I was creating pre_install.sh
and post_install.sh
hook scripts to check whether roundcube has been updated and execute renamed composer.phar.original
file and execute it to update using variable COMPOSER_ALLOW_SUPERUSER=1
to avoid the interactive question.
I donāt know whether it should be a good idea to modify v-add-sys-roundcube
to add COMPOSER_ALLOW_SUPERUSER=1
before calling roundcubeās update.sh
script:
COMPOSER_ALLOW_SUPERUSER=1 $RC_INSTALL_DIR/bin/update.sh --version "$version" > /dev/null 2>&1
Because, Iām afraid, a lot of users could have this issue. On the other side, it is supposed we should not use composer as rootā¦
With 1.9.0 we could update the permissions so it runs under the new Hestia-web user and run the the update thenā¦
Probably the best solutionā¦
I agree, the best solution is to change the owner of /var/lib/roundcube/
to new Hestia-web user and execute the roundcube installation/upgrade with that user.
But till the new 1.9.0 version, I suppose we could fix it adding the composer variable before executing update.sh script or there will be a lot of stuck upgrades out there
Yes ā¦
Ok, let me open a PR
Great
Mergedā¦
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.