Re: [systemd-devel] systemd-sysusers and gshadow

2014-07-07 Thread Lennart Poettering
On Sun, 06.07.14 19:17, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Shouldn't systemd-sysusers update /etc/gshadow when adding 'basic' groups? From sysusers.c I don't see that gshadow (and shadow) is updated, and this seems to cause problems on package updates. Consider the

Re: [systemd-devel] systemd-sysusers and gshadow

2014-07-07 Thread Leonid Isaev
Hi, Thanks for the explanation... On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote: I wasn#t aware of grpck, and quite frankly don't think it makes much sense, what the tool is doing. Why? Checking syntax can never hurt... Does it mean that on each update, a

Re: [systemd-devel] systemd-sysusers and gshadow

2014-07-07 Thread Lennart Poettering
On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Thanks for the explanation... On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote: I wasn#t aware of grpck, and quite frankly don't think it makes much sense, what the tool is doing. Why?

Re: [systemd-devel] systemd-sysusers and gshadow

2014-07-07 Thread Leonid Isaev
On Mon, Jul 07, 2014 at 05:40:42PM +0200, Lennart Poettering wrote: On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Thanks for the explanation... On Mon, Jul 07, 2014 at 12:26:03PM +0200, Lennart Poettering wrote: I wasn#t aware of grpck, and quite

Re: [systemd-devel] systemd-sysusers and gshadow

2014-07-07 Thread Lennart Poettering
On Mon, 07.07.14 13:16, Leonid Isaev (lis...@umail.iu.edu) wrote: On Mon, Jul 07, 2014 at 05:40:42PM +0200, Lennart Poettering wrote: On Mon, 07.07.14 11:08, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Thanks for the explanation... On Mon, Jul 07, 2014 at 12:26:03PM

[systemd-devel] systemd-sysusers and gshadow

2014-07-06 Thread Leonid Isaev
Hi, Shouldn't systemd-sysusers update /etc/gshadow when adding 'basic' groups? From sysusers.c I don't see that gshadow (and shadow) is updated, and this seems to cause problems on package updates. Consider the following scenario: 1. A package is updated, so timestamp of /usr gets ahead