search

Icinga / icinga2

The core of our monitoring platform with a powerful configuration language and REST API.
https://icinga.com/docs/icinga2/latest
GNU General Public License v2.0
2.03k stars 578 forks source link

Windows MSI fails to install if C:\ProgramData\icinga2 already exists #8984

Open odenbach opened 3 years ago

odenbach commented 3 years ago

Describe the bug

We use a GPO to deploy icinga2 to our windows machines and a config deployment system (bcfg2) to deploy config files as well. If the config deployment system installs some files to C:\ProgramData\icinga2 BEFORE the MSI is installed, the installation fails.

To Reproduce

Install Windows. Download https://packages.icinga.com/windows/Icinga2-v2.13.1-x86_64.msi Create empty directory C:\ProgramData\icinga2. Install package. Fail.

Expected behavior

Installer should run through without any error messages. The package should install all contained files to the usual directories, regardless if they exist before.

Screenshots

icinga2-installer-error1 icinga2-installer-error2
odenbach commented 3 years ago

To be more precise: If C:\ProgramData\icinga2 already exists, the installer fails to create the etc and var directories with its default content. Therefore C:\ProgramData\icinga2\etc\icinga2\features-available\windowseventlog.conf does not get created which then leads to the installer to finally fail. If however the mentioned file exists before running the installer, it will run fine. But it will not update the config files in features-available. This is wrong in my opinion: a new version could contain new versions of these configs and should therefore update them (not the ones in features-enabled of course!).

julianbrost commented 3 years ago

Is that something that worked for you before? The installer takes the presence of the C:\ProgramData\icinga2 directory as a marker whether it has to copy the initial config there:

https://github.com/Icinga/icinga2/blob/95cdc00ad4e1ab788794322c92c54cd3f5c8c2bf/icinga-installer/icinga-installer.cpp#L219-L245

So if you create that yourself beforehand, you probably end up with an incomplete configuration. Or do you create the full configuration yourself but with a different directory structure?

odenbach commented 3 years ago

I see. When we install a machine both the config client and Icinga2 get installed automatically. We usually create the config host entry after installing the machine, this time I created it before and ran into the problem. So now I know that I have to create the config entry after installing the machine.

I still think that the installer should install everything in *-available. That would be the only way to ship updated default configs. Otherwise an upgraded host would never receive newer configs which might lead into trouble.

julianbrost commented 3 years ago

I still think that the installer should install everything in *-available. That would be the only way to ship updated default configs. Otherwise an upgraded host would never receive newer configs which might lead into trouble.

Installing an additional file in features-available/ that didn't exist before is the part in the installer that is failing. We could add a check to only attempt this if this directory exists to prevent this error within the installer, but that would likely still result in a broken config.

Apart from that, we could switch from taking presence of the whole C:\ProgramData\icinga2 directory as a marker to performing this on files individually, but this needs some consideration to not get it wrong, mainly not to overwrite intentionally changed configuration. Also, the deletion of a file could be an intended change by the administrator.

odenbach commented 3 years ago

I think the best would be to try to copy the behaviour of the Debian package: Files in /etc get updated by a newer package if the old files were not modified. That would mean of course that we would have to detect changes in old files. You could install a file containing the md5 sum for every shipped config file. The next installer could then check if the files have been changed in the meantime and only overwrite the unchanged ones. The other new configs could then get installed as "*.dpkg-new". As a last step then the file containing the md5 sums would get updated to reflect the new versions.

Al2Klimov commented 3 years ago

If the config deployment system installs some files to C:\ProgramData\icinga2 BEFORE the MSI is installed,

Would any of the following be a reasonable workaround to you?

odenbach commented 3 years ago

Well - after the reason was clear I switched over to installing the MSI before running our config management for the first time. That works of course. But still: If newer configs would get shipped with the MSI, I would never get them.

So my idea would be:

ALWAYS install or update features-available

Everything else should only be installed for new installations (i.e. %programdata%/icinga2 does not exist)

Does that make any sense?

julianbrost commented 3 years ago

But still: If newer configs would get shipped with the MSI, I would never get them.

Well not by the default "install a fresh config" code, but we already have some special code to make new features available on existing installations for the windowseventlog feature: https://github.com/Icinga/icinga2/blob/f5f8ccb1f4e0f52dd8f15020532c429754b24e92/icinga-installer/icinga-installer.cpp#L247-L268

Al2Klimov commented 3 years ago

If newer configs would get shipped with the MSI, I would never get them.

If you want to change your config, feel free to do so. Don't you have a GPO?

odenbach commented 3 years ago

Of course I have a GPO and a config deployment system, that is not the point. Often software comes with default config files which work well without changes. In that cases there is no need to deploy them centrally as they already work as expected. These files should be updated by the package installer in case they were updated upstream. Think of openssl configs. They usually contain a list of allowed ciphers. As the openssl package gets updated this list may become updated as well. If we deployed the openssl config centrally we would not get this update automatically.

So my general idea of shipping and updating configs would be: If a config file has not been changed then it should be updated with the new shipped version, similar to the way Debian works.

Al2Klimov commented 1 year ago

Unfortunately IfW can’t help either as it uses the MSI.

[Notice]: Starting Icinga for Windows installation
[Notice]: Remote repository "Icinga Stable" was successfully added
[Notice]: Downloading "agent" from "https://packages.icinga.com/IcingaForWindows/stable/agent/Icinga2-v2.13.5-x86_64.msi"
[Notice]: Installing component "agent" with version "2.13.5" into "C:\Program Files\ICINGA2"
[Error]: Failed to install component "agent":
False
[Notice]: Downloading "service" from "https://packages.icinga.com/IcingaForWindows/stable/service/icinga-service-v1.2.0.zip"
[Notice]: Installing component "service" into "C:\Program Files\icinga-framework-service"
[Notice]: Updating Icinga PowerShell Service binary
[Notice]: Service User ".\LocalSystem" for service "icingapowershell" successfully updated
[Notice]: Stopping service "icingapowershell"
[Notice]: Restarting service "icingapowershell"
[Notice]: Stopping service "icingapowershell"
[Notice]: Service User "NT Authority\NetworkService" for service "icingapowershell" successfully updated
[Notice]: Installation of component "service" was successful
[Notice]: Background daemon Cmdlet "Start-IcingaServiceCheckDaemon" has been configured
[Notice]: Downloading "plugins" from "https://packages.icinga.com/IcingaForWindows/stable/plugins/icinga-powershell-plugins-1.10.0.zip"