[00:05] hallyn: are you there? === prince is now known as King === King is now known as prince === prince is now known as prince[1] === prince[1] is now known as prince === Bray90820_ is now known as bray90820_ === ochoroch1 is now known as ochoroch [06:46] man, for a bad time, undefine the uvtool storage pool in libvirt then try to make it work again. sheeeeesh. [06:47] I ought to be familiar with this cycle by now; ignore libvirt, think it's probably fine, try it again, hate it again. repeat. === athairus is now known as afkthairus [07:22] nevyn: you factoring [07:22] bah [08:43] dnsmaster named[15571]: ../../../lib/isc/ratelimiter.c:185: INSIST((rl->pending).tail == (event)) failed, back trace [08:43] hrms ;) [09:16] Elo [09:17] I'm in the need of some advice, I'll describe my problem, hold on [09:18] 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] 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] cpaelzer, any opinion on a sane default for allocating cpu cores for dpdk/ovs ? [10:31] trying to capture some sort of best-practice for the neutron/ovs/dpdk integration [11:03] jamespage: dpeends on the system size [11:03] jamespage: how complex can the rules become ? [11:03] jamespage: as input vars you surely have the overall #cpus [11:03] cpaelzer, my current thinking was to allocate a core on each numa node along with some ram [11:03] jamespage: do you also have #network cards and maybe even #queues on these cards? [11:04] jamespage: not a bad thinking - I'd consider that a good lower boundary [11:04] jamespage: but it depends a lot if this system primary purpose is passing dpdk traffic [11:05] 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] cpaelzer, I have memory per numa node as a config option, might add cores per numa node as well [11:06] jamespage: htat I like very much [11:06] 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] jamespage: will that end up in dpdk's -c option? [11:07] cpaelzer, yes [11:07] jamespage: while you are at it please consider setting rx queues [11:07] jamespage: after you started openvswitch-dpdk [11:07] cpaelzer, on what formula? [11:07] jamespage: you can set it via "ovs-vsctl set Open_vSwitch . other_config:n-dpdk-rxqs=2" [11:08] that example uses two queues [11:09] jamespage: formular would IMHO be "up to the number of combined queues, but not more than CPUs assigned" [11:09] jamespage: I'd guess that is a sane start [11:09] jamespage: a manual tuning would include locating on which socket a network card is and then make way more complex masks [11:10] jamespage: number of queues can be read with "ethtool -l" [11:10] and - btw - is by default limited to #cpus [11:10] so on my 12 core the card has 64 queues but uses 12 by default [11:11] ah and I wrote it wrong, has to be BEFORE ovs-dpdk restart [11:11] so that on device init it picks it up [12:11] rbasak: remember my query on apache2 backport from Xenial to trusty : looks like it's not going to be as simple : [12:12] rbasak: there is a Pre-Depends: dpkg (>= 1.17.14) after the Utopic version [12:13] " * Bump dpkg Pre-Depends to version that supports relative symlinks in [12:13] dpkg-maintscript-helper's symlink_to_dir. Closes: #769821" [12:13] I remember that now. [12:13] Yeah that one might be a little messy to fix. [12:26] rbasak: the simpler solution is to backport the Utopic version that is the one right before the addition of this pre-depends [12:27] rbasak: and is still what the original bug asked for [12:27] caribou: I think the pre-depends was to fix a bug. [12:28] rbasak: I'm looking at the xenial source;looks like what it was fixing is no longer used [12:28] symlink_to_file [12:28] Perhaps I'm thinking of a different bug. [12:28] symlink_to_dir rather [12:30] bug 1393832 is what I have in mind. [12:30] bug 1393832 in apache2 (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [High,Fix released] https://launchpad.net/bugs/1393832 [12:30] I think that's completely unrelated now. Sorry. [13:08] 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:08] Launchpad bug 1566296 in python-keystoneauth1 (Ubuntu) "Please upgrade python-keystoneauth1 for xenial" [Undecided,New] === Sprockt is now known as Sprocks === xnox_ is now known as xnox === not_phunyguy is now known as phunyguy === akaWolf1 is now known as akaWolf === inaddy_ is now known as inaddy === andol_ is now known as andol === fidothe_ is now known as fidothe === TJ_Remix is now known as TJ- [13:49] 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] frickler, we have a standing ffe for mitaka/xenial [13:49] coreycb, ^^ can you take a look please [13:50] coreycb, I'm +1 on a resync with Debian if that looks good with you. [13:51] 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] 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] 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] jamespage, frickler, yes sounds good I'll take a look today. [13:54] 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] 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] or both :) [13:55] I'm already testing it, it's working so far [13:55] Or... use it in production, its excellent real world testing for the rest of us ;] [13:56] jrwren: ^^ [13:57] frickler, fyi just testing a revised 32 bit compat patch and will get 10.1.0 uploaded to xenial [13:58] I may stay reasonable and use wily with lxc and zfs ppa then [14:00] jamespage: any change to tackle some of my issues with that, too? [14:01] 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:01] Launchpad bug 1488962 in apache2 (Ubuntu) "systemd does not notice when apache2 service fails" [Medium,Confirmed] [14:02] 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 === BlackDex_ is now known as BlackDex [14:04] frickler, on my list for this week... [14:04] not apache2 [14:05] frickler, I see rbasak did some triage - is that bug ^^ a target for xenial? [14:05] frickler, urgh - that's a systemd fix in suse... [14:06] Yeah, that needs attention. [14:06] smoser was going to look at systemd-boot tagged bugs but I think he's occupied on something else. [14:06] jgrimm: ^^ [14:07] :-( [14:07] 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] s/on/one/ [14:07] rbasak, i'm going to suggest cpaelzer for that task [14:07] Slashman: how is that an issue? [14:08] not sure how the update will handle that, and I prefer the latest stable version :p [14:10] jgrimm: dpdk crumbles between my fingers atm, so I unsugegst myself :-) but lets talk in 20 minutes and define priorities [14:10] cpaelzer, ok, i can do1x1 now if you'd like [14:11] jgrimm: let me just adapt and start the next iteration of the testsuite - approx 3 min [14:11] cpaelzer, k [15:02] jgrimm: ohai, PM? [15:03] teward, hi there === kickinz1|eod is now known as kickinz1 === jgrimm is now known as jgrimm-afk [15:33] 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] Launchpad bug 1546116 in manila (Ubuntu) "manila share process init script is missing" [Medium,Fix committed] [15:33] I put the fix up awhile ago but no one has had the chance to review/push [15:35] ddellav, we need to get that into xenial first - manila is one of the git repo's under ~ubuntu-server-dev [15:37] jamespage should I create the MIR? [15:37] ddellav, MIR ? [15:37] jamespage it's in xenial/universe currently [15:38] ddellav, I think we're talking cross purposes [15:38] there is no manila-share package in xenial yet [15:38] jamespage ooooh, that's what you meant. [15:38] ddellav, yes [15:39] jamespage so a requestsync then? [15:39] ddellav, no [15:41] 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] jamespage so what is the next step? [15:41] ddellav, how would you make a packaging change to any of the other core openstack packages? [15:44] 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] ddellav, git+ssh://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/manila is the source for manila [15:45] can you propose the fix for this bug against that please? [15:46] jamespage yep [15:46] ddellav, thanks! [15:46] ddellav, the delta in your bzr branch looks fine btw - just needs targetting to the right location! [15:46] jamespage gotcha, thanks [15:46] server team still meeting today? [15:49] teward: yeah, scheduled to start in 10 minutes [15:49] cool [15:49] just making sure, I can't ever keep track of whomever is chair :) [15:50] https://wiki.ubuntu.com/ServerTeam/Meeting has chair [15:50] but as you say, not always 100% accurate [15:50] yep === kickinz1 is now known as kickinz1|eod [16:17] frickler, any thoughts on what we should set the TasksMax attribute to for ceph-osd/mds/mon ? [16:17] 512 is way to low [16:18] frickler, looking at the juju charms, we currently set kernel.pid_max to 2097152 as a sane default [16:23] 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 === twoface89 is now known as twoface88 === wendar_ is now known as wendar [16:56] 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] but they include fixes for most of your reported problems... [17:19] TJ- hello again :) === twoface89 is now known as twoface88 === twoface89 is now known as twoface88 === afkthairus is now known as athairus === jgrimm-afk is now known as jgrimm [18:45] 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] axisys: you can track the patch status in Ubuntu here: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-3115.html [18:47] axisys: in the meantime there are some mitigation you can apply as mentioned in http://www.openssh.com/txt/x11fwd.adv [18:49] sdeziel: forgot to mention, I was there already... but let me check the mitigations [18:49] axisys: disable X11Forwarding and it'll help mitigate [18:50] yup [18:50] "Set X11Forwarding=no in sshd_config. This is the default." [18:50] not sure the defaults in Ubuntu's openssh-server, but it's that simple to help mitigate [18:50] Debian/Ubuntu changed that default [18:51] how do I check the default values? is there a switch ? [18:51] axisys: /etc/ssh/sshd_config [18:51] go poke there, which is on your system. [18:51] edit those configuration items, so that X11Forwarding has 'no' instead of 'yes' [18:51] unless you need X forwarding [18:51] 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] in which case you're stuck between a rock and a hard-place [18:53] axisys: sed -i 's/^X11Forwarding.*/X11Forwarding no/' /etc/ssh/sshd_config [18:58] sdeziel: and no-x11-forwarding on those keys [18:59] axisys: that would work too but the global param also covers password authentication [19:27] sdeziel: right.. would you know if ubuntu will have a upgrade available soon? [19:28] unlikely [19:28] we've rated it low, so it'll only get handled alongside something else [19:28] 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] axisys: for the record, sarnold is on the security team - he speaks from knowledge therein ;) [19:29] so if it's an "Unlikely, unless we handle it alongside something else", well... :P [19:29] teward: appreciate that.. [19:29] 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] sarnold: I know how that is ;-) [19:30] sarnold: thank you [19:30] 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] axisys: maybe you could create a thin wrapper around xauth that logs something prior to calling the real xauth [19:31] 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] sdeziel: so no log today of xauth use? [19:32] confining sshd with apparmor isn't exactly trivial though :) [19:33] axisys: maybe sshd logs something specific when calling to xauth. I don't know since I don't use that [19:34] sdeziel: on that token since it is enabled today.. let me use it and see how the log looks like.. thanks [19:34] 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] https://code.launchpad.net/~sdeziel/apparmor/usr.sbin.sshd-refresh [19:36] ^^ it was fun indeed :) [19:37] cap_sys_ptrace??? [19:38] oh. right. [19:38] #insert [19:38] yeah [19:39] * axisys struggling to follow [19:40] 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] 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] axisys: I also have a version for 14.04 but nothing for 12.04 [19:41] 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] 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] sarnold: hmm, let me update that bzr merge proposal with the commented-out stuff removed [19:42] I wish apparmor's was tracked in git [19:46] yeah :/ [19:46] see afore-mentioned backlog :( [19:51] yeah, at least the conversion is in the pipeline === twoface89 is now known as twoface88 === twoface89 is now known as twoface88 [20:44] sdeziel: yep atleast DEBUG1 is necessary to catch [20:44] x11-req [20:45] good to know [21:42] i have x11forwarding disabled.. what is the best way to test it? ssh -X remotehost and xterm fails ? [21:45] yeah that shld suffice [21:46] sarnold: oh, that brings a question, i'll poke in -hardened since it's a question about the openssl defaults :P [21:46] openssh* === alexisb is now known as alexisb-afk