[02:45] 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] Good morning. [07:18] hello [07:18] can I ask for a question? [07:19] bitfawkes: Yes [07:19] andol: thanks [07:19] I m trying to get vmware gui from remote server to localhost using ssh -X [07:20] and I get the follow error message [07:20] (vmware-modconfig:3286): Gtk-WARNING **: cannot open display: localhost:11.0 [07:20] I use ubuntu 14.04 server on both system and just on local is installed gnome [07:22] bitfawkes: Might https://superuser.com/a/310201 be the answer? Is the remote sshd configured to allow X-forwardign? [07:22] yes [07:24] is configured to allow [07:32] What command are you using to set up the X forwarding? [07:34] ssh -X user@ip [07:37] I did edit sshd_config [07:38] You might have better luck with the -Y flag, that usually works better for me. [07:38] try ssh -v to dump debug messages. sometimes you can spot it there. check logs on the host, you may get lucky [07:38] lordievader: iirc debian patches ssh client to make -X automatically include -Y [07:41] well now that I go looking for it I'm not finding it. try -Y. :) [07:46] Is it insescure to run ubuntu server without changing default root password? [07:47] ubuntu does not set a root password [08:24] sarnold: that's what [08:24] that's why I mentioned "default" password [08:25] What are the security implications of not doing a "sudo passwd root" post installation ? [08:25] and deploying the server in production publicly [08:26] Without changing the built in root password [08:33] sarnold: Ah, I did not know that, nice. [08:34] b3h3m0th: In theory running that command is worse than not running the command. [08:34] b3h3m0th: As sarnold said, root doesn't have a password. Thus anything you'd try as a password fails. === Oer is now known as OerHeks [08:56] lordievader: then what is the hash stored in shadow against root ? [08:59] hash(salt+something) must evaluate to that right? lordievader sarnold [09:01] it's a valid $6 hash (sha512) [09:03] 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] lordievader: _ruben nope, no one did [09:17] wait, let me verify [09:17] 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] sorry guys, my bad [09:19] I was checking the wrong instance === chmurifree is now known as chmuri [10:47] <_ruben> hehe [10:49] <_ruben> now if only i could get idmapd to work for my nfs4 exports/shares === JanC is now known as Guest30327 === JanC_ is now known as JanC [13:39] cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1665698 is a little confusing right? [13:39] Launchpad bug 1665698 in libvirt (Ubuntu Yakkety) "/etc/qemu-ifup not allowed by apparmor" [Medium,Triaged] [13:40] "a little" is a little underrated [13:40] it is VERY confusing [13:40] I tried to cover and add the bits I found, but by that it accumulated quite some text now [13:41] 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] I often come back to my post summarizing the timeline [13:41] jamespage: that is the comment one should memorize [13:42] jamespage: I'm really interested if you think Openstack in general or UCA would have to do something on top [13:47] 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] cpaelzer: we're not going to put yakkety libvirt into the UCA for newton; its closed to a bump like that [13:49] jamespage: I never wanted to suggest to put yakkety libvirt into UCA-Newton [13:49] jamespage: all the references were only parts of my analysis on the timeline [13:50] cpaelzer: no worries - I realised that [13:50] jamespage/coreycb: there is a newer version of horizon for ocata btw [13:50] jamespage: your latest update is good [13:51] jamespage: IMHO it is only showing the issue when running openstack ocata on anything prior to UCA-Ocata [13:51] 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] 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] jamespage: can you read the answer to your vif type question out of http://cdn.pasteraw.com/b3tw4cjefomfi3e9k09hvodrfun85z ? [13:55] cpaelzer: I groked the code and that path is used for a few vif types [13:55] cpaelzer: I'm concerned that upstream gate say's all good, but we're being told differently [13:55] cpaelzer: openstack has baselines for libvirt compat, and the xenial version is in range [13:56] jamespage: does the upstream gate run on systems with apparmor enabled? [13:57] 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] cpaelzer: I'd hope they don't [13:58] 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] jamespage: not sure you want to push in that to Newton [13:59] 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] cpaelzer: I'll put the SRU on hold for the xenial-newton uca until we get this resolved [13:59] cpaelzer: tend to agree with you btw [13:59] jamespage: there was an update by Neil Jerram - he seems to be the author of that change [14:00] jamespage: is that somebody you know and could contact to revisit that - see comment #30 [14:02] mbbe === BrianBlaze420 is now known as BrianBlaze [14:31] Hi can any one let me know a good alternative to jumpcloud using ubuntu server [14:31] I want to have common login ids for all my ubuntu desktops [14:31] using ubuntu server [15:02] cpaelzer: more comments on https://bugs.launchpad.net/nova/+bug/1665698 [15:02] Launchpad bug 1665698 in libvirt (Ubuntu Yakkety) "/etc/qemu-ifup not allowed by apparmor" [Medium,Triaged] [15:02] cpaelzer: basically nova broke its compatibility with the libvirt 1.2.1 baseline (at least) [15:08] 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] frickler: i been out for a week and just got back today so can you open up a bug for it? thanks [15:13] jamespage: thanks, I made a summar on the related versions to avoid everybody missing the updates before [15:13] new compat wuold be >=1.3.3 === JanC_ is now known as JanC === evade_ is now known as evade === Malediction_ is now known as Malediction === led2 is now known as led1 === kaosine_ is now known as kaosine === mwhudson_ is now known as mwhudson === TodPunk_ is now known as TodPunk === Tahvok_ is now known as Tahvok === akaWolf1 is now known as akaWolf === ashleyd is now known as ashd === ivoks_ is now known as ivoks === diddledan_ is now known as diddledan === BrianBlaze420 is now known as BrianBlaze === ulkesh_ is now known as ulkesh === Gorian- is now known as Gorian === wyre_ is now known as wyre === lordievader is now known as Guest12400 === Guest12400 is now known as lordievader [21:04] 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] kklimonda: works fine in 17.04 [21:07] interesting, for me in 16.04 host [hostname] works fine, returning a bunch of IPs, but ping [hostname] fails [21:08] kklimonda: reproduce here in a 16.04 container [21:08] kklimonda: in 17.04 both work [21:08] thanks, I guess it's been changed since 16.04 [21:08] kklimonda: both work in 16.10 as well [21:11] kklimonda: there's a pretty big jump in the version between 16.04 and 16.10, might need a bug filed [21:14] where is the proper place to put keystores? [21:22] kklimonda: going off version strings, relevant commits might be [21:22] kklimonda: https://github.com/iputils/iputils/commit/0f483ade4ca96c4fdb5c10ec4bd02fce5eed5847 [21:23] bonus, the patch is easy to test :) [21:23] kklimonda: debian bug was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305062 [21:23] Debian bug 305062 in iputils-ping "iputils-ping: stops working with "option inet6" in /etc/resolv.conf" [Normal,Fixed] [21:26] kklimonda: or possibly this one: https://github.com/iputils/iputils/commit/37953bfbe4bd1b4c2be26d837dcfa2934d5a4e16 [21:26] 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] kklimonda: and no longer even print the "unknown host" message :) [21:27] kklimonda: that one might be harder to backport, though [21:27] 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] 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] kklimonda: sure, but ping is a small codebase, easy to iterate and test on :) [21:32] kklimonda: in any case, i'd file a bug [21:32] I've tried, and Launchpad said "nope, not today" ;) [21:33] does this build and work on 16.10: http://pastebin.com/RSUrVfv0 ? [21:35] kklimonda: let me get a build env setup [21:41] kklimonda: it built, it works and spits out the same hostname [21:41] thanks === daniel1 is now known as Odd_Bloke === PaulePan1er is now known as PaulePanter === haasn` is now known as haasn === vamiry_ is now known as vamiry