| 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:35 |
|---|---|---|
| masber | failed with result 'exit-code'. | 03:36 |
| 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:37 |
| masber | I am running ubuntu 16.04 | 03:38 |
| masber | any idea? | 03:38 |
| allquixotic | Will the Canonical Livepatch Service be able to implement LPTI on running kernels or will a reboot be required? | 06:59 |
| lordievader | Good morning | 07:01 |
| cpaelzer | good morning | 07:03 |
| lordievader | Hey cpaelzer how are you doing? | 07:05 |
| 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:06 |
| lordievader | Doing good here, got tea for a change | 07:07 |
| lotuspsychje | for the users that might ask about kpti, !kpti has been updated | 07:26 |
| trippeh | !kpti | 07:31 |
| ubottu | 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/ | 07:31 |
| cpaelzer | thanks lotuspsychje | 10:00 |
| 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:49 |
| 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 | 13:50 |
| 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:33 |
| 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:34 |
| cpaelzer | ahasenack: I have seen such issues | 14:36 |
| cpaelzer | being part of a "when does what die" problem | 14:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| * 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:45 |
| teward | nor I ;P | 14:46 |
| teward | well now I"ve updated all my LXC/LXD systems accordingly heh | 14:53 |
| 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? | 14:57 |
| 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:00 |
| 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:01 |
| * rbasak files bug 1741277 | 15:05 | |
| ubottu | bug 1741277 in cloud-init (Ubuntu) "manage_etc_hosts default is unhelpful" [Undecided,New] https://launchpad.net/bugs/1741277 | 15:05 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| ubottu | 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:19 |
| 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:20 |
| 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:21 |
| rbasak | That's interesting | 15:22 |
| smoser | TJ-: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1730744 | 15:23 |
| ubottu | Launchpad bug 1730744 in systemd (Ubuntu) "sudo is slow (10 seconds) when hostname is not resolvable" [Undecided,New] | 15:23 |
| smoser | that is related | 15:23 |
| smoser | i came to the party late | 15:24 |
| smoser | is that the bug that was originally being raised. | 15:24 |
| rbasak | I suppose the real intention of my bug is "not all platforms running cloud-init make the system hostname resolveable by default" | 15:25 |
| 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:26 |
| smoser | well, all this is part of why i leave it untouched. | 15:27 |
| TJ- | right, the case was a default 17.10 install too. | 15:28 |
| ahasenack | hi, can someone please import ubuntu-fan into the ubuntu server git repo? | 16:02 |
| ahasenack | rbasak: cpaelzer ^ | 16:02 |
| cpaelzer | ahasenack: I'll do so | 16:03 |
| 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:04 |
| ahasenack | nothing in there | 16:05 |
| ahasenack | not even a single url | 16:05 |
| 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:06 |
| ahasenack | cpaelzer: beware the launchpad login oauth token prompt, it's easily missed | 16:09 |
| nacc | cpaelzer: please also add to whitellist | 16:12 |
| cpaelzer | nacc: what would happen if we don't other than getting out of sny? | 16:14 |
| cpaelzer | sync | 16:14 |
| 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:15 |
| cpaelzer | ahasenack: imported | 16:19 |
| cpaelzer | nacc: added to whitelist | 16:19 |
| nacc | cpaelzer: thx | 16:19 |
| cpaelzer | rbasak: I didn't realize what you meant with a fetch being needed along that | 16:20 |
| cpaelzer | anything I should do? | 16:20 |
| ahasenack | !kpti | 16:23 |
| ubottu | 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:23 |
| 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:27 |
| 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:28 |
| 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:39 |
| Neo4 | ??? | 16:40 |
| Neo4 | in ubuntu-server guide I've read it is possible | 16:40 |
| Neo4 | but not recommended, why? | 16:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| Neo4 | :) | 16:52 |
| Neo4 | ok | 16:52 |
| 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 | 16:53 | |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| ahasenack | but host is bionic, netplan all the way | 19:26 |
| ahasenack | hm | 19:26 |
| 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:27 |
| 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:28 |
| ahasenack | but why would 127.0.0.53 not even try the root servers | 19:30 |
| ahasenack | I think it's in a loop | 19:35 |
| 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:08 |
| 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 ;) | 20:09 |
| patdk-lap | odd, everyone has released patches now, except ubuntu :( | 22:40 |
| dax | to be fair, Debian only *just* released | 22:55 |
| 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:13 |
| mason | Ah, but https://lists.debian.org/debian-security-announce/2018/msg00000.html | 23:16 |
| oerheks | https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/ | 23:21 |
| oerheks | "everyone has released patches now" ??? | 23:21 |
| TJ- | patches are great, what we need is built and published binaries :D | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!