Successfull install, BUT 2 issues(why was apache on a pure nginx?)

I successfully installed hestia (pure nginx, no apache), but there are a couple questions/issues:
1: my install terminal warned that apache2 was already installed as part of debian 12, and recommended that it uninstall it., so I typed yes. however, my server is a new VPS, with a brand new auto install of debian 12, from Vultr VPS, and thus shouldn’t have apache in it. So did the hestia script add apache itself and then remove it? will this create problems?
my install script had:
-apache no --multiphp ‘7.4,8.3’ --clamav no --spamassassin no --quota yes --webterminal yes
2: during the install I got this error:
Failed to enable unit: Unit file systemd-timesyncd.service does not exist.
Failed to start systemd-timesyncd.service: Unit systemd-timesyncd.service not found.
But it completed successfully anyway.
I found the hestia setting to set the server to my time. so all is ok?

No, seems the image used by your hosting installs Apache.

If you already has another NTP client/daemon like ntpsec-ntpdate, ntpsec… to synchronize your server’s time, then there is no problem, you can ignore the error.

I contacted Vultr (which is one of the two biggest VPS worldwide) re: the image problem. I received from them:
“What likely is happening with this is that the apache2 directory within /etc/ directory is a holdover from previous versions of Debian. I installed a Debian server on my personal account and apache2 was not running.”
He asked me to run this command:
which apache2
And it gave me: usr/sbin/apache2
I used my filemanager and found that file there, but it is a single binary file(713kb), not text, so can’t be read.
I assume that this won’t pose any problem with my nginx install?
But it is still a mystery. As it stands now, both Vultr and Hestia appear to be blaming each other for the appearance of Apache?

As I already said, if you use --apache no when executing the installer, Hestia doesn’t install apache. Maybe you executed Hestia installer previously… I don’t know, but if Vultr doesn’t include apache in their images and Hestia doesn’t install apache when --apache no is used, then PEBKAM :stuck_out_tongue:

Just in case, this is what Hestia does when checking clonflicting packages, in this case apache2:

dpkg --get-selections | grep apache2

If the package appears in the output, Hestia shows the warning message asking to remove those packages.

I don’t think so but show the output of these commands:

dpkg -l | grep -i apache2
1 Like

Thank you much for all your help and suggestions.
When I enter: dpkg -l | grep -i apache2
I get:
ii apache2-bin 2.4.62-1~deb12u2 amd64 Apache HTTP Server (modules and other binary files)
ii apache2-suexec-pristine 2.4.62-1~deb12u2 amd64 Apache HTTP Server standard suexec program for mod_suexec
(PS: I can assure you I never installed Apache, and I don’t even know the commands for it. upon installing the image, I immediately ran the Hestia script. I have set up more than a dozen Nginx servers over the years, in this way, mostly using Webmin, Vesta, then MyVesta. So I don’t know how this happened or what to think. )

I’ve tested it in a VM using Debian 12 and yes, I can confirm that Hestia installs both packages, well, it doesn’t install apache2-bin but installs apache2-suexec-pristine that depends on apache2-bin so both packages are installed.

When you add the option --apache no Hestia removes these packages from the list:

if [ "$apache" = 'no' ]; then
        software=$(echo "$software" | sed -e "s/apache2 //")
        software=$(echo "$software" | sed -e "s/apache2-bin//")
        software=$(echo "$software" | sed -e "s/apache2-utils//")
        software=$(echo "$software" | sed -e "s/apache2-suexec-custom//")
        software=$(echo "$software" | sed -e "s/apache2.2-common//")
        software=$(echo "$software" | sed -e "s/libapache2-mod-rpaf//")
        software=$(echo "$software" | sed -e "s/libapache2-mod-fcgid//")
        software=$(echo "$software" | sed -e "s/libapache2-mod-php$fpm_v//")
fi

It doesn’t remove the apache2-suexec-pristine package, and that’s where the problem lies. This issue occurs only with the Debian installer. As far as I know, apache2-suexec-pristine should be removed from the list, it shouldn’t be needed when apache2-suexec-custom is going to be used.

I apologize for repeatedly saying that Hestia wasn’t installing it… (in my defense, at least it doesn’t do it directly) :wink:

I’ve created this PR to fix the issue:

That said, you can remove both packages:

apt purge apache2-suexec-pristine apache2-bin
apt autoremove
2 Likes

Ok, thank you again for all your work and constant help! Overall, I’m very impressed with Hestia and looking forward to being part of the community.
So, do you recommend that I remove those 2 packages, or just leave them be. Which might be the safest?

1 Like

You’re welcome :wink:

Remove them, you don’t need those packages.

Hmmm… when I tried those 2 remove lines, the first gave me:
LIBSSH2 returned LIBSSH2_ERROR_SOCKET_SEND

That looks like an error on the client side, which is unable to connect to the SSH server. Could you please provide more information about the error? Were any packages removed? Are you able to connect to your server?

I think my connection must have died late last night. It worked fine today. All went well. Thanks much.

1 Like