RFC: moving from separate users to user monitoring for everything

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: moving from separate users to user monitoring for everything

Lars Vogdt
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Christian Boltz-5
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Christian
In reply to this post by Lars Vogdt
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Lars Vogdt-4
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Lars Vogdt-4
In reply to this post by Christian Boltz-5
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Christian Boltz-5
In reply to this post by Lars Vogdt-4
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Lars Vogdt
Am 17. Januar 2017 01:00:35 MEZ schrieb Christian Boltz <[hidden email]>:
>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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Ludwig Nussel
In reply to this post by Christian Boltz-5
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RFC: moving from separate users to user monitoring for everything

Christian Boltz-5
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: [hidden email]
To contact the owner, e-mail: [hidden email]