[10:42] <TJ-> I have a long-running Linux VM that gets its IPv6 via SLAAC, but after the first successful allocation it seems to expire and not be renewed, losing connectivity. I've tracked it down to the kernel's net.ipv6.conf.eth0.autoconf being set to 0 - but cannot find anything configured to change that. Anyone have any ideas on what might be doing it? This is Ubuntu 18.04 using ifupdown (not
[10:42] <TJ-> systemd-networkd)
[11:06] <tomreyn> the "suddenly after the system booted and ran fine for a while, network configuration changed" symptom reminds me of earlier reports on cloud-init, but that'S the only thing i could think of. and i'm not sure this sounds related to what you're seeing.
[11:28] <Skyrider> What's the best way to upgrade sudo from 1.8 to 1.9?
[11:31] <andol> Carefully :-)
[11:32] <andol> Looks like there are sudo 1.9 packages for Ubuntu 20.10.
[11:33] <andol> If you really need sudo 1.9 for your current Ubuntu release I suggest you rebuild those, and try them out in a test environment.
[11:33] <Skyrider> I recall upgrading sudo weeks ago in my lxc container. Forgot how to though :D
[11:34] <andol> Curious, what's the draw of sudo 1.9?
[11:35] <Skyrider> sudo: setrlimit(RLIMIT_CORE): Operation not permitted <- having this bug fixed in containers.
[11:35] <Skyrider> https://github.com/sudo-project/sudo/issues/42
[11:35] <andol> Ah.
[11:35] <Skyrider> Odd ubuntu 20 comes with a legacy release of sudo though.
[11:36] <andol> Nitpick: There is no such thing as Ubuntu 20.
[11:36] <andol> Ubuntu 20.04 is just as close to 19.10 as it is to Ubuntu 20.10.
[11:37] <Skyrider> I tried looking for 1.9 in the cache policy, but only 1.8 pops up.
[11:38] <andol> Also, looks like sudo 1.9 was released after Ubuntu 20.04 came out.
[11:38] <Skyrider> Guess that makes more sense then ^_^
[11:39] <andol> Anyway, if this is only for a container, rather than for a bare metal host, everything ought to be a lot easier and safer.
[11:40] <andol> Might just as well try grabbing the Ubuntu 20.10 sudo 1.9 binary package(s), and see what happens if you try to install them directly.
[11:42] <Skyrider> I attempted to grab the deb packages, but its attempting to remove my existing sudo.
[11:42] <Skyrider> Which leads to errors "Refusing to remove sudo"
[11:48] <andol> Interesting.
[11:48] <andol> Worked fine for me in an Ubuntu 20.04 VM. https://paste.ubuntu.com/p/FgQyQ7JKwd/
[11:52] <Skyrider> Oddly enough running it a second time works. O_o
[11:52] <Skyrider> Though, its complaining about libpython3.6, not installed. for sudo-ldap and sudo-python.
[11:54] <tomreyn> mixing packages from different ubuntu releases is generally not advisable (exceptions may apply, but that's unsupported then)
[11:54] <Skyrider> I merely grabbed the "sudo-python_1.9.0-1_ubu1804_amd64.deb" file as well, which depends on python3.6
[11:54] <tomreyn> i'd certainly not recommend doing this for the purpose of snoozing a warning message
[11:55] <albert23> Skyrider: did you see there is a very simple solution? echo "Set disable_coredump false" >> /etc/sudo.conf
[11:56] <Skyrider> I actually had no idea ^_^, I merely saw it was resolved in  1.9 of sudo
[11:56] <tomreyn> noticing this would have involved reading more than the first two posts of the bug report
[11:57] <Skyrider> Guess it is because I merely expected for upgrades to latest versions in combination of ubuntu 20 being new as well would be simple.
[11:57] <andol> Skyrider: That sudo-python package doesn't look like it's from the official repositories?
[11:58] <Skyrider> Ya, guess that's my fault for relying on a third party site ^^
[12:17] <TJ-> tomreyn: turned out to be my bad - ifupdown config for IPv6 - if you do not specifically add "autoconf 1" to *every* IPv6 static stanza the tooling sets it to 0 (disabling SLAAC) and we have about 15 static assignments to the same interface and only the first set "autoconf 1"
[12:20] <tomreyn> TJ-: hmm, maybe that's a good reason to do away with ifupdown then indeed.
[12:20] <TJ-> yeah... this is a system that has evolved continuosly since 2007
[12:20]  * tomreyn shudders
[12:21] <TJ-> the problem was the uncommanded "autoconf=0" for the interface
[12:21] <TJ-> at least with ifup --no-act --verbose --force I was able to see it issuing the commands - can't do that with systemd-networkd!
[12:23] <tomreyn> i agree that debugging isn't as easy with many parts of systemd as it should be
[12:24] <tomreyn> (or i lack understanding of how to do it properly)
[12:25] <TJ-> no way to manage active state of sd-nd at present that I'm aware of
[12:26] <tomreyn> hmm, i don't think i ever tried
[12:29] <TJ-> you have to edit the text config files and restart the service
[12:30] <tomreyn> hmm, that's a bit unexpected, a deviation from the behaviour of other service units.
[12:31] <tomreyn> but then i guess networking is somewhat ffoundational and you don't want to accidentially disable it, if that's the perspective where this came from.
[12:31] <tds> i quite like ifupdown2 as an ifupdown alternative
[12:32] <tds> being able to properly diff the running state against config, and only apply changes as needed, is very nice
[12:34] <trippeh> the latest sd-nd has up/down per interface, but you may still need to reload (havent tested it extensively)
[12:35] <TJ-> now I'm fighting with the obtuse openwrt method of configuring multiple interfaces to get IPv6 PD working correctly
[12:35] <trippeh> yeah you just define a wan6 pointing to the same interface/bridge
[12:38] <TJ-> trippeh: unfortunately not in this case; the WAN side is fine and I've just got the LAN side (via Luci) to look correct, clients are seeing PDs and using SLAAC too, but the routing is going astray somehow, or firewall isn't being correctly set. Unusual situation in that I've a /48 PD but the upstream router from me has taken an address from within the PD range so I've had to put a /126 on
[12:38] <TJ-> the WAN6
[12:39] <trippeh> I have DHCPv6-PD working with openwrt, and systemd-networkd at home.
[12:41] <trippeh> the PD support in sd-nd has become quite serviceable in 246
[12:42] <trippeh> TJ-: thats a little weird indeed - but can you just not assign the /64 upstream is in on the downstreams?
[12:44] <TJ-> trippeh: well, the upstream router is on PD::1/48
[12:45] <trippeh> as in /48 "on link"??
[12:45] <TJ-> trippeh: yes
[12:46] <trippeh> are you sure. are they drunk
[12:46] <RoyK> Generally you don't segment to lower than /64
[12:47] <RoyK> But that only gives you 65536 networks on a 48-bit prefix, which can possibly be a hassle? ;)
[12:51] <TJ-> RoyK: it definitely is for our use-case !
[12:53] <RoyK> TJ-: erm - what usecase is that?
[12:56] <TJ-> RoyK: addressing every star in the universe :)
[12:57] <RoyK> TJ-: something like this? https://xkcd.com/865/
[13:01] <TJ-> RoyK: not far off :)
[13:02] <RoyK> TJ-: but seriously - what are you trying to do here?
[13:03] <TJ-> ^^^ read above ^^^
[13:06] <trippeh> if the upstream router has /48 on-link, and then needs to install the same /48 route to your openwrt, what does it do?
[13:06] <trippeh> does it become a ECMP route?
[13:07] <trippeh> this setup sounds borked
[13:08] <RoyK> TJ-: if using openwrt, how large will this routing table become if you do it your way? I *really* doubt your router will be able to handle that
[13:08] <TJ-> RoyK: one entry in the table
[13:08] <TJ-> the /48
[13:09] <RoyK> but what's the point of all those networks???
[13:12] <RoyK> btw, I was thinking more of the internal routing tables - one entry for each network - it'll be a rather nasty job for a small cpu
[13:17] <trippeh> I am rather confused. :)
[13:17] <RoyK> aren't we all?
[17:57] <znf> Here's something I've been beating my head around. I need to install a HWE kernel on 18.04; thing is, last time I did this, the server wouldn't come back online -- it booted, but something happened to it's networking.
[17:57] <znf> What that was? I've no idea.
[17:57] <znf> The thing is - I've got no IPMI/IKVM on this. How can I reboot into the new kernel and then reboot back to the old one if something happens? What's a good failsafe?
[18:01] <tds> znf: can you powercycle the machine remotely?
[18:01] <znf> no
[18:01] <znf> I was thinking I could simply make a script reboot automatically in ~5 minutes unless killed
[18:02] <znf> but I'm drawing a blank on how to make it choose the old kernel back
[18:04] <tds> i suppose you could have the script just reconfigure grub, though that's a bit nasty
[18:05] <znf> and my friend is not to keen on driving there and going on top of a 13 story building with a keyboard and monitor to fix it, understandably
[18:06] <tomreyn> there's a single good answer to such scenarios: wait until you can do it safely.
[18:07] <tomreyn> that's unless it's not a production system and you don't mind loosing it for days or weeks until someone passes by.
[18:08] <znf> eh, it's a box with the only purpose of capturing DVB-S (hence why it's on top of the building)
[18:09] <znf> and I just need the newer kernel to enable a newer intel video driver so I can use quicksync
[18:10] <tomreyn> from what i read it was 'just' that last time, too.
[18:11] <tomreyn> 'just' a differently configured reboot ;)
[18:12] <znf> I mean it's not that important :P
[18:14] <tomreyn> there's grub-reboot for this scenario you have, but i haven't used it in a while, so i'm not certain this still works reliably. maybe soemone else can comment.
[18:21] <znf> I see
[18:21] <znf> that's interesting, but it doesn't really say how the hell to get a picture of the actual MENU_ENTRY number
[18:24] <tomreyn> yes, we lack a utility for this. but i *think* this gives it away:   grep -o "menuentry '[^']*.*" /boot/grub/grub.cfg | awk -F "'" '{print $2":\n\t"$4}'
[18:24] <tomreyn> start counting at 0
[18:28] <znf> the confusing part is the submenu stuff
[18:28] <znf> Ubuntu does it in submenus
[18:29] <znf> The titles should be separated using the greater-than character (>) with no extra spaces.  Depending  on  your  shell  some  characters
[18:29] <znf>        including > may need escaping.
[18:29] <znf> granted, I could also do "Ubuntu, with Linux 4.15.0-99-generic"... probably
[18:48] <tomreyn> right, the submenus are a bit tricky and error prone
[18:51] <tomreyn> https://unix.stackexchange.com/questions/62733/how-to-correctly-set-up-the-right-grub-2-default-menu-entry
[18:54] <tomreyn> so, since the "Advanced" menu is usually the second entry on the main menu, you start with "1" (remember, it's an index, start couting at 0), then you add ">" to indicate there's a submenu, and from the submenu you pick the very entry, again starting to count at 0
[19:12] <xae-a12> Any1 here have experience blocking fake harmful bots?
[19:14] <tomreyn> xae-a12: why, do you live in seattle? build thicker walls, i'd say.
[19:14] <xae-a12> no i thankfully do not lol
[19:15] <tomreyn> but maybe you weren't referring to pysical bots after all, and i just jumped to conclusions for lack of detail?
[22:02] <SpaceBass> Hey folks - I'm trying to debug a problem with LDAP authentication. Does anyone know if it is possible to get verbose output or logs in Ubuntu for libnss_ldap ? ... the config file supports a logging option but it's not clear that the ubuntu client supports it