[00:05] <sdeziel> hallyn: are you there?
[06:46] <sarnold> man, for a bad time, undefine the uvtool storage pool in libvirt then try to make it work again. sheeeeesh.
[06:47] <sarnold> I ought to be familiar with this cycle by now; ignore libvirt, think it's probably fine, try it again, hate it again. repeat.
[07:22] <lifeless> nevyn: you factoring
[07:22] <lifeless> bah
[08:43] <trippeh> dnsmaster named[15571]: ../../../lib/isc/ratelimiter.c:185: INSIST((rl->pending).tail == (event)) failed, back trace
[08:43] <trippeh> hrms ;)
[09:16] <Celphish> Elo
[09:17] <Celphish> I'm in the need of some advice, I'll describe my problem, hold on
[09:18] <Celphish> I'm trying to install ubuntu server 12.04 on a hp-server through ILO, during the setup it states that it's missing firmware for the hardware, and it asks for the file q12500_fw.bin and asks if I want to insert a removable disk or media with it.. I then go on to create a .img with the file on it (also tried a version where the file was on the img at the path /lib/firmware/) but it doesn't seem to find it..
[09:18] <Celphish> problem is that I need that firmware to be loaded for me to be able to access the first disks and so on
[10:30] <jamespage> cpaelzer, any opinion on a sane default for allocating cpu cores for dpdk/ovs ?
[10:31] <jamespage> trying to capture some sort of best-practice for the neutron/ovs/dpdk integration
[11:03] <cpaelzer> jamespage: dpeends on the system size
[11:03] <cpaelzer> jamespage: how complex can the rules become ?
[11:03] <cpaelzer> jamespage: as input vars you surely have the overall #cpus
[11:03] <jamespage> cpaelzer, my current thinking was to allocate a core on each numa node along with some ram
[11:03] <cpaelzer> jamespage: do you also have #network cards and maybe even #queues on these cards?
[11:04] <cpaelzer> jamespage: not a bad thinking - I'd consider that a good lower boundary
[11:04] <cpaelzer> jamespage: but it depends a lot if this system primary purpose is passing dpdk traffic
[11:05] <cpaelzer> jamespage: if this is doing a lot of dpdk traffic like via many cards and/or 40G/100G cards I'd go higher than that
[11:05] <jamespage> cpaelzer, I have memory per numa node as a config option, might add cores per numa node as well
[11:06] <cpaelzer> jamespage: htat I like very much
[11:06] <cpaelzer> cores-per-node starting with 1 as a working but not high-intensity default and up to X as requested would be a good match
[11:06] <cpaelzer> jamespage: will that end up in dpdk's -c option?
[11:07] <jamespage> cpaelzer, yes
[11:07] <cpaelzer> jamespage: while you are at it please consider setting rx queues
[11:07] <cpaelzer> jamespage: after you started openvswitch-dpdk
[11:07] <jamespage> cpaelzer, on what formula?
[11:07] <cpaelzer> jamespage: you can set it via "ovs-vsctl set Open_vSwitch . other_config:n-dpdk-rxqs=2"
[11:08] <cpaelzer> that example uses two queues
[11:09] <cpaelzer> jamespage: formular would IMHO be "up to the number of combined queues, but not more than CPUs assigned"
[11:09] <cpaelzer> jamespage: I'd guess that is a sane start
[11:09] <cpaelzer> jamespage: a manual tuning would include locating on which socket a network card is and then make way more complex masks
[11:10] <cpaelzer> jamespage: number of queues can be read with "ethtool -l"
[11:10] <cpaelzer> and - btw - is by default limited to #cpus
[11:10] <cpaelzer> so on my 12 core the card has 64 queues but uses 12 by default
[11:11] <cpaelzer> ah and I wrote it wrong, has to be BEFORE ovs-dpdk restart
[11:11] <cpaelzer> so that on device init it picks it up
[12:11] <caribou> rbasak: remember my query on apache2 backport from Xenial to trusty : looks like it's not going to be as simple :
[12:12] <caribou> rbasak: there is a Pre-Depends: dpkg (>= 1.17.14) after the Utopic version
[12:13] <rbasak> "  * Bump dpkg Pre-Depends to version that supports relative symlinks in
[12:13] <rbasak>     dpkg-maintscript-helper's symlink_to_dir. Closes: #769821"
[12:13] <rbasak> I remember that now.
[12:13] <rbasak> Yeah that one might be a little messy to fix.
[12:26] <caribou> rbasak: the simpler solution is to backport the Utopic version that is the one right before the addition of this pre-depends
[12:27] <caribou> rbasak: and is still what the original bug asked for
[12:27] <rbasak> caribou: I think the pre-depends was to fix a bug.
[12:28] <caribou> rbasak: I'm looking at the xenial source;looks like what it was fixing is no longer used
[12:28] <caribou> symlink_to_file
[12:28] <rbasak> Perhaps I'm thinking of a different bug.
[12:28] <caribou> symlink_to_dir rather
[12:30] <rbasak> bug 1393832 is what I have in mind.
[12:30] <rbasak> I think that's completely unrelated now. Sorry.
[13:08] <frickler> jamespage: does https://bugs.launchpad.net/ubuntu/+source/python-keystoneauth1/+bug/1566296 look plausible to you? will it be possible to get a FFE or could you only do an update after the initial release is done?
[13:49] <Slashman> hello, do you think the beta version of xenial is fine to use on a server without any graphical interface in production (without net access)? I'm looking at the bug list and doesn't see any show stopper... I want to avoid if possible the update from 15.10 to 16.04 and use latest ZFS and LXD
[13:49] <jamespage> frickler, we have a standing ffe for mitaka/xenial
[13:49] <jamespage> coreycb, ^^ can you take a look please
[13:50] <jamespage> coreycb, I'm +1 on a resync with Debian if that looks good with you.
[13:51] <teward> Slashman: #ubuntu+1 for 16.04 questions.  And I would not use 16.04 unless you have no choice as it is still not released as 'stable' yet.
[13:52] <DirtyCajun> im about to bond 2 nic. i dont have a special switch so im going to use balance-alb, do i need to state bond-lacp-rate or no?
[13:53] <Slashman> teward: thanks for the chan. I understand your point of view, but from the bug tracker I don't see any critical bug for a container/virtualization server
[13:53] <coreycb> jamespage, frickler, yes sounds good I'll take a look today.
[13:54] <jrwren> Slashman: its fine, but the update is not a problem either. Jumping through hoops do avoid running an update does nothing but waste your time, IMO.
[13:54] <teward> Slashman: that isn't why I said that.  It's up to you if you use software that is not yet released as stable - there's still quite a lot of other bugs in the system.  I would suggest waiting anyways, before updating production systems.  Or, stage a testing environment to test things
[13:54] <teward> or both :)
[13:55] <Slashman> I'm already testing it, it's working so far
[13:55] <jrwren> Or... use it in production, its excellent real world testing for the rest of us ;]
[13:56] <Slashman> jrwren: ^^
[13:57] <jamespage> frickler, fyi just testing a revised 32 bit compat patch and will get 10.1.0 uploaded to xenial
[13:58] <Slashman> I may stay reasonable and use wily with lxc and zfs ppa then
[14:00] <frickler> jamespage: any change to tackle some of my issues with that, too?
[14:01] <frickler> jamespage: also I just found an old one: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1488962 this is still present in xenial, too, it seems
[14:02] <jrwren> Slashman: that is no fun. the built in zfs and lxd instead of ppa-zfs and lxc is like upgrading to cadillac from a chevy :p
[14:04] <jamespage> frickler, on my list for this week...
[14:04] <jamespage> not apache2
[14:05] <jamespage> frickler, I see rbasak did some triage - is that bug ^^ a target for xenial?
[14:05] <jamespage> frickler, urgh - that's a systemd fix in suse...
[14:06] <rbasak> Yeah, that needs attention.
[14:06] <rbasak> smoser was going to look at systemd-boot tagged bugs but I think he's occupied on something else.
[14:06] <rbasak> jgrimm: ^^
[14:07] <smoser> :-(
[14:07] <Slashman> there is on issue with zfs between ppa wily and xenial: ppa version is 0.6.5.6 and xenial version is 0.6.5.4
[14:07] <Slashman> s/on/one/
[14:07] <jgrimm> rbasak,  i'm going to suggest cpaelzer for that task
[14:07] <jrwren> Slashman: how is that an issue?
[14:08] <Slashman> not sure how the update will handle that, and I prefer the latest stable version :p
[14:10] <cpaelzer> jgrimm: dpdk crumbles between my fingers atm, so I unsugegst myself :-) but lets talk in 20 minutes and define priorities
[14:10] <jgrimm> cpaelzer, ok, i can do1x1 now if you'd like
[14:11] <cpaelzer> jgrimm: let me just adapt and start the next iteration of the testsuite - approx 3 min
[14:11] <jgrimm> cpaelzer, k
[15:02] <teward> jgrimm: ohai, PM?
[15:03] <jgrimm> teward, hi there
[15:33] <ddellav> jamespage when you get a chance, can you look at my fix for this and push it if possible? https://bugs.launchpad.net/ubuntu/+source/manila/+bug/1546116
[15:33] <ddellav> I put the fix up awhile ago but no one has had the chance to review/push
[15:35] <jamespage> ddellav, we need to get that into xenial first - manila is one of the git repo's under ~ubuntu-server-dev
[15:37] <ddellav> jamespage should I create the MIR?
[15:37] <jamespage> ddellav, MIR ?
[15:37] <ddellav> jamespage it's in xenial/universe currently
[15:38] <jamespage> ddellav, I think we're talking cross purposes
[15:38] <jamespage> there is no manila-share package in xenial yet
[15:38] <ddellav> jamespage ooooh, that's what you meant.
[15:38] <jamespage> ddellav, yes
[15:39] <ddellav> jamespage so a requestsync then?
[15:39] <jamespage> ddellav, no
[15:41] <jamespage> ddellav, we're divergent from debian here - infact it was in Ubuntu first, but members of the openstack-pkg team did their own thing
[15:41] <ddellav> jamespage so what is the next step?
[15:41] <jamespage> ddellav, how would you make a packaging change to any of the other core openstack packages?
[15:44] <ddellav> jamespage normally what i do is package updates, so i debcheckout, import updated package, fix depends and any other issues then push for review. If making an upstream change i use git-review to push changes for CI and manual review.
[15:45] <jamespage> ddellav, git+ssh://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/manila is the source for manila
[15:45] <jamespage> can you propose the fix for this bug against that please?
[15:46] <ddellav> jamespage yep
[15:46] <jamespage> ddellav, thanks!
[15:46] <jamespage> ddellav, the delta in your bzr branch looks fine btw - just needs targetting to the right location!
[15:46] <ddellav> jamespage gotcha, thanks
[15:46] <teward> server team still meeting today?
[15:49] <rharper> teward: yeah, scheduled to start in 10 minutes
[15:49] <teward> cool
[15:49] <teward> just making sure, I can't ever keep track of whomever is chair :)
[15:50] <rharper> https://wiki.ubuntu.com/ServerTeam/Meeting has chair
[15:50] <rharper> but as you say, not always 100% accurate
[15:50] <teward> yep
[16:17] <jamespage> frickler, any thoughts on what we should set the TasksMax attribute to for ceph-osd/mds/mon ?
[16:17] <jamespage> 512 is way to low
[16:18] <jamespage> frickler, looking at the juju charms, we currently set kernel.pid_max to 2097152 as a sane default
[16:23] <jamespage> frickler, but this is really just applied at the process level - so I'm tempted to set it to infinity and allow the server admin to deal with it at the kernel sysctl level
[16:56] <jamespage> frickler, I've uploaded another set of updates for 10.1.0 to the ceph-sru PPA - they will take a while to build
[16:57] <jamespage> but they include fixes for most of your reported problems...
[17:19] <Blueking> TJ- hello again :)
[18:45] <axisys> how do I know if my openssh server is vulnerable to CVE-2016-3115 ? I am using 12.04 lts and I have the latest openssh server already..
[18:47] <sdeziel> axisys: you can track the patch status in Ubuntu here: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-3115.html
[18:47] <sdeziel> axisys: in the meantime there are some mitigation you can apply as mentioned in http://www.openssh.com/txt/x11fwd.adv
[18:49] <axisys> sdeziel: forgot to mention, I was there already... but let me check the mitigations
[18:49] <teward> axisys: disable X11Forwarding and it'll help mitigate
[18:50] <sdeziel> yup
[18:50] <teward> "Set X11Forwarding=no in sshd_config. This is the default."
[18:50] <teward> not sure the defaults in Ubuntu's openssh-server, but it's that simple to help mitigate
[18:50] <sdeziel> Debian/Ubuntu changed that default
[18:51] <axisys> how do I check the default values? is there a switch ?
[18:51] <teward> axisys: /etc/ssh/sshd_config
[18:51] <teward> go poke there, which is on your system.
[18:51] <teward> edit those configuration items, so that X11Forwarding has 'no' instead of 'yes'
[18:51] <teward> unless you need X forwarding
[18:51] <axisys> I know I can manually modify the config.. but is there a switch to get the default value, like postconf and mutt has?
[18:51] <teward> in which case you're stuck between a rock and a hard-place
[18:53] <sdeziel> axisys: sed -i 's/^X11Forwarding.*/X11Forwarding no/' /etc/ssh/sshd_config
[18:58] <axisys> sdeziel: and no-x11-forwarding on those keys
[18:59] <sdeziel> axisys: that would work too but the global param also covers password authentication
[19:27] <axisys> sdeziel: right.. would you know if ubuntu will have a upgrade available soon?
[19:28] <sarnold> unlikely
[19:28] <sarnold> we've rated it low, so it'll only get handled alongside something else
[19:28] <axisys> also, might a be question for #openssh, but anyway find out if anyone used x11 .. if not I could modify it without notifying over 2000 users :-)
[19:29] <teward> axisys: for the record, sarnold is on the security team - he speaks from knowledge therein ;)
[19:29] <teward> so if it's an "Unlikely, unless we handle it alongside something else", well... :P
[19:29] <axisys> teward: appreciate that..
[19:29] <sarnold> we're currently running a pretty steep backlog of issues at the moment, so it's behind a looong queue of other things
[19:29] <axisys> sarnold: I know how that is ;-)
[19:30] <axisys> sarnold: thank you
[19:30] <axisys> so any trick you guys know of x11 has been used recently would help decide how I go about making change with or without change management
[19:30] <sdeziel> axisys: maybe you could create a thin wrapper around xauth that logs something prior to calling the real xauth
[19:31] <sarnold> axisys: another potential mitigation (one I haven't researched at all) is using apparmor policies on the server; that can also confine what authenticated users can do. there's lots of ways of doing that, from giving users a login shell that is confinde with apparmor, or confining sshd with apparmor and using pam_apparmor to change users into a hat ..
[19:32] <axisys> sdeziel: so no log today of xauth use?
[19:32] <sdeziel> confining sshd with apparmor isn't exactly trivial though :)
[19:33] <sdeziel> axisys: maybe sshd logs something specific when calling to xauth. I don't know since I don't use that
[19:34] <axisys> sdeziel: on that token since it is enabled today.. let me use it and see how the log looks like.. thanks
[19:34] <sarnold> back when I was a kid we used to confine sshd with apparmor just for something fun to do on a saturday afternoon! of course back then movies were a quarter and a candy bar a nickel so you couldn't just buy your way to happiness let me tell you
[19:35]  * axisys wonders how old is sarnold
[19:36] <sdeziel> https://code.launchpad.net/~sdeziel/apparmor/usr.sbin.sshd-refresh
[19:36] <sdeziel> ^^ it was fun indeed :)
[19:37] <sarnold> cap_sys_ptrace???
[19:38] <sarnold> oh. right.
[19:38] <sarnold> #insert <rant/kernel_devs/ptrace>
[19:38] <sdeziel> yeah
[19:39]  * axisys struggling to follow 
[19:40] <sdeziel> actually the up to date version of the profile is here: https://github.com/simondeziel/aa-profiles/blob/master/16.04/usr.sbin.sshd
[19:40] <sarnold> it might be nice to clean out all the commented-out stuff.. I can't imagine that we'll bring back the privsep sshd any time soon
[19:40] <sdeziel> axisys: I also have a version for 14.04 but nothing for 12.04
[19:41] <sarnold> axisys: if you care about this specific flaw enough to use apparmor to confine your sshd, these patches would be a good starting point
[19:41] <axisys> sdeziel: might need to enable Log DEBUG .. cuz I do not see anything about xauth on remote's /var/log/auth.log when I login with ssh -X remote
[19:41] <sdeziel> sarnold: hmm, let me update that bzr merge proposal with the commented-out stuff removed
[19:42] <sdeziel> I wish apparmor's was tracked in git
[19:46] <sarnold> yeah :/
[19:46] <sarnold> see afore-mentioned backlog :(
[19:51] <sdeziel> yeah, at least the conversion is in the pipeline
[20:44] <axisys> sdeziel: yep atleast DEBUG1 is necessary to catch
[20:44] <axisys> x11-req
[20:45] <sdeziel> good to know
[21:42] <axisys> i have x11forwarding disabled.. what is the best way to test it? ssh -X remotehost and xterm fails ?
[21:45] <sarnold> yeah that shld suffice
[21:46] <teward> sarnold: oh, that brings a question, i'll poke in -hardened since it's a question about the openssl defaults :P
[21:46] <teward> openssh*