Open four43 opened 5 months ago
hi @four43
The original AMI works as expected i am assuming. Just when you take a copy to a new AMI? I believe this could be something to do with cloud-init, it doesnt appear to be anything to do with this role specifically. Hopefully someone may have seen similar. If you do find the root cause that comes from the role please let us know and we can see if we can add something for you.
Many thanks
uk-bolly
Yes, it is issue with AMI's
I've spotted this issue in my own build.
@four43, in the role => tasks => section_4 => cis_4.6.x.yml => "4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive | Set umask for /etc/login.defs pam_umask settings", try comment out "/etc/bashrc" from the "loop".
@uk-bolly I don't know what the ultimate root cause is, but excluding that file from the loop allowed me to launch the instance normally. I'm guessing something runs in cloud-init that depends on a loose umask in /etc/bashrc.
This is specifically an issue where there are no problems/errors with the Packer AMI build, but launching an instance from the AMI leads to basic systemd service failures.
hi @herman-wong-cf @four43
Thank you both for the feedback, Having a quick read up it is indeed cloud-init. In order to be compliant that will need to be adjusted, to either skip as you have mentioned or set the permissions back in cloud init and once completed fix it to be compliant.
Its not something that we would change as part of the role. It would be a great article once resolved on how to fix it.
Kindest
uk-bolly
hi @uk-bolly , your script changes the /etc/fstab entry so when creating the AMI it got crashes because of that and @herman-wong-cf the role => tasks => section_4 => cis_4.6.x.yml => "4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive | Set umask for /etc/login.defs pam_umask settings", try comment out "/etc/bashrc" from the "loop". this one is issue as well, after implementing it cloud-init runs successfully.
Describe the Issue
After running the playbook I restart the instance and access it. If I take an AMI of the instance and try and run it again however, it won't start properly.
After running:
I can pull logs from the instance that is failing:
Boot Log
``` [2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01H[0m[35m[40m[2J[01;01H[=3h[2J[01;01H[0m[37m[40m Booting `Amazon Linux (6.1.92-99.174.amzn2023.x86_64) 2023' [ 0.071111] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible! [ 11.677731] kauditd_printk_skb: 37 callbacks suppressed [ 11.677733] audit: type=1305 audit(1718920166.950:71): op=set audit_enabled=1 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:syslogd_t:s0 res=1 [ 11.679489] audit: type=1300 audit(1718920166.950:71): arch=c000003e syscall=46 success=yes exit=60 a0=3 a1=7ffdb7634340 a2=4000 a3=7ffdb76343cc items=0 ppid=1 pid=833 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-journal" exe="/usr/lib/systemd/systemd-journald" subj=system_u:system_r:syslogd_t:s0 key=(null) [ 11.683252] audit: type=1327 audit(1718920166.950:71): proctitle="/usr/lib/systemd/systemd-journald" [ 11.688457] systemd[1]: Started systemd-journald.service - Journal Service. [ 11.691369] audit: type=1130 audit(1718920166.960:72): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 11.746154] systemd-journald[833]: Received client request to flush runtime journal. [ 11.796820] audit: type=1130 audit(1718920167.070:73): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 12.015400] audit: type=1130 audit(1718920167.290:74): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-sysusers comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 12.025959] systemd-journald[833]: Data hash table of /var/log/journal/ec25f52d066115e854db78d38b68bbcc/system.journal has a fill level at 78.5 (1785 of 2275 items, 1310720 file size, 734 bytes per hash table item), suggesting rotation. [ 12.028004] systemd-journald[833]: /var/log/journal/ec25f52d066115e854db78d38b68bbcc/system.journal: Journal header limits reached or header out-of-date, rotating. [ 12.105780] audit: type=1130 audit(1718920167.380:75): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 12.147423] audit: type=1130 audit(1718920167.420:76): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup-dev comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 12.176941] audit: type=1130 audit(1718920167.450:77): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dracut-shutdown comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 12.423940] audit: type=1130 audit(1718920167.700:78): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-machine-id-commit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 13.071902] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 13.112759] ACPI: button: Power Button [PWRF] [ 13.113313] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 [ 13.114258] ACPI: button: Sleep Button [SLPF] [ 13.140928] cryptd: max_cpu_qlen set to 1000 [ 13.142801] pps_core: LinuxPPS API ver. 1 registered [ 13.143429] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo GiomettiExpected Behavior
Instance fully boots without failures
Actual Behavior
See log above in repro steps
Control(s) Affected What controls are being affected by the issue
I have no idea! I was hoping someone here might have an idea of what it nuking those systemd units.
Environment (please complete the following information):
Additional Notes Thanks for any insight or ideas!
Possible Solution Unknown