[03:50] <mwhudson> hm
[03:51] <mwhudson> can i use uvt-kvm to create a vm backed onto a lvm lv?
[04:00] <Miplo> Hi, do I need to permit root login on an Ubuntu server using SSH? Wouldn't the actual admin user be enough? (using sudo)
[05:26] <rahuldroy> Hey Guys, I have a quick question. I am planning to make a closed-source website using MySQL as a database. Will I be legally allowed to do that?
[05:32] <sheptard> are you planning on redistributing mysql?
[05:32] <sheptard> or just using mysql to drive the website
[05:32] <rahuldroy> just use mysql to drive the website
[05:33] <sheptard> then why would they care
[05:33] <rahuldroy> I don't want to do anything illegal
[05:33] <sheptard> also, IANAL
[05:33] <rahuldroy> haha neither
[05:33] <rahuldroy> just tyring to make sense of open source licences
[05:34] <rahuldroy> BSD and MIT Seems to have no restriction on commercial use
[05:34] <sheptard> those licenses usually only matter if you plan to use the actual code in another product, or redistribute said product
[05:34] <rahuldroy> GPL seems to though
[05:35] <rahuldroy> lets say I get an GPL Software and customize the code to my needs
[05:35] <rahuldroy> Do I need to make the modifications freely available??
[05:36] <sheptard> only if you want to
[05:36] <sheptard> assuming you aren't selling the software
[05:37] <rahuldroy> thats what I though as well. Does this include saas software??
[05:39] <sheptard> don't think so
[05:39] <sheptard> again, IANAL
[05:41] <rahuldroy> I think it would be be best if I avoid GPL code on my project completely just to be safe but I will keep using MySQL though
[05:59] <EpicCyndaquil> I tried asking in #ubuntu but no one there answered, and you all are probably better with bash anyway: can anyone help me understand why this bash script doesn't work? https://3d3.ca/yLLXL.bash#VT23LM5SHgTzkCLU
[06:01] <vonsyd0w> EpicCyndaquil, what about the #bash channel?
[06:01] <EpicCyndaquil> ah, good idea :)
[06:03] <EpicCyndaquil> shellcheck.net was enough to help me figure it out, so thanks for bringing up #bash, vonsyd0w
[06:04] <vonsyd0w> no prob, my bash skills arent that great... yet
[06:11] <Alina-malina> this cronjob is it recommended to use in high load mode? for example i have multiple users they add posts and the crontab removes those after 5 hours, will that be problem if there are 5000+ users?
[06:19] <lordievader> Good morning.
[06:20] <prgCoder> hey guys - I have a weird problem and my head already hurts...
[06:21] <prgCoder> had a problems where a suse server all of a sudden started to poll the internet and started to use up a lot of bandwidth
[06:21] <prgCoder> local it admin said it was only out going.....
[06:22] <prgCoder> so I grapped another box, formatted the drive and install ubuntu 12 server and transaferred programs and data to it
[06:23] <prgCoder> a day later the same thing started to happen - the suse server is off and the new ubuntu server is up and the local IT admin says this server is plling the internet, over and over again
[06:24] <prgCoder> any ideas on what to look for and where this is coming from - I havetried wireshark and a few others but I have no clue what to look for
[06:24] <lordievader> prgCoder: Investigate what is using it ;) iftop -P might come in handy there.
[06:25] <prgCoder> I will give that a go when the local admin either turns it back on or can some how retard the server from using up most of the bandwidth so i can get in remotely
[06:26] <prgCoder> what should i look for?
[06:29] <lordievader> prgCoder: Something that uses a lot of bandwith. It will show the src ip+port and dst ip+port. From there you can make up which service/application is responsible.
[06:29] <prgCoder> loadievader: thanks
[06:31] <prgCoder> lordievader: thanks
[06:33] <lordievader> :)
[06:34] <lordievader> prgCoder: Good luck
[06:34] <prgCoder> thanks
[09:10] <dv81> whats the easiest tool to backup/restore an entire server's disk?
[09:11] <dv81> to an offsite location
[09:12] <jpds> I doubt you'll find something "easy".
[09:12] <dv81> "easiest"
[09:17] <jpds> dv81: Well, I can only give suggestions like bacula, rsync, obnam, ....
[09:17] <dv81> *googles*
[09:18] <lordievader> I find dirvish quite easy (I've come to understand that dirvish is an rsync wrapper).
[09:20] <alesales> exist also a tool named relax and recover :)
[09:20] <alesales> http://relax-and-recover.org/
[09:20] <alesales> is like aix mksysb or OS/400 SAVSYS :)
[09:21] <dv81> thanks guys
[09:22] <dv81> looking for something that will image a disk, grub and all rather than just certain parts of the fs
[09:22] <dv81> alesales: Rear, looks good thanks
[09:23] <alesales> I never tried...I just heard about that
[09:23] <alesales> I'm not working with Linux on x86 :)
[10:45] <ashd> setting up ldap and samba - ubuntu 14.04 following the ubuntu docs and walkthrough. “id user” shows uid,gid and groups.. but only main group… ldapid shows all the groups… is this the correct behavoir, or have i done something wrong somewhere.
[11:02] <Proshot> afternoon when i login into ubuntu server via ssh i get this welcome http://pastebin.com/46THn4se i was wondering where the config is that displays this message
[11:06] <jamespage> smoser, roaksoax, zul, hallyn: I've added some content to https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes for server this morning
[11:06] <jamespage> I've left some placeholders for MAAS and libvirt right now - if you want to draft something appreciated :-)
[11:06] <jamespage> gaughen, ^^
[11:23] <Proshot> anybody any idea where i get the config files which displays that message
[11:59] <gt8ost4l> anyone know how i can somehow change the mysql default name
[12:00] <bekks> gt8ost4l: default name?
[12:01] <gt8ost4l> yeah the name you give the mysql server the first installation
[12:01] <bekks> gt8ost4l: you dont set any names for mysql servers at all during installation.
[12:02] <gt8ost4l> so its just a password and thats all
[12:03] <bekks> gt8ost4l: you have to enter a password for the mysql root user during installation.
[12:03] <gt8ost4l> so root is just the default
[12:07] <bekks> gt8ost4l: thats the default mysql username of the mysql root user, yes.
[12:08] <gt8ost4l> so theres no way to change that username
[12:08] <bekks> gt8ost4l: Create a new user, done.
[12:09] <gt8ost4l> how do i do that
[12:09] <bekks> gt8ost4l: https://dev.mysql.com/doc/refman/5.1/en/create-user.html
[12:15] <rbasak> gt8ost4l: don't change the name of the root user. The maintainer scripts need root access for upgrades, etc, and so if you change the username you'll break upgrades.
[12:15] <rbasak> gt8ost4l: creating another user for what you want is fine.
[12:47] <zul> jamespage:  https://code.launchpad.net/~zulcss/heat/heat-mir/+merge/215494
[13:04] <Havenstance2> good morning, is there a work around for the gpg not found error in 13.10?
[13:05] <rbasak> What gpg not found error?
[13:06] <Havenstance2> I keep getting a gpg not found error when I try to pull in a key. not sure why it just says gpg package not found
[13:06] <Havenstance2> wget -q http://keys.zentyal.org/zentyal-3.4-archive.asc -O- | sudo apt-key add -
[13:06] <Havenstance2> I enter that then it returns, gpg not found
[13:07] <Havenstance2> the machine sitting right next to it takes the command and returns OK
[13:08] <Havenstance2> only difference is one is server 13.10 amd64 the other is server 13.10 i386
[13:08] <Havenstance2> and its the amd64 throwing the error
[13:09] <rbasak> How did you install the broken machine?
[13:09] <rbasak> The apt package depends on the gnupg package.
[13:09] <rbasak> You might be able to install gnupg to fix the problem, but it sounds like you have a bigger issue there.
[13:10] <rbasak> (or something wrong with your PATH or something)
[13:24] <Haven|Work> rbasak, I just did a fresh install so we will find out when it finishes. I had a network failure on Friday about the time I set this machine up so its possible that it didn't pull a package it needed
[13:24] <jamespage> zul, one typo but other than that +1
[13:26] <zul> jamespage:  saw...thanks
[13:26] <jamespage> hallyn, could you take a look at bug 1305280 - might be related to bug 1304167
[13:42] <zul> jamespage:  im just catching up precise-icehouse this morning
[13:43] <jamespage> zul, libvirt and xen?
[13:43] <zul> jamespage:  yep
[13:44] <jamespage> zul, I'm just sorting out the publishing issue - ceph built twice for armhf on the last version
[13:44] <jamespage> hashsum mismatches all round
[13:44] <zul> jamespage:  uh ok :)
[13:44] <smb> zul, Still the build in P problem? Most admit I have not yet checked how well the current 4.4 does as I tried to make arm64 more real
[13:45] <zul> smb:  still the P problem i have a work around for it though
[13:45] <smb> zul, ok sounds good
[13:50] <jamespage> zul, your patch for heat is still worng
[13:50] <zul> jamespage:  arrgh
[13:50] <zul> jamespage:  gimme a sec
[13:51] <jamespage> zul, you might want to change the name of the patch as well
[13:51] <jamespage> suder ->sudoers
[13:58] <smoser> roaksoax, where are we on maas ?
[13:59] <zul> jamespage:  https://bugs.launchpad.net/bugs/1307518
[13:59] <smoser> :-(
[14:00] <hallyn> hm.  stgraber: ^ wonder if bug 1304167 could be due to the new pivot_mount rule (i haven't dug yet)
[14:03] <jamespage> zul, eh
[14:04] <jamespage> zul, I'll try to reproduce
[14:04] <zul> jamespage:  ditto
[14:07] <stgraber> hallyn: that sounds more like a problem with the new apparmor statements
[14:07] <hallyn> oh god.  is this in cloud archives again?
[14:07] <hallyn> people really need to mentin that
[14:09] <jamespage> zul, I see that we are missing "schema-image.json"
[14:09] <jamespage> hmm
[14:11] <zul> jamespage:  arrgh so we are
[14:11] <jamespage> zul, and that the perms on /var/lib/glance/images and /var/lib/glance/image-cache are wrong
[14:11] <stgraber> hallyn: no, it's just the LXC upload done by the apparmor folks being wrong
[14:11] <jamespage> they are not writable by the glance user
[14:11] <stgraber> hallyn: LXC doesn't version depend on apparmor so it'll happily install with the wrong apparmor version
[14:11] <hallyn> stgraber: feh.  (i'm still waiting for an upgrade so i can get to testing)
[14:11] <stgraber> hallyn: I have a debdiff here, uploading in a minute
[14:11] <jamespage> zul, ah crap - that's a regression from fixing bug 1214947
[14:12] <hallyn> stgraber: thanks
[14:12] <jdstrand> stgraber: what upload? the one I did added the sed rules and was acked by stgraber
[14:12] <jdstrand> err, by you
[14:12] <jamespage> hmm
[14:13]  * jdstrand uploaded 1.0.2-0ubuntu2
[14:13] <stgraber> jdstrand: right, and we missed the fact that you need a versioned dependency on apparmor too.
[14:13] <stgraber> jdstrand: so that precise -> trusty doesn't break
[14:14] <jdstrand> wouldn't that have broken with the dbus rule too?
[14:14] <stgraber> it probably did in some cases but since people don't care much about non-LTS releases we never heard about it
[14:14] <stgraber> jdstrand: http://paste.ubuntu.com/7249946/
[14:15] <jamespage> zul, this highlights a gap in testing I think
[14:15] <zul> jamespage:  we seem to be missing property-protections-policies.conf.sample property-protections-roles.conf.sample as well
[14:15] <zul> jamespage:  agreed
[14:15] <jamespage> zul, hmm - those are just samples
[14:15] <jamespage> less worried about those
[14:16] <roaksoax> smoser: check the bug :)
[14:16] <jdstrand> stgraber: hrmm, apparmor itself has: Breaks: ..., lxc (<< 1.0.2-0ubuntu2~), ...
[14:17] <smoser> roaksoax, i thought we agreed to upload without that feature
[14:17] <smoser> with the 2 bug fixes
[14:17] <stgraber> jdstrand: right, so apparmor won't upgrade with an old LXC, but LXC will happily upgrade with an old apparmor
[14:17] <stgraber> jdstrand: bug 1304167
[14:17] <hallyn> hm, that's not gonna help ppl upstream
[14:17] <stgraber> jdstrand: that's someone getting a cloud instance of beta2, doing apt-get update && apt-get install lxc without doing a dist-upgrade
[14:17] <stgraber> jdstrand: they get the new LXC but not the new apparmor and things break
[14:17] <hallyn> ideally there'd be versioning built into the policy language :)
[14:18] <jdstrand> why doesn't beta2 have the new apparmor?
[14:19] <jdstrand> hallyn: we are getting there
[14:19] <stgraber> no idea, though the problem should also happen when doing 12.04 to 14.04. apt may very happily resolve the upgrade path as lxc in a first batch and apparmor in a second one. Which will cause the exact same failure.
[14:20] <stgraber> On smaller upgrades, you get a single batch so the apparmor breaks is enough to sort out the configure ordering but if they are each in their own batch, then things will break.
[14:21] <stgraber> jdstrand: anyway, I think my fix should be enough for that, I'd just suggest you make sure any other affected package gets something similar or I'd expect quite a few confusing upgrade bugs to show up soon enough...
[14:21] <jdstrand> I don't know how apt will sort these things, but slangasek said the Breaks was enough to dtrt for upgrades. I didn't do 12.04 to 14.04, but I did do upgrade test of lxc under that version and it all worked
[14:22] <jdstrand> if apt isn't breaking isn't honoring that, that seems like a bug in apt
[14:22] <jdstrand> (otherwise why even have the Breaks mechanism at all)
[14:23] <jdstrand> now, I get that a cloud image with the old apparmor will happily install a new lxc
[14:23] <stgraber> no, what apt is doing is perfectly correct. Your debian/control only prevents me from upgrading apparmor before lxc itself has been upgraded.
[14:23] <stgraber> but I can upgrade lxc itself independently of apparmor and nothing will force me to get the right parser
[14:24] <roaksoax> smoser: well... there is some discussion as to how to
[14:24] <roaksoax> smoser: well... there is some discussion as to how to publish that the setting is enabled
[14:25] <hallyn> jodh: ok i'll go ahead and push 'stop on [06]' for cgmanager;  if/when someone has a problem due to it, we can revisit.  ideally there would be a signal emitted right before final umounts (/var and /)
[14:25] <smoser> roaksoax, 2 bugs need fixing
[14:25] <smoser> independent (i thought) of feature being added
[14:25] <zul> jamespage:  https://code.launchpad.net/~zulcss/glance/lp1307518/+merge/215679
[14:25] <smoser> and i had hoped we'd upload with 2 bugs fixed
[14:25] <jodh> hallyn: right, although upstart isn't doing the unmounting.
[14:26] <roaksoax> smoser: i know
[14:26] <roaksoax> smoser: feel free if you want to go ahead and upload those
[14:26] <hallyn> jodh: what is?  doens't seem to be mountall...
[14:26] <roaksoax> smoser: cheery pick and patch the ubuntu package
[14:27] <jdstrand> stgraber: I understand that the cloud image having an old apparmor, apt-get update, apt-get install lxc doesn't work. I'm saying that a do-release-upgrade or apt-get dist-upgrade where apt breaks this into chunks that don't correctly honor the Breaks would be a bug
[14:27] <jodh> hallyn: /etc/init.d/umount*sh
[14:27] <jdstrand> when was the beta2 image generated?
[14:28] <roaksoax> smoser: i rather make I upload than make 2 though
[14:28] <stgraber> jdstrand: having apt do the upgrade in two chunks, first upgrading 200 packages including LXC, then upgrading another 300 packages including apparmor, would honor the Breaks and would make the upgrade fail.
[14:28] <roaksoax> smoser: that's why I'm saying, follow the bug as the latest developments are happen there and for the looks of it, it is just deciding how to notify the user about the setting being enabled by default
[14:29] <jdstrand> stgraber: who is breaking that up into chunks? the user or the upgrader?
[14:29] <stgraber> jdstrand: because it'd technically never have the new apparmor installed before the new lxc, so the Breaks would be satisfied
[14:30] <stgraber> jdstrand: apt does it when there are massive set of packages with complex dependencies (most pre-depends and the like). A lts-to-lts upgrade usually qualifies...
[14:30] <stgraber> jdstrand: you'll often see apt do multiple configure runs during a dist-upgrade, that's the easiest sign to see it do the chunking
[14:30] <hallyn> jodh: ok so we may just have to provide guidance that any upstart jobs using cgm in post-stop should do '|| true'
[14:30] <stgraber> so download of everything => unpack => configure => unpack second chunk => configure second chunk => ...
[14:31] <jdstrand> stgraber: ok, so I'm saying that if in its chunk calculation it allows what you are saying, its calculation is wrong. it should always put them in the same chunk
[14:32] <stgraber> jdstrand: why?
[14:32] <stgraber> it'll always ensure that apparmor isn't installed before the new lxc because that's what you said in your Breaks
[14:32] <jdstrand> because it would break on upgrades when the Breaks is explicitly there to prevent that
[14:32] <stgraber> but that's as much as it'll do for you
[14:32] <stgraber> as that's as much as you asked it to do
[14:33] <stgraber> it won't at all prevent lxc from going in a first chunk on its own and then apparmor in a second chunk
[14:33] <stgraber> because that'd perfectly respect your Breaks
[14:34] <jdstrand> "When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured."
[14:35] <stgraber> so? apt will respect that and things will still break
[14:35] <jdstrand> the broken package is lxc
[14:35] <stgraber> there's no break against installing the new lxc with the old apparmor
[14:35] <jdstrand> yet, it is being configured before apparmor
[14:35] <stgraber> sure because the old installed apparmor doesn't break on the new lxc
[14:35] <jdstrand> (in your scenario)
[14:36] <stgraber> it's just the new apparmor which breaks on the old lxc, but they can be installed 6 months appart for all apt cares
[14:36] <jdstrand> I get that-- but the calculation is wrong. the intent of a massive upgrade is for everything to be upgraded
[14:36] <hallyn> jdstrand: does 'we are getting there' for versoined policy language mean that we might get them during 14.10, or that we might get them during 16.04 timeframe?
[14:37] <jdstrand> if apt breaks it up into a bunch of little things that get you a different upgrade, that is wrong
[14:38] <stgraber> jdstrand: well, usually the point of doing things in chunk is to make the whole upgrade possible to resolve... and unless lxc has a version dependency on the new apparmor or a break against the old apparmor, apt won't necessarily put them both in the same batch
[14:38] <jdstrand> hallyn: you'd have to ask jjohansen. it is recognized as a real problem. I would guess 15.04 though. we are trying to get abstract sockets and lxc finished up first
[14:38] <hallyn> jdstrand: thanks
[14:38] <jdstrand> they are both quite close actually, but trying to be realistic
[14:39] <jdstrand> smoser: hey, who generated the beta2 cloud images?
[14:40] <smoser> jdstrand, they're built in automation
[14:40] <smoser> utlemming would have marked it as 'beta-2'
[14:40] <jdstrand> smoser: so, looking at bug #1304167, I'm quite surprised the old apparmor is still there
[14:41] <jdstrand> smoser: is there an easy way to see a package list with versions of that? is there a beta 3 already?
[14:42] <jdstrand> stgraber: I maintain that is a bug in apt if it operates differently with small and massive upgrades
[14:43] <jdstrand> I don't know that it actually does. I've not seen any upgrade bugs yet.
[14:44] <jdstrand> I guess I can try an upgrade, but if what you say is correct, then upgrades are non-deterministic and just cause my upgrade succeeds doesn't mean yours would
[14:45] <stgraber> jdstrand: well, I don't feel like arguing for hours, it's not an apt bug neither is it something new, I had to fix around 50 of those with the last lts to lts upgrade for 12.04.1. apt does respect your dependencies, however assuming that everything is processed in a single run is wrong and will lead to problems on massive upgrades.
[14:46] <stgraber> jdstrand: feel free to file a bug against apt though, I'm sure mvo will be happy to discuss it though I still expect the outcome to be that packages need to clearly define what they need, which in this case wasn't the case.
[14:46]  * jdstrand doesn't want to argue anymore either
[14:47] <jdstrand> I find it curious that 13.04 to 13.10 didn't have the same issue with dbus policy though
[14:52] <stgraber> jdstrand: well, you need to be pretty unlucky and the larger the set of package and the further they are appart the more likely it becomes. I'd expect 13.04 to 13.10 to be just a few hundred packages, that don't have a massive amount of transitions going on with complex pre-depends/breaks and such. So the upgrade may have happened in a single chunk (if it was resolvable that way) or maybe two, in which case we basically had a 50% chance of
[14:52] <hallyn> smb: for bug 1218959, did you look to see what patches fedora is currently using? :)
[14:53] <hallyn> anyway if that route isn't simple i'll do the darned udev rules.  i'm not sure if we should have later releases remove them then, but they should be safe
[14:53] <stgraber> lts to lts tends to be more like 5-6 runs, especially if we get things like massive debhelper, upstart, libc, ... changes with strict dependencies, it's therefore much more likely to show up in lts to lts than in any other upgrade case
[14:54] <stgraber> (lts to lts are also pretty much the only case where we may get to the point where apt just plain fails to resolve an update, no matter who many chunks it makes)
[14:54] <smb> hallyn, No, if its not mentioned in the bug report (and I have not yet read it carefully) its always a bit hard to find. I wanted to check on the two I think may be the ones. But have not yet got there either
[14:55] <hallyn> smb: ok lemme check one more time, ithought someone said the udev workaround did not work for them.  if nooe said that, we'll do the workaround
[14:56] <zul> jamespage:  ok updated
[14:59] <smb> hallyn, Ok, if they do work it maybe is the simpler route for older kernels. What we will do if that does not work we'll figure out when it does not work. That always works...
[15:01] <jamespage> zul, +1
[15:01] <zul> jamespage:  thanks
[15:01] <jamespage> zul: nope -thankyou!
[15:02] <hallyn> smb: ok yeah let's go with the udev rules.  ttyl
[15:04] <jamespage> coreycb, your grizzly->icehouse upgrade; can you check the keystone.conf post upgrade please
[15:16] <lordievader> Good afternoon.
[15:18] <coreycb> jamespage, sure
[15:18] <coreycb> jamespage, I had compared it vs the havana->icehouse and they were the same post upgrade
[15:19] <jamespage> coreycb, ack
[15:19]  * jamespage thinks again
[15:19] <jamespage> coreycb, the only thing I can think is that something did not happen in the db migrations
[15:19] <coreycb> jamespage, http://paste.ubuntu.com/7250219/
[15:20] <jamespage> coreycb, that looks aok
[15:20] <coreycb> jamespage, ok yeah I was thinking the same.  I can test vs rc2 branches if you think anything's changed.
[15:27] <jamespage> coreycb, I don't think so
[15:31] <jamespage> zul, we might want to considering doing that late-restart thing with debhelper dh_installinit in the packaging
[15:31] <jamespage> right now if you get a kernel update, nova-compute and stuff stays down for a long time
[15:54] <TazaChoncha> hello there
[15:56] <Zal> Hello all. I'm having trouble running an 'apt-get upgrade' on an Ubuntu 12.04LTS EC2 instance. The process stuck at grub-pc. After aborting, the process sticks at lvm2. Now "apt-get upgrade" tells me to run "sudo dpkg --configure -a", which itself sticks again at lvm2. Any tips on getting fixing this installation?
[15:57] <Zal> All I see in dpkg log is a message telling me lvm2 is half configured, when the process freezes
[16:05] <hallyn> we're missing a zul
[16:06] <hallyn> smb: i just uploaded a new libvirt-bin.  are you done with xen-releated libvirt uploads?
[16:06] <Zal> I manually killed the dpkg and frontend processes, blacklisted lvm2 and grub-pc, after which dpkg --configure -a ran successfully. I'm still concerned about the state of my instance though, any pointers are appreciated.
[16:06] <hallyn> Zal: might ask in #ubuntu-devel.  lvm upgrade error would scare me too...
[16:06] <smb> hallyn, If you did a ubuntu13 for T that is fine by me. The 12 was the one I had
[16:07] <hallyn> smb: yeah 13 (phew)
[16:07] <hallyn> Zal: take a look at /var/log/apt/term.log for details on teh lvm failure.
[16:07] <smb> hallyn, Ok, so we are good (hopefully) :)
[16:07] <Zal> hallyn, thanks, I'll look there again, didn't see anything previously
[16:08] <Zal> yeah, no errors there
[16:16] <hallyn> Zal: my *guess* is that there is a hung udev rule which is holding a lock
[16:17] <zul> jamespage:  just about to seed heat
[16:20] <axisys> how to encrypt a folder in my dir? I am sharing this precise 64bit server with multiple system admins
[16:21] <axisys> I like it auto decrypt when I login and only try to access the folder
[16:22] <axisys> and when I get out of the folder/dir, it will go back to encrypt.. is it possible?
[16:22] <axisys> I dont mind to do it manually ..
[16:23] <axisys> so decrypt; access the folder; exit the folder; encrypt
[16:23] <axisys> https://help.ubuntu.com/community/FolderEncryption looks interesting
[16:25] <zul> jamespage/coreycb: glance rc2  has been accepted
[16:33] <jamespage> zul, w00t - I think that means only swift and neutron are still in the queue right?
[16:47] <kosmo> Hi I got problem with my apache server. All was right but after week serevr just crashed and I cant start it.
[16:48] <jpds> Please explain what you mean by "crash".
[16:48] <kosmo> I cant accces it from my local network
[16:48] <bekks> Then investigate the logs.
[16:48] <jpds> Any debug?
[16:49] <jpds> "Crash" could mean anything from meteor strikes, cosmic rays, annexation by Russia, etc.
[16:49] <kosmo> and apache status command resutlts apache server is not running lolz
[16:49] <bekks> kosmo: Then check the logs.
[16:49] <sarnold> oh that crazy putin, here he goes again
[16:49] <jpds> sarnold: He's putin'g himself in your servers.
[16:49] <bekks> Now he crashes server. Does he even pay that "peer" who always terminates connections?
[16:50] <sarnold> jpds: lol
[16:50] <bekks> jpds: :D
[16:50] <sarnold> bekks: hahaha
[16:50] <jpds> kosmo: So you can *access* the server from SSH, but not on HTTP?
[16:50] <kosmo> weell the thing is error.log file is empty
[16:51] <kosmo> jpds yes smbd also works gr8
[16:51] <bekks> kosmo: Which ubuntu release is it?
[16:51] <kosmo> 12.04 LTS
[16:52] <patdk-wk> did you check dmesg?
[16:54] <kosmo> you mean the msg after service apache2 start?
[17:00] <RoyK> kosmo: just type 'dmesg'
[17:05] <jamespage> jdstrand, around? I just got asked to look at the seed changes for bug 1266066 but need some guidance from the security team
[17:06] <jamespage> jpds, technically mterry needs to ack unbound still as well
[17:08] <jpds> jamespage: All tests run as of https://launchpad.net/ubuntu/+source/unbound/1.4.22-1ubuntu4
[17:08] <jdstrand> jamespage: what do you need?
[17:09] <jamespage> jdstrand, just a bit confused as to what actions need to be taken - the bug report references removal of ipsec-tools - but I see racoon that still depends on that
[17:09] <jamespage> jdstrand, I was just going to push strongswan into the supported-misc-servers seed
[17:09] <jdstrand> racoon is superceded by strongswan, no?
[17:09] <jdstrand> jpds: ^
[17:11] <jdstrand> jamespage: I wonder if supported would be better (eg network-manager-strongswan)
[17:11] <sarnold> racoon is built from ipsec-tools, right?
[17:12] <kosmo> I got dmesg output but its big and I didnt find anythnig interesting
[17:12] <jdstrand> sarnold: yes
[17:12] <jamespage> sarnold, yes
[17:13] <jdstrand> so yes, please unseed that :)
[17:13] <jamespage> jdstrand, jpds: OK - so I'll replace racoon with strongswan in the supported-misc-servers seed
[17:13] <jdstrand> jamespage: in case I wasn't clear, I was saying 'supported' instead of 'supported-misc-servers'
[17:14] <jdstrand> jamespage: I'm ok with supported-misc-servers, but supported seems ok too
[17:14] <jdstrand> jamespage: you're call
[17:14] <jdstrand> meh
[17:14] <jdstrand> your*
[17:14] <jamespage> jdstrand, just going on where racoon is currently :-)
[17:14] <jdstrand> that's fine
[17:14] <jdstrand> jamespage: you are taking the list from comment 13?
[17:15] <jdstrand> jamespage: strongswan-pt-tls-client and network-manager-strongswan were also mentioned as desired
[17:16] <jamespage> jdstrand, looking now - but if I just seed strongswan it will pull source+binaries into main right?
[17:17] <jdstrand> jamespage: you want to seed the binaries you want. there are a lot, jpds enumerated those we want
[17:17] <jamespage> jdstrand, ack
[17:18] <jdstrand> hrmm
[17:18] <jdstrand> openvswitch-ipsec depends on racoon
[17:22] <jamespage> jdstrand, indeed
[17:23] <jamespage> jdstrand, I'm assuming the outcome of having ipsec-tools and strongswan in main is not desirable?
[17:23] <jdstrand> it is undesirable
[17:23] <jdstrand> it looks like debian/ovs-monitor-ipsec is the only thing that uses racoon
[17:24] <jdstrand> is there an ovs-monitor-strongswan we can drop in its place?
[17:24] <jdstrand> it looks like Nicira wrote debian/ovs-monitor-ipsec
[17:24] <jdstrand> well, it is the only thing other than the testsuite that uses ipsec-tools
[17:25] <jdstrand> (and the testsuite uses it to test ovs-monitor-ipsec)
[17:25] <jamespage> jdstrand, indeed
[17:25]  * jamespage continues to dig
[17:26] <jdstrand> feel free to commit the change to promote strongswan. the demotion of ipsec-tools can happen separately (but before release)
[17:27] <jpds> jdstrand: openvswitch-ipsec is in universe now.
[17:27] <jamespage> jdstrand, not yet - it looks like upstream ovs have been discussing switch to strongswan but there is no support yet
[17:27] <jamespage> jdstrand, is it?
[17:27] <jamespage> jpds, erm - is it
[17:27] <jpds> jamespage: Yep, cjwatson said he'd move it today.
[17:27] <jdstrand> ah
[17:27] <jdstrand> I was just going to suggest doing that
[17:28] <jamespage> I have to admit to being uncomfortable making this change so late in  cycle
[17:28] <jdstrand> which change?
[17:28] <jamespage> this puts any users of the ipsec feature of openvswitch in a different support position after moving to 14.40
[17:28] <jamespage> 14.04 even
[17:28] <jdstrand> oh, just moving it to universe?
[17:29] <jpds> Well, debian/ovs-monitor-ipsec looks like some nasty hack.
[17:29] <jdstrand> I also mentioned in January that we would want to demote ipsec-tools
[17:30] <jdstrand> ipsec-tools is stagnant
[17:31] <jdstrand> jamespage: note, it does not change the support position over 12.04. openvswitch itself was in universe
[17:31] <jamespage> jdstrand, I know
[17:32] <jpds> jamespage: Ah, yes. The list in my email + strongswan-pt-tls-client (we can ignore n-m for now).
[17:33] <jamespage> jdstrand, yes - but ipsec-tools and racoon where in main
[17:33] <jamespage> jdstrand, I guess I'm uncomfortable as I was not aware of this plan until 10 days ago
[17:34] <jdstrand> jamespage: I'm confused about the support position you are referring to. are you referring to openvswitch or ipsec-tools to strongswan migration?
[17:34] <zzxc> Hey guys. I have a question. I had a script I want to run on startup for a machine that does a mount -bind. How would I get it to run on start up?
[17:34] <jpds> jamespage: Anyone using them, is going to probably see their quality of life improve with something a little more... modern. ;-)
[17:35]  * zzxc wonders if his conf has gone screwie or if jdstrand, jpds, and jamespage are talking using /me comments
[17:35] <jdstrand> jamespage: moving to strongswan is no different than moving to another supported technology in any other software in the stack. we release note that ipsec-tools no longer receives support and users should migrate to strongswan, which works better (more featureful, active upstream, etc)
[17:36] <jdstrand> jamespage: people who need ipsec-tools can use it on 12.04 for 3 more years. upgrade timelines are at their discretion
[17:39] <jdstrand> jamespage: honestly, I bet people are simply installing strongswan from universe anyway-- ipsec-tools hasn't gotten a new release in 3 years
[17:39] <jamespage> jdstrand, just uncomforable doing this right now - I've not had three months to thing about it
[17:40] <jdstrand> jpds: perhaps you can step in here-- you are the one driving this
[17:40] <sarnold> zzxc: must be your configuration, they look like normal /msg #ubuntu-server to me
[17:41] <sarnold> zzxc: /etc/rc.local may be the easiest way to get your script to run; you could create an upstart job just for your script if you wanted to be fancy: http://upstart.ubuntu.com/cookbook/
[17:41] <bekks> zzxc: fstab ;)
[17:42] <jpds> jamespage: Well, I've been using the tool since August last year pretty much.
[17:42] <zzxc> bekks: Hahaha thanks for that bekks.
[17:44] <sarnold> bekks: does that work out alright for bind mounts? cool :)
[17:44] <bekks> sarnold: Sure.
[17:44] <zzxc> sarnold: Actually I never understood upstart jobs. Isn't it just basically just like sticking it in the init.d folder and running update-rc.d?
[17:44] <jpds> jamespage: All the IPsec stuff's in the kernel; there are essentially keyring daemons with feature sets.
[17:45] <zzxc> bekks: Yeah still kind of nervious about that. Espically if something happens to the prod server.
[17:45] <bekks> zzxc: Then test the fstab entries before rebooting. Whats the problem with that?
[17:46] <sarnold> zzxc: I found upstart's 'native' interface easier to use than the sysv compatibility things, or the old sysv-init
[17:47] <jdstrand> jpds: perhaps describing more why it is desirable over ipsec-tools (perhaps with why you are pursuing it to beging with)
[17:47] <zzxc> bekks: Honestly. If I leave the company I'm working for I wouldn't trust the other people to remeber to do a check on the prod machine before restarting it when they need to update it.
[17:48] <zzxc> sarnold: Hmmm alright. Isn't upstart going away in the next couple of version though?
[17:48] <jpds> jdstrand: That's all in the bug.
[17:48] <jamespage> jdstrand, jpds: tbh I don't think this is up to me to decide - this counts as a feature for me - I've pushed it to the release team
[17:49] <sarnold> zzxc: yeah, eventually. fwiw I prefer bekks's advice after hearing it :) hehe
[17:49] <jdstrand> jamespage: from my perspective, the fact that strongswan has an active community upstream, within Debian and Ubuntu, has a modern feature set and is well-written are all compelling. Holding on to something that has gotten upstream attention in 3 years for a security sensitive piece of software is not desirable
[17:50] <jdstrand> hasn't*
[17:50] <zzxc> *sigh* alright. I've gone through enough holding my breath during the heartbleed fixes. Guess I'm going to have another everytime we update it.
[17:50] <jpds> jamespage: Yeah, they pushed me towards you.
[17:53] <sarnold> zzxc?
[17:54] <bekks> zzxc: sudo apt-get update; sudo apt-get dist-upgrade; <- that how to install the heartbleed fixes.
[17:55] <zzxc> Whats up sarnold?
[17:55] <zzxc> bekks: Yeah I know. We took a slightly different route and used unattended_upgrade
[17:56] <zzxc> Boss was terrified of compadibiltiy breaking.
[17:57] <sarnold> zzxc: I'm just curious what you mean by "guess i'm going to have to hold my breath every time we update it" ..
[17:57] <bekks> zzxc: He should have read the changelog then.
[17:57] <zzxc> bekks: ? Which change log?
[17:59] <bekks> zzxc: the changelogs for the bugfixes? http://www.ubuntu.com/usn/usn-2165-1/
[18:02] <zzxc> bekks, Yeah of course right. No I read through that. It was more along the lines of only doing a security update rather than updating jaxb, or 3cpo, or hibernate.
[18:02] <bekks> zzxc: Those applications do not need to be updated to fix the heartbleed issue.
[18:04] <zzxc> Right. no I get that we could have just recompiled openssl as well with the noheartbeat flag and it would have worked as well. But I wanted to do all of the security updates. He didn't want to update anything that wasn't a secuirty fix so using unattended_upgrade was the medium for only updating the security patches, and not other updates that would have been covered in a dis-upgrade.
[18:05] <bekks> you can easily cover security-only updated in dist-upgrade, too.
[18:06] <sarnold> zzxc: thanks for not compiling your own, that's a path of pain and suffering. we do updates so our users don't have to do them themselves :) hehe
[18:07] <sarnold> zzxc: see https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories  for a quick description of what bekks is describing
[18:07] <zzxc> bekks: How so?
[18:07] <zzxc> sarnold: Thanks
[18:08] <bekks> zzxc: Disable all repos but the security ones, run sudo apt-get update; sudo apt-dist-upgrade; and re-enable all formerly disabled repos again.
[18:08] <bekks> 1zThat takes about 5 minutes overall.
[18:09] <zzxc> Mmmmm yeah, I thought of that as well. You can also change the ranking of secuirty updates to 500 and downgrade the none security updates to 50.
[18:10] <bekks> Which doesnt help at that point.
[18:10] <zzxc> Basically all i had to do was do sudo apt-get update && unattended-upgrade -d. which did the same thing.
[18:10] <bekks> because regardingless of the ranking, non-security updated would have been pulled in.
[18:13] <zzxc> bekks: No currently installed applications have a ranking of 100 (I beleive) so unless you need pull in a new version for a dependency its less desirable than an application that has already been installed.
[18:13] <bekks> zzxc: That doesnt affect what I just said. :)
[18:13] <zzxc> So why would the non-security be updated?
[18:14] <bekks> Because of the enabled repos.
[18:14] <bekks> Not because of their ranking whatsoever.
[18:14] <sarnold> if all your updates are through unattended-upgrades it probably does the right thing; but when you go to run apt-get -u dist-upgrade yourself, it'll pull in all -updates and -security packages together..
[18:14] <bekks> dist-upgrade literally means "get them all". No matter which ranking the updates have.
[18:15] <zzxc> http://askubuntu.com/questions/194/how-can-i-install-just-security-updates-from-the-command-line the second entry was was I was talking about.
[18:16] <zzxc> was what*
[18:16] <zzxc> sarnold: Actually that was what I was wondering about. If I do a dis-upgrade -security does it only pull in security updates?
[18:17] <bekks> There is no such parameter.
[18:19] <zzxc> bekks, Ok I didn't think there was. Is there a way to tell dis-upgrade to only install the secuirty updates?
[18:19] <bekks> zzxc: Disable all other repos.
[18:21] <zzxc> bekks, Ok right, so short of disabling the other repos there is no way to do that?
[18:22] <zzxc> sarnold: And right. But the lead developer didn't want to do a full update because he was convinced it would break something and at midnight I didn't really feel like arguing with him about it.
[18:23] <sarnold> zzxc: yeah, that part makes a lot of sense :) hehe
[18:23] <dv81> zzxc: it will break imo
[18:25] <zzxc> Doing an unattended_upgrade to update only the secuirty patches? It wouldn't shock me honestly, but it is a feature that sets it self up like a cron job to do updates on prod machines ever so often. And honestly the system is pretty stable still and I just need it to work for about 2 or 3 more months then I can upgrade the system to the new LTS.
[18:27] <zul> hallyn:  i already uploaded a fix for the libvirt cloud-archive bug
[18:27] <zzxc> Or more actually build a new system and move over to that. I'm also hoping I can move the data volumes over to ext4 or s3.
[18:28] <bekks> zzxc: You are on ext3 currently?
[18:30] <zzxc> For the data volumes yes. A lot of the infrastructure has been here well before I got here.
[18:30] <hallyn> zul: which one is that?
[18:30] <bekks> zzxc: Then mount the as ext4, done.
[18:31] <zzxc> bekks, wait really? I know ext3 and ext4 are pretty simalar but won't I still not have the journaling functionality of a ext4 drive?
[18:32] <bekks> Guest88173: [~chatzilla@c-69-244-43-156.hsd1.az.comcast.net]  that should be enough to know you're not anonymous ;)
[18:32] <bekks> zzxc: ext3 is a journalling fs, too.
[18:32] <bekks> zzxc: And you can upgrade to ext4 by just mounting ext3 as ext4.
[18:33] <lordievader> bekks: Really, no need for any conversion tools?
[18:33] <bekks> lordievader: No need for tools whatsoever.
[18:33] <zul> hallyn:  the libvirt apparmor change on precise
[18:33] <lordievader> Nice :)
[18:33] <hallyn> zul: ok, so you took the one i uploaded to trusty?
[18:34] <zul> hallyn:  when did that happen?
[18:34] <hallyn> earlier today
[18:34] <zul> hallyn:  no but i will
[18:34] <hallyn> cool, thx
[18:48] <zzxc> bekks: Cool good to know. Thank you.
[19:08] <jamespage> jpds, still around? whats the closest thing to ipsec-utils in strongwan?
[19:09] <jpds> jamespage: That packages doesn't exist?
[19:10] <jamespage> jpds, I have to replace ipsec-utils on the iso with something equivalent
[19:10] <jpds> $ apt-cache show ipsec-utils
[19:10] <jpds> N: Unable to locate package ipsec-utils
[19:10] <patdk-wk> ipsec-tools you mean?
[19:11] <jamespage> I do
[19:11] <jamespage> jpds, ipsec-tools
[19:11] <jpds> jamespage: All of that should be in strongswan-starter.
[19:13] <jamespage> jpds, ok
[19:13] <jamespage> jpds, just testing the seed changes now
[19:16] <jamespage> jdstrand, I'll make the seed change in the ISO to demote ipsec-tools in favour of strongswan-starter
[19:17] <jdstrand> jamespage: ok. I looked at openvswitch more and it shouldn't need a packaging change
[19:18] <jdstrand> I thought it did, but it doesn't install raccoon or ipsec-tools during the build
[19:18] <jdstrand> I'm kinda curious what the testsuite is actually testing now, but not enough to look at it :P
[19:20] <jamespage> jpds, which was the additional package you wanted in the seed?
[19:21] <jpds> jamespage: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1266066/comments/13
[19:21] <jpds> jamespage: +strongswan-pt-tls-client.
[19:22] <jdstrand> jamespage: ok, so I should not touch serv-ship. got it
[19:22] <jamespage> jpds, ok
[19:22] <jdstrand> server-ship
[19:22] <jamespage> jpds, how does this look> http://paste.ubuntu.com/7251357/
[19:24] <jpds> jamespage: +1.
[19:25] <jamespage> jpds, is strongswan-nm - that appear to pull network-manager into the misc-server seed?
[19:25] <jpds> jamespage: Oh, drop that one.
[19:25] <jpds> That would be for network-manager-strongswan, which I'm not too fussed about.
[19:25] <jamespage> jpds, ack
[19:31] <jamespage> jdstrand, jpds: seed changes pushed
[19:32] <jdstrand> thanks!
[19:32] <jamespage> jdstrand, np
[19:32] <jpds> jamespage: Thank you!
[19:32] <jdstrand> ipsec-tools demoted (openvswitch-ipsec already was)
[19:32] <jamespage> jpds, thanks for your work on this this cycle
[19:32] <jdstrand> crafting a release note now
[19:38] <jpds> jamespage: Always a pleasure. :)
[19:41] <jamespage> jdstrand, thanks for doing the release note btw
[19:42] <jdstrand> np
[19:44] <jdstrand> jamespage: did you commit all your changes? I only see the strongswan-starter change
[19:44] <jamespage> jdstrand, in server-ship yes
[19:45] <jamespage> jdstrand, the others are in supported-misc-servers in the platform.trusty seeds
[19:45] <jdstrand> ah, platform.trusty
[19:46] <jdstrand> right. thanks!
[19:46] <jdstrand> jamespage: I'm going to get ahead of component-mismatches and promote these now
[19:58] <smoser> zul, is there a way to easily tell which cloud-archive packages have delta ?
[19:58] <bekks> have delta compared to what?
[19:59] <smoser> compared to their source release.
[19:59] <smoser> ie, the majority are straight (changelog change only) backports of trusty packages for icehouse
[19:59] <smoser> but some require changes.
[20:01] <smoser> my best guess is package presense at https://code.launchpad.net/~ubuntu-cloud-archive/
[20:04] <zul> smoser: not really...its just libvirt/xen/mongodb/subunit that have deltas
[20:06] <smoser> i'm fairly sure thats not true.
[20:06] <smoser> i know mongodb oes
[23:56] <Runemoro> Hi, could anyone help me fix some problems I'm having with bind9?
[23:58] <Runemoro> Whenever I do "dig @rebornlegend.no-ip.org rebornlegend.tk", I get the correct response, but if I remove the "@rebornlegend.no-ip.org" part, it doesn't work anymore. I've checked with whois that my nameserver is set to rebornlegend.no-ip.org
[23:59] <sarnold> hah, why is the "dot tk" registry in the netherlands? o_O