=== scoobydoo_ is now known as scoobydoo === admin07 is now known as admin0 === scoobydoo_ is now known as scoobydoo === scoobydoo_ is now known as scoobydoo [08:44] Is there a specific reason, why Ubuntu choose to use dracut? [10:02] Hi, maybe someone could help me with ubuntu server netplan stuff, I am going bald from trying to figure out what is wrong. Context: I have network 10.93.0.0/16 the server has a bridge with one interface and static IP address of 10.93.2.2/16, everything generates and works but for some reason I can't access anything higher than 10.93.127.254, I [10:02] tried adding a static route for 10.93.0.0/16 via 10.93.0.1 but didn't help, but then I removed default generated route which looked suspicious to me (the 10.93.0.0/16 via 10.93.2.2 in the paste) and it worked then, I would consider it's done but I know it's not permanent so maybe can help me figure out whats wrong with netplan so I would not need [10:03] to make changes after each reboot? https://paste.ubuntu.com/p/kPrPBwPQBx/ [10:15] morning! Could anyone please import php-cache-integration-tests into git ubuntu? :) [10:16] Cc rbasak sergiodj ^ [10:44] Max[m]123456: Ubuntu doesn't use dracut? [10:47] athos: done [10:48] rbasak: thanks! [10:51] "Max: Ubuntu doesn't use dracut?" <- The initrd of the installer sure looks like it does [10:53] Max[m]123456: AIUI Ubuntu uses update-initramfs which isn't dracut. Are you really asking why Ubuntu uses an initramfs at all? [11:02] Well, I know it needs to use one. But what I see inside the installer does not look similar to the initramfs, Ubuntu creates after the installation. [11:02] I'm just asking about inconsistencies [12:41] sergiodj: kanashiro hey, are you on debconf-discuss@? Did you see the yubikey email? [14:21] ahasenack: you need one? :) [14:21] I expensed one [14:22] so I'm good [14:22] but you guys should take the opportunity and get one if possible, and if you are going to debconf [14:23] yes! [14:23] I got one in 2019. [16:46] hi folks, packaging opinion question for apt purge behavior: for packages whose runtime emits configuration :wq [16:46] wow, sorry. will try again [16:47] irc isn't vi :) [16:48] :) hi folks, packaging opinion for apt purge behavior: for packages where the runtime emits unpackaged config files into other service config directories, should apt purge remove these runtime artifacts or leave the vestigial config content around? [16:49] It depends :-P [16:49] I ask as cloud-init emits network configuration potentially into /etc/netplan or /etc/network/interfaces.* parts directories which it doesn't package itself. [16:49] As an extreme example, consider vi. I use it to adjust system configuration in /etc, and when (if!) I purge vi, I don't expect those changes to be reverted. [16:50] So assuming you're asking about ua, similarly if the user asks ua to make a system change, I'd expect the change to remain after it is purged, I think. Where that makes sense under the circumstances. [16:50] but runtime will decide to dump those conf files into those directories depending on what version of a distro you are running. [16:51] in the event that someone wants to purge cloud-init, should the cloud-init package care about augemented configuration that dynamically got created by the initial runtime. [16:51] Right, so for cloud-init, I think it's much the same. Its task is to set up networking, and so perhaps the networking it set up should remain if it's gone. [16:51] agreed [16:51] These network config artifacts would be known to cloud-init [16:51] it's not cloud-init configuration, it just was done by cloud-init [16:51] OTOH, if its *presence* is supposed to keep networking going, then removing the package might be expected to remove it. [16:52] So it's a question of which of those two cases fits. [16:52] ahasenack: right. it's an artifact of cloud-init running. it's not a static config file that cloud-init delivers in the cloud-init.dev [16:52] ahasenack: right. it's an artifact of cloud-init running. it's not a static config file that cloud-init delivers in the cloud-init.deb [16:53] and right, I'm concerned in this particular case that removing such a config file could lead to unexpected results if someone restarts the network service after the purge [16:54] But it just raised a general quesiton in my mind: should a deb package that emits config content to other services generally cleanup anything it knows it could have emitted? And I guess the answer is case-by-case [16:54] I think it's case-by-case to work out which of these two categories the case fits into. [16:54] here is another consideration: if that other package (that got its config from cloud-init) is removed, will it remove this config file that cloud-init emitted? [16:55] User expectation of package presence vs. the package as a tool to enact configuration changes. [16:55] consider .d directories [16:55] For most packages it's package presence, but cloud-init, ua and vim are all special cases. [16:56] andreas: `dpkg: warning: while removing netplan.io, directory '/etc/netplan' not empty so - [16:56] not removed ` [16:56] yeah unexpected config files left around :) [16:56] was that a purge? [16:56] ahasenack: yep [16:57] but that doesn't break a system [16:57] removing the netplan config generated by cloud-init just because cloud-init was removed might break the system [16:57] rbasak: and right cloud-init is a tool to provide config changes. the use-case for using it, and then purging it is "interesting" to say the least [16:57] this is the exercise to be made [16:59] It's also pretty rare to want to purge cloud-init [17:00] I have seen some packages debconf prompt at purge time to ask the question if associated data (eg. in /var) should be deleted also. [17:00] So that's a pattern you could use - and maybe default it to the safe option of not deleting those files. [17:01] But I suppose it all depends on why you're asking the question :) [17:02] I've often purged cloud-init... I was being lazy and wanted my edits to files created by cloud-init to persist through reboots without having cloud-init resetting them [17:02] Right, my thoughts are I don't want cloud-init to do this by default because it's risky from the standpoint of someone using a system, and purging cloud-init, and expecting it to keep working. The removal of something as critical as the current network configuration is more likely to lead people down a path than leaving it in place. [17:03] sdeziel: ok that is a good perspective to have here, thanks. As someone can certainly be sure if cloud-init is purged it's not going to do anything funky on later boots. [17:04] blackboxsw: and in those cases, I appreciated the fact that artifacts stayed after the purge ;) [18:23] .... and it's hard to discover the `sudo touch /etc/cloud/cloud-init.disabled` or other mechanisms to disable cloud-init across reboots. So someone would certainly be sure if cloud-init was no longer there. [18:58] ahasenack, thanks for the reminder about the yubikey, I just sent an email requesting that [18:58] \o/ [18:59] ahasenack, the one you got is Yubikey version 4, USB A ? [19:00] I have v4 and v5, really like v5 a lot [19:00] no, version 5, NFC, usb-c [19:00] yeah, grab v5 [19:00] if you don't need nfc/cellphone usage of it, v4 is fine [19:00] v4 has no FIDO2 support [19:00] nfc is not needed, I think there are 5s without nfc [19:00] oh? I must have forgot about fido2 [19:00] fido (1) is supported by 4 [19:01] here in Brazil the 5C/NFC costed me about €90 [19:01] no idea about brazil, but I know india has some insane import taxes around well, importing anything, expecially IT [19:02] yeah, here it's 60%, including shipping costs [19:03] so if the key costs, say, U$ 50, and U$ 20 for shipping, amounting to U$ 70, you pay 70*1.6 [19:05] *ouch* [19:06] https://www.yubico.com/support/shipping-and-buying-information/resellers/ might be an option, in regards to shipping costs, etc. [19:08] oh, good to know, https://kriptobr.com/ actually has good prices [19:09] hmm, that is worse than india, 42% including shipping [19:09] about the same price I got mine from somewhere else, via amazon.com.br [19:09] don't really get why shipping is included, other than the ovious one [19:09] https://kriptobr.com/produto/yubikey-5cnfc-2fa-fido-fido2/ is the one I got, I paid R$ 464,00 [19:10] https://kriptobr.com/produto/yubikey5c/ [19:10] the ones I use [21:10] ahasenack: thanks for the pointer. today's been crazy, but I will send an email about the yubikeys for sure