`/etc/skel` not used for core user in Fedora CoreOS?

Project Discussion
1

I’m basically trying to create a folder on each $HOME folder of any user as seen in this butane configuration:

variant: fcos
version: 1.4.0
...
storage:
  directories:
    - path: /etc/skel/.kcli
      mode: 0775

But the .kcli folder is not created nor for the core user nor for root:

[core@localhost ~]$ sudo ls -la /root/
total 20
drwx------.  2 root root   83 Feb 16 18:30 .
drwxr-xr-x. 24 root root 4096 Feb 16 17:47 ..
-rw-------.  1 root root    7 Feb 16 18:30 .bash_history
-rw-r--r--.  1 root root   18 Feb 16 17:38 .bash_logout
-rw-r--r--.  1 root root  141 Feb 16 17:38 .bash_profile
-rw-r--r--.  1 root root  492 Feb 16 17:38 .bashrc
[core@localhost ~]$ ls -la ${HOME}
total 16
drwx------. 5 core core 124 Feb 16 18:30 .
drwxr-xr-x. 3 root root  18 Feb 16 17:38 ..
-rw-------. 1 core core  12 Feb 16 17:46 .bash_history
-rw-r--r--. 1 core core  18 Feb 15 05:03 .bash_logout
-rw-r--r--. 1 core core 141 Feb 15 05:03 .bash_profile
-rw-r--r--. 1 core core 492 Feb 15 05:03 .bashrc
drwxr-xr-x. 3 core core  17 Feb 16 17:48 .config
drwx------. 3 core core  19 Feb 16 17:48 .local
drwx------. 3 core core  31 Feb 16 17:38 .ssh

[core@localhost ~]$ cat /etc/fedora-release 
Fedora release 35 (Thirty Five)

[core@localhost ~]$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Wed 2022-02-16 17:29:32 UTC)
Deployments:
● fedora:fedora/x86_64/coreos/stable
                   Version: 35.20220131.3.0 (2022-02-15T02:52:38Z)
                BaseCommit: 069a6d0fa20603081a2f1f247832d6d5fd0d99c8d4c169611efa2df6ada82d9e
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
           LayeredPackages: libvirt libvirt-daemon-driver-qemu qemu-kvm tmux vim

  fedora:fedora/x86_64/coreos/stable
                   Version: 35.20220131.3.0 (2022-02-15T02:52:38Z)
                    Commit: 069a6d0fa20603081a2f1f247832d6d5fd0d99c8d4c169611efa2df6ada82d9e
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F

Am I missing something?

Thanks!

1 Like
2

I imagine this is because users are created before files are created during Ignition provisioning.

3

That’s fine, but I guess it is problematic in this case. Can’t those tasks be performed in a different order forcing them somehow?

4

I think it’s likely that we won’t change the ordering because other things depend on it (i.e. trying to lay down files owned by a user; the user needs to be created first so we know the UID) but you can always ask the maintainers over at Issues · coreos/ignition · GitHub

For you for now you’d either need to create the users later in the boot process using a systemd unit, or have Ignition create the files in each user’s home dir that you had Ignition create.

1 Like
5

@dustymabe ,

create the users later in the boot process using a systemd unit

Interesting! Do you have an example?