[02:43] <Beret> å/b 5
[05:49] <bigdaddy63376> My laptop suspended when I closed the lid.  I think a server OS should not do that.  I would like /etc/systemd/logind.conf in the install media to have HandleLidSwitch=ignore
[05:59] <bigdaddy63376> Do I need to do this myself and get access to place a pull request? 
[05:59] <bigdaddy63376> Or is there someone here who knows about the maintainer for the package that contains that file?
[06:05] <mybalzitch> you can edit the file yourself
[07:42] <Maik> bigdaddy63376: i'd go for a raspberry pi 4 and uses that as a server, laptop aren't really made for that.
[07:59] <znf> if you ever manage to find a rpi in stock :)
[13:32] <ahasenack> is there some sort of "who am I" command for the current ubuntu release I'm running?
[13:32] <ahasenack> or should I just parse /etc/os-release?
[13:32] <ahasenack> I didn't want to source that whole file for just one variable
[13:33] <ahasenack> ah, there is lsb_release -cs
[13:38] <jfsimon1981_b> Hi, Could someone let me know how we properly do a subnet with nat ?  I have a lan at 10.0.*.* and i need to create a subnet 192.168.100.* with nat and dhcp for test purposes
[13:38] <jfsimon1981_b> https://pastebin.com/dKFSqUHm
[13:39] <jfsimon1981_b> I crafted a configuration file though it's not yet working, this is the complete file
[13:39] <jfsimon1981_b> Thanks
[14:19] <znf> ahasenack, the preferred and reliable way is to source /etc/os-release
[14:19] <ahasenack> I don't want to potentially "pollute" my shell script with random variables
[14:19] <znf> you're not poluting with "random" variables
[14:20] <ahasenack> well, it's an external file I don't control
[14:20] <znf> but that's the proper and reliable way to determine OS across multiple distributions and linux releases
[14:20] <znf> has been a standard for a few years now
[14:20] <znf> a minimized 22.04 doesn't have lsb_release, AFAIK 
[14:22] <sdeziel> `awk -F= '/^VERSION_CODENAME=/ {print $2}' /etc/os-release` should avoid the pollution
[14:26] <znf> I'm sure the 1kb of memory saved will be appreciated :P
[15:34] <samy1028c> Hello all.  We have a system with exim4 running with custom user:group.  However, every so often (6 or more months) it seems something on this Ubuntu 20.04 FIPS LTS is resetting permissions back to Debian-exim:adm.  Any ideas what to look at?
[15:36] <samy1028c> We updated the cron.daily/exim4 to have the custom user:group when tidydb runs.  However, even if something daily ran, it doesn't explain why after 9 months the permissions reset.
[15:36] <samy1028c> Is there anything in Ubuntu itself that might be causing this?
[15:38] <sdeziel> samy1028c: does the permission/ownership reset happens at the same time the exim4 package is updated?
[15:40] <samy1028c> sdeziel: ahh, actually, I hadn't looked at dpkg.log.  It does show that exim4-base updated at the time exim4 stopped working.
[15:40] <samy1028c> hmm, so a question - how do I get it to not clobber the permissions?
[15:40] <rbasak> https://git.launchpad.net/ubuntu/+source/exim4/tree/debian/exim4-base.postinst?h=applied/ubuntu/focal-devel resets the permissions I think?
[15:40] <rbasak> I'm not sure the packaging supports use of a custom user/group.
[15:41] <samy1028c> so, why did it even update?  We purposefully do not install updates automatically because we have to test through our scripts and such to ensure non-breakage.
[15:42] <rbasak> How have you configured updates not to install automatically?
[15:42] <samy1028c> I run "apt list --upgradeable" and there are a number of items waiting on us to trigger the updates on after regression testing/QA is completed on our dev systems.
[15:43] <samy1028c> What exactly does "install" do in init.d?   ./rc3.d/S01exim4:    install -d -oDebian-exim -gDebian-exim -m750 /run/exim4
[15:43] <samy1028c> rbasak, how can I double-check the automatic updates?
[15:45] <samy1028c> ahh, /etc/apt/apt.conf.d/50unattended-upgrades
[15:46] <rbasak> It's pretty hacky/unsafe to rely on not installing updates to avoid an update from reverting an unsupported configuration change. I'd find another way to solve your problem.
[15:50] <samy1028c> yeah, perhaps a cronjob to check permissions regularly.
[15:50] <samy1028c> We may also review our need for the custom permissions as this may have been required when we first deployed this system on 18.04 several years ago.
[15:50] <rbasak> No, that's just as bad. Stop chasing your tail!
[15:56] <bG9s> I mean restorecon exists to basically check contexts (basically similar to permissions)
[15:57] <bG9s> not a bad idea to make sure permissions and contexts are in order
=== elastic_dog is now known as Guest5195
[17:56] <ahasenack> can somebody see a mistake here? It's like "apt-get update" wasn't run. If I shell into the container, run apt-get update, then try to install those strongswan packages, it works: https://pastebin.ubuntu.com/p/Nx9JwV8gn7/
[18:00] <patdk-lap> you are even running cron inside the container?
[18:00] <patdk-lap> none of mine do, so it would never autoupdate a container
=== blackboxsw_away is now known as blackboxsw
[18:32] <ahasenack> found it, cloud-init was still running in the background and changing sources.list, which invalidated the first apt-get update run
=== lord_black is now known as lord_daemon
[20:45] <sarnold> ahasenack: that feels like it's worth a bug report, perhaps cloud-init ought to be locking the apt frontend lock or something while doing its thing
[20:46] <ahasenack> there is this trick that I have seen other use, and I am using now too:
[20:46] <ahasenack> lxc exec "${container}" -- cloud-init status --wait
[20:47] <sarnold> oh nice. i mean, a bit annoying, but at least there's a thing for that :)
[20:49] <blackboxsw> +1 on that blocking `cloud-init status --wait` trick (sry was afk earlier). But, if one process is running something like ` DEBIAN_FRONTEND=noninteractive apt-get install` shouldn't the apt/dpkg locks be setup already to block other services trying to install pkgs?
[20:49] <ahasenack> that is not the issue
[20:50] <ahasenack> sources.list was rewritten after my first apt-get update
[20:50] <ahasenack> so that invalidated that apt-get update
[20:50] <ahasenack> it was like this
[20:50] <ahasenack> apt-get update
[20:50] <blackboxsw> ahh ok
[20:50] <ahasenack> cloud-init rewrites sources.list
[20:50] <ahasenack> apt-get install <package>
[20:50] <ahasenack> package: not found
[20:50] <blackboxsw> ahh so race on config file update vs final apt-get install
[20:51] <ahasenack> yeah, I was doing "apt-get update && apt-get install package"
[20:51] <ahasenack> but in between, sources.list got rewritten by cloud-init
[20:56] <blackboxsw> yeah, hard to avoid that situation without either providing the directives in #cloud-config specifically via `packages: [package]\npackage_update: true` or by just externally calling cloud-init status --wait (or setting up a systemd service that is `After=cloud-init.target`
[23:38] <k8yun> hello... does anyone have a good tutorial link to setting up postfix in ubuntu? Looking to only send emails out as notification system.
[23:40] <sarnold> k8yun: try https://ubuntu.com/server/docs/mail-postfix
[23:40] <Teridon> ubuntu autoinstall question with cloud-init ssh_keys.  During autoinstall, I see that /etc/ssh/ has the keys I specified in my user-data file.  But after install finishes and reboots, it has new keys.  I do have "ssh_deletekeys: false" in the top level of the user-data.  It's also generating a dsa key, despite the specified "ssh_genkeytypes"   https://dpaste.org/q1dPA  not sure if my PXE boot line is relevant; the "cloud-init-bios
[23:40] <Teridon> " directory has the user-data file  https://dpaste.org/RWVBP
[23:41] <k8yun> thank you. I will go through the link.  I had gone through a few links and all of them did not allow me to send an email out so far but I will give this link a try.
[23:42] <sarnold> k8yun: depending upon where you're hosting your machine, itmight be worth talking with your isp or managing 'security groups' on the machine or whatever
[23:42] <sarnold> k8yun: it's pretty common for smtp to be blocked everywhere to cut down on spam
[23:43] <sarnold> k8yun: .. and also pretty common for smtp recipients to be brutal with RBLs and so on to block mail from dynamic ranges, entire countries, etc
[23:43] <k8yun> I see.  I am not too familiar with how smtp works.  I tried to send to my work email then the `/var/log/mail.log` showed that it was trying to connect to my work domain.  
[23:44] <k8yun> so I think I might need to implement some security measure in the set up so that my work email server recognizes it as a safe sender or something... not sure... I will go through the link provided and find out more I guess
[23:44] <Teridon> related:  if your DNS doesn't have SPF setup you're probably also going to have trouble
[23:46] <Teridon> is this channel archived? if so where?  my VPN is sometimes unstable and I don't want to miss a reply
[23:50] <blackboxsw> Teridon: archive of this channel https://irclogs.ubuntu.com/2022/11/28/%23ubuntu-server.html  it's a few hours behind
[23:50] <Teridon> ty
[23:51] <blackboxsw> Teridon: also autoinstall question. the Ubuntu live installer (server and desktop) actually runs cloud-init in two boot stages. if you provide top-level #cloud-config keys outside of 'autoinstall:' those keys will apply the the ephemeral pre-provisioning environment (not the target installed system after reboot)
[23:52] <blackboxsw> if your keys you pasted are provided below autoinstall:user-data:X,Y,Z then they'll apply to the final installed environment across reboot.
[23:57] <sarnold> blackboxsw: that sounds like a very useful thing to know. do you know if it's written down anywhere? :)
[23:58] <sarnold> aha! it is! it is! though I think I might have overlooked it if I hadn't been looking for it