[02:45] <genii-netbook> For Samsung ARTIK7, use the ARTIK10 install? https://developer.ubuntu.com/core/get-started/artik-5-10#alternative-install:-ubuntu-server-16.04-lts
[07:18] <lordievader> Good morning.
[07:18] <bitfawkes> hello
[07:18] <bitfawkes> can I ask for a question?
[07:19] <andol> bitfawkes: Yes
[07:19] <bitfawkes> andol: thanks
[07:19] <bitfawkes> I m trying to get vmware gui from remote server to localhost using ssh -X
[07:20] <bitfawkes> and I get the follow error message
[07:20] <bitfawkes> (vmware-modconfig:3286): Gtk-WARNING **: cannot open display: localhost:11.0
[07:20] <bitfawkes> I use ubuntu 14.04 server on both system and just on local is installed gnome
[07:22] <andol> bitfawkes: Might https://superuser.com/a/310201 be the answer? Is the remote sshd configured to allow X-forwardign?
[07:22] <bitfawkes> yes
[07:24] <bitfawkes> is configured to allow
[07:32] <lordievader> What command are you using to set up the X forwarding?
[07:34] <bitfawkes> ssh -X user@ip
[07:37] <bitfawkes> I did edit sshd_config
[07:38] <lordievader> You might have better luck with the -Y flag, that usually works better for me.
[07:38] <sarnold> try ssh -v to dump debug messages. sometimes you can spot it there. check logs on the host, you may get lucky
[07:38] <sarnold> lordievader: iirc debian patches ssh client to make -X automatically include -Y
[07:41] <sarnold> well now that I go looking for it I'm not finding it. try -Y. :)
[07:46] <b3h3m0th> Is it insescure to run ubuntu server without changing default root password?
[07:47] <sarnold> ubuntu does not set a root password
[08:24] <b3h3m0th> sarnold: that's what
[08:24] <b3h3m0th> that's why I mentioned "default" password
[08:25] <b3h3m0th> What are the security implications of not doing a "sudo passwd root" post installation ?
[08:25] <b3h3m0th> and deploying the server in production publicly
[08:26] <b3h3m0th> Without changing the built in root password
[08:33] <lordievader> sarnold: Ah, I did not know that, nice.
[08:34] <lordievader> b3h3m0th: In theory running that command is worse than not running the command.
[08:34] <lordievader> b3h3m0th: As sarnold said, root doesn't have a password. Thus anything you'd try as a password fails.
[08:56] <b3h3m0th> lordievader: then what is the hash stored in shadow against root ?
[08:59] <b3h3m0th> hash(salt+something) must evaluate to that right? lordievader sarnold
[09:01] <b3h3m0th> it's a valid $6 hash (sha512)
[09:03] <lordievader> Did you set a password?
[09:14] <_ruben> if there's a hash for root in /etc/shadow, someone ran passwd for that user
[09:15] <_ruben> by default the "hash" is *
[09:17] <b3h3m0th> lordievader: _ruben nope, no one did
[09:17] <b3h3m0th> wait, let me verify
[09:17] <b3h3m0th> with my old snapshot
[09:18] <_ruben> it's simple, ubuntu doesn't set a password for root by default. if there is a password set, it was done so "manually"
[09:19] <_ruben> (wouldn't be the first time someone did 'sudo passwd' instead of 'passwd'. been there, done that ;))
[09:19] <b3h3m0th> sorry guys, my bad
[09:19] <b3h3m0th> I was checking the wrong instance
[10:47] <_ruben> hehe
[10:49] <_ruben> now if only i could get idmapd to work for my nfs4 exports/shares
[13:39] <jamespage> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1665698 is a little confusing right?
[13:40] <cpaelzer> "a little" is a little underrated
[13:40] <cpaelzer> it is VERY confusing
[13:40] <cpaelzer> I tried to cover and add the bits I found, but by that it accumulated quite some text now
[13:41] <cpaelzer> If you are looking at/into that now please let me know if you have any need of clarification for the few posts I added
[13:41] <cpaelzer> I often come back to my post summarizing the timeline
[13:41] <cpaelzer> jamespage: that is the comment one should memorize
[13:42] <cpaelzer> jamespage: I'm really interested if you think Openstack in general or UCA would have to do something on top
[13:47] <jamespage> cpaelzer: I have updates in  proposed for newton which contain the fix that caused the problem, yet I see no problems (see last posting)
[13:48] <jamespage> cpaelzer: we're not going to put yakkety libvirt into the UCA for newton; its closed to a bump like that
[13:49] <cpaelzer> jamespage: I never wanted to suggest to put yakkety libvirt into UCA-Newton
[13:49] <cpaelzer> jamespage: all the references were only parts of my analysis on the timeline
[13:50] <jamespage> cpaelzer: no worries - I realised that
[13:50] <zul> jamespage/coreycb: there is a newer version of horizon for ocata btw
[13:50] <cpaelzer> jamespage: your latest update is good
[13:51] <cpaelzer> jamespage: IMHO it is only showing the issue when running openstack ocata on anything prior to UCA-Ocata
[13:51] <cpaelzer> jamespage: I still fix the yakkety/zesty libvirt, but just for the sake of fixing a real issue in general, not the one of the bug reporter in particular
[13:52] <cpaelzer> jamespage: I see the last comment of the reporter that this is lined up for newton - is this what you referred to the updates in proposed ?
[13:54] <cpaelzer> jamespage: can you read the answer to your vif type question out of http://cdn.pasteraw.com/b3tw4cjefomfi3e9k09hvodrfun85z ?
[13:55] <jamespage> cpaelzer: I groked the code and that path is used for a few vif types
[13:55] <jamespage> cpaelzer: I'm concerned that upstream gate say's all good, but we're being told differently
[13:55] <jamespage> cpaelzer: openstack has baselines for libvirt compat, and the xenial version is in range
[13:56] <cpaelzer> jamespage: does the upstream gate run on systems with apparmor enabled?
[13:57] <cpaelzer> jamespage: because with the older libvirt it is qemu now calling the default path and that is blocked by apparmor - if they run apparmor disabled it would look normal
[13:57] <jamespage> cpaelzer: I'd hope they don't
[13:58] <cpaelzer> jamespage: on an old libvirt the change in Openstack is a change in "what you ask for" - while "" was nop, not setting anything is "please run default path"
[13:58] <cpaelzer> jamespage: not sure you want to push in that to Newton
[13:59] <cpaelzer> jamespage: I can only fix newer libvirt to understand "" as being a nop, but as I outlined in the bug - I think the Openstack change is faulty
[13:59] <jamespage> cpaelzer: I'll put the SRU on hold for the xenial-newton uca until we get this resolved
[13:59] <jamespage> cpaelzer: tend to agree with you btw
[13:59] <cpaelzer> jamespage: there was an update by Neil Jerram - he seems to be the author of that change
[14:00] <cpaelzer> jamespage: is that somebody you know and could contact to revisit that - see comment #30
[14:02] <jamespage> mbbe
[14:31] <adityaduggal> Hi can any one let me know a good alternative to jumpcloud using ubuntu server
[14:31] <adityaduggal> I want to have common login ids for all my ubuntu desktops
[14:31] <adityaduggal> using ubuntu server
[15:02] <jamespage> cpaelzer: more comments on https://bugs.launchpad.net/nova/+bug/1665698
[15:02] <jamespage> cpaelzer: basically nova broke its compatibility with the libvirt 1.2.1 baseline (at least)
[15:08] <frickler> zul: are you still working on networking-bgpvpn packaging? the first version seems to be lacking a systemd service definition and a couple of files in /etc
[15:09] <zul> frickler: i been out for a week and just got back today so can you open up a bug for it? thanks
[15:13] <cpaelzer> jamespage: thanks, I made a summar on the related versions to avoid everybody missing the updates before
[15:13] <cpaelzer> new compat wuold be >=1.3.3
[21:04] <kklimonda> what's responsible for ubuntu not resolving non RFC1034-compliant hostnames (for example you can't ping _http._tcp.nova.clouds.archive.ubuntu.com)
[21:06] <nacc> kklimonda: works fine in 17.04
[21:07] <kklimonda> interesting, for me in 16.04 host [hostname] works fine, returning a bunch of IPs, but ping [hostname] fails
[21:08] <nacc> kklimonda: reproduce here in a 16.04 container
[21:08] <nacc> kklimonda: in 17.04 both work
[21:08] <kklimonda> thanks, I guess it's been changed since 16.04
[21:08] <nacc> kklimonda: both work in 16.10 as well
[21:11] <nacc> kklimonda: there's a pretty big jump in the version between 16.04 and 16.10, might need a bug filed
[21:14] <DammitJim> where is the proper place to put keystores?
[21:22] <nacc> kklimonda: going off version strings, relevant commits might be
[21:22] <nacc> kklimonda: https://github.com/iputils/iputils/commit/0f483ade4ca96c4fdb5c10ec4bd02fce5eed5847
[21:23] <sarnold> bonus, the patch is easy to test :)
[21:23] <nacc> kklimonda: debian bug was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305062
[21:26] <nacc> kklimonda: or possibly this one: https://github.com/iputils/iputils/commit/37953bfbe4bd1b4c2be26d837dcfa2934d5a4e16
[21:26] <nacc> kklimonda: 16.10 and 17.04 are aftre that commit, so it's probably that, where they dropped the older API calls altogether
[21:27] <nacc> kklimonda: and no longer even print the "unknown host" message :)
[21:27] <nacc> kklimonda: that one might be harder to backport, though
[21:27] <nacc> kklimonda: but an easy test would be to use the older and newer API calls in a test program and see if they respond differently on 16.04
[21:31] <kklimonda> nacc: well, ping was just an example anyway - I actually hit this deep in a larger codebase, something calling boost library to resolve hostname. That being said, I've stolen some online example of getaddrinfo, and it's failing just the same on 16.04
[21:32] <nacc> kklimonda: sure, but ping is a small codebase, easy to iterate and test on :)
[21:32] <nacc> kklimonda: in any case, i'd file a bug
[21:32] <kklimonda> I've tried, and Launchpad said "nope, not today" ;)
[21:33] <kklimonda> does this build and work on 16.10: http://pastebin.com/RSUrVfv0 ?
[21:35] <nacc> kklimonda: let me get a build env setup
[21:41] <nacc> kklimonda: it built, it works and spits out the same hostname
[21:41] <kklimonda> thanks