[03:35] <masber> good afternoon, I have an ubuntu vm and I can't make the network to work... this is the error message I see in journalctl -xe --> Failed to start Raise network interfaces.
[03:36] <masber> failed with result 'exit-code'.
[03:37] <masber> the story is I created a new vm and installed ubuntu in it but I make a mistake selecting the primary nic to setup the server ip
[03:37] <masber> so after installation I went to the /etc/network/interfaces and changed the interface name to the right one
[03:37] <masber> then I rebooted the networking server and I am getting this error since then
[03:38] <masber> I am running ubuntu 16.04
[03:38] <masber> any idea?
[06:59] <allquixotic> Will the Canonical Livepatch Service be able to implement LPTI on running kernels or will a reboot be required?
[07:01] <lordievader> Good morning
[07:03] <cpaelzer> good morning
[07:05] <lordievader> Hey cpaelzer how are you doing?
[07:06] <cpaelzer> ignoring my habit to see things worse than they are, actually good :-)
[07:06] <cpaelzer> how about you lordievader
[07:06] <cpaelzer> had a good start?
[07:07] <lordievader> Doing good here, got tea for a change
[07:26] <lotuspsychje> for the users that might ask about kpti, !kpti has been updated
[07:31] <trippeh> !kpti
[10:00] <cpaelzer> thanks lotuspsychje
[13:49] <cpaelzer> ahasenack: ovfs2-tools is good now
[13:49] <cpaelzer> ahasenack: do you want me to sponsor it as it is now?
[13:49] <ahasenack> saw your reply, just replied to that
[13:49] <ahasenack> running the dep8 tests locally
[13:50] <cpaelzer> ahasenack: ok - give me (or another uploader) a ping when you tihnk it is ready
[13:50] <ahasenack> ok
[13:50] <ahasenack> I can actually upload that one, just not push the upload tag
[14:33] <cpaelzer> ahasenack: well we can revise the tag if needed
[14:33] <cpaelzer> ahasenack: so I could push the tag as-is
[14:33] <cpaelzer> which means you can upload if you are happy after some time
[14:33] <cpaelzer> and if not we can change the upload tag to whatever is the truth then
[14:33] <ahasenack> let's wait a bit, I'm getting a silly dep8 test error
[14:33] <ahasenack> which works if I run it interactively in a vm
[14:33] <cpaelzer> ok, waiting for you
[14:34] <ahasenack> basic                FAIL stderr: yes: standard output: Broken pipe
[14:34] <ahasenack> that's just a "yes | fsck.ocfs2 -f -y -F $DISK 2>&1"
[14:36] <cpaelzer> ahasenack: I have seen such issues
[14:36] <cpaelzer> being part of a "when does what die" problem
[14:37] <cpaelzer> in my case I had an unlimited read from /dev/urandom piped to something else
[14:37] <cpaelzer> yes is an endless-til-killed stream
[14:37] <cpaelzer> so it might be the same issue
[14:37] <cpaelzer> if you can run with a limited amount of "y" try that ahasenack
[14:38] <ahasenack> what do you mean limited amount of "y"?
[14:38] <cpaelzer> like 4 times "y" instead of infinited
[14:38] <rbasak> I thought a pipeline was supposed to return the result of the final command?
[14:38] <ahasenack> oh
[14:38] <cpaelzer> rbasak: that is mostly just a warning
[14:38] <cpaelzer> in my cases it didn't even affect RCs
[14:38] <cpaelzer> ahasenack: does it for you?
[14:38] <ahasenack> I'll try after lunch
[14:38] <cpaelzer> affect RCs?
[14:38] <rbasak> Oh
[14:38] <rbasak> Hold on
[14:39] <rbasak> You need allow-stderr in your Restrictions
[14:39] <rbasak> IMHO, that's a wart with dep8 tests.
[14:39] <ahasenack> rbasak: the test passed in the past
[14:39] <ahasenack> and I don't get this error when I run it in a vm
[14:39] <rbasak> OK, so that's a race that cpaelzer is describing.
[14:39] <cpaelzer> yeah if that goes out on stderr then rbasak is right, the allow is needed then
[14:39] <ahasenack> so yes, allow-stder would work around it
[14:40] <ahasenack> but I will try a bit more some other tricks before
[14:40] <rbasak> If you're going to use a yes | pipe, then I think an allow-stderr is required.
[14:40] <rbasak> And would be the correct fix.
[14:40] <cpaelzer> OTOH if you can easily do the same with limited number of "y" do that
[14:40]  * ahasenack -> lunch
[14:40] <cpaelzer> expect might the the best but also most complex solution
[14:40] <teward> i think i asked this but didn't get a response, who do I have to bother about the cloud-images.ubuntu.com linux images for lxc/lxd, because there's a small issue with them...
[14:40] <teward> minor but annoying ultimately :P
[14:40] <cpaelzer> stgraber: ^^
[14:41] <cpaelzer> oh sorry
[14:41] <rbasak> teward: ask the actual issue please :)
[14:41] <cpaelzer> are lxc/lxd even on cloud-images?
[14:41] <rbasak> ubuntu:xenial comes from somewhere. No idea where :)
[14:42] <teward> cpaelzer: the disk images for {INSERT_UBUNTU_RELEASE_HERE} are.  https://paste.ubuntu.com/26319708/ for `lxc remote list` output
[14:42] <teward> rbasak: the cloud images, when spun up by LXC/LXD, don't get the hostname added to /etc/hosts
[14:42] <teward> which can in some cases cause issues with `sudo` and such
[14:42] <teward> Debian's cloud images have no problem with this
[14:42] <cpaelzer> ok, then they are pushed there
[14:42] <cpaelzer> still I think the hightlight to stgraber ^^ still is the right one for you
[14:43] <rbasak> teward: http://cloudinit.readthedocs.io/en/latest/topics/modules.html#update-etc-hosts
[14:43] <rbasak> "If this is set to false, cloud-init will not manage /etc/hosts at all. This is the default behavior."
[14:43] <teward> rbasak: so, then, where does one make that change
[14:44] <rbasak> lxc profile edit default
[14:44] <rbasak> config:
[14:44] <rbasak>   user.user-data: |
[14:44] <rbasak>     #cloud-config
[14:44] <rbasak>     manage_etc_hosts: localhost
[14:44] <teward> *throws the !pastebin factoid at rbasak*
[14:44] <teward> just saying :P
[14:44] <teward> i'll update that
[14:45]  * rbasak throws the manual back at teward :-P
[14:45] <teward> rbasak: *very* odd though that that only happens for the Ubuntu images
[14:45] <rbasak> Ubuntu images from ubuntu:xenial etc. uses cloud-init by default
[14:45] <rbasak> images:debian/sid/amd64 etc. do not.
[14:45] <teward> ah, makes senses.
[14:45] <teward> sense*
[14:45] <rbasak> I'm not sure what images:ubuntu/... does. Presumably they don't use cloud-init. But I normally want cloud-init, so I never use those ones.
[14:46] <teward> nor I ;P
[14:53] <teward> well now I"ve updated all my LXC/LXD systems accordingly heh
[14:57] <rbasak> smoser: any thoughts on moving the manage_etc_hosts default? When do people _want_ it to be false, except to avoid breaking existing setups?
[15:00] <Odd_Bloke> teward: rbasak: cpaelzer: ubuntu:* and ubuntu-daily:* come from cloud-images.u.c.; images:* come from stgraber.  The cloud-images project would be the appropriate place on LP to file a bug. :)
[15:01] <stgraber> though in this case, whether it's a bug is debetable, I've always found it weird that cloud-init doesn't generate the /etc/hosts entry, but based on its documentation, it's clearly deliberate
[15:05]  * rbasak files bug 1741277
[15:11] <teward> stgraber: could we not override that on our side of things?
[15:11] <teward> because in 99% of cases you are probably going to *expect* it to not cause `sudo` to explode in the lxc/lxd container with an 'unable to find hostname HOSTNAMEGOESHERE' error
[15:11] <teward> it still works, but...
[15:12] <stgraber> teward: the eaiest would be to have a different default in cloud-init when dealing with a container, though I'd expect the sudo issue to be just as true inside a cloud instance, so not sure why this is lxd-specific
[15:12] <teward> stgraber: so far i've only noticed it in lxd.
[15:13] <smoser> rbasak: well, in cases where dns works, a sane cloud that provides dns entry in its dhcp (or otherwise) provided dns servers
[15:13] <teward> but since i don't have any non-lxd cloud-init-initiated instances... :P
[15:14] <smoser> in such an environment, the cloud knows the right result for looking up hostname, and if you put an entry in /etc/hosts for localhost, you break what would have worked.
[15:14] <smoser> the issue is not "lxd specific", its "broken cloud specific".
[15:15] <smoser> why should the platform not provide an answer for the hostname that it gave the instance from the dns server that it provided to the instance.
[15:15] <rbasak> Is it sane for the local hostname to result in a round trip around the network via DNS?
[15:15] <smoser> maybe
[15:15] <smoser> i honestly think that the sane fix is to stop sudo from doing that nonsense.
[15:15] <smoser> no one uses sudo like that anymore
[15:16] <smoser> with one sudo config spread across multiple hosts
[15:16] <rbasak> I think it's reasonable for a system to expect to always get a result from looking up itself.
[15:16] <rbasak> On lxd, we're in a position to make that happen.
[15:16] <smoser> where the hostname of the system is looked up via dns
[15:16] <rbasak> The question is just about which component should manage that.
[15:16] <smoser> really, i think the solution for "get rid of that warning from sudo" is to *get rid of that warning from sudo*
[15:17] <rbasak> It's not just sudo.
[15:17] <rbasak> Other stuff breaks too.
[15:17] <smoser> like ?
[15:17] <rbasak> I don't recall.
[15:17] <rbasak> I don't see it often, because I consider a system not being able to look up its own name as broken and always fix that first.
[15:17] <smoser> and anything that *does* depend on it is honestly probably broken.
[15:18] <smoser> in some way, its overly simplistic solution to "whats my IP address" or something like that.
[15:18] <rbasak> Perhaps
[15:18] <rbasak> But it's still broken for a system to not be able to look up its own ame
[15:18] <smoser> yeah.
[15:18] <TJ-> There was a bug recently affecting sudo causing hangs when the system was offline, when mdns was installed for nsswitch, too
[15:19] <smoser> i do think we should look at doing this better, and have a solution for bionic that does the best thing.
[15:19] <smoser> can anyone actually  justify sudo doing a hostname lookup?
[15:19] <rbasak> I don't object to fixing sudo. I just don't think that resolves the issue from the user's perspective.
[15:19] <smoser> in a year > 2000 ?
[15:19] <TJ-> nacc and I were debugging it, bug 1295229
[15:20] <rbasak> The problem with sudo is that the file format specification will continue to permit hostnames even if nobody uses that facility.
[15:20] <rbasak> Changing that is extremely difficult.
[15:20] <rbasak> So then it becomes a request to optimise sudo to not do a lookup unless it needs it.
[15:20] <TJ-> could the solution be in nsswitch instead ?
[15:21] <rbasak> TJ-: then it wouldn't (easily) be configurable though.
[15:21] <rbasak> OTOH, the solution in /etc/hosts is fine and is configurable.
[15:21] <smoser> TJ-: i think that is in the realm of 'myhostname' plugin or something
[15:21] <smoser> https://www.freedesktop.org/software/systemd/man/nss-myhostname.html
[15:21] <TJ-> smoser: yeah, thanks for jogging my memory on that one... we found that a recent addition
[15:22] <rbasak> That's interesting
[15:23] <smoser> TJ-: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1730744
[15:23] <smoser> that is related
[15:24] <smoser> i came to the party late
[15:24] <smoser> is that the bug that was originally being raised.
[15:25] <rbasak> I suppose the real intention of my bug is "not all platforms running cloud-init make the system hostname resolveable by default"
[15:26] <rbasak> I'd consider it resolved as soon as that is true.
[15:26] <TJ-> smoser: in the case that nacc and I investigated, we found the nsswitch.conf "hosts: ..." entries didn't seem to be processed in the order, or according to the rules, as documented
[15:27] <smoser> well, all this is part of why i leave it untouched.
[15:28] <TJ-> right, the case was a default 17.10 install too.
[16:02] <ahasenack> hi, can someone please import ubuntu-fan into the ubuntu server git repo?
[16:02] <ahasenack> rbasak: cpaelzer ^
[16:03] <cpaelzer> ahasenack: I'll do so
[16:04] <ahasenack> thanks
[16:04] <cpaelzer> running
[16:04] <cpaelzer> but I think it had a native git
[16:04] <cpaelzer> check d/control maybe?
[16:04] <ahasenack> hm
[16:05] <ahasenack> nothing in there
[16:05] <ahasenack> not even a single url
[16:06] <ahasenack> readme points at http://www.ubuntu.com/fan and that's it
[16:06] <ahasenack> the other url is for iana.org
[16:06] <ahasenack> that /fan one is a 404, btw
[16:09] <ahasenack> cpaelzer: beware the launchpad login oauth token prompt, it's easily missed
[16:12] <nacc> cpaelzer: please also add to whitellist
[16:14] <cpaelzer> nacc: what would happen if we don't other than getting out of sny?
[16:14] <cpaelzer> sync
[16:15] <nacc> cpaelzer: it breaks the assumption that all of the existinng repos keep up with the publisher
[16:15] <nacc> cpaelzer: but htat's it :)
[16:19] <cpaelzer> ahasenack: imported
[16:19] <cpaelzer> nacc: added to whitelist
[16:19] <nacc> cpaelzer: thx
[16:20] <cpaelzer> rbasak: I didn't realize what you meant with a fetch being needed along that
[16:20] <cpaelzer> anything I should do?
[16:23] <ahasenack> !kpti
[16:27] <rbasak> cpaelzer: we mean the bastion gets the whitelist straight out of the git tree rather than the snap. So the bastion needs the updated whitelist fetching with git before it'll take effect.
[16:27] <rbasak> (also the loop restarting I think)
[16:28] <rbasak> I don't think you need to do anything.
[16:28] <rbasak> But probably useful to know that.
[16:28] <cpaelzer> thanks rbasak
[16:39] <Neo4> I'm going to make user root owner apache, put in pache2.conf root instead www-data?
[16:39] <Neo4> it can solve permission problem?
[16:39] <Neo4> now I need always pug www-data to growp of my user
[16:40] <Neo4> ???
[16:40] <Neo4> in ubuntu-server guide I've read it is possible
[16:40] <Neo4> but not recommended, why?
[16:42] <nacc> Neo4: you want root to own your website?
[16:42] <nacc> Neo4: then if there is an exploit of apache2, the exploiter has root on your system, potentially
[16:42] <Neo4> nacc: yes, for apach2 can be able write files always
[16:43] <nacc> Neo4: that's not a reasonable thing for a webserver
[16:43] <Neo4> nacc: do you think it's possible? Exploit can be if I install some module?
[16:43] <Neo4> nacc: ok, I'll train comond chmode and find than
[16:44] <Neo4> nacc: always should after install site put rights 775 and 664
[16:44] <Neo4> if would apache is root I right would be 755 and 644
[16:45] <Neo4> nacc: or I should just change owner of files from my user to www-data
[16:45] <Neo4> but I put root and neo is my current user to www-data goup and www-data to group neo and root
[16:45] <Neo4> and rights 775
[16:46] <teward> NEVER add anything to the `root` group
[16:46] <teward> NEVER add yourself to the `www-data` group
[16:46] <teward> NEVER add the webserver www-data user to your own user group
[16:46] <teward> use actual permissions to control things instead
[16:46] <Neo4> teward: why?
[16:46] <teward> or ACLs for 'customized' rules.
[16:46] <teward> Neo4: permissions and security
[16:46] <Neo4> teward: if filewill have ownerchip www-data and froup www-data I can't copy this file ?
[16:46] <teward> you *never* want to give `www-data` or non-root system accounts access to `root`
[16:47] <teward> Neo4: I think you need to get an understanding of how file permissions work
[16:47] <teward> and how the underlying system permissions structures on LInux work
[16:47] <Neo4> teward: I know
[16:47] <teward> BEFORE continuing.  my two cents.
[16:47] <Neo4> teward: see www-data create his own files and owner will be www-data : www-data
[16:48] <teward> i know this - i'm very fluent in filesystem permissions.
[16:48] <teward> the problem is
[16:48] <teward> you want someone *else* to access the data
[16:48] <Neo4> I'll connect to my server and can't edit this files, because apache creates it with 755 rules and my user is not in group
[16:48] <teward> well, the `root` user has god access to everything that doesn't have specialized access permissions
[16:48] <Neo4> teward: yes, for edit files
[16:48] <teward> want to know another method?
[16:49] <Neo4> teward: if my user neo in www-data group I put right 775 or 664 and can do it
[16:49] <teward> Neo4: alternativelyt
[16:49] <teward> you can give your user ownership of the files
[16:49] <teward> www-data as group access
[16:49] <teward> and set the setgid bit for all directories
[16:49] <teward> and set the setgid bit for all directories within the document root*
[16:49] <teward> thereby giving both you and `www-data` read/write/edit permissions.
[16:50] <teward> which is the ***proper*** way to do this.
[16:50] <teward> ... well one of them anyways.
[16:50] <Neo4> teward: I don't know what is setgid bit
[16:50] <teward> https://askubuntu.com/questions/767504/permissions-problems-with-var-www-html-and-my-own-home-directory-for-a-website/767534#767534
[16:50] <teward> steps 1, 2, and 3.
[16:50] <teward> replace `/var/www/html` with the actual directory for your document root
[16:50] <teward> and stop messing with who has group access to whichever account
[16:50] <teward> then go research how filesystem permissions work in Linuxl
[16:51] <teward> because if you don't understand the basic permissions structure, IMO you should probably be hiring someone to do this stuff for you instead :P
[16:51] <teward> (yes i'm salty and grumpy today, i've been staring at code all day so my eyes hurt and i have a massive headache)
[16:51] <teward> (and four servers explodified so i'm busy rebuilding those... what a horrible day for me >.>)
[16:52] <Neo4> :)
[16:52] <Neo4> ok
[16:53] <Neo4> thanks, will try
[16:53] <teward> step 3, the setgid bit, just basically says "Any file created in this directory with default permission settings will get the group set to the same group-ownership as the folder it's created in" in a nutshell
[16:53] <teward> it's far more complex than just that
[16:53] <teward> but it's the brief explanation
[16:53] <teward> now i need coffee
[16:53]  * genii slides one on over to teward, ASAP
[19:22] <ahasenack> I'm trying to debug a dns resolution problem in an lxd container (artful),
[19:22] <ahasenack>  /etc/resolv.conf has nameserver as 127.0.0.53
[19:22] <ahasenack> that's systemd-resolved
[19:23] <ahasenack> and it's not working: dig @127.0.0.53 just times out
[19:23] <ahasenack> but dig @some-external-dns works just fine
[19:23] <ahasenack> so where do I find out which forwarders systemd-resolved is using?
[19:23] <ahasenack> tcpdump -i any port 53 shows nada when I use dig against @127.0.0.53, just dig's requests, but no reply
[19:24] <ahasenack>  /etc/systemd/resolved.conf has everything commented (#)
[19:24] <teward> ahasenack: did you *specify* any DNS servers in the network config or in the host for the LXD bridge/dhcp to assign?
[19:25] <ahasenack> it's an lxd deployed via juju into that host, which is deployed via maas
[19:25] <ahasenack> the host is fine
[19:25] <ahasenack> the host also has 127.0.0.53 in resolv.conf,
[19:25] <ahasenack> and its /etc/systemd/resolved.conf is also default
[19:25] <ahasenack> so I also don't know where the host is getting the upstream dns from
[19:26] <ahasenack> but host is bionic, netplan all the way
[19:26] <ahasenack> hm
[19:27] <ahasenack> juju also used netplan for this xenial container...?
[19:27] <ahasenack> it just created the netplan config, but netplan is not even installed in this container, so that's a no-op
[19:28] <ahasenack> but yeah, /etc/network/interfaces has no dns-nameserver config
[19:28] <ahasenack> just the domain
[19:28] <ahasenack> and the loopback interface does have a dns-nameserver, and that's 127.0.0.53
[19:28] <ahasenack> which is what ended up in /etc/resolv.conf
[19:30] <ahasenack> but why would 127.0.0.53 not even try the root servers
[19:35] <ahasenack> I think it's in a loop
[20:08] <sarnold> I don't think systemd-resolved is a recursor, is it? I thought it just forwarded queries to another server
[20:08] <sarnold> I wouldn't expect it to check roots itself
[20:09] <teward> sarnold: last i checked it isn't
[20:09] <teward> but if systemd-resolved has no upstream DNS set for forwarding it just implodes
[20:09] <teward> same issue I had with dnsmasq ;)
[22:40] <patdk-lap> odd, everyone has released patches now, except ubuntu :(
[22:55] <dax> to be fair, Debian only *just* released
[23:13] <mason> https://security-tracker.debian.org/tracker/CVE-2017-5753 doesn't reflect a release yet
[23:13] <mason> nor https://www.debian.org/security/
[23:16] <mason> Ah, but https://lists.debian.org/debian-security-announce/2018/msg00000.html
[23:21] <oerheks> https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/
[23:21] <oerheks> "everyone has released patches now" ???
[23:34] <TJ-> patches are great, what we need is built and published binaries :D