Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#41310 - [elasticsearch] do NOT use sysusers

Attached to Project: Community Packages
Opened by Dave Reisner (falconindy) - Wednesday, 23 July 2014, 18:57 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Wednesday, 23 July 2014, 21:56 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Massimiliano Torromeo (mtorromeo)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Using sysusers means that you never packages files which are owned by the users you create via sysusers, because the UID will vary between every machine.

Please do not do this. We need to plan something larger (distro-wide) if we're going to go down this road of using sysusers.
This task depends upon

Closed by  Massimiliano Torromeo (mtorromeo)
Wednesday, 23 July 2014, 21:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  elasticsearch-1.3.0-1
Comment by Massimiliano Torromeo (mtorromeo) - Wednesday, 23 July 2014, 19:54 GMT
I'm sorry, I don't understand the issue here. The sysusers config file contains a fixed UID that cannot change between machines (E.g. "u elasticsearch 114") and is in the sub-1000 range generally reserved for system users and unlikely to get in conflict with automatically assigned UIDs.
An install file with a useradd call would have the same effect as far as I understand.

Also, even if I create the user in the install script with useradd, I do not need to package files owned by the elasticsearch user (all files in the package are owned by root:root).
Only the data directory needs those permissions, and other than that the user is used by the systemd service file at runtime.

If there is really an issue with using sysusers or even if it's just a packaging policy I can revert the change but I would still like to understand the reason why.
Comment by Dave Reisner (falconindy) - Wednesday, 23 July 2014, 20:05 GMT
Well, sysusers will never update /etc/shadow or /etc/gshadow, which leads to shadow.service complaining on bootup. None of this is automatic, either, which means you're still fiddling with post install/remove scripts to get this done.
Comment by Massimiliano Torromeo (mtorromeo) - Wednesday, 23 July 2014, 20:16 GMT
Oh, that's weird... but at least now I get it.
Now I wonder why this is the case. Given the fact that sysusers is meant to allow for a stateless system to boot or to be "factory resetted" this behavior seems like a bug because if you can't use it like this it seems pretty useless for everything else.

Other than the shadow files issue, everything else would have been fine though, right?

I will get back to the old way of creating users anyway. Thanks for the explanation!
Comment by Dave Reisner (falconindy) - Wednesday, 23 July 2014, 20:34 GMT
> Other than the shadow files issue, everything else would have been fine though, right?
Well, I believe this to be the case, but there's been a lot of dust kicked up on the systemd-devel ML recently about sysusers and what exactly the scope of it is. I'd really like to see this all settle out before we make any decision to lean on it in Arch. We may decide some day that this is all good and fine and that users who want to worry about shadow's own definitions of "consistency" are on their own.

Loading...