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