[06:34] Good morning === cpaelzer__ is now known as cpaelzer [10:58] hello, looking through this guide: https://help.ubuntu.com/lts/serverguide/network-configuration.html.en It mentioned for setting temporary ip addresses that a name server could be configured in /etc/resolv.conf. Of course out of curiosity I looked at my existing copy of that file just to see what is in it, it has the statement "nameserver 127.0.0.53". The system is currently using [10:58] an Address from my dhcp server and I know that 127.x.x.x is not routable. My Gateway router should have given it a differnet address. What gives? Does this have something to do with having IPv6 too? [11:06] never mind, I don't read comments === waveform_ is now known as waveform [12:12] teward: sorry, tls 1.3 nginx? I'm out of the loop [12:35] Heya, I am trying to install Ubuntu server 16.04 32 bit on a very old machine: Pentium 4 2.8 ghz with 1.5GB ram booting from a USB stick. Booting works, but when I press "Install Ubuntu Server" the screen freezes and I can't do anything. [12:52] how long did you wait to determine if it was frozen? [12:58] Hi. I'm running ubuntu-18.04 guest on Hyper-V server using linux-azure kernel. My apt-get dist-upgrade hangs where I am unable to upgrade systemd and udev. Aborting and trying to repeating with 'dpkg --configure -a' resumes the hang. The kernel reports 'INFO: task xyz:2773 blocked for more than 120 seconds", where xyz is various services, like systemd or udev or network. Which is probably why the [12:58] upgrade fails. [12:58] The kernel is probably not good, but is it safe to reboot at this point? Being in the middle of an upgrade? What is the approach for this? [13:03] I would reboot into an older kernel [13:12] rbasak: 15:01:55> ahasenack: it seems bit odd to me to do it in the preinst. What if the package version is just removed - shouldn't it also get removed then in that case? [13:12] rbasak: the new package doesn't have the cache file anymore, so there is nothing to remove upon uninstallation [13:13] heh, what is the point of the stop job timer when the timeout is ever increasing? It's like a progress bar saying "Wait a little bit" and then "oh, wait some more" [13:13] rbasak: the old package did remove the cache file in postrm [13:13] if it was a purge [13:13] ahasenack: ah - that sounds right then [13:17] Anyone else here that have any experience with the linux-azure kernels for production use? [13:34] i think it was a mishighlight [13:35] ahhh yes my bad i read the first name of a user not the last [13:35] rbasak: mind if I pick your brain? [13:36] Sure [13:36] rbasak: see PMs [13:37] error: tired. [13:37] two questions: (1) for a no changes rebuild in -proposed against the newer libssl in proposed what's the version string notation? (2) Does it make sense for TLS 1.3 and NGINX to version-depend on a minimum supported libssl-dev to ensure TLS 1.3 is available in it? [13:37] rbasak: ^ [13:38] FYI all, me without coffee in the mornings is a little crazy :/ [13:38] *goes to find some* [13:38] what should I use to configure network interfaces and have the settings presist after a reboot? [13:38] I think for a no change rebuild in the development release that already has a -XubuntuY we just bump the Y. [13:38] Mead: create a yaml file for netplan [13:38] rbasak: this is bionic-proposed [13:38] So the same as a regular SRU would be fine I think. [13:38] that's the problem [13:38] ah [13:38] that makes sense, [13:39] The only useful thing about using build1 is that it doesn't block autosync [13:39] I think a versioned build depends only makes sense when it's _required_ for the build to use that version (ie. will fail or be buggy if the version is older) [13:40] We don't usually for example update versioned dependencies in build deps when we do a transition [13:41] makes sense. the only reason I ask is because TLS1.3 requires a specific version of OpenSSL or newer... *shrugs* [13:41] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386 led to https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1823476 apparently. [13:41] Launchpad bug 1797386 in openssl (Ubuntu) "[SRU] OpenSSL 1.1.1 to 18.04 LTS" [Undecided,In progress] [13:41] Launchpad bug 1823476 in nginx (Ubuntu Bionic) "Rebuild with OpenSSL 1.1.1" [Wishlist,In progress] [13:41] Therefore I think it's sufficient not to have a versioned build-depend on a libssl-dev if it's available in bionic-proposed already, unless there's some other serious reason why we want that test. [13:41] Maybe better, if you really want to ensure that we don't accidentally ship an nginx that doesn't have TLS 1.3 support, to add a dep8 test to check that TLS 1.3 works. [13:42] ahhh, that makes sense, and that's a trivial test to add heh [13:42] cryptodan: I'm not familure with yaml, can you suggest a place to get started or reference quide for the network config? [13:42] ... relatively speaking xD [13:44] Mead: https://netplan.io/examples [13:45] rbasak: I presume I'll need to talk to the Release Team / SRU team to get them to let it into proposed with the openssl sru blocking it of course? Or should I wait for that to clear? [13:46] cryptodan: thanks. === ddstreet_away is now known as ddstreet [14:04] dang it, YAML is a rather deep rabbit hole [14:05] Mead: its rather painless just make sure your indents are kosher [14:05] yeah I'm reading up, no tabs just spaces [14:13] cryptodan: how many spaces is needed? [14:13] Mead: copy the examples over and edit them [14:16] Mead: as many as you want, as long as it's consistent [14:18] ok, sounds like a job for notepad++ [14:19] will empty lines be a problem too? [14:21] Mead: here is mine https://termbin.com/0h88 [14:23] weird the file created during install doesn't have that "renderer:" line and the "version:2" line is at the bottom. Wonder if that is why the system hangs a bit during startup. [14:25] it would complain at applying the changes [14:25] you dont need to reboot to apply the changes with netplan [14:26] so far I've only messed with the "ip" command when it comes to networking [14:26] no, empty lines are fine [14:27] you would create the 01-netcfg.yaml file then do sudo netplan apply and that would apply the ip without reboot [14:27] the order of the entries is not important either [14:27] I suppose you could also just run "netplan generate' or 'netplan try' if you want to make sure the config is good [14:30] * Mead goes to read the man for netplan [14:36] * Mead realizes he's talking to one of the authors [14:36] I REALLY like netplan [14:37] i didnt before, but i like it and have used it to setup statics on my desktop and server [14:37] took me a bit to get used to [14:39] It seems like an ok system for configuring your network stuff, as a r&s guy who cut his teeth with IOS it is much different from what I'm use to. [14:44] cyphermox: how old is the man you helped create? [14:52] it's up to date with whatever you have installed [14:52] I keep it up to date with every release [14:55] Thank you for your work. [14:59] thanks :) [15:03] The netplan generate command is described in the --help as "generate backend specific config files from ..." could you elaborate a bit on that? [15:04] sure. It takes the yaml, and generates the config files for networkd or NetworkManager, depending on what you set "renderer" to. the default is networkd [15:06] so the "netplan apply" command has to be issued for them to take effect? [15:07] yes [15:07] netplan apply will actually do both; generate and then restart the services [15:07] 'netplan generate' is mostly there so we can easily test things, and because we need the generator at boot time [15:08] what happens at boot is the generate part runs, before networkd or network-manager are even started [15:08] then they start and they already have the config they need [15:12] and as a someone trying to get familure with linux, I need to ask: where systemd/networkd the config it generates is stored? Is that another file stored for the daemon or is it placed in ram every boot? [15:12] /etc/systemd/network [15:12] thanks [15:15] hurm, my /etc/systemd/network directory is empty [15:16] Mead: /run/systemd/network for files generated for this boot only (not persistent) [15:19] I'll be back, my dog is demanding something, and is suspect it is a walk around the block [15:47] cpaelzer: on amavisd-new [15:47] Do you know about Launchpad bug patterns? [16:03] ls [16:03] heh wrong window [16:12] so lets me iron this out "netplan apply" the creates the config files from the yaml file and places them in /run/systemd/network , and the generate config is run at boot to create those configs. So with netplan there really isn't a static config for systemd that survives boot, it is generated every boot from the yaml? [16:16] its only done if you need a static ip for that machine, but if you dont then you dont need a yaml file [16:18] cryptodan: sure, defaults to DHCP [16:19] Mead: netplan apply runs "generate" and restarts networkd/NetworkManager. netplan generates creates the config files from the yaml file and places them in /run [16:19] Mead: so; netplan is persistant config on disk, that always generates the same actual config for networkd provided the yaml isn't changed [16:20] so sure, the networkd config itself isn't persistent (it's in /run), but it's always generated the same way as long as you don't modify the config in /etc/netplan [16:23] got it, thanks. This is good info. So since ubuntu users netplan there is no need for configs to be placed in /etc/systemd/network [16:23] err uses [16:24] well, that depends [16:24] if there's something you can't do with netplan, you can add override files in /etc/systemd/network [16:27] so if there is a config file for an interface in /etc/systemd/network netplan epm [16:27] err [16:27] so if there is a config file for an interface in /etc/systemd/network netplan won't configure that interface? [16:30] no, that's not it [16:30] I mean you could write a file, say /etc/systemd/network/10-netplan-ens3.network.d/toto.conf [16:30] and have some extra keys in there that you need to add to the netplan config that gets generated in /run/systemd/network/10-netplan-ens3.network, for example [16:33] so netplan will look there and add from the config stored in the /etc/systemd/... to the file it creates to place in running config? [16:34] yeah, networkd merges a bunch of files together from various locations [16:34] ie. whatever is in /lib/systemd/network, /etc/systemd/network, and /run/systemd/network, in that order, last is most preferred [16:35] so, files with the exact same name are replaced, but you can also "extend" them with this .d directory structure [16:44] Thanks, I could keep asking more question, but I'm getting farther and farther from my what I set out to learn. It isn't every day I (knowingly) get to pick the brain of the author of the man file I'm studying. [16:52] Mead: don't hesitate. I idle in #netplan always too; but the best is to highlight me since I'm in quite a lot of channels [16:56] Awsome, I'll join and highlight ya next time I've got a netplan specific question. === bhh is now known as benharri [17:54] can a bond interface also be a bridge interface? [17:56] codefriar: you can join a bond device to a bridge [17:56] great [19:30] rbasak: is there a standard/easy way to create a debian patch that patches binary data? In this case, it's an ssl certificate used during tests, but it's in DER format (binary), not PEM [19:30] I remember a thing [19:30] * rbasak looks it up [19:30] I seem to remember a package that applied a patch via d/rules [19:30] and had it commented out in d/p/series [19:31] but still, how to encode the binary diff in the patch [19:31] git has --binary [19:31] but it's a git thing only it seems [19:31] debian/source/include-binaries is what I'm remembering. From dpkg-source(1) [19:31] Just looking to see if it's relevant [19:32] k [19:51] are there big underlying changes to networking between 18.04 and 18.10? [19:57] yeah, hey decided to backtrack on netplan [19:57] oh, wait, that was wishful thinking [20:00] codefriar: not especially, no [23:27] Hmm, what could be causing a server to hang on an attempted reboot? That is to say, if I use `reboot` it seems to try and reboot, but then the machine is stuck in some weird limbo, where the 18.04 install seems to have indeed stopped running, and nothing is accessible remotely or displayed locally, but it never actually comes back up on its own, I have to manually power-cycle it then... [23:27] I suppose the answer is probably just "UEFI is black magic", particularly considering that this server, unlike most of the others at work, *is* booting with secure boot. [23:29] (It does shut down cleanly with `poweroff`)