On Sat, 2016-08-13 at 22:19 +0200, Paul Gevers wrote:
> Sorry for taking a while before responding. Holiday season.
No worries..

> I couldn't quickly find under which user
> the
> program icinga is running
Mutliple things come here together:
- the user/groups under which the icinga daemon itself runs
  => per default user: nagios
- the user/groups under which several services, sitting on top of
  icinga, run... for example the webfrontends, which access the DB then
  => here it depends a bit on the frontend (the legacy one from nagios,
     which runs as CGI vs. the "new" ones from icinga itself, which run
     as PHP). The legacy one however, doesn't access the DB.
  => for CGI, it depends again,... is suexec?
  => for PHP, it depends again on the SAPI (mod_php, CGI?, FCGI?)

In the end, every user is basically free to choose, I for example run
all frontends under their own separated user.
So the legacy CGI get's su'ed to e.g. cgi-icinga-classic, the new ones
run via PHP-CGI and get's su'ed to e.g. cgi-icinga-web...

> but are Unix sockets appropriate?
This is also the most appropriate way. Security-wise it's plain stu***
to run all CGI programs under the same user (e.g. cgi-suexec), and it's
even worse to run PHP programs with mod_php, which place them all under
the webserver's user context (typically and per default www-data user
in Debian).


>  I.e. I
> found a hint it may be running under the nagios user, then Unix
> sockets
> only work if the database user is called the same obviously.
Which is the hint?
Anyway, e.g. postgresql (which I use) allows for a user mapping (https:
//www.postgresql.org/docs/current/static/auth-username-maps.html) when
using the socket based "peer" auth method.
That basically means I can tell postgresql, if system user "foo"
connects, treat him as postgresql user "bar".
So there is no need for the user names being the same.

This works quite well, partially even under db-config (for some of the
connections it makes)... its just that it still tries to make TCP
connections for whatever reason.


>  (The
> maintainers of icinga believe that the default authentication scheme
> should be password (thus TCP) as can be seen in the config file of
> icinga2-ido-pgsql.
Well not sure what they actually mean or not.
Icinga1/2 both support connecting via UNIX sockets, they just don't
show examples for this in their installation guide.


>  One of my packages (cacti) doesn't even know itself
> how to run via an Unix socket
Sure? Normally most postgresql driver interfaces support both (the only
exception I'd know are the Java drivers),.. usually they just configure
it awkwardly via the host/port config options shared with TCP.


> If you leave the password for the icinga user blank, dbconfig will
> create one for you, as if you are using the password scheme, you need
> a
> password obviously.
Well I've seen that,...

I generally think that's a bad thing, btw,... if the user says don't
set a password, then no password should be set, assuming the user does
security somehow else (e.g. via sockets, which is way more secure than
doing local auth with some password, that can probably be easily brute-
forced).
*If* the user takes care on security already somehow else, the
additional password auth just costs performance on each connection.
On UNIX socket connections, no passwords are examined anyway.
Any on TCP the user may have far more superior stuff in place (some
tunneling via a secure network/VPN/SSH?).


>  Now, when
> I try to install icinga2-ido-pgsql (with normal priority), the
> package
> installs fine. So can you please be more verbose on what you did and
> answered in the TCP case, such that I can reproduce?
Well as I've said I did choose UNIX sockets, and I think I've renamed
the DB from icinga2 to just icinga, but that shouldn't matter.
Also my debconf prio was low.

The error that came was as given in the initial bug report, i.e.
despite me choosing unix sockets, it still tried TCP connections (which
of course didn't work, as I've disabled it in postgresql).


> Please also run "debconf-show icinga2-ido-pgsql" and show us the
> output
> (in the situation where you have the issue).
# debconf-show icinga2-ido-pgsql
  icinga2-ido-pgsql/pgsql/app-pass: (password omitted)
  icinga2-ido-pgsql/password-confirm: (password omitted)
  icinga2-ido-pgsql/app-password-confirm: (password omitted)
  icinga2-ido-pgsql/pgsql/admin-pass: (password omitted)
* icinga2-ido-pgsql/db/app-user: icinga@localhost
  icinga2-ido-pgsql/install-error: abort
  icinga2-ido-pgsql/internal/reconfiguring: false
* icinga2-ido-pgsql/pgsql/authmethod-admin: ident
  icinga2-ido-pgsql/missing-db-package-error: abort
* icinga2-ido-pgsql/pgsql/admin-user: postgres
  icinga2-ido-pgsql/remote/newhost:
  icinga2-ido-pgsql/upgrade-error: abort
  icinga2-ido-pgsql/pgsql/no-empty-passwords:
* icinga2-ido-pgsql/dbconfig-reinstall: false
* icinga2-ido-pgsql/db/dbname: icinga
  icinga2-ido-pgsql/remove-error: abort
  icinga2-ido-pgsql/dbconfig-remove: true
  icinga2-ido-pgsql/pgsql/manualconf:
  icinga2-ido-pgsql/pgsql/changeconf: false
  icinga2-ido-pgsql/passwords-do-not-match:
* icinga2-ido-pgsql/pgsql/method: Unix socket
  icinga2-ido-pgsql/remote/port:
  icinga2-ido-pgsql/purge: false
  icinga2-ido-pgsql/dbconfig-upgrade: true
  icinga2-ido-pgsql/database-type: pgsql
  icinga2-ido-pgsql/remote/host: localhost
  icinga2-ido-pgsql/upgrade-backup: true
* icinga2-ido-pgsql/enable: true
* icinga2-ido-pgsql/dbconfig-install: true
* icinga2-ido-pgsql/pgsql/authmethod-user: ident
  icinga2-ido-pgsql/internal/skip-preseed: false

I should note here that "ident" is the same as "peer" for postgresql
when doing UNIX sockets.


> Also, if you can reproduce the issue
Sure it happens every time.

> , running the installation with
> export dbc_debug=true
> is also very helpful (mind you, you may have to hide your passwords
> before you send the response).
I can do this but it's a bit work-intensive now that the server
basically runs already in production.
Was the information above already enough for you?
If not I can stop the services, make some temp DB for a test and run it
with dbc_debug=true


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to