[01:07] <Javezim> Anyone had an issue with GlusterFS Running on ZFS, where by deleting data from Gluster pool doesn't delete it from the ZFS Bricks available space on Ubuntu 16.04
[01:07] <Javezim> Doing a du -csh, the data has gone, but doing a df -h shows that the data is still there
[01:07] <Javezim> the df -h never shrinks after deleting files
[02:41] <SpaceBass> hey folks
[02:42] <SpaceBass> anyone familiar with EncFS? I'm using -o umask='0002' but it's not honoring that once it's mounted
[02:42] <SpaceBass> I end up with: -rwxrwxr-x
[02:46] <trippeh_> well that do match the umask. maybe you want 0007 or 0027 instead?
[02:46] <trippeh_> (never used encfs myself)
[02:49] <SpaceBass> trippeh_, I think you're right...it 0007 isn't it?
[02:49] <trippeh_> if you want other to be none, yes
[02:51] <SpaceBass> that worked - thanks trippeh_ !
[02:51] <trippeh_> np :)
[03:36] <SuperLag> I'm running into this issue. http://lvb.link/2gQpCM9 I'm trying to use Ubuntu Server as a template to create new VMs from, and the VMs created from the template have no networking. Is there any way to permanently fix that issue, so I can continue to use it in an *automated* fastion? or am I stuck with manually editing files every time, to fix it?
[03:37] <SuperLag> I'm using kitchen-test, which spins up an Ubuntu VM and runs the cookbooks I've written, and tests everything, then it destroys the VM
[03:37] <SuperLag> Chef stuff, that is.
[05:39] <fluvvell> I virtually never use ftp, but am setting up vsftpd - certificates work for tls, but I
[05:39] <fluvvell> get stuck around the jail setup, which file do I put the user I'm allowing in?
[05:39] <fluvvell> I get a prompt using filezilla, the correct certificate comes up, then it fails on password.
[05:40] <fluvvell> I know I don't put the username in the same file as the disallowed users,
[05:41] <fluvvell> I wanted to chroot the user - sandbox him as it were but I'm going in circles
[07:14] <fluvvell> I am setting up vsftpd - certificates work for tls, but I get stuck around the jail setup, which file do I put the user I'm allowing in?  I get a prompt using filezilla, the correct certificate comes up, then it fails on password.
[07:14] <fluvvell>  I know I don't put the username in the same file as the disallowed users,  I wanted to chroot the user - sandbox him as it were but I'm going in circles  Anyone used vsftpd successfully?
[11:01] <caribou> rbasak: I need to revisit my nut merge : AFAICT, I followed the wiki instructions step by step
[11:49] <rbasak> caribou: we can go through it together if you like. I know the documentation is a bit lacking.
[11:50] <caribou> rbasak: I may have found the reason : using usd tag on the logical goes to fetch the version in the changelog and, once the changelog is removed from the reconstruct/{vers}, it has the debian version at the top
[11:50] <caribou> rbasak: unless I've made yet another mistakke
[11:52] <caribou> rbasak: if you checkout to the logical/{vers} tag, the changelog has 2.7.2-4 as a version, w/o the ubuntu1, which is in the changelog commit of the reconstruct/{version}
[11:54] <rbasak> caribou: I don't follow. What steps are you taking exactly?
[11:54] <caribou> rbasak: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow#Detailed_workflow
[11:55] <rbasak> Oh, I think I see.
[11:55] <caribou> rbasak: sorry, I meant deconstruct/{vers} though
[11:56] <caribou> rbasak: step #6 creates the tag
[11:58] <rbasak> Yes, that's a bug in either "usd tag" or the workflow documentation.
[11:58] <rbasak> I'll file a bug.
[11:58] <rbasak> For now, can you rename the tag manually please?
[11:58] <rbasak> Sorry about that. I've never actually used "usd tag" - I predate the tooling and tend to do things by hand :-/
[12:02] <rbasak> caribou: I filed bug 1651113
[12:03] <caribou> rbasak: well, I was doing it by hand the first time and mistakenly took 2.7.4-4 so  I decided that it would be better to adhere strictly to the doc :-)
[12:03] <caribou> rbasak: ok, will do & force push the change
[12:13] <caribou> rbasak: done
[12:25] <rbasak> caribou: have you got commits 11414d6 and 0d4aab8 muddled?
[12:26] <rbasak> Old logical commit 40d6910 too.
[12:27] <rbasak> Actually it's just 40d6910 that seems to be squashed into 11414d6 now.
[12:27] <caribou> rbasak: I'll look at it
[12:30] <rbasak> caribou: and did you manage to send any of the delta to Debian please?
[12:39] <rbasak> caribou: so for the logical, I'd expect 40d6910 and 53cc078 to be squashed together. Logically, it's just "add nut to dialout group", as opposed to "add nut to dialout group, then fix how we did it".
[12:39] <rbasak> caribou: and then in your merge branch, 11414d6 needs splitting out, with the "add nut to dialout group" part squashed with 0d4aab8f in a separate commit that is just "add nut to dialout group".
[12:40] <caribou> rbasak: thanks for the review, I'll try to get it done by EOD
[12:41] <rbasak> caribou: no problem, and no rush. I haven't finished the review, but this fix probably should involve rebasing and will mutate all the commit ids. So shall I want for you to do that before continuing?
[12:41] <caribou> rbasak: I'm fighting a QEMU upstream bisection in-package
[12:41] <rbasak> caribou: you can create a merge.v3 when you're ready.
[12:41] <caribou> rbasak: yes, that was my thought
[12:42] <rbasak> caribou: sounds good. Also don't forget to check that debian/changelog still matches after those changes.
[13:49] <caribou> smoser: any  news regarding the SRU for LP: #1648380 ?
[13:50] <caribou> seems to be blocked by another SRU
[14:28] <smoser> caribou, yeah, its blocked by the other... the other is supposed to i think go in today
[14:29] <smoser> and there is an upload in the queue to go in as soon as it can
[14:29] <smoser> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=cloud-init
[14:29] <caribou> smoser: thanks!
[14:30] <smoser> but we didn't want to re-start a waiting period on the one already in -proposed
[14:30] <cpaelzer> rbasak: FYI since Debian split off some packages the strongswan update is in the NEW queue
[14:31] <cpaelzer> rbasak: I tihnk this is just normal, but if you think there is something odd going on and I'd need to adapt anything let me know
[14:39] <rbasak> cpaelzer: that sounds as expected, thanks.
[18:07] <whitekidney> is there any way to do livepatching on ubuntu servers **without** the canonical livepatch service?
[18:11] <genii> !info ksplice
[18:11] <genii> Apparently not.
[18:12] <genii> !info ksplice xenial
[18:12] <genii> !info ksplice trusty
[18:12] <whitekidney> ksplice is only free for desktop systems
[18:13] <genii> ..besides which it seems to have been removed or superceded
[18:13] <whitekidney> ya exactly, by what :P ive been googling around
[18:38] <nacc> whitekidney: i mean, sure, you could presumably provide the patch data yourself to your kernel? but then you'd need to maintain/provide that data. That is, you'd do the live patching just like you would with a mainline kernel?
[18:39] <nacc> whitekidney: ksplice was deleted from debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805916
[18:41] <nacc> whitekidney: i'm assuming you'd want to read Documenation/livepatch/* in the kernel source
[19:20] <hasenov> hello, anyone know how to succesfully import an image into novalxd that is not ubuntu?
[19:20] <hasenov> specifically, i would like to import centos image
[19:21] <hasenov> i was able to succesfully import images from cloud-images.ubuntu.com
[19:21] <hasenov> however all those images hosted are ubuntu
[19:27] <hasenov> the images hosted from cloud.centos.org do not seem to work
[19:29] <sarnold> hey hasenov :) the centos kernels may be fairly different from the ubuntu kernels, I'm not 100% sure the software in the container would be prepared for the kernel configuration options we used on our kernels
[19:30] <hasenov> oh i see, sarnold, would you be able to explain to me why centos container images work with lxd however fail to start up with novalxd?
[19:31] <hasenov> im just trying to figure out how it all works
[19:32] <hasenov> i am able to succesfully start up centos container instances using "lxc start instance" however when i try to start up same image with novalxd it wont work
[19:42] <sarnold> hasenov: ahh I see
[19:42] <sarnold> hasenov: are you able to import the images into glance?
[19:51] <hasenov> sarnold: hi, i can import it succesfully
[19:51] <hasenov> however when i start it from the horizon web ui it refuses to start
[19:52] <sarnold> hasenov: oh, that's a start; what error do you get?
[19:57] <hasenov> on the log console i dont get any error, it completely empty
[19:57] <hasenov> however when i goto the compute-nova log file, i get WARNING nova.compute.manager [-] [instance: 8ec8e338-a0cf-4968-88bc-8a6d4bfa2d31] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 4, current VM power_state: 4
[19:58] <hasenov> its status is Active, however Power State always goes to Shut Down
[19:59] <hasenov> hmm, if i go into the compute node and try to start it up manually with "lxc start instance" it throws out
[20:00] <hasenov>             lxc 20161219195844.236 ERROR    lxc_start - start.c:start:1439 - No such file or directory - failed to exec /sbin/init
[20:00] <hasenov>             lxc 20161219195844.236 ERROR    lxc_sync - sync.c:__sync_wait:57 - An error occurred in another process (expected sequence number 5)
[20:00] <hasenov>             lxc 20161219195844.236 ERROR    lxc_start - start.c:__lxc_start:1354 - failed to spawn 'instance-00000020'
[20:00] <hasenov>             lxc 20161219195844.748 ERROR    lxc_conf - conf.c:run_buffer:347 - Script exited with status 1
[20:00] <hasenov>             lxc 20161219195844.748 ERROR    lxc_start - start.c:lxc_fini:555 - failed to run post-stop hooks for container 'instance-00000020'.
[20:00] <hasenov>             lxc 20161219195844.748 WARN     lxc_commands - commands.c:lxc_cmd_rsp_recv:172 - command get_cgroup failed to receive response
[20:01] <hasenov>             lxc 20161219195844.748 WARN     lxc_commands - commands.c:lxc_cmd_rsp_recv:172 - command get_cgroup failed to receive response
[20:01] <hasenov> however the same image works with lxc outside of the compute node, if that makes sense
[20:03] <sarnold> yeah, that makes sense; you'd expect lxd to be good at handling lxd images :)
[20:07] <dasjoe> kirkland: hi! I think it'd be nice if manpg.es/ would keep pointing to the latest LTS, I just realized it points at zesty as of now :)
[20:24] <hasenov> yeah, i get this error for the cloud centos image too
[20:24] <hasenov> guess i am SOL on this?
[20:25] <sarnold> hasenov: it's probably worth a bug report or a mail to the server mail list
[21:48] <sarnold> rbasak: nice reply to ubuntu-devel re security sponsoring, thanks :)