[00:33] <meena> somebody please unstale this: https://github.com/canonical/cloud-init/pull/2003
[00:33] -ubottu:#cloud-init- Pull 2003 in canonical/cloud-init "move get_ib_* functions to cloudinit.distros.networking" [Open]
[03:37] <holmanb> I gotchu meena
[03:43] <holmanb> meena: re bug 269767: for the title might want to strike mention of LXC and mention instead that lxd is using qemu as the emulator
[03:43] -ubottu:#cloud-init- Bug 269767 in usb-creator (Ubuntu) "Depends: syslinux" [Undecided, Fix Released] https://launchpad.net/bugs/269767
[03:43] <holmanb> bad ubottu
[03:55] <holmanb> I was refering to the freebsd bug, not whatever ubottu dragged up
[06:11] <cpaelzer> holmanb: hehe, bug numbers are techs "They-Who-Must-Not-Be-Named" :-P
[07:07] <meena> holmanb: I got six other FreeBSD VMs running just fine under qemu on that machine
[12:32] <meena> holmanb: https://github.com/freebsd/freebsd-src/pull/664 i got a weak start on a fix, but had no time for testing yet
[12:32] -ubottu:#cloud-init- Pull 664 in freebsd/freebsd-src "apic: prevent divide by zero in CPU frequency init" [Open]
[13:30] <ananke> hah. I spent couple hours beating my head agains the wall trying to figure out why a certain program would run just fine from cron or directly, but it would just exit without a single error when executed from a per-boot script
[13:30] <ananke> come to find out, it expected HOME env variable to exist
[14:21] <meena> ananke: I think somebody in here is working on a cc_env module
[14:23] <meena> https://github.com/canonical/cloud-init/pull/1965#issuecomment-1387581108
[14:23] -ubottu:#cloud-init- Pull 1965 in canonical/cloud-init "add proxy support for ansible galaxy" [Open]
[14:28] <ananke> ohh, that plugin would be nice, since all of our systems are behind proxies, and configuring it everywhere is a bane of my existance
[14:29] <ananke> for this particular issue I'm just going to set HOME locally in the script, but it was such a pain to figure out what was going on. I was saving strace log files trying to find out why it would just exit
[14:30] <ananke> it was xfreerdp client btw
[14:33] <ananke> on the subject of environment variables, they can be such a pain. For example, we've found out that that various distros have limit on the length of variables that pam_env will accept from /etc/environment
[14:33] <ananke> for some distros it was 1024 bytes, for some it was 256
[14:33] <ananke> we found out, because our NO_PROXY is about 1050 bytes
[15:09] <meena> ananke: oooooooooof.
[15:09] <meena> so what happened? did it truncate? or reject?
[15:30] <ananke> meena: it truncates it. 
[15:31] <ananke> I forget which ones truncate to what length, but both debian and ubuntu are affected. 
[15:35] <ananke> it was disappointing to see that, to say the least. we had to pivot from being able to rely on /etc/environment to having additional script in /etc/profile.d/
[15:42] <waldi> i would say, everyone chooses their own problems. maybe reducing the size of NO_PROXY by using wildcards would be a good idea. but what do i know
[15:56] <ananke> waldi: NO_PROXY doesn't support wildcards
[15:57] <ananke> the whole proxy setup via env variables is a huge mess in the linux world. different rules govern no_proxy than http/s/ftp/all_proxy