On Sun, 16 Jul 2017, Erwan David wrote:
> Le 07/16/17 à 18:32, Don Armstrong a écrit :
> > If you don't care about this in your log, then you can either filter it,
> > or comment out pam_unix in /etc/pam.d/common-session-noninteractive.
>
> Commenting it will remove authentication methods ?
No. Th
On Sun, Jul 16, 2017 at 12:32:22PM +0200, Václav Ovsík wrote:
>...
> With su is /var/log/auth.log flooded too, I didn't noticed
> before :-/ (logcheck was filtering this). So the last chance is probably
> the utility setpriv mentioned in the runuser manpage. Unfortunately the
> utility is in the o
Le 07/16/17 à 18:32, Don Armstrong a écrit :
> On Sun, 16 Jul 2017, Václav Ovsík wrote:
>> On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
>>> OMG, I don't looked into /var/log/auth.log :(
>>>
>>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
>>> user pos
On Sun, 16 Jul 2017, Václav Ovsík wrote:
> On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
> > OMG, I don't looked into /var/log/auth.log :(
> >
> > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
> > user postgres
> > Jul 16 11:57:57 rt2 runuser: pam_unix
On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
> OMG, I don't looked into /var/log/auth.log :(
>
> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
> user postgres
> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for
> user postgre
On Sun, Jul 16, 2017 at 12:32:22AM +0200, Václav Ovsík wrote:
> Bingo! This helped runuser instead of su.
>
> su - $DBUSER -c [...]
> to
> runuser -c [...] $DBUSER
OMG, I don't looked into /var/log/auth.log :(
Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for user
On Fri, Jul 14, 2017 at 05:07:22PM -0500, Don Armstrong wrote:
>...
> This plugin is horribly designed, and runs su - $DBUSER -c [...] for its
> functioning.
>
> It should instead just su $DBUSER -c [...]; or better yet, not actually
> su to the database user, and instead run as a user which only
On Fri, 14 Jul 2017, Jonathan de Boyne Pollard wrote:
> Don Armstrong:
> > Something like this (untested)
>
> When you do test it (-: you will discover the rather drastic
> side-effect on all of the repeated SSH logins of suddenly running them
> in a completely different control group with comple
Am 15.07.2017 um 00:07 schrieb Don Armstrong:
> This plugin is horribly designed, and runs su - $DBUSER -c [...] for its
> functioning.
Indeed.
> It should instead just su $DBUSER -c [...]; or better yet, not actually
> su to the database user, and instead run as a user which only has the
> abili
On Sat, 08 Jul 2017, Václav Ovsík wrote:
> On Fri, Jul 07, 2017 at 10:34:20PM +0200, Michael Biebl wrote:
> >...
> > You create 19 PAM sessions for the postgres user per minute. What
> > exactly are you doing here?
>
> This morning refreshed my mind :)
> I completely forget about monitoring of th
Don Armstrong:
> Something like this (untested)
When you do test it (-: you will discover the rather drastic side-effect on all
of the repeated SSH logins of suddenly running them in a completely different
control group with completely different settings. The systemd PAM hook does
quite a lot of
On Fri, 14 Jul 2017, Jonathan de Boyne Pollard wrote:
> There's no way to actually turn the per-user instance off, for
> accounts that should *never* have per-user service managers.
Something like this (untested) in /etc/pam/common-session would do the
trick:
session [success=2 default=ignore] pa
Václav Ovsík:
> How I should get rid of this session management the right way?
I have seen this systemd problem myself.
What is happening is that every time something SSHes in as user postgres,
systemd-logind is starting up a per-user instance of systemd along with with a
whole bunch of per-user
On Fri, Jul 07, 2017 at 10:34:20PM +0200, Michael Biebl wrote:
>...
> You create 19 PAM sessions for the postgres user per minute. What
> exactly are you doing here?
This morning refreshed my mind :)
I completely forget about monitoring of the host yesterday.
There was installed plugin for Postgre
Am 07.07.2017 um 16:03 schrieb Václav Ovsík:
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4504 of user postgres.
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4505 of user postgres.
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4506 of user postgres.
> Jul 7 15:42:35 rt2 s
Hi,
I'm running Debian server hosting Request Tracker with Postgresql as
database back-end. There is also gnupg-agent & dirmngr installed
(because of SMIME/GPG mail support). Systemd logs about starting user
sessions and Postgresql for some reason starts user sessions internally
frequently. This is
16 matches
Mail list logo
