Skip to content
This repository has been archived by the owner on Oct 16, 2020. It is now read-only.

Cannot add user to systemd-journal in ignition #1920

Closed
alanhmogo opened this issue Apr 17, 2017 · 7 comments
Closed

Cannot add user to systemd-journal in ignition #1920

alanhmogo opened this issue Apr 17, 2017 · 7 comments

Comments

@alanhmogo
Copy link

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1367.5.0
VERSION_ID=1367.5.0
BUILD_ID=2017-03-31-0245
PRETTY_NAME="Container Linux by CoreOS 1367.5.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
COREOS_BOARD="amd64-usr"

Environment

ec2 AMI: ami-d1de49b1

Expected Behavior

I am trying to use a unit file as a way to add a user test to systemd-journal in ignition as follows:

systemd:
  units:
    - name: systemd-sysctl.service
      enable: true
    - name: etcd2.service
      enable: true
    - name: fleet.service
      enable: true
    - name: edit-etc-group.service
      enable: true
      contents: |
        [Unit]
        Description=Add systemd-journal group to /etc/group
        ConditionFirstBoot=True

        [Service]
        ExecStart=/usr/bin/sh -c "getent group systemd-journal >> /etc/group"
        ExecStartPost=/usr/sbin/usermod -aG systemd-journal test

Shown below the ignition JSON generated by CT from the above configuration:

{"ignition":{"version":"2.0.0","config":{}},"storage":{},"systemd":{"units":[{"name":"systemd-sysctl.service","enable":true},{"name":"etcd2.service","enable":true},{"name":"fleet.service","enable":true},{"name":"edit-etc-group.service","enable":true,"contents":"[Unit]\nDescription=Add systemd-journal group to /etc/group\nConditionFirstBoot=True\n\n[Service]\nExecStart=/usr/bin/sh -c \"getent group systemd-journal \u003e\u003e /etc/group\"\nExecStartPost=/usr/sbin/usermod -aG systemd-journal test\n"}]},"networkd":{},"passwd":{}}

I am expecting to see the content of the /etc/group to include the group systemd-journal:x:248:core,systemd-journal-upload. See below for expected behavior:

$ cat /etc/group
wheel:x:10:root,core
sudo:x:150:
docker:x:233:core
fleet:x:253:core
rkt:x:251:core
systemd-coredump:x:998:
rkt-admin:x:999:
systemd-journal:x:248:core,systemd-journal-upload     <----- expected to see this -----

**Note1: this is to use the technique recommended in this Google Group https://groups.google.com/forum/#!topic/coreos-user/i6hqzqmlaSc (but as in cloud config)

**Note2: I am already passing this config to CT tool so I can use the generated JSON as user-data to launch the ec2 instance

Actual Behavior

After ec2 instance launched:

$ cat /etc/group
wheel:x:10:root,core
sudo:x:150:
docker:x:233:core
systemd-coredump:x:998:
fleet:x:253:core
rkt-admin:x:999:
rkt:x:251:core

Reproduction Steps

  1. Launch ec2 instance with AMI ami-d1de49b1 and the user-data JSON in this bug report
  2. Once the instance launched, ssh in and then look for the file /etc/group and not find the group systemd-journal:x:248:core,systemd-journal-upload in the file.

Other Information

This workaround of adding a user to systemd-journal was proven to be working using the cloud config in the following format:

  #cloud-config

  hostname: coreOS-cloud-config
  coreos:
    units:
      - name: systemd-sysctl.service
        command: restart
      - name: etcd2.service
        command: start
      - name: fleet.service
        command: start
      - name: "edit-etc-group.service"
        command: "start"
        content: |
          [Unit]
          Description=Add systemd-journal group to /etc/group
          ConditionFirstBoot=True

          [Service]
          ExecStart=/usr/bin/sh -c "getent  group systemd-journal >> /etc/group"
          ExecStartPost=/usr/sbin/usermod -aG systemd-journal test

Environment

This is an ec2 t2.micro HVM machine

@crawford
Copy link
Contributor

This is a duplicate of #1267 but is formatted nicer. I'm closing out the original in favor of this.

@cgonyeo
Copy link

cgonyeo commented Apr 17, 2017

I responded to you over email, copy/pasting my reply here in case others find this in the future:

I think your issue is that the systemd unit needs to have an [Install] section to be able to work properly.

I was able to test this container linux config successfully: https://gist.github.com/dgonyeo/55803e0526707c00571c9a0a5f8369cf

Can you see if adding that section to your unit fixes the problem?

@alanhmogo
Copy link
Author

Thanks so much @dgonyeo this is proven to be working after I added the [Install] in the unit file
ie.

         [Unit]
         Description=Add systemd-journal group to /etc/group
         ConditionFirstBoot=True

         [Service]
         ExecStart=/usr/bin/sh -c "getent  group systemd-journal >> /etc/group"
         ExecStartPost=/usr/sbin/usermod -aG systemd-journal test
       
         [Install]
         RequiredBy=multi-user.target

All good!

@cgonyeo
Copy link

cgonyeo commented May 18, 2017

Two PRs were just merged that changes the OS to allow ignition to easily modify things like groups:
coreos/bootengine#113
coreos/baselayout#64

You should now be able to add test to systemd-journald with the following config (pending an Ignition release and the OS changes working their way down):

{
  "ignition": { "version": "2.1.0-experimental" },
  "passwd": {
    "users": [
      {
        "name": "systemUser",
        "groups": ["systemd-journald"]
      }
    ]
  }
}

@cgonyeo cgonyeo closed this as completed May 18, 2017
@alanhmogo
Copy link
Author

Thanks @dgonyeo !

@bgilbert
Copy link
Contributor

We're dropping this from the upcoming alpha while we dig into some problems. Reopening.

@bgilbert bgilbert reopened this May 24, 2017
@bgilbert bgilbert assigned bgilbert and unassigned cgonyeo Jun 27, 2017
@bgilbert bgilbert removed their assignment May 24, 2018
@bgilbert
Copy link
Contributor

Thank you for reporting this issue. Unfortunately, we don't think we'll end up addressing it in Container Linux.

We're now working on Fedora CoreOS, the successor to Container Linux, and we expect most major development to occur there instead. Meanwhile, Container Linux will be fully maintained into 2020 but won't see many new features. We appreciate your taking the time to report this issue and we're sorry that we won't be able to address it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants