If Apache is already installed on the box, the web settings page system doesn't work

[digininja]

In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

familiar enough to know what is broken

---

Expected behaviour:

Changes made on settings.php should stick

Actual behaviour:

The changes don't stick

Steps to reproduce:

The box I installed Pi-hole on already had Apache installed and working so when the web files were installed they dropped into the existing web root and were picked up and served by Apache. The lighttpd server installed never manages to start up.

The scripts/pi-hole/php/savesettings.php page builds up a command which it then runs using exec on line 301.

You've got an entry in a sudoers include file to allow lighttpd to run sudo commands but as I'm apache the sudo command asks for a password which exec can't give it and so fails silently. The $success string that is built up never gets an error, only the second line which says the update worked. I confirmed this by adding the apache user to the sudoers config file you created and re-doing the changes.

I'd suggest a couple of fixes....

• Have your installer check for existing web servers and handle them gracefully
• Have the exec calls take the return value as well as just the string that comes back and check that to make sure things work correctly. This will also pick up general bugs or failures rather than just this specific instance.

Troubleshooting undertaken, and/or other relevant information:

[dschaper]

I'll add this to the list of things to look and and fix with a rewrite of the installer script.

[digininja]

ok, sounds good.

[dschaper]

@Mcat12 Should we track this here in core, or would you like this for the web interface?

[AzureMarker]

This is a core issue, because core should make sure web has the necessary privileges and correct environment to run in. I do see that error handling could be improved for the settings page in this insurance, but it should not have to handle this case.

[dschaper]

Do we really want core to be enabling sudo nopass for the httpd daemon that we do not install?

[AzureMarker]

The core issue is that the user wants to use a server which we don't support with a config we didn't create. It's not a situation we can easily detect and warn against in the current architecture. The solution is to either use lighttpd, or fix the config manually since it's unsupported. With the upcoming API and web interface, these kinds of issues should not appear.

[dschaper]

Agreed, the only actions needed are potentially some clarification on the error message or error handling, correct? And that is something to be done on the web side. Is there anything here in core that we can or need to do?

[AzureMarker]

In that case, it can be a web issue that the command status should be checked.

[UncleSuperman]

I ran into this as well and the fix was simple. You simply need to update the username in /etc/sudoers.d/pihole from lighttpd to the user your web server is running as (apache, httpd, etc.).