[opensuse-packaging] RFC: moving from separate users to user monitoring for everything
Hi I'm maintaining some packages in the server:monitoring repository and want to make my live a bit easier in the future (and I hope that also our users will benefit from it)... At the moment, we follow upstream very close regarding the names of the users and groups used for monitoring related packages (and especially daemons): Package | User(s) | Group(s) ------------------------------------------------ icinga | icinga | icinga, icingacmd naemon | naemon | naemon nagios | nagios | nagios, nagcmd shinken | shinken | shinken zabbix | zabbix, zabbixs | zabbix, zabbixs Please note that at least icinga, naemon, nagios and shinken are very similar and even their configuration is more or less compatible. So you can easily migrate between the different daemons without too much administration overhead. While - from a security stand point - the current approach to use the upstream users/groups is very smart, as it allows you to run multiple daemons on a single host that can not influence each other, it becomes more and more a nightmare from a packaging (and customer) view: A lot of 3rd party applications want to get access to sockets, directories or other parts, that belong to the corresponding daemon (check_mk*, pnp4nagios, BPView, {nagios-,icinga-www} - as both can run also on the other core, nagiosgrapher, nagiosgraph, nagserv, nsca, ... just to name a few). As result, there have to be either "permission" files to change the ownerships after installation of sucha 3rd party application - or even separate $pkg-$daemon sub-packages that come with the correct owner:group setup for the $daemon part. The problem with "permissions": * there is a small, but important time frame between installing a package update and executing "chkstat --system --set" on the host to correct the ownerships again * it needs additional openSUSE specific READMEs and support for users that are not aware of the fact that they might need to edit a file, that is not mentioned upstream, before the application works * our security team does not seem to like the approach ;-) The problem with a separate sub-package: * Some (older?) openSUSE distribution checks had problems with files and directories that were packaged in multiple sub-packages (even if the sub-packages conflicted with each other). Which made it impossible to get the package in Factory at all. * Even with "supplements" and "suggests", people might have to choose their sub-package manually, if there is just a small mistake. * it becomes a packagers nightmare to adapt all the available plugins and 3rd party apps for all the possible monitoring daemons... So instead of maintaining a growing list of packages that require more and more time for packaging and maintenance (to support users by providing help to install 3rd party app X together with daemon Y), I like to get your feedback about the following approach: * use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd That would allow the 3rd party applications/packages to use the same user/group without any modifications. From a security stand point, this might be a nightmare, correct. But please think how often a user is running more than one monitoring solution in parallel on the same machine? Instead: how often might it be that a user wants to migrate from one monitoring solution to another and has to go through a lot of config files and filesystem permissions before he can start with the real migration? We need to document the new "generic/default monitoring user/group on openSUSE", of course. But we also would need more and more documentation if we follow the current approach - so I do not see this as negative impact. An alternative might be to reduce the available monitoring packages for openSUSE to get more time for packaging and documentation if we stay on the current system. But I like freedome, so I do not like this point ;-) As far as I found out (but I did only a small research), other distributions like Debian are using also just one set of monitoring users/groups for the compatible monitoring applications. If someone knows more, I would be very happy to hear. So my question is: what is your opinion? CU, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Mittwoch, 11. Januar 2017, 13:17:40 CET schrieb Lars Vogdt:
I'm maintaining some packages in the server:monitoring repository and want to make my live a bit easier in the future (and I hope that also our users will benefit from it)...
At the moment, we follow upstream very close regarding the names of the users and groups used for monitoring related packages (and especially daemons):
Package | User(s) | Group(s) ------------------------------------------------ icinga | icinga | icinga, icingacmd naemon | naemon | naemon nagios | nagios | nagios, nagcmd shinken | shinken | shinken zabbix | zabbix, zabbixs | zabbix, zabbixs
Please note that at least icinga, naemon, nagios and shinken are very similar and even their configuration is more or less compatible. So you can easily migrate between the different daemons without too much administration overhead.
Does "more or less compatible" also mean that they store their configuration and the collected data in the same directories?
A lot of 3rd party applications want to get access to sockets, directories or other parts, that belong to the corresponding daemon
So instead of maintaining a growing list of packages that require more and more time for packaging and maintenance (to support users by providing help to install 3rd party app X together with daemon Y), I like to get your feedback about the following approach:
* use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd
That would allow the 3rd party applications/packages to use the same user/group without any modifications.
Do these 3rd party applications need full access to all files owned by the "monitoring" user, or only by some of them (like sockets)? Would it be an option to create "monitoring" and "monitorcmd" groups and to make the relevant files group-writeable while keeping the separate "nagios" etc. users? Regards, Christian Boltz -- Let me know when you once find some actual outcome of SUCH a thread... [Dominique Leuenberger in opensuse-factory] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi On Fri, 13 Jan 2017 19:49:30 +0100 Christian Boltz wrote:
Please note that at least icinga, naemon, nagios and shinken are very similar and even their configuration is more or less compatible. So you can easily migrate between the different daemons without too much administration overhead.
Does "more or less compatible" also mean that they store their configuration and the collected data in the same directories?
No. At least not in the standard way. You can start icinga with "/usr/sbin/icinga /etc/nagios/nagios.cfg" to use the nagios configuration instead of the default icinga one, but all bring their own configuration in their own directory namespace.
That would allow the 3rd party applications/packages to use the same user/group without any modifications.
Do these 3rd party applications need full access to all files owned by the "monitoring" user, or only by some of them (like sockets)?
Would it be an option to create "monitoring" and "monitorcmd" groups and to make the relevant files group-writeable while keeping the separate "nagios" etc. users?
Might be. An interesting approach that I need to check. As I wrote in another mail: this might also be a solution for 3rd party add-ons that expect the monitoring daemons to write into their (the 3rd party app) directories. CU, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 11.01.2017 um 13:17 schrieb Lars Vogdt:
* use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd usr: mon or i(cinga)n(agios,aemon)s(shinken)mon -> insmon group: mon or insmon sub group: moncmd or insmoncmd
is it possible to have this new user/group only for the 3rd-party packages to allow this new user/group to access icinga, nagios & co stuff ? -- Christian ---------------------------------------------------- - Please do not 'CC' me on list mails. Just reply to the list :) ---------------------------------------------------- http://www.sc24.de - Sportbekleidung ---------------------------------------------------- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi On Sun, 15 Jan 2017 21:36:37 +0100 Christian wrote:
Am 11.01.2017 um 13:17 schrieb Lars Vogdt:
* use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd usr: mon or i(cinga)n(agios,aemon)s(shinken)mon -> insmon group: mon or insmon sub group: moncmd or insmoncmd
According to my latest experience with reviews, a 3 character user/group name is considered too short => mon will not get accepted. While I can understand your idea of combining the daemon names in the future name for the user/group, I suspect that this will not make the use-case of these user/group really clear to our customers. That's why I suggested "monitoring"...
is it possible to have this new user/group only for the 3rd-party packages to allow this new user/group to access icinga, nagios & co stuff ?
Depends: some of those 3rd party packages need only access to a socket, which can easily be done by adding them to a group that has access (if you know the group name of each monitoring daemon, of course ;-). The interesting part is the other way: nagios/icinga can provide performance data for 3rd party packages to process them. But if the Nagios process is not able to write the data into the defined directory of the 3rd party package (because the default user might be icinga and not nagios), that's bad. So someone has to add the nagios/icinga/shinken/... user to a 3rd party group. The directory names are also an interesting point (/var/{lib,log}/icinga vs. /var/{lib,log}/nagios as example), where I'm currently unsure how to handle them. From a first view, keeping them as they are might be the best solution. But we should in general think about /usr/lib/nagios/plugins/ - the standard installation place for all "monitoring plugins" at the moment. If we are correct, those plugins should go into something like /usr/lib/monitoring/plugins in the future - maybe with a symlink to the old place for a couple of years? => time to start a "monitoring cleanup round" ;-) CU, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Montag, 16. Januar 2017, 12:03:33 CET schrieb Lars Vogdt:
According to my latest experience with reviews, a 3 character user/group name is considered too short => mon will not get accepted.
The reason behind this is probably to avoid collisions with "real" user accounts. IIRC there was a discussion about a username policy for packages some years ago, and one of the ideas was to enforce that (new) system users and groups should always start with an underscore, for example "_monitoring". However, the user list in rpmlint looks like this policy was never honored, and I'm not even sure if it left the proposal stage.
While I can understand your idea of combining the daemon names in the future name for the user/group, I suspect that this will not make the use-case of these user/group really clear to our customers. That's why I suggested "monitoring"...
Right, "monitoring" is much better than a cryptic insider joke ;-) Besides that, we'd have to update "insmon" to something like "insymon" if someone creates a "yet another monitoring" fork of nagios ;-)
The interesting part is the other way: nagios/icinga can provide performance data for 3rd party packages to process them. But if the Nagios process is not able to write the data into the defined directory of the 3rd party package (because the default user might be icinga and not nagios), that's bad. So someone has to add the nagios/icinga/shinken/... user to a 3rd party group.
Or the 3rd party packages have to use the "monitoring" group for those directories, which might be the easier solution.
The directory names are also an interesting point (/var/{lib,log}/icinga vs. /var/{lib,log}/nagios as example), where I'm currently unsure how to handle them. From a first view, keeping them as they are might be the best solution.
But we should in general think about /usr/lib/nagios/plugins/ - the standard installation place for all "monitoring plugins" at the moment. If we are correct, those plugins should go into something like /usr/lib/monitoring/plugins in the future - maybe with a symlink to the old place for a couple of years?
This would also mean that the plugins _have to_ be compatible with all monitoring tools (nagios/incinga/whatever). Are they?
=> time to start a "monitoring cleanup round" ;-)
Will you do this before or after the progress.o.o cleanup? ;-) I did quite some ticket cleanup and sorting in the last days, but I'm OOP [1] to continue with several of them. Regards, Christian Boltz [1] Out Of Permissions - and no, I won't tell you about the missing permissions to avoid I have to do everything ;-)) -- Das 42te Gebot des Usernetzes besagt: "Du sollst nicht süchtig siggen eines Süchtigen Signatur. Auf das du selber nicht siggsüchtig werdest." Wahrscheinlich wird das jetzt wieder gesiggt. [WoKo in dag°] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 17. Januar 2017 01:00:35 MEZ schrieb Christian Boltz
IIRC there was a discussion about a username policy for packages some years ago, and one of the ideas was to enforce that (new) system users and groups should always start with an underscore, for example "_monitoring". However, the user list in rpmlint looks like this policy
was never honored, and I'm not even sure if it left the proposal stage.
Sounds reasonable to me.
The interesting part is the other way: nagios/icinga can provide performance data for 3rd party packages to process them. But if the Nagios process is not able to write the data into the defined directory of the 3rd party package (because the default user might be icinga and not nagios), that's bad. So someone has to add the nagios/icinga/shinken/... user to a 3rd party group.
Or the 3rd party packages have to use the "monitoring" group for those directories, which might be the easier solution.
That's why I want to go the way with one user and two groups for all monitoring daemons :-)
But we should in general think about /usr/lib/nagios/plugins/ - the standard installation place for all "monitoring plugins" at the moment. If we are correct, those plugins should go into something like /usr/lib/monitoring/plugins in the future - maybe with a symlink to the old place for a couple of years?
This would also mean that the plugins _have to_ be compatible with all monitoring tools (nagios/incinga/whatever). Are they?
The answer is: yes! :-)
=> time to start a "monitoring cleanup round" ;-)
Will you do this before or after the progress.o.o cleanup? ;-) I did quite some ticket cleanup and sorting in the last days, but I'm OOP [1] to continue with several of them.
Hihi ;-) let me see what I can do. I just want to clarify the monitoring situation before 42.3 gets in the hot phase. CU, Lars BTW: anyone interested in Hackweek? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz wrote:
Am Montag, 16. Januar 2017, 12:03:33 CET schrieb Lars Vogdt:
According to my latest experience with reviews, a 3 character user/group name is considered too short => mon will not get accepted.
The reason behind this is probably to avoid collisions with "real" user accounts.
IIRC there was a discussion about a username policy for packages some years ago, and one of the ideas was to enforce that (new) system users and groups should always start with an underscore, for example "_monitoring". However, the user list in rpmlint looks like this policy was never honored, and I'm not even sure if it left the proposal stage.
It never left proposal state. It needs someone to actively push it forward. Current version is https://github.com/LinuxStandardBase/lsb/pull/21 I don't expect much from LSB side. So we'd have to implement this on our own. A not fully discussed nor solved problem is whether and how to migrate existing system users. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Dienstag, 17. Januar 2017, 09:18:16 CET schrieb Ludwig Nussel:
Christian Boltz wrote:
IIRC there was a discussion about a username policy for packages some years ago, and one of the ideas was to enforce that (new) system users and groups should always start with an underscore, for example "_monitoring". However, the user list in rpmlint looks like this policy was never honored, and I'm not even sure if it left the proposal stage. It never left proposal state. It needs someone to actively push it forward. Current version is https://github.com/LinuxStandardBase/lsb/pull/21
That looks like a different topic. I was thinking about usernames, but this pull request is mostly about the UID. (As a side note, the example users there follow the "_something" scheme.)
A not fully discussed nor solved problem is whether and how to migrate existing system users.
I'd say: don't. You'd need to scan the whole filesystem to chown existing files and directories, and if the users already exist, they already have a valid UID ;-) so I see no point in chaning it. For newly created users, useradd should indeed use the proposed UIDs. Regards, Christian Boltz --
if THIS is the way the project is heading, I see a big sign of doom at the end of the tunnel... Not testing new software early enough also will *not* make the product better. We're both right -- only history will tell who's more right :-) [> Dominique Leuenberger and Stefan Seyfried in opensuse-factory]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
Christian -
Christian Boltz -
Lars Vogdt -
Lars Vogdt -
Ludwig Nussel