=== blahdeblah_ is now known as blahdeblah
=== giraffe is now known as Guest32325
=== maclin1 is now known as maclin
=== enick_867 is now known as RAOF
=== AdmWiggin is now known as tianon
=== tacocat is now known as e[_]
[06:38] <cpaelzer> blahdeblah: I'm here now
[06:38] <cpaelzer> blahdeblah: are you still around?
[06:39] <blahdeblah> cpaelzer: sure am
[06:39] <cpaelzer> you wanted to talk about script tag in libvirt xml?
[06:40] <blahdeblah> More about the things you discovered in the process of fixing that.  You said you considered a backport of a larger feature from upstream?
[06:40] <cpaelzer> blahdeblah: yeah but we dropped that - anybody really needing it can/shall use newer libvirt - the regression risk was too high
[06:40] <blahdeblah> which seemed to be https://libvirt.org/git/?p=libvirt.git;a=commit;h=9c17d665fdc5f0ab74500a14c30627014c11b2c0
[06:40] <cpaelzer> yeah that was it
[06:42] <blahdeblah> So it seems that under libvirt 1.x using interfaces of type ethernet are pretty much not recommended
[06:42]  * blahdeblah rummages for reference
[06:42] <cpaelzer> IIRC it was not recommended for a long time, waren't there some needs to elevate permissions to use it
[06:43] <blahdeblah> yeah - e.g. RH discourage its use altogether: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_host_configuration_and_guest_installation_guide/app_generic_ethernet
[06:44] <cpaelzer> yeah there are more refs
[06:44] <cpaelzer> https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems?rd=Tools/Virtualization/BugReporting#Errors_using_.3Cinterface_type.3D.27ethernet.27.2F.3E
[06:44] <blahdeblah> And on xenial, even if you implement those 4 settings, it still doesn't work because the AppArmor profile blocks it. :-)
[06:44] <blahdeblah> cpaelzer: So that's confirmed that I understood what you said in that bug correctly, here comes the question:
[06:45] <blahdeblah> Is there any safe way to use libvirt with generic ethernet on xenial?
[06:45] <cpaelzer> it was used heavily at earlier times
[06:45] <blahdeblah> yeah - I found another bug saying on precise & trusty it worked
[06:46] <blahdeblah> (presumably because people just ignored the risks of the elevated privilege)
[06:46] <cpaelzer> it was changed who executes the script (also for security) - but in the past just dropping security was more common than today
[06:46] <cpaelzer> yeah just what you wrote in your second msg
[06:48] <blahdeblah> cpaelzer: So is there any safe, sensible way to use this in xenial, or do I need to upgrade to zesty or later?
[06:51] <cpaelzer> blahdeblah: well, the TL;DR is - back in hat time qemu was executing the script - so to do most of the work (setup a vnic) it needs a set of permissions you usually take away for security reasons
[06:51] <cpaelzer> blahdeblah: if you consider not dropping capabiliteis and running it as root unsafe (likely) then there would be no safe way that comes to my mind immediately
[06:53] <blahdeblah> The whole point of this is to run some custom setup on the interface, so my thought was to just use an unprivileged process to send the right info to something running as root.
[06:53] <cpaelzer> blahdeblah: in the bug you referred the reporter had I quote "we do have our own infrastructure installed to overcome these restrictions. One such measure is having a daemon running as root that does the actual interface creation, triggered by the interface setup script."
[06:53] <cpaelzer> blahdeblah: if you have something like that, then yes it can be made safer
[06:54] <cpaelzer> blahdeblah: your thought sounds very similar to what they had in place
[06:55] <blahdeblah> Probably because I read their comment in the bug. :-)
[06:55] <cpaelzer> hehe
[06:56] <blahdeblah> cpaelzer: So back to the fix for that bug: it gives the impression that the fix is already included in the current xenial packages, and all we need to do is specify a different setup script and it should be possible to make that - is that correct?
[06:56] <blahdeblah> *make that work
[06:56] <cpaelzer> yes
[06:56] <cpaelzer> it no more does some prechecks which were broken (that was the bug)
[06:57] <cpaelzer> so you can reference to your script of choice, that is called in the context of qemu and qemu's user
[06:57] <cpaelzer> if you can make that script work you are good
[06:58] <cpaelzer> in later versions libvirt will call the script before qemu (higher permissions)
[06:58] <blahdeblah> Because I tried that and I still got the error "could not open /dev/net/tun: Operation not permitted"
[06:58] <cpaelzer> there are some of the caps which still ahve to be lifted I think
[06:58] <cpaelzer> just a sec
[07:01] <cpaelzer> blahdeblah: essentially depending on how much your script already does you need a asubset of https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/App_Generic_Ethernet.html
[07:01] <cpaelzer> likely the cgroup_device_acl thing
[07:01] <cpaelzer> that has no tap/tun by default
[07:01] <blahdeblah> I tried that on its own without success
[07:02] <cpaelzer> hmm, I thought back then that was it for me - any apparmor denials or other ususal suspects left in the picture?
[07:03] <blahdeblah> not that I can see: https://pastebin.canonical.com/202632/
[07:05] <cpaelzer> let me cross check that for a few minutes, sometimes memory is better when doing than when talking about it
[07:08] <blahdeblah> cpaelzer: Don't spend a lot of time; this isn't a critical thing - just me trying to get my preferred network topology created.
[07:08] <cpaelzer> ok, but my personal rule of thumb would then be "do not try to base your preferred thing on soemhing deprecated" :-)
[07:08] <cpaelzer> I'll let you know if I see soemthing you can try in addtion to what you did
[07:09] <blahdeblah> cpaelzer: Is generic ethernet actually deprecated as a libvirt interface?  Because that would definitely put a damper on my preferred topology.
[07:10] <cpaelzer> Read the section "investigation" on https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/App_Generic_Ethernet.html - that pretty much covers my known state of it
[07:12] <blahdeblah> OK - thanks.  I'm grateful for the time you've already spent.
[07:19] <cpaelzer> blahdeblah: ok I have what you need
[07:19] <cpaelzer> blahdeblah: you have to apply all I sent you in the fredora link plus the following two for apparmor
[07:20] <cpaelzer> in /etc/apparmor.d/abstractions/libvirt-qemu
[07:20] <cpaelzer> capability net_admin,
[07:20] <cpaelzer>   /etc/qemu-ifup rmix,
[07:20] <cpaelzer> the latter is your script
[07:20] <blahdeblah> cpaelzer: Already?  Wow. :-)
[07:20] <cpaelzer> of course that is far from save :-)
[07:20] <cpaelzer> leaving the case now, have fun
=== maclin1 is now known as maclin
[07:21] <blahdeblah> cpaelzer: Yeah - so given how unsafe it is, I think I'll upgrade the host and try with libvirt 2.x
[07:21] <blahdeblah> cpaelzer: Much appreciated
=== JanC is now known as Guest4348
[10:47] <doko> mitya57: could you have  look at https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.2+dfsg-2build1/+build/13692836 ?
[10:48] <mitya57> doko, ok will look
[10:48] <doko> ta
[10:48] <Laney> hmm, I thought I saw a way to boot a (nova) cloud instance with a kernel on the local system but I can't find that now
[10:48] <Laney> did I make that up?
[11:00] <doko> mitya57: and same for https://launchpadlibrarian.net/344935458/buildlog_ubuntu-bionic-amd64.kdb_3.0.2-1build2_BUILDING.txt.gz  (I was pointing a the new cmake, but maybe it's qt related as well)
[11:01] <mitya57> doko: it's new Qt, some *.cmake files were moved from qttools5-dev-tools to qttools5-dev, needs a new B-D.
[11:02] <mitya57> I will likely fix both in Debian and then sync.
[11:05] <doko> mitya57: note that debian still has icu 57
[11:05] <mitya57> Should that make any difference?
[11:05] <doko> I hope not ...
[13:32] <doko> Laney, seb128: is TheMuso still looking at sound issues?
[13:32] <doko> https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/1730947
[13:32] <ubottu> Launchpad bug 1730947 in cairo-dock-plug-ins (Ubuntu) "package fails to build with glibc-2.26" [High,Confirmed]
[13:32] <doko> infinity: ^^^
[13:43] <jbicha> doko: no, duflu works on pulseaudio though
[14:50] <smoser> hey all. anyone know of a way to "wait until system is booted".
[14:50] <smoser> sh -c 'while :; do s=$(systemctl is-system-running); r=$?; [ "$s" = "initializing" -o "$s" = "starting" ] || break; sleep .2; done; read up idle < /proc/uptime; echo "$r $s $up";
[14:50] <smoser> that works, but i figure theres probably holes in it and i'd love something that didnt poll
[14:50] <smoser> xnox ? any ideas ?
[14:54] <doko> Laney: do you see slow setups of autopkg tests environments on lyc-* auto testers?
[14:57] <xnox> smoser, what do you want to do, when things finish booting?
[14:57] <xnox> smoser, you can create an idle unit that kicks in after everything is odne
[14:57] <smoser> stuff
[14:57] <rharper> smoser: like you want to listen to sd_notify bus
[14:57] <rharper> for an "i'm done booting event"
[14:58] <smoser> the reason for my asking today, is that i often write:
[14:58] <smoser>  lxc launch ubuntu-daily:xenial x1
[14:58] <Laney> doko: haven't noticed it being slower than lgw01 but I've not exactly been looking
[14:58] <smoser>  sleep 10 ; # wait for the system to boot
[14:58] <smoser>  lxc exec x1 -- do-some-thing-useful
[14:58] <Laney> are you talking about instance startup?
[14:59] <Laney> like time-to-ssh?
[14:59] <doko> Laney: https://portal.admin.canonical.com/107182
[15:00] <xnox> smoser, with lxc1 there was http://man7.org/linux/man-pages/man1/lxc-wait.1.html which blocks until instance is booted.
[15:00] <smoser> i figure i'm not the only person in the world that wants to do that sort of things.
[15:00] <xnox> smoser, i thought there was "not ready yet state"
[15:00] <smoser> xnox: i'd rather ask the system than ask lxc to figure it out.
[15:00] <smoser> because honestly it can't possibly know for a generic container.
[15:01] <smoser> the system itself is best suited to say "i'im done"
[15:01] <cjwatson> I tend to loop until lxc exec $foo runlevel has a digit in the second field, but that's kind of old-school and not exactly elegant
[15:02] <smoser> cjwatson: my loop above a newer-school example of effectively that.
[15:03]  * smoser is happy that no one here is giving him the system-init-author response of "there is no way to tell when the system is 'finished' booting"
[15:03] <rharper> smoser: that's left as an exercise to the questioner
[15:05] <smoser> i think ideally there'd be a command in ubuntu that ran in a non-polling mode and just blocked until systemd showed something other than 'initializing' or 'starting'. and then parroted that value.
[15:05] <smoser> wait-for-booted --block --max-wait=1m
[15:05] <smoser> degraded
[15:06] <xnox> smoser, well systemctl list-jobs -> will show if it is still doing stuff or not.
[15:07] <smoser> i think that checking for values other than 'initializing' or 'starting' is what i want
[15:17] <smoser> but it just seems like that is somethign that the system should give me. so i was asking if such a thing existed.
[15:22] <lolek> hello
[15:22] <lolek> I'm tyring to find a way to disable menuproxy from inside a c++ any hints?
[18:32] <TJ-> nacc: ping? patch available fixing bug #1730731 be great if you can test/confirm the fix and get it published
[18:32] <ubottu> bug 1730731 in ycmd (Ubuntu) "[16.04] no autocomplete and multiple errors due to not using python3 interpreter or extension calling conventions" [Undecided,In progress] https://launchpad.net/bugs/1730731
[18:45] <nacc> TJ-: weird that i didn't get a notification
[18:46] <nacc> TJ-: i'll look at it today
[18:46] <nacc> TJ-: ah just got it, ok
[18:47] <TJ-> nacc: Thank-you. It's working fine here; the patch wsa originally suggested for Debian (in the tracked bug) but then they fixed it by pulling an entirely new upstream release
[18:47] <nacc> TJ-: ack, that's normal, and also what has it fixed in the later releases
[18:48] <TJ-> nacc: the patch is still being carried in the later Debian releases so I guess it is still required (it's in 17.10 too)
[18:49] <TJ-> nacc: anyhow, it's quite minimal and it works so I'm happy :)
[18:49] <nacc> TJ-: cool, will keep you posted in the bug
[19:34] <dmj_s76> jbicha: How do you feel about packaging a new version of python-xlib for debian and ubuntu?
[19:35] <jbicha> dmj_s76: the Debian maintainer will take care of that. I pinged him last week.
[19:37] <dmj_s76> jbicha: okay, good to hear!  It looks like debian still points to the project on sourceforge, when it switched to github years ago.
[19:37] <jbicha> dmj_s76: since you're here, the fix for LP: #1724024 is ready to be verified
[19:37] <ubottu> Launchpad bug 1724024 in mutter (Ubuntu Artful) "can't set usable scale for hidpi internal display if when using external display less than 1600x1200" [Medium,Fix committed] https://launchpad.net/bugs/1724024
[19:40] <dmj_s76> jbicha: Thanks, I'll test and get back to you on that.
=== e[_] is now known as tacocat
[21:17] <niedbalski> arges, rbasak hello guys , any of you can check the verification for LP: #1657256? also, not sure why the Trusty series wasn't moved into -proposed (it's currently seating in unapvd).
[21:17] <ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu Trusty) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
[22:35] <bdmurray> blackboxsw: Could you add a test case to bug 1722564? I've uploaded a fix to the artful SRU queue.
[22:35] <ubottu> bug 1722564 in apport (Ubuntu Artful) "apport question will not accept multi-character responses" [Medium,In progress] https://launchpad.net/bugs/1722564
[23:06] <blahdeblah> Starting firewall maintenance now (see previous message to ubuntu-devel-announce)
=== Guest6094 is now known as RAOF
=== Orphis_ is now known as Orphis