| === scoobydoo_ is now known as scoobydoo | ||
| === admin07 is now known as admin0 | ||
| === scoobydoo_ is now known as scoobydoo | ||
| === scoobydoo_ is now known as scoobydoo | ||
| Max[m]123456 | Is there a specific reason, why Ubuntu choose to use dracut? | 08:44 |
|---|---|---|
| gcds | 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 |
| gcds | 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:02 |
| gcds | to make changes after each reboot? https://paste.ubuntu.com/p/kPrPBwPQBx/ | 10:03 |
| athos | morning! Could anyone please import php-cache-integration-tests into git ubuntu? :) | 10:15 |
| athos | Cc rbasak sergiodj ^ | 10:16 |
| rbasak | Max[m]123456: Ubuntu doesn't use dracut? | 10:44 |
| rbasak | athos: done | 10:47 |
| athos | rbasak: thanks! | 10:48 |
| Max[m]123456 | <rbasak> "Max: Ubuntu doesn't use dracut?" <- The initrd of the installer sure looks like it does | 10:51 |
| rbasak | Max[m]123456: AIUI Ubuntu uses update-initramfs which isn't dracut. Are you really asking why Ubuntu uses an initramfs at all? | 10:53 |
| Max[m]123456 | 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 |
| Max[m]123456 | I'm just asking about inconsistencies | 11:02 |
| ahasenack | sergiodj: kanashiro hey, are you on debconf-discuss@? Did you see the yubikey email? | 12:41 |
| utkarsh2102 | ahasenack: you need one? :) | 14:21 |
| ahasenack | I expensed one | 14:21 |
| ahasenack | so I'm good | 14:22 |
| ahasenack | but you guys should take the opportunity and get one if possible, and if you are going to debconf | 14:22 |
| utkarsh2102 | yes! | 14:23 |
| utkarsh2102 | I got one in 2019. | 14:23 |
| blackboxsw | hi folks, packaging opinion question for apt purge behavior: for packages whose runtime emits configuration :wq | 16:46 |
| blackboxsw | wow, sorry. will try again | 16:46 |
| patdk-lap | irc isn't vi :) | 16:47 |
| blackboxsw | :) 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:48 |
| rbasak | It depends :-P | 16:49 |
| blackboxsw | 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 |
| rbasak | 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:49 |
| rbasak | 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 |
| blackboxsw | but runtime will decide to dump those conf files into those directories depending on what version of a distro you are running. | 16:50 |
| blackboxsw | 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 |
| rbasak | 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 |
| ahasenack | agreed | 16:51 |
| blackboxsw | These network config artifacts would be known to cloud-init | 16:51 |
| ahasenack | it's not cloud-init configuration, it just was done by cloud-init | 16:51 |
| rbasak | OTOH, if its *presence* is supposed to keep networking going, then removing the package might be expected to remove it. | 16:51 |
| rbasak | So it's a question of which of those two cases fits. | 16:52 |
| blackboxsw | 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 |
| blackboxsw | 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:52 |
| blackboxsw | 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:53 |
| blackboxsw | 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 |
| rbasak | I think it's case-by-case to work out which of these two categories the case fits into. | 16:54 |
| ahasenack | 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:54 |
| rbasak | User expectation of package presence vs. the package as a tool to enact configuration changes. | 16:55 |
| ahasenack | consider .d directories | 16:55 |
| rbasak | For most packages it's package presence, but cloud-init, ua and vim are all special cases. | 16:55 |
| blackboxsw | andreas: `dpkg: warning: while removing netplan.io, directory '/etc/netplan' not empty so - | 16:56 |
| blackboxsw | not removed ` | 16:56 |
| blackboxsw | yeah unexpected config files left around :) | 16:56 |
| ahasenack | was that a purge? | 16:56 |
| blackboxsw | ahasenack: yep | 16:56 |
| ahasenack | but that doesn't break a system | 16:57 |
| ahasenack | removing the netplan config generated by cloud-init just because cloud-init was removed might break the system | 16:57 |
| blackboxsw | 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 |
| ahasenack | this is the exercise to be made | 16:57 |
| rbasak | It's also pretty rare to want to purge cloud-init | 16:59 |
| rbasak | 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 |
| rbasak | So that's a pattern you could use - and maybe default it to the safe option of not deleting those files. | 17:00 |
| rbasak | But I suppose it all depends on why you're asking the question :) | 17:01 |
| sdeziel | 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 |
| blackboxsw | 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:02 |
| blackboxsw | 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:03 |
| sdeziel | blackboxsw: and in those cases, I appreciated the fact that artifacts stayed after the purge ;) | 17:04 |
| blackboxsw | .... 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:23 |
| kanashiro | ahasenack, thanks for the reminder about the yubikey, I just sent an email requesting that | 18:58 |
| ahasenack | \o/ | 18:58 |
| kanashiro | ahasenack, the one you got is Yubikey version 4, USB A ? | 18:59 |
| patdk-lap | I have v4 and v5, really like v5 a lot | 19:00 |
| ahasenack | no, version 5, NFC, usb-c | 19:00 |
| ahasenack | yeah, grab v5 | 19:00 |
| patdk-lap | if you don't need nfc/cellphone usage of it, v4 is fine | 19:00 |
| ahasenack | v4 has no FIDO2 support | 19:00 |
| ahasenack | nfc is not needed, I think there are 5s without nfc | 19:00 |
| patdk-lap | oh? I must have forgot about fido2 | 19:00 |
| ahasenack | fido (1) is supported by 4 | 19:00 |
| ahasenack | here in Brazil the 5C/NFC costed me about €90 | 19:01 |
| patdk-lap | no idea about brazil, but I know india has some insane import taxes around well, importing anything, expecially IT | 19:01 |
| ahasenack | yeah, here it's 60%, including shipping costs | 19:02 |
| ahasenack | so if the key costs, say, U$ 50, and U$ 20 for shipping, amounting to U$ 70, you pay 70*1.6 | 19:03 |
| sarnold | *ouch* | 19:05 |
| andol | https://www.yubico.com/support/shipping-and-buying-information/resellers/ might be an option, in regards to shipping costs, etc. | 19:06 |
| ahasenack | oh, good to know, https://kriptobr.com/ actually has good prices | 19:08 |
| patdk-lap | hmm, that is worse than india, 42% including shipping | 19:09 |
| ahasenack | about the same price I got mine from somewhere else, via amazon.com.br | 19:09 |
| patdk-lap | don't really get why shipping is included, other than the ovious one | 19:09 |
| ahasenack | https://kriptobr.com/produto/yubikey-5cnfc-2fa-fido-fido2/ is the one I got, I paid R$ 464,00 | 19:09 |
| patdk-lap | https://kriptobr.com/produto/yubikey5c/ | 19:10 |
| patdk-lap | the ones I use | 19:10 |
| sergiodj | ahasenack: thanks for the pointer. today's been crazy, but I will send an email about the yubikeys for sure | 21:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!