Specifying group "systemd-journal" in cloud-init doesn't work #312
Comments
|
I think I may be mistaken here, I'll reopen if I can reproduce. Apologies for the noise. |
|
I can reproduce this, and @mischief was able to reproduce on the latest image. |
|
Notes:
|
|
i can't successfully add systemd-journal to the user's groups with useradd. the command that is constructed based on your cloud-config is: |
|
Works for me, starting with no log user existing ( |
|
Oops, fat-fingered close, sorry. |
|
This has been a known problem ever since we introduced images with the current disk layout. Each of the different shadow utils behaves a little differently here: some will silently ignore users/groups that exist on the systemd (provided by some nss module) but do not appear in the /etc files while others will fail. In no case do the tools copy the information into /etc in order to modify it. The assumption being that groups not in /etc are provided by something like LDAP so the local system shouldn't have control over them. The mixes of behavior, particularly the silent ignoring, turns that assumption into a whole series of surprises though. CoreOS provides most system users and groups in /usr/share/baselayout/ to allow changes between versions to happen seamlessly without needing some special tool to merge/update the /etc files during upgrades. /etc is under the control of the user so system updates shouldn't muck with it whenever possible. To work around the awkwardness of the situation we do copy a couple things to /etc like the 'core' user and the 'docker' group but avoided doing everything. Since that scheme was implemented a year ago systemd has actually written a tool specifically for safely updating the passwd/group databases in /etc during system upgrades. Switching to this scheme and removing the nss module that reads from /usr/share/baselayout will get systems working in the way users expect but we haven't gotten around to making the switch. |
|
Is there any way to (manually) add a user to the $ usermod -aG systemd-journal me
$ groups me
# => sudo docker me |
|
Any workarounds for this? |
|
Switching to sysusers.d should partly solve the issue. But sysusers.d is developed (surprise) for system users and it doesn't allow to set additional options (shell, etc.) |
|
For reference this script copies some users/groups from /usr to /etc so that they can be modified, in lieu of moving to sysusers.d systemd-journal will need to be added to this list. https://github.com/coreos/baselayout/blob/master/scripts/coreos-tmpfiles |
|
@marineam I already modified this script, but you didn't accept related changes. coreos/baselayout#37 |
|
@kayrus As mentioned in coreos/baselayout#37 that change doesn't look quite right to me, safely updating existing files needs to be a bit fancier. I may have misread it though. Adding things to /etc during updates is independent of what lands in /etc on first boot though, we can easily add more groups so new systems can easily modify systemd-journal and so on. |
|
any updates? Trying to Add systemd-journal to an account that exists. |
3dt needs to read the journal. In order to do that it needs to be in systemd-journal group. The issue is that coreos uses several backends for users and groups. One is a regular /etc/passwd, /etc/groups and the other is located under /usr/share/baselayout. If we try to append dcos_3dt user with flag -G this will not work. (Tested on CoreOS beta (1068.3.0)) This seems to be a long running issue with CoreOS coreos/bugs#312 However if we try to change a user's primary group with -g flag all works as expected. This is not meant to be merged, used for testing at this point.
3dt needs to read the journal. In order to do that it needs to be in systemd-journal group. The issue is that coreos uses several backends for users and groups. One is a regular /etc/passwd, /etc/groups and the other is located under /usr/share/baselayout. If we try to append dcos_3dt user with flag -G this will not work. (Tested on CoreOS beta (1068.3.0)) This seems to be a long running issue with CoreOS coreos/bugs#312 However if we try to change a user's primary group with -g flag all works as expected. This is not meant to be merged, used for testing at this point.
3dt needs to read the journal. In order to do that it needs to be in systemd-journal group. The issue is that coreos uses several backends for users and groups. One is a regular /etc/passwd, /etc/groups and the other is located under /usr/share/baselayout. If we try to append dcos_3dt user with flag -G this will not work. (Tested on CoreOS beta (1068.3.0)) This seems to be a long running issue with CoreOS coreos/bugs#312 However if we try to change a user's primary group with -g flag all works as expected.
|
Is there any update regarding this issue ? |
|
Unfortunately, no updates. I can tell you though that it is very unlikely that we will be fixing this for coreos-cloudinit. We've been investing in Ignition, the successor to coreos-cloudinit, which greatly simplifies configuration while drastically increasing the breadth of what can be configured. I'm going to close this out in favor of #1267. |
|
Oh yeah! . We can also use ignition for this 👍. Thanks @crawford |
|
@hectorj2f as far as I can tell, ignition doesn't yet solve this, or? |
I've got a system service and I want it to be able to read the systemd logs. To do that, it needs to be in the
systemd-journalgroup. However, specifying it under "groups" has no effect. Groups works, but not for this system group.Is it possible to make this work?
The text was updated successfully, but these errors were encountered: