| keithzg | Ah, weekends, time to upgrade personal servers and break them ;) I seem to be stuck on a DigitalOcean droplet I upgraded from 20.04 to 22.04 which now just doesn't bring eth0 up. The netplan config is generated by cloud-init and it sure looks fine to me, just a dead-simple DHCP-based config that really should work, and all the /etc/cloud config files seem the same as my droplets already on 22.04 which are working just fine. And then overriding it with a | 01:24 |
|---|---|---|
| keithzg | static one doesn't work either . . . anyone got any suggestions for things to check or try? | 01:24 |
| tomreyn | anything on the logs? outdated libraries which should have been removed (use apt-forktracer and/or deborphan, review release upgrader log for "Foreign" packages)? | 01:27 |
| tomreyn | which error messages are you encountering, running which command (replace sensitive content by "REDACTED" as needed) | 01:28 |
| keithzg | I don't see any errors in the logs until the point where eth0 is failing to be brought up. Don't have apt-forktracer or deborphan installed apparently, and uhh naturally it is tricky to install those at the moment. I'm not running any commands per se, hell I don't even know what the Netplan equivalent of "ifup" would be because that's not a thing anymore. | 01:33 |
| keithzg | Where would I actually find the release upgrader's log? It didn't even prompt me to consider removing outdated packages at the end of the upgrade IIRC, so I doubt that's the problem, but it seems worth a check anyways. | 01:36 |
| tomreyn | system logs usually go somewhere below /var/log | 01:47 |
| keithzg | gee thanks tips | 01:47 |
| tomreyn | i think there is release-upgrade/ or similar in there | 01:47 |
| tomreyn | you can use the "ip" command to configure interfaces manually | 01:48 |
| tomreyn | from memory, "netplan apply" applies a netplan configuration | 01:48 |
| keithzg | There's no `release-upgrade`, there's an `upgrade` but it only has a telemetry JSON file with some info on the total number of packages downloaded and such. | 01:49 |
| tomreyn | did you use "do-release-upgrade" to carry out the release ugrade, though? | 01:50 |
| keithzg | Yup yup | 01:50 |
| tomreyn | hmm thats unusual, i think | 01:50 |
| keithzg | `netplan test` is an even bigger friend of mine that `netplan apply`, with it I think I've got it working finally, by fully writing out a manual netplan file using a static address (with a few false starts because of YAML's pickiness about spaces-based indentation hah). Still baffled why the cloud-init generated one is bogus, hell I even see lines in the journal where it comes to the right conclusions about what address, gateway, and netmask to use for | 01:52 |
| keithzg | the interface and then . . . the netplan file it actually writes out on every boot is still just a basic DHCP one which isn't working. | 01:52 |
| tomreyn | the current variant of "ifup" is also the "ip" command, "ip link set INTERFACE up", optionally add "-force " after "ip " | 01:52 |
| keithzg | Ahh good point, I think I knew that but had forgotten | 01:52 |
| keithzg | I might have had to do that after running `netplan apply`, because the config I wrote that is now working for me didn't take effect after the apply, needed a reboot. Or perhaps something else somehow changed on that reboot . . . | 01:53 |
| keithzg | Well, apache2 isn't working now but I'm sure I can figure *that* one out, that's some nice old software I already learned enough about to fix config issues in *previous* decades heh | 01:54 |
| keithzg | Ah indeed, it was just an old PHP version that needed to be a2dismod'd | 01:55 |
| tomreyn | glad you worked it out | 02:14 |
| keithzg | Still a bit troubled by cloud-init's failings, but so it goes, automagick has a tendency to go awry . . . | 05:24 |
| === TWPEagle816372 is now known as TWPEagle81637 | ||
| Mmike_ | Hi, not sure what's the best place to ask this, so here goes: | 19:08 |
| Mmike_ | Why is systemd unit for auditd preventing access to home directories? | 19:08 |
| Mmike_ | root@enchilada:~# grep Home /lib/systemd/system/auditd.service | 19:08 |
| Mmike_ | ProtectHome=true | 19:08 |
| Mmike_ | I created an override because I want auditd to track stuff from some user's home dir, but it seems to me this restriction is kind-of pointless? | 19:09 |
| simpoir | Mmike_: If I had to take a wild guess, I'd say that since home dirs tend to contain credentials, user info and other bits that you generally don't want to leak into audit logs. Not knowing what might be in there, preventing auditd from accessing it is likely considered a "good default" to avoid leaking that. As with anything, there can be exceptions. | 19:49 |
| rbasak | Mmike_: FWIW, upstream dropped it recently: https://github.com/linux-audit/audit-userspace/commit/12cf14eda9fadeb7337a44653a80a57456afbb34 | 22:22 |
| -ubottu:#ubuntu-server- Commit 12cf14e in linux-audit/audit-userspace "Drop ProtectHome from auditd.service as it interferes with rules" | 22:22 | |
| rbasak | Ubuntu followed since Lunar (so it's dropped in 24.04 for example) | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!