Icinga Config (/etc/icinga2) in Version Control (github / gitlab)

I’ve Googled this to death but can’t really find anything relevant (lots returned but usually because the page includes a github.com URL etc.).

I’ve also searched the forum and same sort of issues as above but nothing relevant.

The issues I’m having do this myself is the permissions on the /etc/icinga2 folder (having to Sudo git to do anythingf). My thoughts were to have another folder for conf.d but that won’t have the rest of the config. My second thought was to create a symbolic link for the entire icinga2 folder but that will also mean a change of permissions.

So what is best practice and what does everybody else do around this and permissions?

Any help gratefully appreciated.

It’s changing your permissions?

I track my icinga config in our own Gitlab system. I symlink /opt/icinga/icinga2 to /etc/icinga2, /opt/icinga being my git repo with all kinds of other related junk in it. Anything that’s set to icinga:icinga there doesn’t change when I git pull. If you’re doing this as an unprivileged user, maybe add yourself to the icinga group and make sure the group has write permissions.

Hi,

please share a concrete output of ls -lah from the affected directories, and explain which user you would prefer, and how that relates to version control with Git.

Cheers,
Michael

I’ve been unclear. Nothing is changing permissions. Using git under sudo all the time causes issues (the main one being any commit are done under that sudoed root account.

I have solved the problem by using Blake’s suggestion of using a folder under /opt to hold the incinga config and creating a symbolic link to the /etc/icinga2 folder.

1 Like