[00:01] <nacc> slashd: thanks for the prompt help there
[01:35] <cliluw> Where do I find the debug symbols for SSSD? I don't see a sssd-dbg package.
[01:37] <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:38] <sarnold> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
[01:39] <cliluw> sarnold: That's very informative. Thank you!
[05:51] <tsimonq2> Hey hey :)
[06:14] <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:27] <cpaelzer> good morning
[07:00] <cpaelzer> nacc: thanks for your reply on the MP, I'm one level further on actually understanding what it is about
[07:01] <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:03] <lordievader> Good morning
[07:07] <cpaelzer> hiho lordievader
[07:08] <lordievader> Hey cpaelzer
[07:08] <lordievader> How are you doing?
[07:14] <cpaelzer> as I should :-)
[07:14] <cpaelzer> and you?
[07:20] <lordievader> Doing good here :)
[07:20] <cpaelzer> glad to hear that
[07:58] <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 ?
[08:01] <cpaelzer> promach_: you have 100% loss of your ping
[08:01] <cpaelzer> so the assumption would be that you cannot be routed there
[08:02] <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:04] <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:05] <cpaelzer> and you connected via ssh over local network?
[08:06] <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:07] <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:08] <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:09] <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:10] <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:11] <promach_> https://www.diffchecker.com/JlL4Hy5x
[08:11] <cpaelzer> I won't recommend on network setup in general
[08:12] <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:13] <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:14] <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:15] <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:16] <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:52] <joelio> any idea what time the kernel patches land? thanks
[09:05] <rbasak> joelio: please keep all spectre/meltdown discussion in #ubuntu-hardened.
[09:05] <rbasak> People in this channel don't know.
[09:31] <joelio> rbasak: sure, didn't know that was a channel!
[15:42] <nacc> cpaelzer: +1 thank you!
[16:27] <cpaelzer> nacc: the needs-review -> WIP changes are outdated things you want to update first?
[16:58] <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:59] <patdk-lap> yes, yes
[17:00] <sdeziel> mtl: you'll be moving to 4.13 (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown)
[17:01] <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:09] <mtl> there's 4.13 package but I think I should just wait for the upgrade?
[17:12] <sdeziel> mtl: you want at least 4.13.0-25.29 for Meltdown
[17:20] <nacc> cpaelzer: yeah
[18:01] <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:03] <coreycb> mwhahaha: i think it typically corresponds to the service
[18:04] <mwhahaha> ok wasn't sure if it was usually like adm or something as i've seen that for some stuff
[18:05] <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:06] <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:08] <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:09] <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:10] <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:11] <coreycb> mwhahaha: ok makes sense
[18:40] <DexterF> hi
[18:49] <dpb1> o/
[18:52] <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:53] <DexterF> "wlx74da38e18cfb" namely - sounds odd, is this the wifi dev..?
[18:53] <sdeziel> DexterF: yes as it has the "wl" prefix
[18:54] <nacc> powersj: fyi, i just reproduced our ci issue on bionic on my laptop
[18:55] <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:56] <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:57] <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:58] <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:59] <nacc> calling /usr/bin/lxc from a classic snap, where SNAP will be set, means /usr/bin/lxc thinks it is a snap :)
[19:00] <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:01] <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:02] <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:04] <powersj> nacc: I could unassign myself, but not assign
[19:04] <nacc> powersj: ok
[19:04] <nacc> powersj: i'll fix it
[19:08] <nacc> stgraber: i don't have a repo in front of me, was that introduced with 2.0.21?
[19:09] <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:10] <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:11] <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:14] <nacc> i wonder if this is a snapd change
[19:18] <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:19] <powersj> which shows snapcraft, but no snapd upgrade till new year
[19:22] <nacc> yeah it's weird
[19:27] <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:29] <nacc> powersj: about to propose the MP, one sec
[19:32] <nacc> powersj: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/335900
[19:33] <powersj> ok :) now let's watch ci pass
[20:28] <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:29] <nacc> powersj: ok, the job still failed, i'm looking
[20:29] <powersj> we do all the testing in a vm
[20:33] <DexterF> why do wifi interfaces have these terribly cryptic names in u/s? 16.04?
[20:34] <DexterF> [10425.671179] rtl8192cu 1-3:1.0 wlxe84e0633374f: renamed from wlan0
[20:34] <DexterF> wlan0 would have been nice actually
[20:35] <nacc> DexterF: feel like you are 2+ years too late to the party: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[20:36] <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:38] <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
[21:10] <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:11] <TJ-> gunix: kernels are in testing, some possible regressions still being investigated
[21:12] <gunix> TJ-: so debian released the kernel update without testing?
[21:24] <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:25] <gunix> TJ-: redhat had to backport to kernel 3 ... i'm not amazed
[21:29] <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:31] <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:33] <Odd_Bloke> -108 just migrated to -security, should be available to install on machines any minuten now.
[22:28] <cyphermox> mdew: I think you want to set "accept-ra: no"
[22:28] <cyphermox> otoh, you're talking about the link-local address...
[22:32] <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:33] <mdew> cyphermox: net.ipv6.conf.default(and eth0, and lo, and all).accept_ra=0, as well as .autoconf=0
[22:34] <cyphermox> mdew: right, but this is something else
[22:36] <mdew> cyphermox: "something else?" are you speaking in regards to the netplan yaml config, or..?
[22:37] <cyphermox> mdew: both really
[22:37] <cyphermox> netplan does not currently support this
[22:38] <cyphermox> systemd *might*, but I'd want to test it first to see if it really does the right thing
[22:39] <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:41] <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:42] <tsimonq2> (upped two times instead of one)
[22:47] <gunix> TJ-: ubuntu 16.04 is LTS distro so people expect to have the LTS kernel on it, not 4.13
[22:48] <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:51] <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:53] <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:54] <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:55] <cyphermox> mdew: if there's anything, there's #netplan, don't hesitate :)
[23:25] <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:26] <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:28] <stgraber> nacc: hmm, our test is litteraly os.Getenv("SNAP") != "", so unsetting should do the right thing...
[23:28] <nacc> stgraber: yeah
[23:29] <nacc> stgraber: there's not an easy way for me to debug that, is there?
[23:32] <stgraber> nacc: so you're seeing it attempt to connect to the wrong socket path?
[23:33] <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:34] <nacc> stgraber: yeah, it's `lxc file push` that's failing for us
[23:35] <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:37] <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:38] <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:39] <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:40] <nacc> stgraber: oh bother
[23:40] <nacc> stgraber: i see it now
[23:40] <nacc> stgraber: totally my fault
[23:41] <nacc> stgraber: does the hostpath stuff affect pull too?
[23:42] <stgraber> yep
[23:42] <nacc> stgraber: ok, let me test this fix
[23:47] <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:51] <stgraber> :)