[00:01] slashd: thanks for the prompt help there [01:35] Where do I find the debug symbols for SSSD? I don't see a sssd-dbg package. [01:37] cliluw: probably http://ddebs.ubuntu.com/ [01:37] sweet http://ddebs.ubuntu.com/pool/main/s/sssd/ [01:37] cliluw: there's a handy way to add that repo to apt so you can use it exactly as you wish [01:38] https://wiki.ubuntu.com/Debug%20Symbol%20Packages [01:39] sarnold: That's very informative. Thank you! [05:51] Hey hey :) [06:14] 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] good morning [07:00] nacc: thanks for your reply on the MP, I'm one level further on actually understanding what it is about [07:01] 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] Good morning [07:07] hiho lordievader [07:08] Hey cpaelzer [07:08] How are you doing? [07:14] as I should :-) [07:14] and you? [07:20] Doing good here :) [07:20] glad to hear that [07:58] 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] promach_: you have 100% loss of your ping [08:01] so the assumption would be that you cannot be routed there [08:02] promach_: what kind of setup is that - home setup with computer+router or something more complex? [08:02] cpaelzer: I connected to my Ubuntu box through SSH [08:04] so you have your system you are sitting in fornt of - and a box that you have connected to via ssh? [08:04] yes [08:05] and you connected via ssh over local network? [08:06] local ==> My desktop connects to one ethernet port, my ubuntu box is connected to another. They are not physically connected [08:06] local ==> My desktop connects to one ethernet socket, my ubuntu box is connected to another ethernet socket. They are not physically connected [08:06] ok both plugged on the same local switch or router then I'd guess [08:07] I suppose [08:07] promach_: is your Desktop linux as well? [08:07] yes [08:07] ok, then for a start compare the network and routing of both [08:07] that would be something like [08:07] both my desktop and my box are using Ubuntu [08:07] ip route show [08:07] and [08:08] ip addr show [08:08] for my box ? [08:08] promach_: do the following on both boxes [08:08] (ip addr show; ip route show) |& pastebinit [08:08] well if you have no internet that won't help too much [08:08] but call the commands (without the redirection to pastebinit [08:09] and compare the output [08:09] ok [08:09] your desktop should have routing set up correctly (we see you here) - but the other system seems to differ [08:10] your config has manually set gateway 172.21.150.1 on the server [08:10] in case this is the wrong thing you should fix it [08:10] your desktop works so check what it has [08:10] and that ip route show will tell you [08:11] https://www.diffchecker.com/JlL4Hy5x [08:11] I won't recommend on network setup in general [08:12] but it seems your gateway should be 172.21.151.254 [08:12] so, nameserver 172.21.151.254 for ubuntu box ? [08:12] why not just use dhcp, that likely just works? [08:12] I need static IP [08:13] I'd still recommend telling your dhcp server to make the ip reliable [08:13] but the shortest path to solve this for now is to set gateway to the address above [08:14] ok, now rebooting my ubuntu box after gateway address modification [08:14] no need to fully reboot [08:14] but I assume you triggered it already [08:15] already rebooted [08:15] root@localhost:~# cat /etc/resolv.conf [08:15] # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) [08:15] # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN [08:15] nameserver 8.8.8.8 [08:15] nameserver 8.8.8.8 [08:15] nameserver 8.8.4.4 [08:15] nameserver 172.21.151.254 [08:15] root@localhost:~# [08:16] thanks. [08:16] I could do [08:16] apt-get update [08:16] now [08:16] cpaelzer [08:16] ok, have fun promach_ [08:16] ok [08:52] any idea what time the kernel patches land? thanks [09:05] joelio: please keep all spectre/meltdown discussion in #ubuntu-hardened. [09:05] People in this channel don't know. [09:31] rbasak: sure, didn't know that was a channel! === MannerMan_ is now known as MannerMan === albech1 is now known as albech === albech2 is now known as albech1 [15:42] cpaelzer: +1 thank you! [16:27] nacc: the needs-review -> WIP changes are outdated things you want to update first? [16:58] 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] yes, yes [17:00] mtl: you'll be moving to 4.13 (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown) [17:01] No fixes for 4.10 per https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown - see the very bottom [17:01] Whoops, sorry sdeziel - beat me to it :-) [17:09] there's 4.13 package but I think I should just wait for the upgrade? [17:12] mtl: you want at least 4.13.0-25.29 for Meltdown [17:20] cpaelzer: yeah [18:01] 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] mwhahaha: i think it typically corresponds to the service [18:04] ok wasn't sure if it was usually like adm or something as i've seen that for some stuff [18:05] 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] sounds good, the policy.json file is going away and it used to be root: so i'm needing to handle that in -puppet for continuity [18:08] mwhahaha: ah right, the defaults are moving into the code now [18:08] yea so in RDO we're dropping the files [18:09] but the way we manage the files in puppet assumes the existence of such files :D [18:09] i think it's always been broken for ubuntu tho [18:09] cause i'm not sure if they exist or not [18:10] mwhahaha: well you should be able to just drop them for ubuntu if you want the defaults [18:10] right, we have an optional ability to update the existing ones (or add new ones) [18:11] mwhahaha: ok makes sense [18:40] hi [18:49] o/ [18:52] 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] "wlx74da38e18cfb" namely - sounds odd, is this the wifi dev..? [18:53] DexterF: yes as it has the "wl" prefix [18:54] powersj: fyi, i just reproduced our ci issue on bionic on my laptop [18:55] powersj: are we using x-backports in CI? [18:55] DexterF, why ??? buy a cheap AP and be done with it [18:55] 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] powersj: which snap locally? [18:55] powersj: i think it's a lxd bug [18:55] master [18:56] powersj: so you built the git-ubuntu snap, installed it, then ran the integrationn test using that snap: [18:56] git-ubuntu from master (to be more clear) [18:56] ? [18:56] The failure seems to come from when you run your in-tree integration test, specifically [18:56] git-ubuntu build-source [18:56] Ussat, last resort option. long story. [18:56] powersj: right, build-source launches a container [18:56] powersj: did you try that on your host? [18:56] this is hostapd -dd https://pastebin.com/Aaeuavvu [18:56] nacc: yes and that is what worked and completed as expected [18:57] powersj: that's what fails on bionic [18:57] nacc: https://paste.ubuntu.com/26354741/ [18:57] powersj: does your host have x-backports enabled? [18:57] nacc: no I'm running artful and using the lxc/lxd snap [18:57] ah [18:57] 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] which I think is the same version of x-backports [18:57] powersj: i think that's the difference [18:57] found the bug [18:57] ok :) [18:57] (I think) [18:58] lol [18:58] any snap that calls the host's LXC is busted [18:58] stgraber: --^ [18:58] https://paste.ubuntu.com/26354780/ [18:59] calling /usr/bin/lxc from a classic snap, where SNAP will be set, means /usr/bin/lxc thinks it is a snap :) [19:00] 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] stgraber: yeah [19:00] stgraber: i *could* unset the SNAP env variables in that subcommand's call [19:01] that entails a lot of knowledge of lxd in our code :) [19:01] well, "a lot" == any :) [19:01] powersj: so you're off the hook, can you re-assign the bug to me? [19:01] nacc: will do! [19:02] 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] stgraber: yeah -- i can do the above in our code for now, with a comment [19:02] 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] nacc: I could unassign myself, but not assign [19:04] powersj: ok [19:04] powersj: i'll fix it [19:08] stgraber: i don't have a repo in front of me, was that introduced with 2.0.21? [19:09] probably around 2.18 for the feature releases and definitely 2.0.11 for the LTS [19:09] 2.0.11 is the first LXD LTS release to work as a snap [19:10] hrm, strange that we only started hittig this recently [19:10] stgraber: or was that a typo? 2.0.11 is what is in x-updated [19:11] 2.0.11 is the latest LXD LTS release and what's currently in xenial-updates [19:11] stgraber: ok, just double-checking [19:14] i wonder if this is a snapd change [19:18] nacc: builds started failing on build 119 which was Dec 11 according to jenkins [19:18] here is the upgrade log: https://paste.ubuntu.com/26354850/ [19:19] which shows snapcraft, but no snapd upgrade till new year [19:22] yeah it's weird [19:27] well that works [19:27] powersj: and i think, funnily, if i run the job with the fix, it will pass CI :) [19:27] awesome [19:27] have a diff? [19:29] powersj: about to propose the MP, one sec [19:32] powersj: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/335900 [19:33] ok :) now let's watch ci pass === Neo5 is now known as Neo4 [20:28] powersj: just to confirm, the git-ubuntu ci is still using lxd as a deb, right? [20:28] nacc: correct, it uses the lxd that comes with the xenial cloud image [20:29] powersj: ok, the job still failed, i'm looking [20:29] we do all the testing in a vm [20:33] why do wifi interfaces have these terribly cryptic names in u/s? 16.04? [20:34] [10425.671179] rtl8192cu 1-3:1.0 wlxe84e0633374f: renamed from wlan0 [20:34] wlan0 would have been nice actually [20:35] DexterF: feel like you are 2+ years too late to the party: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ [20:36] DexterF: it's been that way since 16.04, at lleast [20:36] DexterF: you can disable it if you want, but it does solve a large class of problems [20:38] such as making the systemd gods angry [20:38] mdeslaur: :) [20:38] ;) [20:38] 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] 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] 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] gunix: kernels are in testing, some possible regressions still being investigated [21:12] TJ-: so debian released the kernel update without testing? === lol768_ is now known as lol768 [21:24] 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] TJ-: redhat had to backport to kernel 3 ... i'm not amazed [21:29] gunix: the 4.13 kernel is -proposed right now, for wider testing, and a later version is in the kernel PTI PPA [21:29] TJ-: kernel 4.13 is proposed for whaT? [21:29] TJ-: arch is on 4.15, deb is on 4.9, ubuntu LTS is on 4.4 :D [21:31] 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] -108 just migrated to -security, should be available to install on machines any minuten now. [22:28] mdew: I think you want to set "accept-ra: no" [22:28] otoh, you're talking about the link-local address... [22:32] 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] cyphermox: net.ipv6.conf.default(and eth0, and lo, and all).accept_ra=0, as well as .autoconf=0 [22:34] mdew: right, but this is something else [22:36] cyphermox: "something else?" are you speaking in regards to the netplan yaml config, or..? [22:37] mdew: both really [22:37] netplan does not currently support this [22:38] systemd *might*, but I'd want to test it first to see if it really does the right thing [22:39] 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] mdew: please file a bug at https://bugs.launchpad.net/netplan/+filebug so I don't forget to implement this [22:41] o/ [22:41] grr [22:42] (upped two times instead of one) [22:47] TJ-: ubuntu 16.04 is LTS distro so people expect to have the LTS kernel on it, not 4.13 [22:48] 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] gunix: That said, the LTS kernel is now available in xenial-security. :) [22:51] 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] Thanks [22:53] Odd_Bloke: checking now, i hope it exists on the mirror from romania [22:53] Odd_Bloke: TJ-: yes, the kernel update is here! [22:54] gunix: :) [22:54] 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] mdew: alright [22:55] mdew: if there's anything, there's #netplan, don't hesitate :) [23:25] 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] 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] nacc: hmm, our test is litteraly os.Getenv("SNAP") != "", so unsetting should do the right thing... [23:28] stgraber: yeah [23:29] stgraber: there's not an easy way for me to debug that, is there? [23:32] nacc: so you're seeing it attempt to connect to the wrong socket path? [23:33] stgraber: first line is the env sent to subprocess.run [23:33] 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] stgraber: yeah, it's `lxc file push` that's failing for us [23:35] stgraber: you cann see line 4 is passing a normal host path and then line 6 is using snapped-path [23:35] nacc: line 4 of? [23:35] the pastebin [23:35] bah which i didn't paste! [23:35] https://paste.ubuntu.com/26356323/ [23:35] stgraber: sorry! [23:35] :) [23:37] 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] stgraber: yep, that's where i saw the bit about SNNAP [23:38] *SNAP [23:38] nacc: and an unset/empty SNAP should definitely get you out of there (3rd if) [23:38] yep [23:39] 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] stgraber: let me do that now [23:40] stgraber: oh bother [23:40] stgraber: i see it now [23:40] stgraber: totally my fault [23:41] stgraber: does the hostpath stuff affect pull too? [23:42] yep [23:42] stgraber: ok, let me test this fix [23:47] stgraber: i was dumbly changing the env of commands run with `lxc exec ...` rather than the `lxc file ...` commands [23:47] stgraber: so the one place it matters wasn't being affected :) [23:51] :)