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.
smime.p7s
Description: S/MIME cryptographic signature