[02:24] <jpastore> hi I'm trying to run tshark remotely over ssh to pipe to my local wireshark, I'm getting an error that I do not have permission to the device? I've created the wireshark group, added myself to it, reconfigured the package, and I get a permission error relating to the device. How do you grant permission to a device? There is nothing in udev either which is strange...
[03:04] <hallyn_> smb: arges:  hm, is libvirt on xenial working for you? I get
[03:04] <hallyn_> Feb 16 19:03:53 sl libvirtd[2705]: Cannot set property Before, or unknown property.
[03:04] <hallyn_> Feb 16 19:03:53 sl libvirtd[2705]: Cannot open log file: '/var/log/libvirt/qemu/cdboot.log': Device or resource busy
[03:05] <hallyn_> (which i've seen mentinoed in a bug somewhere)
[03:05] <hallyn_> iirc it was a systemd machinectl problem
[03:05] <hallyn_> hm, i'l lhave to look into it tomorrow
[08:54] <smb> hallyn_, Not sure I had been trying to do boots from CD. I'll check. Sounds a bit like either missing file or something wrong with aa profile(s)
[08:56] <lordievader> Good morning.
[09:03] <Seven_Six_Two> not sure what happened, but most of my server's services stopped connecting. znc, apache, owncloud
[09:04] <Seven_Six_Two> and oddly, my server and desktop are connected to the same router, and my desktop can ssh in to the server, and the desktop can browse the web, but my server can't ping google.
[09:05] <Seven_Six_Two> the default gateway for both machines is the same
[09:11] <Sling> Seven_Six_Two: how are you trying to ping google?
[09:12] <Seven_Six_Two> ping google.com
[09:12] <Sling> Seven_Six_Two: try ping 8.8.8.8
[09:12] <Sling> it that works, DNS is probably not working for you
[09:12] <Seven_Six_Two> that doesn't work
[09:13] <Sling> what happens when you try?
[09:13] <lordievader> Does pinging the gateway work?
[09:13] <Seven_Six_Two> that's so messed up. It's not doing anything
[09:13] <Seven_Six_Two> yes, I get a response from the gateway's lan ip
[09:13] <lordievader> Seven_Six_Two: What is the output of 'ip r'?
[09:14] <Seven_Six_Two> default via 192.168.168.1 dev eth0
[09:14] <Seven_Six_Two> 10.8.0.0/24 via 10.8.0.2 dev tun0
[09:15] <Seven_Six_Two> 10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
[09:15] <Seven_Six_Two> 169.254.0.0/16 dev eth0  scope link  metric 1000
[09:15] <Seven_Six_Two> 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.80
[09:15] <Seven_Six_Two> 192.168.168.0/24 dev eth0  proto kernel  scope link  src 192.168.168.80
[09:15] <lordievader> !paste
[09:16] <lordievader> I suppose you do dhcp?
[09:17] <Seven_Six_Two> yes, static dhcp from the router
[09:18] <lordievader> Does the gateway run a firewall which is dropping icmp by any chance?
[09:18] <Seven_Six_Two> I believe so
[09:18] <Seven_Six_Two> checking
[09:19] <Seven_Six_Two> well, it's not set to ignore or forbid, but icmp-flood attack filtering is enabled
[09:20] <Seven_Six_Two> oh dammit. that's it, isn't it. how did you figure that? the only thing I've changed recently is stats in the router, and didn't notice that icmp-flood filtering is only enabled with stats.
[09:20] <lordievader> I guess I can conclude from this that you have access to the gateway? Can you ping 8.8.8.8 from there?
[09:21] <Seven_Six_Two> correct. ping from router works
[09:21] <lordievader> Odd. Well perhaps it is that. Can you ping 8.8.8.8 from the problem host when the icmp-flood filtering is disabled?
[09:22] <Seven_Six_Two> oh udp-flood and tcp-syn-flood filtering too
[09:23] <lordievader> That shouldn't matter for ping ;)
[09:23] <Seven_Six_Two> lol. and my server is on blocked list
[09:23] <Seven_Six_Two> in router. no it's like my router is seeing too many icmp packets and cutting off the server
[09:23] <Seven_Six_Two> one sec though. I'll disable and test
[09:24] <Seven_Six_Two> yeah, as soon as I remove the server ip from the blocked list, it starts working again.
[09:24] <Seven_Six_Two> so the router is seeing too many of some packet type
[09:25] <lordievader> Heh, and the firewall strikes once again ;)
[09:26] <Seven_Six_Two> thanks for the help. I made some changes, and know where to look if it happens again.
[09:40] <Razva> hey! is there any know Juju bug regarding network interfaces not named eth?
[09:46] <lordievader> Razva: What version of Ubuntu is this?
[09:49] <ikonia> going to need to be more specific than "a bug regarding network interfaces not named eth"
[10:14] <YamakasY> how large is the size of a mirror, without sources, for 14.04 ?
[10:14] <YamakasY> only 64bit btw
[10:16] <Razva> lordievader 14. should we use 15?
[10:20] <lordievader> Razva: No, I was asking since 15.10 uses a newer version of udev which uses bios dev names instead of the old naming scheme. Perhaps the udev of Trusty got updated to the same version though.
[10:20] <lordievader> Razva: What kind of network names do you have now?
[10:42] <smb> hallyn_, As a follow-up on libvirt: I can boot kvm guests via libvirt. I realized that "cdboot" would be your guests name. I'd check whether /var/lib/libvirt/qemu is a directory owned by libvirt-qemu.kvm and writable at least for that user.
[10:45] <Razva> lordievader VLAN
[10:46] <lordievader> Razva: What? We were talking about interface names right?
[11:13] <Razva> lordievader well it might be, I have no idea, but what I know is that with eno1 juju basically fails
[11:14] <lordievader> Razva: Well look on Launchpad if this has been reported before, else make a new bug report.
[15:13] <spm_draget> Silly question, but after installing a fresh ubuntu-server and assigning a static IP and nameserver… where is the nameserver saved? Should it be in /etc/netwrok/interfaces… because I do not see it there…?
[15:21] <freeone3000> I have a Lenovo ThinkServer running 14.04 LTS. I'm trying to get the health of its primary drive raid, but I get: https://gist.github.com/freeone3000/4cc6e1633f22796de875 . (The server has a hardware raid controller with two SATA drives connected as SAS)
[15:24] <jelly-home> freeone3000: which pci device is that controller?  lspci -nn
[15:26] <freeone3000> jelly-home: "04:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] [1000:0079] (rev 05)"
[15:30] <spm_draget> Ah okay, /etc/network/interfaces is the correct thing
[15:31] <dami0> hi, i'm trying to test out SingleSignOn was going through the instructions and just wanted to ask about faking the domain names, if i put the server down in the /etc/hosts files, is that loopback for the server itself and the server's LAN ip on the clients?
[15:32] <jelly-home> freeone3000: see if mpt-status works for that one
[15:34] <freeone3000> jelly-home: Always prints "ioctl: no such device", but man pages say it doesn't take an argument and should autodetect.
[15:36] <freeone3000> Did the autoload bit, tried specifying '-u /dev/sda' and '-u 0:40' but no change.
[15:36] <jelly-home> no idea then, perhaps there are backports of newer smartmontools for trusty somewhere
[15:36] <ivoks> jelly-home: look at you :)
[15:43] <jelly-home> yeah, ECHAN
[15:43]  * jelly-home felt sorry for the LSI user
[16:11] <leitao> jgrimm, cyphermox: Any idea if docker on 16.04 will be compiled with golang (other than gccgo) for ppc64el?
[16:13] <jgrimm> leitao, the plan is to build docker1.10 with golang-1.6 for most architectures including ppc64el
[16:13] <leitao> thanks
[16:13] <jgrimm> leitao, do you have a preference on technical merits?
[16:14] <leitao> jgrimm, that is what we need. Thank you!
[16:14] <leitao> 1.9 seems to have some issue
[16:14] <leitao> jgrimm, btw, any chance to move docker from universe to main?
[16:15] <jgrimm> leitao, no plans to do so
[16:16] <leitao> jgrimm, it means docker is not supported by Canonical, right?
[16:18] <jgrimm> leitao, community supported is the way its described -> https://help.ubuntu.com/community/Repositories/Ubuntu
[16:21] <arrrghhh> anyone have suggestions for something like Crashplan which has a Linux client?  I really liked Crashplan, until they decided to change their pricing structure and doubled everything since I last renewed 4 years ago...
[16:29] <nacc> hallyn: not sure if you saw, but i updated the numactl merge reuqest yesterday
[16:29] <nacc> if you could ack, that'd be great
[16:31] <freeone3000> arrrghhh: tarsnap
[16:32] <arrrghhh> freeone3000, hm that's one I have not heard of before
[16:58] <hallyn> nacc: what's the url again?
[16:58] <hallyn> smb: uh, no, nothing to do with cds.  my old windows vista vm also doesn't start
[16:58] <nacc> hallyn: one sec, https://code.launchpad.net/~nacc/ubuntu/+source/numactl/+git/numactl
[16:58] <nacc> merge branch
[17:00] <hallyn> smb: "Cannot set property Before, or unknown property." is the critical line I think.  (or I'm wrong and it's a red herring :)
[17:00] <smb> hallyn, hm odd. me and arges did notice no such errors.
[17:00] <arges> hallyn: is this only with windows guests?
[17:01] <hallyn> arges: no
[17:02] <hallyn> arges: smb: it probably ha snothing to do with libvirt itself, though, bc it seems to be a dup of https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1529079
[17:03] <arges> hallyn: i take a look.. my uvtool vms have been working fine
[17:03] <hallyn> nacc: thx, lemme do that right now
[17:05] <smb> arges, and I was using virt-manager. Only difference is that the host is a fresh Xenial install
[17:07] <nacc> hallyn: thanks!
[17:08] <hallyn> smb: hold on;  fresh install did work, or did not work?
[17:09] <smb> hallyn, fresh install does work for me
[17:09] <smb> hallyn, you and the other reporter seem to use upgraded hosts
[17:09] <hallyn> smb: yup
[17:09] <arges> ok yea I have been using fresh xenial installs
[17:09] <arges> so we need some upgrade testing I suppose
[17:10] <hallyn> well that gives ideas of where to start looking at least, that's good :)
[17:10] <hallyn> bugs.debian.org is down?
[17:10] <hallyn> can the bot tell me about debian bug 814952 ?
[17:10] <hallyn> nacc: is debian bug 814952 the one you filed ?
[17:11] <smb> hallyn, and since the other bug was opened last year it already happened with an earlier update of libvirt ...
[17:12] <smb> hallyn, hm you happen to use special args for libvirtd (which might be ignored by the old service conversion)? Though I do read the right file now
[17:13] <hallyn> smb: yes but it didn't hapen until i upgraded to xenial.  i *think*
[17:13] <hallyn> no special args,
[17:13] <hallyn> root      2705     1  0 Feb13 ?        00:00:00 /usr/sbin/libvirtd
[17:14] <smb> ok, well still allows for breakage with the xml definitions which would not be new
[17:15] <smb> hallyn, have you tried to virsh edit the config and do a small change then write it back
[17:16] <smb> validation is done for writes... though the error messages for that used to be poor
[17:19] <hallyn> nacc: LGTM, wish i could see the debian bug, but th
[17:19] <hallyn> x
[17:19] <hallyn> nacc: did you do a merge request against anything?  Should I just push the package to x?
[17:21] <arges> hallyn: can you dumpxml the faulty vm and pastebin it somewhere
[17:22] <hallyn> i'll object to "the faulty vm" :-)
[17:22] <hallyn> arges: just a min
[17:23] <arges> hallyn: well the one that libvirt cant parse
[17:23] <arges> and perhaps there is a qemu log somewhere to see if that cmdline it produced looks messed up
[17:24] <hallyn> arges: it can't parse any of several I had.  I deleted all but one, and created one new one.
[17:24] <hallyn> http://paste.ubuntu.com/15101328/
[17:25] <hallyn> arges: the logfile has : libvirt:  error : libvirtd quit during handshake: Input/output error
[17:26] <hallyn> nacc: hm, having trouble building a source pkg
[17:27] <hallyn> why is debuild being stupid and trying to include .git?
[17:28] <hallyn> there msut be  a better way to build than to mv .git .. first
[17:28] <hallyn> that is to ohacky
[17:30] <arges> ok i'll look
[17:33] <hallyn> nacc: ffs can't you file a debian bug to fix the pkging to be 3.0 quilt? :)  kills me
[17:33] <hallyn> anyway, pushing, thx
[17:42] <teward|> rbanffy: ping, if you're around and can give some guidance on the nginx package, that'd be great - gotta pick between two evils :/
[17:42] <teward|> erm
[17:42] <teward|> rbasak: ^
[17:42] <teward|> sorry rbanffy for the mishighlight
[17:43] <nacc> hallyn: :) i can do that for the next release
[17:44] <rbasak> teward|: around but otp. Do you want to provide a summary here please?
[17:45] <teward|> rbasak: FTBFS as is, we have to update the Lua moduel in -extras.  Two options: nitpick the fix from upstream which fixes the missing udp connector struct, or take from Debian's git repository in where they update the entire module to the release candidate version on openresty's github pages, which brings in additional changes to the Lua module (I don't have a complete list)
[17:45] <teward|> rbasak: not sure which is the correct approach, though i can get either done before FeatureFreeze once I get some guidance
[17:46] <teward|> Debian's updating of the package also incorporates the fix, apparently, though that will undergo its own build tests as well
[17:49] <teward|> rbasak: basically, i'm not sure which approach will work better, hence seeking some advice :/
[17:51] <rbanffy> NP, teward. It happens all the time.
[18:15] <hallyn> smb: arges: all right, sorry, focusing on the libvirt thing now
[18:15] <hallyn> oh, one more thing first,
[18:15] <arges> hallyn: no problem, ive downloaded the xml files from you and the bug report, trying to look at what the differences are and repo on my end
[18:15] <arges> hallyn: ok no problem
[18:17] <hallyn> arges: saving xml works fine, sothat's not the problem
[18:17] <hallyn> lemme set up two vms, one with upgrade and one with clean install, and compare...
[18:18] <arges> hallyn: yea that's what I was trying to do, but hopefully that points us in the right area. wondering if its osmething to do with how the disk controllers are setup
[18:18] <arges> that would be my swag
[18:48] <hallyn> arges: wtf.  failed to reproduce in a vm
[18:50] <arges> hallyn: yea i'm not having luck here either.
[18:51] <arges> hallyn: what did you upgrade from? wily?
[18:54] <hallyn> arges: yeah, maybe i need to start from vivid, which my laptop apparently did
[18:54] <hallyn> (though not directly)
[18:54] <hallyn> i'll try from trusty - upstart->systemd seems more likely to e a trigger
[18:55] <arges> hallyn: ok
[19:01] <hallyn> arges: i think when we find the cause we're gonna laaaaaugh
[19:02] <arges> hallyn: : ) progres?
[19:03] <hallyn> wiating on the trusty vm install
[19:03] <hallyn> oh it's done
[19:07] <arges> hallyn: grabbing lunch... keep me posted
[19:07] <hallyn> k
[19:13] <rbasak> teward: extras is in universe, right? So no security team main concern about whether to follow Debian's import or take from nginx upstream.
[19:14] <teward> rbasak: correct - extras is in Universe
[19:14] <teward> rbasak: though, once dynamic modules are applied, we're going to have to scramble to make sure some are in Main, some aren't
[19:14] <teward> because it's not nice when that's taken into account
[19:14] <rbasak> teward: my remaining question would be about user visible differences. Is there a cost to committing to one over the other now? IOW, will any user have a reason to care if you take one approach now and switch later?
[19:14] <teward> (that's the future though)
[19:15] <teward> rbasak: AIUI, no, there won't be any major reasons for Users to care.  However, one reduces the plugin-specific future merge delta by one tiny commit, the other reduces it to zero when merging in from Debian
[19:15] <rbasak> If that's not a concern then I'd pick the easiest thing, which I guess you get to trade off. Following Debian is nice, but the benefit depends on how much we've diverged in this aresa.
[19:15] <rbasak> area
[19:15] <teward> mmm
[19:15] <rbasak> OTOH, cherry-picking a trivial patch may be far easier.
[19:16] <rbasak> That's what we'd probably want to do after FF anyway.
[19:16] <teward> rbasak: they're both available on git - patches are nice anyways :P
[19:16] <teward> indeed
[19:16] <teward> though, every new release of nginx will have to get an FF exception
[19:16] <teward> which is fine, but it's one of those annoying little headaches :)
[19:16] <rbasak> I thought we had an understanding with the release team on the plan? Or did that not get fully resolved?
[19:17] <rbasak> Keep ubuntu-release advised, certainly. I'm not sure if you need an explicit and formal FFe approval for each step though.
[19:17] <teward> i'm not sure we did since the policy change, the TB discussion was one fo "everything still gets standard FF review before upload" iirc
[19:17] <teward> rbasak: well, from this point on, each nginx will likely have some minor feature changes
[19:17] <teward> so it'd need FFe if standard policy is followed
[19:17] <rbasak> Ah, OK.
[19:17] <teward> plus HTTP/2 bugfixes which don't affect the builds currently
[19:17] <teward> (because it's not enabled)
[19:18] <teward> rbasak: i'm going to nitpick the minor change form upstream that enables building and doesn't implement an rc version of the third party module
[19:18] <teward> seems like the lesser evil
[19:19] <rbasak> OK, that sounds good. Thank you for considering carefully, as always!
[19:19] <teward> that's my job :)
[19:19] <teward> and thank you for being a sounding board and for the ongoing advice
[19:19] <teward> it's always nice to bounce opinions off others first :)
[19:19] <rbasak> np
[19:19] <rbasak> I forgot the other option was rc
[19:19] <rbasak> That makes your choice sound even better.
[19:23] <teward> mhm
[19:40] <hallyn> arges: hm, not reproduced in trusty vm either.  so i guess i'll have to look more closely at my own setup.
[19:40] <hallyn> fascinating
[19:41] <arges> hallyn: yikes, ok
[21:40] <hallyn> eureka
[21:42] <hallyn> arges: smb: systemd-machined, provided by systemd-container, is causing the problem
[21:46] <arges> hallyn: so your hunch in the bug earlier was corrupt
[21:46] <arges> correct
[21:46] <hallyn> accuse me of corruption?   I'll sue!
[21:46] <arges> haha
[21:47] <hallyn> yeah i just don't get why systemd-machined woudl ship in systemd-container.  that's weird
[21:47] <hallyn> mind you the bug may still actually be in libvirt
[21:47] <hallyn> but i find that hard to believe, as we're on 1.3.x
[21:47] <hallyn> anyway with that found i'll lower it's priority and defer it :(
[21:51] <arges> cool hopefully we can catch it before release
[22:35] <jak2000> arrrghhh
[22:35] <jak2000> are you there?