[00:43] <hallyn> rbasak: great, thanks
[01:52] <patdk-lap> heh, I always set dedicated ipmi interface, set static ipmi ip
[01:52] <patdk-lap> normally fixes up those issues
[02:19] <sarnold> patdk-lap: even for the home lab?
[02:26] <patdk-lap> expecially
[02:26] <patdk-lap> I'm running 7 vlans currently here at home
[02:27] <patdk-lap> none of that is a lab though
[02:38] <sarnold> none of my switches can do vlan, heh
[02:39] <sarnold> I've never learned enough about vlans to see it as a priority, so i've never spent the extra money
[02:39] <patdk-lap> I don't own a switch that doesn't do vlans
[02:40] <patdk-lap> swapping the current one out soon, for a poe model
[02:42] <patdk-lap> crap, this unbound issue I have, is still present as a bug :(
[07:48] <frickler> jamespage: coreycb: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1567811
[07:48] <jamespage> frickler, oh good spot!
[07:57] <smb> jamespage, if possible maybe depend loosely on both variants. Would be nice to have something like "provides" aliases for services. But I cannot find anything
[07:58] <jamespage> smb, we only have libvirt-bin in Ubuntu right?
[07:58] <smb> jamespage, right now, but it might change in future when we get rid of more delta
[07:59] <jamespage> smb, sure - we can switch when we do that :-)
[08:00] <smb> jamespage, of course :) but still a pain to always think of the implications if say backporting into cloud-archive
[08:00] <smb> for sysvinit scripts it was at least possible to say this provides libvirt-bin and libvirtd... but rather useless nowadays
[08:41] <frickler> jamespage: smb: if you want to add Alias=libvirtd.service to libvirt-bin.service, that would also work, just tested that variant
[08:42] <jamespage> frickler, that's a nice backwards compat feature
[08:43] <smb> Yeah... wondering why I did not see that in the systemd.service doc
[08:44] <smb> jamespage, would you know whether hallyn has some other things queued or shall I wait till he comes around to sync up
[08:44] <jamespage> smb,  not sure tbh
[08:44] <jamespage> smb, I'd wait for hallyn
[08:44] <smb> jamespage, ack
[08:44] <jamespage> smb, I'd also say that this is not critical for xenial
[08:44] <jamespage> hmm - well not from openstack's perspective
[08:45] <jamespage> I have no idea about other systemd units that might be dependening on libvirtd
[08:45] <smb> jamespage, hard to say. just if there is an "Alias" option that should not break anything existing while resolving anything we do not know about
[08:46] <jamespage> smb, yah so maybe it does make sense for compat with direct syncs from debian
[08:46] <jamespage> smb, shall I raise a libvirt task for that bug as well?
[08:47] <smb> jamespage, That is what we usually tried to maintain (for build dependencies and in sysvinit, just did not know about alias for systemd). yeah I think makes sense. probably can be lesser prio as you fix nova
[08:52] <bvi> anyone experience with ServeRAID M5120 in jbod mode?
[08:52] <bvi> installer doesn't even boot when this hba in in the server (lenovo x3650m5)
[08:55] <smb> frickler, Just to confirm: under which section did you add the alias? Install?
[08:57] <frickler> smb: yes, then disable/enable the service once in order to create the symlink
[08:58] <smb> frickler, ok, thanks
[09:09] <bvi> err M5210 .... damn typo
[09:09] <frickler> would it make sense to change to upstream connection of https://launchpad.net/ubuntu/xenial/+source/nova to mitaka instead of essex?
[10:53] <frickler> jamespage: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1567881
[12:30] <BlessJah> ubuntu seems to completely ignore preseed file I provide
[12:32] <BlessJah> In syslog I can see file has been loaded properly, but I cannot get any directive working, it still asks me questions that has been answered
[13:13] <frickler> jamespage: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1567935 is my final one for today, but https://bugs.launchpad.net/neutron/+bug/1567923 might also be interesting for you
[13:27] <supNow> just upgraded ubuntu server to 14.04 and I'm getting a grub_term_highlight_color not found error. google search suggests it can't find grub but I havn't found any real information on how to fix.
[13:28] <supNow> From reading it's saying that it can't find the bootloader. I have booted into a live session from a usb drive. Is there an easy way to fix it from there? Or should I try to boot into ubuntu-server using grub from the usb drive?
[13:30] <hateball> !fixgrub | supNow
[13:32] <supNow> @hateball it was actually ubuntu-server upgrade. There is no windows. Will that same thing work though that you linked?
[13:35] <hateball> supNow: Yes, it just tells you how to reinstall grub
[13:35] <supNow> ok great, thanks
[13:47] <coreycb> jamespage, we're not going to be able to sync magnum at this point in the cycle as it needs a big bump to python-docker
[13:47] <hallyn> smb: queued up for libvirt? i got nothing
[13:47] <ddellav> coreycb swift is ready for review/push lp:~ddellav/ubuntu/+source/swift
[13:48] <coreycb> ddellav, ok
[13:48] <jamespage> coreycb, 1.5.0 not good enough?
[13:48] <jamespage> coreycb, we may want the new version anyway - jgrimm - thoughts ^^ ?
[13:48] <coreycb> jamespage, not according to requirements.txt
[13:48] <smb> hallyn, k, I sent you a patch as well as have pushed a branch to lpgit. don't think its urgent now that nova got fixed
[13:49] <jgrimm> jamespage,  syncing magnum?
[13:49] <jgrimm> or bumping up python-docker?
[13:49] <coreycb> jgrimm, python-docker
[13:49] <jamespage> jgrimm, no syncing python-docker - we're right up to date with docker so we may actually want that right?
[13:50] <jgrimm> yes, we are at latest upstream
[13:50] <jgrimm> not sure if python-docker is that current tho?
[13:51] <jgrimm> docker.io-1.10.3 is what we carry.
[13:51] <coreycb> jgrimm, it's a bit behind, we're currently at 1.5.0 and it looks like they're up to 1.8.0 upstream
[13:52] <hallyn> smb: you didn't push to the xenial branch?
[13:53] <smb> hallyn, no, though I could have I guess. I used a smb/xenial one
[13:57] <jgrimm> coreycb, indeed 1.5.0 sounds quite long in the tooth.   I'm not seeing anything in their docs that gives me a warm fuzzing on what versions of docker their client supports?
[13:58] <jgrimm> coreycb, but i'd think you'd be better off moving up, though testing needed
[14:10] <kaffien> i ran a do-release-upgrade and ended up on 16.04.  Now our veeam setup cannot contact the NFS shares.  Is there something i need to configure on my ubuntu server to allow that again?
[14:12] <kaffien> veeam cannot connect to the SSH server i have running either
[14:12] <kaffien> but i can via a ssh client  on that same workstation.   nmap shows all the appropriate ports are open.
[14:12] <kaffien> nm wrong channel
[14:28] <coreycb> jamespage, ddellav: all of the final mitaka release packages are uploaded to xenial for mitaka now (sans the magnum sync)
[14:31] <jgrimm> \o/
[15:38] <ppetraki> if I use an lxd profile to limit the number of cpus to say 2. /proc/cpuinfo is showing two cpus, but lscpu is showing all the host cpus. Is that the intended behavior? http://pastebin.ubuntu.com/15690427/
[15:39] <patdk-wk> yes
[15:39] <patdk-wk> the kernel restricts what cpu's things can run on
[15:40] <patdk-wk> but it doesn't go around limiting the view of the physical hardware
[15:40] <ppetraki> ah ok
[15:41] <ppetraki> thanks
[15:45] <sdeziel> ppetraki: /proc/cpuinfo of the container is a lxcfs mount showing just the CPUs that you have enabled for that host
[15:50] <nacc> ppetraki: lscpu is looking in /sys/ in contrast, iirc
[15:58] <tiblock> Hi. I have ubuntu 14.04 server with 20GB on / and some logs files ate everything and i was not able to lauch anything so i removed about 18gb logs but `df -h` says only 300mb free, `ncdu` says 2.1gb used. Tryed to do `tune2fs -m 5 /dev/...` but its not helping. How to get space back?
[15:59] <tiblock> Oh, it just jumped to 9.8gb free... Okay. Problem kinda solved itself. Still missing about half but 9.8gb its okay.
[15:59] <nacc> tiblock: might need to issue a `sync;sync` if you deleted a ton of files
[15:59] <nacc> tiblock: it would probably be better to figure out what log exploded
[16:00] <lordievader> tiblock: Restart your loging service, it probably still has a link open to those files, thus they are still on disk.
[16:00] <tiblock> nacc, after `sync;sync` still says 8.8gb used and i fouln log, my own application made it, forgot to add folder to logrotate. I deleted that logs.
[16:01] <nacc> tiblock: ah ok, yeah i'd check lsof or as lordievader said
[16:01] <nacc> tiblock: in case it's being held open
[16:01] <nacc> `du -h` at the appropriate level might give you a better idea of what is consuming space rather than `df`
[16:02] <tiblock> Ah i see, `lsof` shows 7115024813 byte log file opened and says `(deleted)`. Okay, there is my space. Thank you very much!
[16:03] <tiblock> Awesome! After restart of that application i got all my space back.
[16:03] <tiblock> 2.2gb used
[16:05] <nacc> tiblock: nice, yeah, it was presumably still ref'd so couldn't be fully removed from disk (just unlinked from the fs effectively)
[16:06] <lordievader> You can do lovely tricks with this...
[16:08] <nacc> lordievader: "lovely" :)
[16:13] <sdeziel> nacc: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1556308 was approved for upload when you get a chance
[16:14] <nacc> sdeziel: ack, i don't have upload rights :)
[16:14] <nacc> sdeziel: hence sponsors is subscribed
[16:14] <sdeziel> oh didn't know. Thanks anyways
[16:14] <Blueking> patdk-wk  everything works fine now :)
[16:16] <patdk-wk> heh, I just filed an unbound bug last night, that just annoys me
[16:16] <sdeziel> patdk-wk: yeah, noticed this
[16:17] <patdk-wk> stupid unbound segfaulting on libcrypto :(
[16:17] <nacc> sdeziel: np, i'll see if i can find somebody
[16:17] <sdeziel> patdk-wk: would you mind opening a bug in Debian re /usr/sbin being in PATH? The Ubuntu delta should be kept minimal
[16:17] <patdk-wk> figured cron restart would be a temp fix, nope :(
[16:18] <patdk-wk> ah, I'll look
[16:18] <sdeziel> patdk-wk: latest Debian and soon Ubuntu will use the package helper which now calls unbound-anchor with a full path. Only unbound-checkconf will need fixing making it a oneliner
[18:16] <ppetraki> before first install lxd, I configured my own bridge, bridge0 (via nm) and made that the default bridge. Then I created a new profile called scaleout, which when used makes my containers use lxcbr0, which doesn't even exist. Even claims there's an IP address, which is unreachable. That's a bug right?
[18:44] <sarnold> ppetraki: that does sound like a bug; iirc there's a way to tell lxd which bridge to use (it's liable to be a different mechanism than whatever you used to mark yours 'default') -- but it feels funny that it then reports unreachable IPs
[19:03] <ppetraki> sarnold, well, I told it not to even make the lxcbr0 (whatever the default bridge is) to begin with, it physically doesn't exist. So it's like the new profile, which I created from scratch decided to inherit a device config without telling me. It gets better, when I take the 'device' config from default and insert it into my new profile, those containers now have no interface.
[19:04] <ppetraki> sarnold, about to retest on a fresh vm, I'll keep you posted
[19:05] <sarnold> ppetraki: note that recent lxd changes have switched to using lxdbr0 by default, among other bridge-related changes https://launchpad.net/ubuntu/+source/lxd/+changelog
[19:06] <sarnold> ppetraki: it may be worth mkaing sure your image has the 2.0.0~rc9-0ubuntu3 release..
[19:18] <ppetraki> sarnold, ok, I have that release installed. the default config isn't getting my bridge. http://pastebin.ubuntu.com/15696446/  . just installed this vm from scratch
[19:20] <sarnold> ppetraki: probably one for stgraber ^^^
[19:20] <ppetraki> sarnold, ... and if I restart the lxd service it's there :)
[19:20]  * ppetraki sees if it can use it
[19:20] <sarnold> hunh
[19:21] <ppetraki> sarnold, http://pastebin.ubuntu.com/15696528/
[19:22] <stgraber> ppetraki: either you're on an old packaging which doesn't restart lxd-bridge for you or your lxc profile command ran right before the change is effective
[19:22] <sarnold> ppetraki: try the ps aux again after sudo service lxd start; iirc it's a socket-activitated thing
[19:22] <ppetraki> stgraber, just installed the whole distro an hour ago
[19:22] <stgraber> ppetraki: ok, so chances are that if you ran that lxc profile command again a second later it would have been right
[19:22] <ppetraki> stgraber, see http://pastebin.ubuntu.com/15696446/
[19:23] <stgraber> ppetraki: ok, so yeah, you are on the latest, which means that the change very likely was applied a few ms after you ran that lxc profile command
[19:24] <stgraber> ppetraki: profile changes can only be applied after the daemon is started so the very first query you do may return the old config. We do however hold container startup until the config was updated so you can't race it and start a container with the old bridge.
[19:26] <ppetraki> stgraber, I'm not the fastest typist in the world, perhaps a few seconds passed between the start and me asking for the profile. In either case, it's easy enough to sleep a sec or restart the service before continuing.
[19:26] <stgraber> ppetraki: lxd is socket activated
[19:27] <stgraber> ppetraki: so the first lxc command you run will start it, it won't be running until then
[19:27] <ppetraki> stgraber, ah, right, the new systemd stuff
[19:27] <ppetraki> ok
[19:27] <stgraber> so if the first command you run is "lxc profile show default" then it very likely will show you the old values
[19:27] <ppetraki> stgraber, I'll just poll for the right keys to show up then
[19:27] <stgraber> if it's the second command you run, it should be fine as the profile update script is very quick and starts immediately when the API is available
[19:28] <sarnold> is there a do-nothing command that'll start it that would be a nice first command to run?
[19:28] <stgraber> ppetraki: why do you need to wait?
[19:28] <stgraber> sarnold: lxc finger
[19:28] <sarnold> stgraber: looks perfect :)
[19:29] <ppetraki> stgraber, I don't. Just like you said, if I run the lxc command again it should have reflect the correct profile
[19:29] <sarnold> ppetraki: try: 'lxc finger ; lxc profile show default' and see if that's the results you expect
[19:29] <ppetraki> stgraber, so when I script this, I'll just call that and wait until bridge0 actually shows up in the config
[19:29] <stgraber> ppetraki: well, my question is more, why do you need to check that bridge0 made it in there?
[19:29] <ppetraki> stgraber, its correct
[19:30] <ppetraki> stgraber, about to create a bunch of containers with it via script
[19:30] <stgraber> ppetraki: if the next thing you do is launch a container, lxd will already wait for profile config updates to be done before actually starting it
[19:30] <ppetraki> so I want it to be correct
[19:30] <ppetraki> stgraber, ok, I will try that, less work, better
[19:31] <stgraber> yeah, we sure didn't want users running "lxc launch ubuntu:14.04 blah" as their first command and that picking up the wrong bridge, so we do have logic to avoid that very problem :)
[19:32] <ppetraki> I'm sure. It's just that I just spent a hour or so working with a slightly older version that wasn't as well behaved. So I got a little paranoid
[19:32] <stgraber> we just can't do the same with the profile API as the profile update script itself needs the API to be functional to update the config :)
[19:32] <stgraber> ah yeah, that particular fix was introduced in rc9
[19:32] <ppetraki> stgraber, good stuff so far, it looks like it'll suit us well. passing through kernel devices was fun
[19:33] <stgraber> :)
[19:33] <ppetraki> now to get the rest of the stack up
[19:37] <ppetraki> stgraber, ugh, check this out. it's like the default profile isn't the default. http://pastebin.ubuntu.com/15696865/
[19:37] <stgraber> ppetraki: nope, you're just not reading this right :)
[19:37] <ppetraki> of course!
[19:37] <stgraber> ppetraki: it's listing you the interfaces INSIDE the container
[19:38] <stgraber> ppetraki: ubuntu:x/amd64 is pretty dated (last beta) so it still has lxcbr0
[19:38] <stgraber> ppetraki: if you were to use ubuntu-daily:x/amd64 you wouldn't see that interface anymore
[19:38] <sdeziel> stgraber: nested lxc ?
[19:38]  * ppetraki switches images
[19:38] <stgraber> sdeziel: yeah, it's showing the lxcbr0 that's running inside the container as we have lxd pre-installed in cloud images
[19:39] <sdeziel> makes sense, thanks
[19:40] <sarnold> owwwww
[19:40] <sarnold> now my head hurts
[19:42]  * patdk-wk is so far happy with lxc, though, it kindof annoying to adjust my apparmor profiles for it
[19:43] <patdk-wk> or is there a better way to *stack* apparmor profiles
[19:43] <patdk-wk> think I use changehat :(
[19:44] <patdk-wk> ah, used aa_change_profile
[19:45] <tyhicks> patdk-wk: the Xenial kernel has support for stacking AppArmor profiles
[19:45] <sarnold> patdk-wk: I -think- that just landed..
[19:46] <patdk-wk> ya, I'm using 16.04
[19:46] <sarnold> patdk-wk: .. dunno if lxd has adapted yet
[19:46] <tyhicks> patdk-wk: the required userspace changes will hopefully land within the next few days
[19:46] <tyhicks> sarnold: no, they haven't
[19:46] <patdk-wk> I found out my profile change didn't work, so I created a lxc profile + my changes
[19:46] <patdk-wk> then adjust the lxc profile to allow that profile to be used
[19:46] <patdk-wk> worked for now, just seems like a bit of extra work
[19:46] <patdk-wk> ok
[19:46] <tyhicks> patdk-wk: you'll (hopefully) soon have aa_stack_profile() in Xenial's libapparmor
[19:47] <patdk-wk> so that will only work when running lxc 16.04 guests?
[19:47] <patdk-wk> but not 14.04 right?
[19:47] <patdk-wk> unless backport libapparmor somehow
[19:47] <sarnold> the stacks would be managed by the 16.04 lts system; i'd expect it to work..
[19:48] <tyhicks> patdk-wk: it'll require a 16.04 host
[19:48] <tyhicks> patdk-wk: note that lxc/lxd integration for stacked profiles is not in place yet
[19:48] <patdk-wk> oh
[19:49] <tyhicks> patdk-wk: as long as you have a 16.04 host, it should work with any ubuntu container, including 14.04
[19:49] <patdk-wk> so the inside will call normal aparmor call, and it will be adjusted to a stack call?
[19:49] <patdk-wk> I think that is what I don't get :)
[19:49] <patdk-wk> ok :)
[19:49] <tyhicks> the container setup code in the host will change to aa_stack_profile() (or simply adjust policy)
[19:50] <tyhicks> inside the container, nothing needs to change
[19:50] <patdk-wk> well, I have a good test for it when it's ready atleast :)
[19:50] <tyhicks> great :)
[19:50] <patdk-wk> updating my profiles for 16.04 was fun, so many new things I can limit :)
[19:51] <tyhicks> :)
[19:51] <sarnold> :D
[21:04] <ppetraki> stgraber, I guess I can't call this from a container? mlockall( MCL_CURRENT|MCL_FUTURE ); our process doesn't want to be swapped out
[21:05] <stgraber> ppetraki: I'm guessing that's a privileged call so not for unprivileged containers
[21:06] <stgraber> ppetraki: you could try to make the container privileged though (lxc config set NAME security.privileged true && lxc restart NAME)
[21:06] <ppetraki> stgraber, can I make it a privledged container?
[21:06] <stgraber> at which point root in the container will be real root outside of it, so unless the kernel is being weird because of cgroups and stuff, this should work
[21:09] <ppetraki> stgraber, that's working
[21:10] <ppetraki> it got further, and then I ran out of space :). good, it looks like it's getting the resources it needs
[21:47] <Velus-universe> hello im folling this https://help.ubuntu.com/community/PostfixVirtualMailBoxClamSmtpHowto and i get to  this bit Make Dovecot listen for authentication requests and it says the code needs to be updated for newer version? can someone help me with this bit please?
[21:54]  * patdk-lap wonders why it wouldn't work
[21:56] <Velus-universe> https://help.ubuntu.com/community/PostfixVirtualMailBoxClamSmtpHowto#Configure_Dovecot shows a pre and post 12.4 setup and they look different, i cant figure out how it needs to be changesd
[21:59] <Velus-universe> patdk-lap, would you bhe able to help me with this please
[22:00] <patdk-lap> http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
[22:01] <patdk-lap> though, you still need the passdb and userdb sections
[22:05] <Velus-universe> patdk-lap, would the service auth be like this then http://pastebin.com/EMuMbmnN
[22:07] <patdk-lap> remove executable
[22:07] <patdk-lap> remove user
[22:08] <patdk-lap> and the example you are following uses auth-client instead of auth
[22:08] <Velus-universe> ok
[22:09] <patdk-lap> dunno why they are having you use cram-md5, that is horrible
[22:10] <Velus-universe> ok patdk-lap ifd i remove the user and that it reuses connection
[22:14] <patdk-lap> odd, I don't have it
[22:17] <Velus-universe> i got it working now anyway, now i just need to ad mx records to my domain name but i forgot how to do them lol
[22:18] <patdk-lap> just mx?
[22:18] <patdk-lap> if you plan to send email you should have ptr, spf, and maybe dkim
[22:18] <Velus-universe> yeah i will be doing them in a bit but i need to figure out how to do the mx i will be setting up the ptr and spf after the mx
[22:19] <conrmahr> Can you format a disk with a RAID array on UBNTU server?
[22:19] <patdk-lap> conrmahr, what does that even mean?
[22:20] <conrmahr> I know I'm an idiot
[22:20] <conrmahr> I took an 4TB WD Red Drive from a Synology DiskStation
[22:21] <conrmahr> and installed it on a computer runnning Ubuntu Server but it can't mount it.
[22:21] <patdk-lap> well ya
[22:21] <patdk-lap> no one claims synology uses some standard raid/filesystem that ubuntu understands
[22:21] <conrmahr> Can I just erase and format it to ext4?
[22:21] <patdk-lap> I personally have no idea what they use
[22:21] <patdk-lap> sure
[22:22] <conrmahr> yeah that's what i want to do
[22:22] <sarnold> patdk-lap: i'd always had the impression that it was dm-raid with ext4; iirc they even use ecryptfs for their encrypted storage
[22:22] <patdk-lap> dunno
[22:22] <sarnold> but their own 'magic raid" thing may be different, non-standard..
[22:22] <conrmahr> f-synology
[22:22] <conrmahr> im sick of it
[22:22] <patdk-lap> most of them use mdadm/dm-raid
[22:22] <conrmahr> i just want to run my own Ubuntu server
[22:22] <patdk-lap> some of them, heh, don't
[22:23] <patdk-lap> I know mine uses raid-3d
[22:25] <patdk-lap> believe it was made by ibm
[22:25] <Velus-universe> patdk-lap, i have done the mx record now yay
[23:51] <conrmahr> Can anyone help me format a HDD on Ubuntu server with a raid array?
[23:52] <nacc> conrmahr: you mean you want to use SW RAID with the partitions of a single HDD?
[23:53] <conrmahr> i just remove everything from a HDD and start fresh with a clean ext4 partition
[23:54] <nacc> conrmahr: ok, maybe just restate what you are trying to do?
[23:55] <conrmahr> Yes I have a computer with a 60GB SSD with Ubuntu Server on it
[23:55] <conrmahr> I want to install a 4TB WD Red HDD as a secondary
[23:56] <bekks> And where is that raid array then?
[23:56] <conrmahr> but that WD HDD is from a Synology NAS which was formated with a RAID array
[23:56] <bekks> So you need to put a new primary partition table on it.
[23:56] <bekks> Do you use UEFI?
[23:56] <conrmahr> yes
[23:57] <conrmahr> i think i've tried but it says it's "in use"
[23:57] <bekks> You've tried what?
[23:57] <conrmahr> with 'parted"
[23:57] <conrmahr> new primary partition
[23:57] <bekks> UEFI has no primary partitions.
[23:58] <bekks> you are still trying to use legacy mode.
[23:59] <conrmahr> i'm pretty sure my BIOS is UEFI
[23:59] <conrmahr> let me check