| nacc | slashd: thanks for the prompt help there | 00:01 |
|---|---|---|
| cliluw | Where do I find the debug symbols for SSSD? I don't see a sssd-dbg package. | 01:35 |
| sarnold | cliluw: probably http://ddebs.ubuntu.com/ | 01:37 |
| sarnold | sweet http://ddebs.ubuntu.com/pool/main/s/sssd/ | 01:37 |
| sarnold | cliluw: there's a handy way to add that repo to apt so you can use it exactly as you wish | 01:37 |
| sarnold | https://wiki.ubuntu.com/Debug%20Symbol%20Packages | 01:38 |
| cliluw | sarnold: That's very informative. Thank you! | 01:39 |
| tsimonq2 | Hey hey :) | 05:51 |
| nacc | rbasak: fyi, i think it makes sense to stack all of my importer changes on top of yours -- turns out it actually rebased really easily; now to break it up so you can review :) | 06:14 |
| cpaelzer | good morning | 06:27 |
| cpaelzer | nacc: thanks for your reply on the MP, I'm one level further on actually understanding what it is about | 07:00 |
| cpaelzer | I'll try my luck on discussing it again - which hopefully is again either helpful or drives it to be more understandable in general :-) | 07:01 |
| lordievader | Good morning | 07:03 |
| cpaelzer | hiho lordievader | 07:07 |
| lordievader | Hey cpaelzer | 07:08 |
| lordievader | How are you doing? | 07:08 |
| cpaelzer | as I should :-) | 07:14 |
| cpaelzer | and you? | 07:14 |
| lordievader | Doing good here :) | 07:20 |
| cpaelzer | glad to hear that | 07:20 |
| promach_ | hi, I have https://paste.ubuntu.com/26351812/ but I still could not connect to internet for one of my Ubuntu box. May I know why ? | 07:58 |
| cpaelzer | promach_: you have 100% loss of your ping | 08:01 |
| cpaelzer | so the assumption would be that you cannot be routed there | 08:01 |
| cpaelzer | promach_: what kind of setup is that - home setup with computer+router or something more complex? | 08:02 |
| promach_ | cpaelzer: I connected to my Ubuntu box through SSH | 08:02 |
| cpaelzer | so you have your system you are sitting in fornt of - and a box that you have connected to via ssh? | 08:04 |
| promach_ | yes | 08:04 |
| cpaelzer | and you connected via ssh over local network? | 08:05 |
| promach_ | local ==> My desktop connects to one ethernet port, my ubuntu box is connected to another. They are not physically connected | 08:06 |
| promach_ | local ==> My desktop connects to one ethernet socket, my ubuntu box is connected to another ethernet socket. They are not physically connected | 08:06 |
| cpaelzer | ok both plugged on the same local switch or router then I'd guess | 08:06 |
| promach_ | I suppose | 08:07 |
| cpaelzer | promach_: is your Desktop linux as well? | 08:07 |
| promach_ | yes | 08:07 |
| cpaelzer | ok, then for a start compare the network and routing of both | 08:07 |
| cpaelzer | that would be something like | 08:07 |
| promach_ | both my desktop and my box are using Ubuntu | 08:07 |
| cpaelzer | ip route show | 08:07 |
| cpaelzer | and | 08:07 |
| cpaelzer | ip addr show | 08:08 |
| promach_ | for my box ? | 08:08 |
| cpaelzer | promach_: do the following on both boxes | 08:08 |
| cpaelzer | (ip addr show; ip route show) |& pastebinit | 08:08 |
| cpaelzer | well if you have no internet that won't help too much | 08:08 |
| cpaelzer | but call the commands (without the redirection to pastebinit | 08:08 |
| cpaelzer | and compare the output | 08:09 |
| promach_ | ok | 08:09 |
| cpaelzer | your desktop should have routing set up correctly (we see you here) - but the other system seems to differ | 08:09 |
| cpaelzer | your config has manually set gateway 172.21.150.1 on the server | 08:10 |
| cpaelzer | in case this is the wrong thing you should fix it | 08:10 |
| cpaelzer | your desktop works so check what it has | 08:10 |
| cpaelzer | and that ip route show will tell you | 08:10 |
| promach_ | https://www.diffchecker.com/JlL4Hy5x | 08:11 |
| cpaelzer | I won't recommend on network setup in general | 08:11 |
| cpaelzer | but it seems your gateway should be 172.21.151.254 | 08:12 |
| promach_ | so, nameserver 172.21.151.254 for ubuntu box ? | 08:12 |
| cpaelzer | why not just use dhcp, that likely just works? | 08:12 |
| promach_ | I need static IP | 08:12 |
| cpaelzer | I'd still recommend telling your dhcp server to make the ip reliable | 08:13 |
| cpaelzer | but the shortest path to solve this for now is to set gateway to the address above | 08:13 |
| promach_ | ok, now rebooting my ubuntu box after gateway address modification | 08:14 |
| cpaelzer | no need to fully reboot | 08:14 |
| cpaelzer | but I assume you triggered it already | 08:14 |
| promach_ | already rebooted | 08:15 |
| promach_ | root@localhost:~# cat /etc/resolv.conf | 08:15 |
| promach_ | # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) | 08:15 |
| promach_ | # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN | 08:15 |
| promach_ | nameserver 8.8.8.8 | 08:15 |
| promach_ | nameserver 8.8.8.8 | 08:15 |
| promach_ | nameserver 8.8.4.4 | 08:15 |
| promach_ | nameserver 172.21.151.254 | 08:15 |
| promach_ | root@localhost:~# | 08:15 |
| promach_ | thanks. | 08:16 |
| promach_ | I could do | 08:16 |
| promach_ | apt-get update | 08:16 |
| promach_ | now | 08:16 |
| promach_ | cpaelzer | 08:16 |
| cpaelzer | ok, have fun promach_ | 08:16 |
| promach_ | ok | 08:16 |
| joelio | any idea what time the kernel patches land? thanks | 08:52 |
| rbasak | joelio: please keep all spectre/meltdown discussion in #ubuntu-hardened. | 09:05 |
| rbasak | People in this channel don't know. | 09:05 |
| joelio | rbasak: sure, didn't know that was a channel! | 09:31 |
| === MannerMan_ is now known as MannerMan | ||
| === albech1 is now known as albech | ||
| === albech2 is now known as albech1 | ||
| nacc | cpaelzer: +1 thank you! | 15:42 |
| cpaelzer | nacc: the needs-review -> WIP changes are outdated things you want to update first? | 16:27 |
| mtl | I have been running kernel 4.10.0-30-generic for 153 days on Xenial, will there be a security kernel upgrade soon and do I need to reboot my server? | 16:58 |
| patdk-lap | yes, yes | 16:59 |
| sdeziel | mtl: you'll be moving to 4.13 (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown) | 17:00 |
| ScottE | No fixes for 4.10 per https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown - see the very bottom | 17:01 |
| ScottE | Whoops, sorry sdeziel - beat me to it :-) | 17:01 |
| mtl | there's 4.13 package but I think I should just wait for the upgrade? | 17:09 |
| sdeziel | mtl: you want at least 4.13.0-25.29 for Meltdown | 17:12 |
| nacc | cpaelzer: yeah | 17:20 |
| mwhahaha | coreycb, jamespage: what is the default groups that are used for the services? is there a special group or is it just a group named after the service? ie heat, zaqar, etc | 18:01 |
| coreycb | mwhahaha: i think it typically corresponds to the service | 18:03 |
| mwhahaha | ok wasn't sure if it was usually like adm or something as i've seen that for some stuff | 18:04 |
| coreycb | mwhahaha: i just grepped a few to be sure, and they correspond to the service. there may be some exceptions that i didn't come across, but in general this is the case at least. | 18:05 |
| mwhahaha | sounds good, the policy.json file is going away and it used to be root:<service> so i'm needing to handle that in -puppet for continuity | 18:06 |
| coreycb | mwhahaha: ah right, the defaults are moving into the code now | 18:08 |
| mwhahaha | yea so in RDO we're dropping the files | 18:08 |
| mwhahaha | but the way we manage the files in puppet assumes the existence of such files :D | 18:09 |
| mwhahaha | i think it's always been broken for ubuntu tho | 18:09 |
| mwhahaha | cause i'm not sure if they exist or not | 18:09 |
| coreycb | mwhahaha: well you should be able to just drop them for ubuntu if you want the defaults | 18:10 |
| mwhahaha | right, we have an optional ability to update the existing ones (or add new ones) | 18:10 |
| coreycb | mwhahaha: ok makes sense | 18:11 |
| DexterF | hi | 18:40 |
| dpb1 | o/ | 18:49 |
| DexterF | installed minimal ubuntu server and now want to turn it into an AP via a usb 11n stick. I'm fairly green with routing/AP setup and hostapd gives me trouble. so far I installed hostapd and dnsmasqd, modified a sample hostapd.conf and ran it against a strangely cryptic device name which according to ifconfig -a is the wifi device | 18:52 |
| DexterF | "wlx74da38e18cfb" namely - sounds odd, is this the wifi dev..? | 18:53 |
| sdeziel | DexterF: yes as it has the "wl" prefix | 18:53 |
| nacc | powersj: fyi, i just reproduced our ci issue on bionic on my laptop | 18:54 |
| nacc | powersj: are we using x-backports in CI? | 18:55 |
| Ussat | DexterF, why ??? buy a cheap AP and be done with it | 18:55 |
| powersj | nacc: interesting, when I ran it using the integration-test script, which launches a xenial cloud image to the testing it reproduced as well, but when I built the snap locally and installed it, everything worked | 18:55 |
| nacc | powersj: which snap locally? | 18:55 |
| nacc | powersj: i think it's a lxd bug | 18:55 |
| powersj | master | 18:55 |
| nacc | powersj: so you built the git-ubuntu snap, installed it, then ran the integrationn test using that snap: | 18:56 |
| powersj | git-ubuntu from master (to be more clear) | 18:56 |
| nacc | ? | 18:56 |
| powersj | The failure seems to come from when you run your in-tree integration test, specifically | 18:56 |
| powersj | git-ubuntu build-source | 18:56 |
| DexterF | Ussat, last resort option. long story. | 18:56 |
| nacc | powersj: right, build-source launches a container | 18:56 |
| nacc | powersj: did you try that on your host? | 18:56 |
| DexterF | this is hostapd -dd https://pastebin.com/Aaeuavvu | 18:56 |
| powersj | nacc: yes and that is what worked and completed as expected | 18:56 |
| nacc | powersj: that's what fails on bionic | 18:57 |
| powersj | nacc: https://paste.ubuntu.com/26354741/ | 18:57 |
| nacc | powersj: does your host have x-backports enabled? | 18:57 |
| powersj | nacc: no I'm running artful and using the lxc/lxd snap | 18:57 |
| nacc | ah | 18:57 |
| DexterF | tells me a lot but not exactly what's a warning, what's a rightful error and its state. does not seem to be working though. | 18:57 |
| powersj | which I think is the same version of x-backports | 18:57 |
| nacc | powersj: i think that's the difference | 18:57 |
| nacc | found the bug | 18:57 |
| powersj | ok :) | 18:57 |
| nacc | (I think) | 18:57 |
| nacc | lol | 18:58 |
| nacc | any snap that calls the host's LXC is busted | 18:58 |
| nacc | stgraber: --^ | 18:58 |
| nacc | https://paste.ubuntu.com/26354780/ | 18:58 |
| nacc | calling /usr/bin/lxc from a classic snap, where SNAP will be set, means /usr/bin/lxc thinks it is a snap :) | 18:59 |
| stgraber | hmm, indeed, not sure what we can really do about that, all the other env variables are likely to be just as wrong :) | 19:00 |
| nacc | stgraber: yeah | 19:00 |
| nacc | stgraber: i *could* unset the SNAP env variables in that subcommand's call | 19:00 |
| nacc | that entails a lot of knowledge of lxd in our code :) | 19:01 |
| nacc | well, "a lot" == any :) | 19:01 |
| nacc | powersj: so you're off the hook, can you re-assign the bug to me? | 19:01 |
| powersj | nacc: will do! | 19:01 |
| stgraber | we could change the logic in LXD to check for some other variable that we set in the snap wrappers but that'd take a while for us to do as we don't have any planned LXD releases until 3.0 | 19:02 |
| nacc | stgraber: yeah -- i can do the above in our code for now, with a comment | 19:02 |
| nacc | it would be nice if there was some way to know you're a re-exec from snapd, but i suppose that's something that should be transparent to the child | 19:02 |
| powersj | nacc: I could unassign myself, but not assign | 19:04 |
| nacc | powersj: ok | 19:04 |
| nacc | powersj: i'll fix it | 19:04 |
| nacc | stgraber: i don't have a repo in front of me, was that introduced with 2.0.21? | 19:08 |
| stgraber | probably around 2.18 for the feature releases and definitely 2.0.11 for the LTS | 19:09 |
| stgraber | 2.0.11 is the first LXD LTS release to work as a snap | 19:09 |
| nacc | hrm, strange that we only started hittig this recently | 19:10 |
| nacc | stgraber: or was that a typo? 2.0.11 is what is in x-updated | 19:10 |
| stgraber | 2.0.11 is the latest LXD LTS release and what's currently in xenial-updates | 19:11 |
| nacc | stgraber: ok, just double-checking | 19:11 |
| nacc | i wonder if this is a snapd change | 19:14 |
| powersj | nacc: builds started failing on build 119 which was Dec 11 according to jenkins | 19:18 |
| powersj | here is the upgrade log: https://paste.ubuntu.com/26354850/ | 19:18 |
| powersj | which shows snapcraft, but no snapd upgrade till new year | 19:19 |
| nacc | yeah it's weird | 19:22 |
| nacc | well that works | 19:27 |
| nacc | powersj: and i think, funnily, if i run the job with the fix, it will pass CI :) | 19:27 |
| powersj | awesome | 19:27 |
| powersj | have a diff? | 19:27 |
| nacc | powersj: about to propose the MP, one sec | 19:29 |
| nacc | powersj: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/335900 | 19:32 |
| powersj | ok :) now let's watch ci pass | 19:33 |
| === Neo5 is now known as Neo4 | ||
| nacc | powersj: just to confirm, the git-ubuntu ci is still using lxd as a deb, right? | 20:28 |
| powersj | nacc: correct, it uses the lxd that comes with the xenial cloud image | 20:28 |
| nacc | powersj: ok, the job still failed, i'm looking | 20:29 |
| powersj | we do all the testing in a vm | 20:29 |
| DexterF | why do wifi interfaces have these terribly cryptic names in u/s? 16.04? | 20:33 |
| DexterF | [10425.671179] rtl8192cu 1-3:1.0 wlxe84e0633374f: renamed from wlan0 | 20:34 |
| DexterF | wlan0 would have been nice actually | 20:34 |
| nacc | DexterF: feel like you are 2+ years too late to the party: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 20:35 |
| nacc | DexterF: it's been that way since 16.04, at lleast | 20:36 |
| nacc | DexterF: you can disable it if you want, but it does solve a large class of problems | 20:36 |
| mdeslaur | such as making the systemd gods angry | 20:38 |
| nacc | mdeslaur: :) | 20:38 |
| mdeslaur | ;) | 20:38 |
| DexterF | ok, if that's a legitimate dev name then. still cannot figure why hostapd tears down the AP again but I guess that's one for the forums | 20:38 |
| mdew | Hello. Has anyone had any luck disabling EUI64 IPv6 addresses on 17.10? I've applied a static IPv6 address via netplan, but it's still leasing that address 'link-local' to my eth0. | 21:10 |
| gunix | guys, when is ubuntu releasing kernel update for meltdown security vulnerability for 16.04? the latest kernel from repo is from dec 11 and it's vulnerbale | 21:10 |
| TJ- | gunix: kernels are in testing, some possible regressions still being investigated | 21:11 |
| gunix | TJ-: so debian released the kernel update without testing? | 21:12 |
| === lol768_ is now known as lol768 | ||
| TJ- | gunix: you'd have to ask Debian that. There are many variations of the Ubuntu kernel images requires a lot of testing. Some Red Hat/CentOS systems have been suffering inability to boot after applying the RHEL patches too. | 21:24 |
| gunix | TJ-: redhat had to backport to kernel 3 ... i'm not amazed | 21:25 |
| TJ- | gunix: the 4.13 kernel is -proposed right now, for wider testing, and a later version is in the kernel PTI PPA | 21:29 |
| gunix | TJ-: kernel 4.13 is proposed for whaT? | 21:29 |
| gunix | TJ-: arch is on 4.15, deb is on 4.9, ubuntu LTS is on 4.4 :D | 21:29 |
| TJ- | gunix: 4.13 is the hwe-edge kernel for 16.04; the current 4.10 hwe (from 17.04) is out of support on 13th Jan so no patches being applied to that. 4.4.0-108.131 is currently in the kernel PTI PPA | 21:31 |
| Odd_Bloke | -108 just migrated to -security, should be available to install on machines any minuten now. | 21:33 |
| cyphermox | mdew: I think you want to set "accept-ra: no" | 22:28 |
| cyphermox | otoh, you're talking about the link-local address... | 22:28 |
| mdew | cyphermox: I have accept_ra=0 in sysctl, but no luck. I am talking about the link-local address. I'm able to remove it via 'ip addr delete', but I'd like it to not even try to get that address on boot. | 22:32 |
| mdew | cyphermox: net.ipv6.conf.default(and eth0, and lo, and all).accept_ra=0, as well as .autoconf=0 | 22:33 |
| cyphermox | mdew: right, but this is something else | 22:34 |
| mdew | cyphermox: "something else?" are you speaking in regards to the netplan yaml config, or..? | 22:36 |
| cyphermox | mdew: both really | 22:37 |
| cyphermox | netplan does not currently support this | 22:37 |
| cyphermox | systemd *might*, but I'd want to test it first to see if it really does the right thing | 22:38 |
| cyphermox | mdew: the true "link-local" addresses over fe80:: can't currently be disabled via netplan, accept-ra is to disable SLAAC using the prefix coming from RAs | 22:39 |
| cyphermox | mdew: please file a bug at https://bugs.launchpad.net/netplan/+filebug so I don't forget to implement this | 22:41 |
| tsimonq2 | o/ | 22:41 |
| tsimonq2 | grr | 22:41 |
| tsimonq2 | (upped two times instead of one) | 22:42 |
| gunix | TJ-: ubuntu 16.04 is LTS distro so people expect to have the LTS kernel on it, not 4.13 | 22:47 |
| Odd_Bloke | gunix: 4.13 is more recent, so the patches were easier to apply there (and there's less risk), which I believe is why it landed first. | 22:48 |
| Odd_Bloke | gunix: That said, the LTS kernel is now available in xenial-security. :) | 22:48 |
| mdew | cyphermox: I misinformed what I was talking about. It wasn't the link-local, but a couple of other IPs in a similar net-space that I had statically assigned. EUI64. I attempted to apply 'accept-ra: no' in the yaml config before you had responded, applied, and rebooted. Came back up without those other two global IPs, just the one that I assigned, and the link-local. So I think I've got it figured out. | 22:51 |
| mdew | Thanks | 22:51 |
| gunix | Odd_Bloke: checking now, i hope it exists on the mirror from romania | 22:53 |
| gunix | Odd_Bloke: TJ-: yes, the kernel update is here! | 22:53 |
| Odd_Bloke | gunix: :) | 22:54 |
| Odd_Bloke | gunix: To avoid relying on your mirror for important security updates, it's recommended to keep security.ubuntu.com in your sources.list for -security. | 22:54 |
| cyphermox | mdew: alright | 22:54 |
| cyphermox | mdew: if there's anything, there's #netplan, don't hesitate :) | 22:55 |
| nacc | stgraber: hrm, so i'm doing a bunch of logging and i see that i'm correclty unsetting SNAP in the env before calling lxc. But it still is using /var/lib/snapd/hostfs ... any ideas? | 23:25 |
| keithzg | Oho, here I was refreshing https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-5754.html wheras I should've just been `apt update`ing! | 23:26 |
| stgraber | nacc: hmm, our test is litteraly os.Getenv("SNAP") != "", so unsetting should do the right thing... | 23:28 |
| nacc | stgraber: yeah | 23:28 |
| nacc | stgraber: there's not an easy way for me to debug that, is there? | 23:29 |
| stgraber | nacc: so you're seeing it attempt to connect to the wrong socket path? | 23:32 |
| nacc | stgraber: first line is the env sent to subprocess.run | 23:33 |
| stgraber | hmm, actually, that wouldn't make sense, the socket path is determined based on the LXD_DIR env variable (if present), so I'm guessing you're talking about file transfers or something else that uses paths? | 23:33 |
| nacc | stgraber: yeah, it's `lxc file push` that's failing for us | 23:34 |
| nacc | stgraber: you cann see line 4 is passing a normal host path and then line 6 is using snapped-path | 23:35 |
| stgraber | nacc: line 4 of? | 23:35 |
| nacc | the pastebin | 23:35 |
| nacc | bah which i didn't paste! | 23:35 |
| nacc | https://paste.ubuntu.com/26356323/ | 23:35 |
| nacc | stgraber: sorry! | 23:35 |
| stgraber | :) | 23:35 |
| stgraber | nacc: not sure what to tell you, the only mention of the /var/lib/snapd/hostfs path in our entire codebase is in our HostPath() function here https://github.com/lxc/lxd/blob/master/shared/util.go#L106 | 23:37 |
| nacc | stgraber: yep, that's where i saw the bit about SNNAP | 23:38 |
| nacc | *SNAP | 23:38 |
| stgraber | nacc: and an unset/empty SNAP should definitely get you out of there (3rd if) | 23:38 |
| nacc | yep | 23:38 |
| stgraber | nacc: just for fun, did you try running /usr/bin/env rather than "lxc", do see what the actual env is for a subcommand? | 23:39 |
| nacc | stgraber: let me do that now | 23:39 |
| nacc | stgraber: oh bother | 23:40 |
| nacc | stgraber: i see it now | 23:40 |
| nacc | stgraber: totally my fault | 23:40 |
| nacc | stgraber: does the hostpath stuff affect pull too? | 23:41 |
| stgraber | yep | 23:42 |
| nacc | stgraber: ok, let me test this fix | 23:42 |
| nacc | stgraber: i was dumbly changing the env of commands run with `lxc exec ...` rather than the `lxc file ...` commands | 23:47 |
| nacc | stgraber: so the one place it matters wasn't being affected :) | 23:47 |
| stgraber | :) | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!