ignition: not getting correct context on authorized keys file #2
Assignees
Comments
|
Hmm, that should've been fixed by coreos/ignition#613, which made it in 0.28.0. I'll have to take a closer look. |
|
For me Hmm though that one is going to be made by Anaconda right now. |
|
OK, after familiarizing myself with the assembler again, I finally got to the point of testing this... and it works fine here: The big difference is f28 vs f29. Will try again on f28.
Yeah, that's seems correct. If it's not created by Ignition, then it won't know about it and add it to the list of things to relabel. I guess we could just relabel all of |
|
Hmm, no also works on f28: Since the master branch bumped to f29, I used this diff: diff --git a/fedora-coreos-base.yaml b/fedora-coreos-base.yaml
index dcacc3f..8a6ebd3 100644
--- a/fedora-coreos-base.yaml
+++ b/fedora-coreos-base.yaml
@@ -8,8 +8,8 @@ tmp-is-dir: true
# Required by Ignition, and makes the system not compatible with Anaconda
machineid-compat: false
-releasever: 29
-automatic_version_prefix: 29
+releasever: 28
+automatic_version_prefix: 28
repos:
- fedora
- fedora-updates
diff --git a/fedora-coreos.yaml b/fedora-coreos.yaml
index ce035ef..5f7fc0c 100644
--- a/fedora-coreos.yaml
+++ b/fedora-coreos.yaml
@@ -1,9 +1,9 @@
# unified-core compatible
-ref: fedora/29/x86_64/coreos
+ref: fedora/28/x86_64/coreos
include: fedora-coreos-base.yaml
packages:
- - fedora-release-coreos
+ - fedora-release-atomichost
rojig:
license: MIT
diff --git a/fedora.repo b/fedora.repo
index 72ca7f8..6ef6253 100644
--- a/fedora.repo
+++ b/fedora.repo
@@ -6,7 +6,7 @@ enabled=1
#metadata_expire=7d
repo_gpgcheck=0
type=rpm
-gpgcheck=1
+gpgcheck=0
gpgkey=file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
skip_if_unavailable=False
@@ -17,7 +17,7 @@ metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$rele
enabled=1
repo_gpgcheck=0
type=rpm
-gpgcheck=1
+gpgcheck=0
metadata_expire=6h
gpgkey=file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
skip_if_unavailable=False
@@ -27,7 +27,7 @@ name=Fedora $releasever - $basearch - Test Updates
failovermethod=priority
metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f$releasever&arch=$basearch
enabled=1
-gpgcheck=1
+gpgcheck=0
metadata_expire=6h
gpgkey=file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-29-primary
skip_if_unavailable=False |
|
i'll check again on monday |
|
ok. i'm on f29 now and using @cgwalters however the user creation was specified in anaconda kickstart: I also see this when I first boot, which is probably an artifact (bug??) of ignition creating the user instead of anaconda: |
figured it out: https://github.com/cgwalters/fedora-coreos-config/issues/4 |
|
ok #4 is fixed and this is still a problem for me. want to update to latest config and coreos-assembler and see if you can reproduce ? |
|
Sure, let me give it a try. |
|
Yup, looks good here: How exactly do you provision your system? Can you paste your ignition config? |
|
using virt-install - a command like this: with ignition config: the relabel service doesn't mention the authorized_keys file: output from ignition-files.service below: |
|
Hmm, yeah I can reproduce this. At first I thought it was due to what we mentioned above with the I'll have to investigate further. |
|
This one blocks having |
cgwalters
added a commit
to cgwalters/coreos-assembler
that referenced
this issue
Sep 14, 2018
|
Hmm, so surprisingly, it looks like In FCOS: But resolving the link: And the reason I didn't hit this when working on coreos/ignition#569 is that I was testing on RHCOS at the time. Colin did mention it but it was working fine in my tests of course. Anyway, testing a patch now. |
jlebon
added a commit
to jlebon/ignition
that referenced
this issue
Sep 14, 2018
The behaviour of how `restorecon` handles symlinks changed between RHCOS and FCOS. More specifically, `restorecon` will follow symlinks that are part of a given path, but not if the target path is a symlink itself. On OSTree-based systems, `/home` and `/root` are just symlinks, so the newer `restorecon` wasn't actually relabeling anything under there. Add the real paths to the list of dirs to relabel and add `-i` so that it's not a fatal error on non-OSTree-based systems. Closes: coreos/fedora-coreos-config#2
jlebon
added a commit
to jlebon/ignition
that referenced
this issue
Sep 14, 2018
The behaviour of how `restorecon` handles symlinks changed between RHCOS and FCOS. More specifically, `restorecon` will follow symlinks that are part of a given path, but not if the target path is a symlink itself. On OSTree-based systems, `/home` and `/root` are just symlinks, so the newer `restorecon` wasn't actually relabeling anything under there. Add the real paths to the list of dirs to relabel and add `-i` so that it's not a fatal error on non-OSTree-based systems. Closes: coreos/fedora-coreos-config#2
c4rt0
pushed a commit
to c4rt0/fedora-coreos-config
that referenced
this issue
Mar 27, 2023
Make CentOS a build-time option again
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not sure why but ignition doesn't seem to be working with selinux in this repo right now. If I boot the resulting image and set
enforcing=0on the kernel command line in grub I get the system up.I see that ignition-relabel.service ran but it doesn't touch authorized_keys for some reason
and I see the AVC denials
the startup logs from ignition are shown below:
The text was updated successfully, but these errors were encountered: