=== kallesbar__ is now known as kallesbar
=== kallesbar_ is now known as kallesbar
[05:18] <NickZ> I'm getting a strange error on ubuntu bionic server install; it's attempting to run zpool and failing because it's not installed
[05:20] <NickZ> https://pastebin.com/CpiyUrMy
[05:20] <NickZ> anyone else run into this?
[05:20] <NickZ> relevant line starts at 162
[05:26] <X-Rob> NickZ: at a guess, you have an existing zfs pool there and curtin doesn't know how to handle it. Disconnect the drives?
[05:31] <NickZ> nope, these are completely clean drives
[05:32] <NickZ> manually partitioning the drives prior to install seems to resolve the issue
=== cpaelzer_ is now known as cpaelzer
[06:30] <^Squirrel^> hi, can I get help for ubuntu gere?
[06:32] <hateball> !ask | ^Squirrel^
[06:32] <ubottu> ^Squirrel^: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[06:33] <^Squirrel^> I have a folder /proc/4838/cwd that is 9.4G, process 4838 identified as Samba - I think it is killing my server - is it normal that it should be so big, and if not, how to I get it back to normal size?
[06:33] <^Squirrel^> my server being the server on which that ubuntu runs, of course
[06:36] <lordievader> Good morning
[06:37] <^Squirrel^> alternative question: I have a partition for /, one for /home and one for /var. I would like to find the larger files for the / partition, a way that doesn't scan the other (mounted) partitions even if linked to it - is there a way to do that?
[06:37] <^Squirrel^> morning lordievader
[06:39] <keithzg[m]> Hah, just ran the 16.04 -> 18.04 upgrade on a server with molly-guard installed, and molly-guard cancelled the automatic reboot afterwards
[06:40] <lordievader> ^Squirrel^: `du -x` skips directories on different file systems, as per the man page.
[06:42] <^Squirrel^> thanks
[06:42] <^Squirrel^> so "du -x /" is what I should run?
[06:52] <^Squirrel^> ok that works, still doesn't tell me what is filling my 10G of /root folder
[06:52] <^Squirrel^> folder/partition
[06:56] <mdeslaur> rbasak: are you planning on working on that mysql merge?
[06:57] <mdeslaur> rbasak: or is lars doing it?
[06:58] <rbasak> mdeslaur: we're taking care of it. Lars has a branch up for review. I'm hoping to get to it today, but I'm not sure.
[06:58] <mdeslaur> rbasak: ok, cool, thanks!
[07:04] <^Squirrel^> lordievader, is there a way to check what size the folders are (the sum of the files in that folder and subfolders) on a server (no GUI)
[07:07] <rbasak> ^Squirrel^: du. See the du manpage for details of -s and -c.
[07:07] <rbasak> Or you can use baobab on a desktop machine connecting over ssh.
[07:07] <sarnold> ^Squirrel^: du -shx /*  may be useful
[07:08] <^Squirrel^> thank, will try. Root space free is 0  I can't install anything new
[07:08] <^Squirrel^> I have ssh access too yes
[07:13] <lordievader> du is installed by default.
[07:15] <^Squirrel^> rsalveti, sarnold, I use these thanks
[07:15] <^Squirrel^> lordievader, yes, of course
[07:15] <^Squirrel^> this is weird
[07:16] <^Squirrel^> df reports that my root partition is 0, but sudo du xhc reports 3.6G is used. / is a 10G partition
[07:17] <^Squirrel^> I am using LVM, can it be the reason?
[07:19] <lordievader> Might simply be removed files in use.  df sees those, du doesn't.
[07:22] <^Squirrel^> so what does "removed files in use" mean?
[07:23] <^Squirrel^> I have rebooted the server, this partition is still full
[07:23] <^Squirrel^> that's 5G worth of dark matter
[07:24] <jelly> ^Squirrel^: no, lvm is not the reason.  Look for unlinked files still in use by opened processes.
[07:25] <sarnold> a reboot is a good way to fix that though :/
[07:25] <^Squirrel^> I rebooted already, twice, to no avail
[07:25] <^Squirrel^> jelly, how do I do this?
[07:25] <sarnold> lsof or fuser are the usual tools
[07:25] <jelly> you might have files hiding under a mountpoint below this one
[07:25] <jelly> lsof -n +L1
[07:26] <sarnold> jelly: ooh +1
[07:26] <jelly> but if you rebooted that would have cleared the processes
[07:26] <^Squirrel^> no output of this lsof
[07:26] <^Squirrel^> lsof -n +L1
[07:27] <jelly> how many mountpoints do you have other than / ?
[07:27] <jelly> with real filesystems or bind mounts
[07:27] <jelly> (also, doing anything with /* is bad form, avoid)
[07:28] <^Squirrel^> expcluding tmpfs and udev, 16
[07:28] <jelly> umount everything else under / and retry du -x /
[07:28] <sarnold> jelly: how else would you get a list of all top-level files and directories?
[07:28] <jelly> siwtch
[07:28] <^Squirrel^> in reality, about 8 I explicitly mounted
[07:28] <jelly> sarnold: ls -ld, not du
[07:29] <jelly> or echo
[07:29] <^Squirrel^> including /var
[07:29] <^Squirrel^> and /home
[07:29] <sarnold> jelly: ls and echo do not summarize the sizes of all files linked in all directories underneath those top-level directories
[07:29] <jelly> sarnold: what use are sizes of files in /proc
[07:30] <sarnold> jelly: good point.
[07:31] <^Squirrel^> ok jelly, this might be getting somewhere - umounted -a then I get a total which corresponds more to df outuput
[07:31] <jelly> (procfs is slow, in might take half an hour just traversing that on a busy system)
[07:33] <jelly> du can very well traverse directories on its own, no need to help it with *
[07:34] <jelly> ^Squirrel^: look at directory contents previously hidden under other mountpoints
[07:35] <sarnold> ^Squirrel^: btw, once you've got some space to install new packages, ncdu may be to your liking :)
[07:35] <^Squirrel^> I tried to install ncdu, can't :P
[07:36] <^Squirrel^> but once I find the problem here, I will
[07:36] <^Squirrel^> I need to create a root user now - I can't unmount /home otherwise
[07:36] <sylario> I have a problem, I have a 16.04 server that lose all network connectivity from time to time. I can see the DHCP addresses in ip a, but I cannot ping it and it cannot ping anything
[07:37] <jelly> sure you can, just get your CWD ass out of /home
[07:37] <sylario> Network come back with sudo systemctl restart networking
[07:37] <jelly> (but having root is always nice, for other reasons)
[07:38] <^Squirrel^> lol I could just CWD out indeed
[07:38] <jelly> or as they call it in sh, "cd"
[07:38] <jelly> lsof -n|grep /home
[07:39] <^Squirrel^> but I can't umount home, cause I'm still logged into a user using /home...
[07:45] <^Squirrel^> ok /home umounted...
[07:47] <^Squirrel^> jelly, du -x / still reports some of the umounted folders...
[07:48] <^Squirrel^> yup. that's it :)
[07:48] <^Squirrel^> I knwo the problem now
[07:48] <^Squirrel^> Yay!
[07:48] <^Squirrel^> thanks guys!
[07:50] <^Squirrel^> Solved!
[07:52] <^Squirrel^> thanks jelly especially :)
[08:10] <sylario> What can I do to investigate losing connectivity after a reboot?
[08:11] <sylario> The system has the correct IPs, but there is no connectivity at all without rebooting networking
[08:11] <sylario> from syslog and apache, I can see the machine rebooted around the time of the problem
[08:15] <tomreyn> sylario: maybe the dhcp server wasn't working by the time your system booted up again?
[08:15] <tomreyn> oh you saiid it got the correct ips, sorry
[08:15] <sylario> It's some kind of xen hosting I think
[08:16] <tomreyn> so does resolving not work then, or are remote (and what about local) targets not reachable if addressed via ip address either?
[08:17] <tomreyn> * lacal targets, such as you gateway
[08:18] <sylario> I have access via an emergency console, I cannot ping google or the french taxes office from the problematic server, I cannot ping any of the server's IPs
[08:18] <sylario> sudo systemctl restart networking solve everything
[08:18] <tomreyn> the servers' LAN or WAN IPs?
[08:19] <tomreyn> and where from
[08:19] <sylario> It has only public IPs, not addresses in private ranges
[08:21] <tomreyn> ok so i'm wondering whether while this problem occurs, you could, from the server, ping 1.1.1.1 or 8.8.8.8 or the servers' gateway (as listed by ip route | grep ^default)
[08:21] <sylario> I try to ping it from public IPs from two different ISP, and I connect on it with an emergency console provided by the hosting company
[08:21] <sylario> I did not try that
[08:22] <tomreyn> in case you wont be able to ping the gateway when it happens again, talk to your hosting company.
[08:23] <tomreyn> in the meantime review /var/log/syslog to get a better idea of why the network didn't come up fully after the reboot.
[08:27] <sylario> tomreyn: thx for your help, i'll try that as soon as I can test on the server.
[08:27] <sylario> It will go in the next ticket
[12:18] <vimes> hello! I just rented an Ubuntu VPS but I see some weird traffic spikes, I wondered if any one had some recomendations for some good traffic montioring tool, preferably that saves traffic so I can see when traffic spiked and what caused it, a web gui would be nice but terminal works too. preferably open source
[12:20] <sarnold> vimes: perhaps ntopng is the tool you want
[12:21] <vimes> thanks! I'll check it out sarnold
[12:58] <rbasak> vimes: iftop for realtime viewing. Not sure about looking later though. It would make sense for it to have a pcap replay feature but I don't see that.
=== cpaelzer_ is now known as cpaelzer
[16:31] <tobias-urdin> jamespage: heads up on possible upgrade path bug for keystone, dont know how to add ubuntu tracking
[16:31] <tobias-urdin> https://bugs.launchpad.net/keystone/+bug/1793347
[16:31] <ubottu> Launchpad bug 1793347 in OpenStack Identity (keystone) "keystone upgrade fails q->r oslo.log requirement to low" [Undecided,New]
[16:34] <tobias-urdin> coreycb: ^
[16:43] <bin_bash> are auto-upgrades enabled by default? I have a vm that was provisioned and it was, and I'm trying to determine if this is a provisioning problem or a distro problem.
[17:00] <leftyfb> bin_bash: I don't know for sure, but you can easily find out by spending the 1 minute it takes to do the server install from usb onto a device
[17:00] <bin_bash> sure if i had a device to install it on
[17:00] <bin_bash> but i dont so i'm asking here
[17:10] <tobias-urdin> jamespage: coreycb and another possible one https://bugs.launchpad.net/nova/+bug/1793353
[17:10] <ubottu> Launchpad bug 1793353 in OpenStack Compute (nova) "broken upgrade path q->r requirement for oslo.db" [Undecided,New]
[17:13] <pragmaticenigma> bin_bash: Virtual Box is a decent way to test things with temporarily
[17:17] <nacc> based upon a bionic lxd, it seems like some sources are enabled. That is the cloud image, though, not necessarily the same as the base server install
[17:19] <pragmaticenigma> I thought server enabled root and -security by default... I just can't find the documentation on it.
[17:22] <bin_bash> pragmaticenigma: sure if that was a viable option, but it's not unfortunately.
[17:22] <bin_bash> nacc: that's pretty terrible...
[17:23] <pragmaticenigma> bin_bash: what do you mean by terrible?
[17:23] <bin_bash> pragmaticenigma: if i install a package of a specific version on a freshly provisioned VM, and then come back the next day, the package shouldn't have been upgraded.
[17:23] <bin_bash> but that's exactly what happened.
[17:25] <pragmaticenigma> bin_bash: If it is truly the default of -security having been enabled, then the version didn't change, a patch was applied to mitigate a security vulnerability. What package was auto-updated on you?
[17:25] <bin_bash> nodejs
[17:25] <bin_bash> APT::Periodic::Update-Package-Lists "1";
[17:25] <bin_bash> APT::Periodic::Unattended-Upgrade "1";
[17:26] <bin_bash> this was the content of /etc/apt/apt.conf.d/20auto-upgrades
[17:27] <pragmaticenigma> bin_bash: what about the 50* one?
[17:28] <bin_bash> do you want the whole thing in a paste?
[17:28] <bin_bash> it's actually mostly commented out
[17:29] <bin_bash> pragmaticenigma: https://0bin.net/paste/rLMnSMn5X4TrAjtu#8GTWJhVLB7ukZuOZw8G5nCySn5G7pdsV6ZcAGrf+I1Z
[17:30] <pragmaticenigma> bin_bash: If what I've found so far is true, only the first two are not commented out... the rest are... specifically -security isn't commented out
[17:30] <pragmaticenigma> bin_bash: the link says there is no paste there
[17:30] <bin_bash> then someone else must have clicked it
[17:30] <bin_bash> is there a bot that crawls links and opens them?
[17:31] <pragmaticenigma> anyone in this room could have clicked that before I got the chance to
[17:32] <bin_bash> Unattended-Upgrade::Allowed-Origins {
[17:32] <bin_bash>         "${distro_id}:${distro_codename}";
[17:32] <bin_bash>         "${distro_id}:${distro_codename}-security";
[17:32] <bin_bash> "${distro_id}ESM:${distro_codename}"
[17:32] <bin_bash> thats the only uncommented part
[17:32] <pragmaticenigma> including the bots... with the spam attack on freenode
[17:32] <bin_bash> oh and this
[17:32] <bin_bash> Unattended-Upgrade::DevRelease "false";
[17:32] <bin_bash> i mean it was mere seconds between pasting and you trying to click, so it must have been something automatic. never had that problem in another channel, most bots just fetch metadata
[17:33] <pragmaticenigma> okay, from what you have posted so far then... your instance is setup to only auto update security patches.
[17:33] <bin_bash> hm
[17:33] <bin_bash> even this though?
[17:33] <bin_bash> "${distro_id}:${distro_codename}";
[17:33] <bin_bash> that doesn't have -security
[17:34] <pragmaticenigma> that is your "root" store... the items in there do not change until a point release occurs, suchas 18.04.1 to 18.04.2
[17:34] <bin_bash> plus if i specifically install a version (which I did), that should add some kind of flag, right?
[17:34] <pragmaticenigma> bin_bash: no... those are defined in another file, explicately by the person doing the sysadmin
[17:35] <bin_bash> =/
[17:41] <pragmaticenigma> I wish I could find release notes to verify the enabled by default for you. Short of installing (which I can't do at my present location) I can't find anything online to verify other than a bug that 16.04 ignored a users selection of no unattended updates
[17:42] <bin_bash> yeah thats what i was looking for as well
[17:42] <bin_bash> but didn't find it
[17:43] <bin_bash> thank you for looking though
[17:43] <pragmaticenigma> bin_bash: the closest that I can find is Ubuntu Desktop Gnome/unity have installed the package by default, and in Debian, the default configuration is to enable the main or root and the "-security" by default
[17:44] <bin_bash> hm interesting
[17:44] <pragmaticenigma> bin_bash: I know that Ubuntu Desktop asks during installation, and by default has "Install security updates without confirmation" preselected
[17:44] <bin_bash> this is jsut a weird one-off package. gotta have node6 for this dumb  thing -.-
[17:45] <pragmaticenigma> bin_bash: I was partitially expecting you to mention something about GhostScript, as there were some significant security vulnerabilities patched in the last 24 hours
[17:45] <bin_bash> ahh
[17:46] <bin_bash> well i had a helluva time installing node6 at all. every other time ive done it on 16.04 i just added the source list and then apt install and it was fine
[17:46] <bin_bash> this time i had to specify the version
[17:48] <pragmaticenigma> I wish I were more familiar with it... I know 18.04 some foundational pieces where significantly changes (netplan, etc) that have made some rather hard support questions
[17:52] <pragmaticenigma> bin_bash: Found it! The default config file for the unattended-upgrades package has main and -security enabled by default in 50unattended-upgrades
[17:52] <bin_bash> it seems like something that should be documented
[17:52] <bin_bash> oooo
[17:52] <bin_bash> where did you find that
[17:52] <pragmaticenigma> https://launchpad.net/ubuntu/+source/unattended-upgrades/1.1ubuntu1.18.04.5
[17:52] <bin_bash> thank you!
[17:52] <pragmaticenigma> rather: https://launchpad.net/ubuntu/+source/unattended-upgrades
[17:53] <bin_bash> perfect
[17:53] <bin_bash> i read that as "unintended upgrades"
[17:53] <bin_bash> hahaha which is more fitting -.-
[17:54] <pragmaticenigma> yeah... I go back and forth on whether I want to enable it... sometimes I get really tired of the prompts on Desktop... at the same time, I run MythTV and don't want it to decide to apply updates in the middle of a recording and trigger the daemon to restart
[17:55] <pragmaticenigma> I typically install all instances from the mini.iso release. In part because I can still install to 32 bit machines with it, and it's the same dialog prompts no matter what the final version I'm intending to install
[17:55] <pragmaticenigma> and depending how far into the release we are, I don't have to spend an extra hour or two installing updates after installing the release
[17:57] <pragmaticenigma> bin_bash: from this, I would assume the author of your vm included/installed the unattended upgrades package. Assuming they either clicked through accepting the default selections or installed the package after the fact, I don't think it was the vm's authors intent to misconfigure. As much as trying to follow the defaults offered by the original installation
[17:58] <pragmaticenigma> bin_bash: it really should be better documented. it's even harder for server as most the documentation highlights the desktop installations more than server. I would assume Canonical would rather people installing server sign up for a support plan
[18:06] <bin_bash> it's just so frustrating. i dont think anything should automatically update on a server, that's just asking for problems.
[18:08] <pragmaticenigma> bin_bash: Agree'd to a degree... the problem is the number of systems that get abandoned or aren't maintainted regularly that really could benefit such that they don't fall vicitm to someone's bot net
[18:11] <pragmaticenigma> at minimum at least the security holes are plugged. If the unattended update broke your nodeJs application, that is really strange. unless it's the tenuous behavior of node6 (?) and ubuntu 18.04 you experienced?=
[18:13] <bin_bash> well the thing is that im installing it from nodesource
[18:13] <bin_bash> this is the official way of doing it according to nodejs
[18:13] <bin_bash> https://nodejs.org/en/download/package-manager/
[18:13] <bin_bash> unfortunately something must have changed in 18.04
[18:13] <bin_bash> because previously i just added the source, apt install, done
[18:13] <bin_bash> this time even after adding the source it STILL installed the one from the main repo
[18:14] <bin_bash> i had to do apt install nodejs=6.14.1-1nodesource1
[18:14] <bin_bash> this time, it's weird
[18:18] <pragmaticenigma> not too wiered... beneath the instructions for installing to Debian/Ubuntu... it mentions it only supports 16.04 and 14.04
[18:18] <pragmaticenigma> so I think that might be the root of your issue
[18:39] <bin_bash> ooh i didnt even see that
[18:40] <bin_bash> still though i dont think 18.04 was LTS when this was published
[18:42] <pragmaticenigma> probably not, and there are a lot of under the hood changes with 18.04 that they might be trying to hammer out
[18:43] <bin_bash> yea
[18:43] <bin_bash> bleh
[18:43] <bin_bash> effed up to call it LTS when theyre still fixing things
[18:43] <bin_bash> absurd
[18:47] <pragmaticenigma> bin_bash: depends on your perspecitve... If you take NodeJS out of the equation, 18.04 by itself is very stable (i'm currently running it) ... since nodejs team have to react to the change (they can't exactly see into what Canonical is planning for ubuntu) it takes a while before they get their dependencies and scripts polished and ready. There were some significant changes in 18.04 starting with the netowrk
[18:47] <pragmaticenigma> management, and even the daemon managment
[18:47] <bin_bash> im not just talking about nodejs though
[18:48] <bin_bash> in general a server shouldn't do upgrades without intervention by default
[18:48] <bin_bash> think about php for example. there are many platforms that only work on php 7.0 or php 7.1 but not both. if php were security-upgraded to 7.1, that could cause a huge problem
[18:58] <nacc> bin_bash: release don't upgrade major versions
[18:58] <nacc> generally
[18:59] <nacc> bin_bash: "LTS" has nothing to do with "bug-free"
[18:59] <bin_bash> but thats exactly what happened with nodejs lol so i can't really expect it to not happen with other packjages
[18:59] <nacc> bin_bash: you weren't using an ubuntu version
[18:59] <nacc> bin_bash: so go complain to node, not here.
[18:59] <bin_bash> what?
[19:00] <bin_bash> the problem was with the core ubuntu repo.
[19:00] <nacc> bin_bash: you were using some external repository, right?
[19:00] <bin_bash> i was TRYING to
[19:00] <bin_bash> but it kept overriding it
[19:00] <nacc> bin_bash: what is 'it'?
[19:01] <bin_bash> apt/synaptic
[19:01] <nacc> bin_bash: i think maybe you just don't understand how packages work...
[19:01] <bin_bash> i think maybe you're not understanding what i'm saying
[19:01] <nacc> bin_bash: are you complaining that 18.04 has 8.10.0 while you wanted 6.14.1 ?
[19:01] <bin_bash> If I were to install weechat on debian from the weechat repos
[19:01] <nacc> full stop.
[19:01] <nacc> weechat repos?
[19:01] <nacc> debian?
[19:01] <bin_bash> apt wouldnt then override that for the core repos
[19:01] <bin_bash> it's called an example
[19:02] <nacc> if the weechat version in debian was greater than from weechat then yes it would.
[19:02] <nacc> bin_bash: i am fairly sure you just didn't check versions of packages via `apt-cache policy`, didn't bother to pin, and are complaining about that.
[19:03] <bin_bash> no, i'm complaining that the system made an internal, automatic decision to upgrade a package from another repository
[19:04] <nacc> bin_bash: what 'other' repository?
[19:04] <nacc> bin_bash: apt-cache policy nodejs, please
[19:04] <bin_bash> and for the record, i /DID/ check apt-cache policy
[19:04] <nacc> (if nodejs is the package you are worried about)
[19:04] <bin_bash> jesus fuck. i literally said I installed the package from nodesource. overnight, ubuntu upgraded that package from the extra repository
[19:04] <nacc> because the version in ubuntu is greater
[19:05] <nacc> you are choosing to run some third party repositroy
[19:05] <bin_bash> except it shouldn't do that bny default
[19:05] <nacc> and didn't bother to configure your apt sources appropriately to pin it
[19:05] <nacc> that's your opinion.
[19:08] <_KaszpiR_> bin_bash apt-pin
[19:10] <bin_bash> _KaszpiR_: thats not a command. apt-cache search doesn't even return anything
[19:10] <_KaszpiR_> https://jaqque.sbih.org/kplug/apt-pinning.html
[19:10] <bin_bash> regardless, if i install a package from one repo, it shouldn't be overriden by a package from another repo
[19:10] <bin_bash> ive literally never encountered that on any distro
[19:10] <_KaszpiR_> not really
[19:11] <_KaszpiR_> welcome to debian :/
[19:11] <bin_bash> ive been using debian for years
[19:11] <bin_bash> and this is the first time running into this
[19:11] <bin_bash> ¯\_(ツ)_/¯
[19:11] <_KaszpiR_> heh, lucky you, then
[19:11] <_KaszpiR_> got that many times
[19:12] <bin_bash> maybe because usually the other repo has newer versions rather than older
[19:12] <bin_bash> i'm used to running outdated packages on arch because nothing is automated, everything is deliberate
[19:13] <pragmaticenigma> bin_bash: The repos are just storage containers... the repos themselves don't set a hierarchy. the packages themselves do with their naming convention since they sort alphanumerically. Debian happens to come earlier in the alphabet than Ubuntu... therefor an Ubuntu package is going to get precendence since it occurs later in the alphabet
[19:14] <pragmaticenigma> assuming the package name is of 6nodejs-ubuntu-18.04 versus 6nodejs-debian-9
[19:14] <bin_bash> pragmaticenigma: tbh mostly my upset is regarding a package being changed in any way without my deliberate action, and having this set as a default parameter and also not well-documented is porblematic
[19:15] <pragmaticenigma> I assure you it's documented somewhere... but the joy of linux is... where?
[19:17] <bin_bash> i didnt say totally undocumented, i just said not well-documented. :P
[19:18] <pragmaticenigma> I have the same premise
[19:22] <nacc> appears to have changed in ubuntu with https://git.launchpad.net/ubuntu/+source/unattended-upgrades/commit/?id=558990e4
[19:22] <nacc> not 100% on that
[19:22] <nacc> it used to be -security only, though, and then the release pocket was added
[19:23] <pragmaticenigma> nacc: that jives with what I found in the package from launchpad
[19:24] <nacc> in this case, it wouldn't matter, though, actually
[19:24] <nacc> a newer version is in ubuntu, period
[19:25] <nacc> and the -security case has been that way for quite some time
[19:25] <nacc> maybe unattended-upgrades became installed by default, dunno
[19:27] <pragmaticenigma> nacc: I remember seeing it somewhere that server began installing it by default, but I just can't find a release note or documentation on it
[21:33] <grandy> hello, probably a dumb question: how to I get cloud-init to write the netplan file ?
[21:37] <grandy> i edited the clout-init file but not sure what command makes it generate the outputs
[21:38] <nacc> grandy: cloud-init runs once at boot
[21:39] <grandy> nacc: hmm, my ubuntu server install has a comment in the netplan that it was generated by cloud-init. I modified the cloud-init file in question and rebooted, but it did not update the netplan file.  Just trying to add another network interface
[21:42] <nacc> grandy: which file did you edit?
[21:45] <grandy> nacc: /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg
[21:46] <nacc> smoser: rharper --^ ? i don't know, tbh; does it need to be in the initrd instead?
[21:48] <grandy> nacc: i added the enx... interface, eno1 was already configured: https://pastebin.com/m6vyvDeJ
[21:49] <smoser> grandy: that will only be written once per instance.
[21:49] <smoser> so if the instance-id has not changed, changes to that will not get updated to the system.
[21:49]  * smoser has to go afk.
[21:49] <grandy> smoser: ahh, ok, so it's mainly for the intial config of the machine... where would i add a new network interface?
[21:50] <nacc> grandy: what do you mean 'add a new network interface'? You mean just the configuration for it, right?
[21:50] <grandy> smoser: yeah just to tell it to bring it up and use dhcp
[21:51] <nacc> grandy: i think you just want to put that in your netplan config file, no?
[21:51] <grandy> smoser: there is a configuration in /etc/netplan that is generated by cloud init, but it warns that it might be regenerated.
[21:51] <nacc> grandy: i mean, you can add another file in /etc/netplan, aiui
[21:52] <grandy> nacc: ahh ok, this is the contents of /etc/netplan/50-cloud-init...
[21:52] <grandy> https://www.irccloud.com/pastebin/RxCAvqeg/
[21:52] <nacc> grandy: right, so leave that one alone (i think)
[21:52] <nacc> grandy: and add nother (see `man netplan`)
[21:53] <grandy> nacc: ahh ok, so  then where would I change the config for eno1 ? a new file also?  Just wondering in case i have to do that later.
[21:54] <grandy> nacc: it must be that cloud-init is meant for ephemeral instances, in which case it seems to make sense.
[21:54] <nacc> grandy: see the manpage, you can override settings with appropriately named files
[21:54] <nacc> grandy: cloud-init initializes an instance based upon cloud-provided data (among other things)
[21:55] <grandy> nacc: ok will do, yeah ok, this is starting to make sense now, just installed ubuntu server and it's been a few years since I have configured my own server so was not really up to speed on cloud-init ... thanks much for the help
[21:56] <nacc> grandy: sure, their docs are good toohttps://cloudinit.readthedocs.io/en/latest/topics/examples.html
[21:57] <grandy> nacc: yeah i was reading over them a bit when I thought it was meant for ongoing config updates and was thinking wow this looks like a great approach to config.
[22:12] <grandy> nacc: it worked. thanks again
[22:13] <nacc> grandy: cool, np!