[01:20] <maddawg2> hey all...  so been using ubuntu server at work for a nmber of our facilities (open vpn tunnels, squid proxy, dhcp, firewall, etc)...  normally we've been using Firewall builder so that some of our windows system administrators can configure the firewall with a GUI...however it looks like firewall builder has stopped developing
[01:20] <maddawg2> any alternatives people can recommend?
[01:46] <sarnold> maddawg2: ufw is simple enough, even though it's commandline; I think someone put together a gui around it but I can't vouch for the quality of it..
[01:47] <lkthomas> guys, anyone have experience to run multicast routing ?
[01:48] <maddawg2> yea sarnold we're looking for a GUI and we dont want a gui on the computer
[01:48] <maddawg2> with firewall builder we could install it to Windows and make our rules there and it would generate a conig file that would then get uploaded to the ubuntu server
[01:49] <sarnold> maddawg2: you could try X forwarding, ssh -X hostname xterm   to get a quick idea of what I mean..
[01:52] <maddawg2> yea but then they wouldnt be on windows
[01:52] <maddawg2> these are windows administrators
[01:52] <maddawg2> needin g to administer a linux firewall
[02:08] <sarnold> ahh
[07:05] <lordievader> Good morning.
[10:52] <Gwys> Hi all ! I'm trying to install openstack through MAAS following this documentation http://ubuntu-cloud-installer.readthedocs.org/en/latest/multi-installer.guide.html
[10:52] <Gwys> But I've an issue with br0 during openstall-install
[10:52] <Gwys> Someone can help me ?
[10:53] <Gwys> I see some error on br0 in the log files. And it look like the script comment my interface in /etc/network/interface
[10:54] <Gwys> There are error logs : http://pastebin.com/22yELB7r
[11:05] <strikov> rbasak: regarding this bug: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1438788
[11:05] <strikov> rbasak: it's upgrade related thing; previous version of the package generated this incorrect symlink and we have to manually remove it
[11:06] <strikov> rbasak: it was not a good idea to remove it somewhere inside installation handlers of the new version because this file/link may be legal
[11:07] <strikov> rbasak: i.e. user created it manually not buggy package
[11:07] <strikov> rbasak: that's definitely a bug of debhelper-systemd and i need to file it
[11:08] <rbasak> strikov: OK. So workaround available, and only affects users who had mysql-server-5.6 5.6.23-1~exp1~ubuntu4 installed?
[11:10] <strikov> rbasak: i'm reproducing this now on a cloud instance to provide with a workaround which 100% works
[11:10] <strikov> rbasak: yes, only when you upgrade from ubuntu4
[11:10] <rbasak> strikov: I think it's OK to leave it then - we can just explain it in the bug for users to apply the workaround.
[11:11] <strikov> rbasak: ok
[11:11] <rbasak> strikov: and then explain that it's too difficult to fix without breaking other users, and then mark it Won't Fix.
[12:31] <Arrick> hey all, if I am working with a .conf file, is ; a commented line?
[12:36] <davegarath> Arrick: It depend for what application is .conf file. Usually a comment is #
[12:37] <Arrick> its the smb.conf
[12:37] <Arrick> there are dozens of lines which start with ; that follow the # liens
[12:37] <Arrick> lines
[12:38] <davegarath> smb.conf use both  # and ; as a comment
[12:39] <davegarath> # is used as a comment and ; is used to comment a statement
[12:40] <Arrick> I'm having an issue with winbindd and smb, cant seem to figure out how to get it to lookup usernames, or anything.
[12:40] <Arrick> wbinfo -u says error looking up domain users
[13:21] <strikov> rbasak: just fyi, debian guys provide cloud images since jan2015: http://cdimage.debian.org/cdimage/openstack/testing/
[13:21] <strikov> rbasak: it might be useful for testing while filing debian bugs
[13:50] <Adri2000> I've just discovered uvt; I understand it as being a way to create VMs from cloud images. I have a side question: is there a recommended way to build cloud images? is the toolchain used for building those at cloud-images.ubuntu.com available somewhere?
[14:23] <jcastro> Adri2000, check this out: https://launchpad.net/~ubuntu-on-ec2
[15:00] <jamespage> coreycb, huh - quick poke at the ci builds - missing deps for the source packages was not helping as a result of move to systemd
[15:00] <rbasak> strikov: that's useful. Thank you!
[15:02] <coreycb> jamespage, what was missing?
[15:02] <rbasak> Adri2000: I think our toolchain for building cloud images is available. utlemming might be able to help with that. But it is not recommended. We think that you should use "official" cloud images instead, and use cloud-init on first boot to customize them as needed.
[15:02] <rbasak> Adri2000: or, if you must, modify the official cloud image for local use but starting from the official one, rather than going from scratch.
[15:02] <rbasak> Adri2000: of course, you can do what you like. We just try to best support that workflow.
[15:04] <MDTech-us_MAN> hello
[15:04] <jamespage> coreycb, dh-systemd and openstack-pkg-tools
[15:04] <jamespage> without those you can't cut the source packages
[15:04] <MDTech-us_MAN> what is a good program that will backup specific programs and file every once in a while? maybe even somethign with a good (web?) interface?
[15:06] <coreycb> jamespage, so the ci builds don't use the deps from debian/control?  because those should be in the debian/control files.
[15:08] <jamespage> coreycb, not for cutting the source packages
[15:09] <coreycb> jamespage, ok
[15:31] <Adri2000> rbasak: typical use case is I want ubuntu cloud images that include specific configuration to my local network (think, apt mirrors and such). what would be the proper way to create those, if not using the toolchain used to build the "official" images"?
[15:33] <Odd_Bloke> Adri2000: You have two options, really: (a) take the cloud images and modify them, or (b) use cloud-init to do what you need to do on first boot.
[15:34] <Odd_Bloke> Adri2000: The toolchain used to build the official images starts from scratch, but you don't have to start from scratch because we build the official cloud images. :)
[15:34] <Adri2000> Odd_Bloke: then what tool do you recommend to do (a) ?
[15:35] <Odd_Bloke> Adri2000: Have a look at http://ubuntu-smoser.blogspot.co.uk/2014/08/mount-image-callback-easily-modify.html
[15:37] <Adri2000> thanks
[15:46] <rbasak> Adri2000: to set apt mirrors and things, I suggest you use cloud-init. Then you don't have to keep re-rolling your customised cloud images.
[15:46] <rbasak> Adri2000: you can inject configuration information into the cloud images, which cloud-init then uses. http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt documents the configuration you can do.
[15:47] <rbasak> Modifying a cloud image is easy. Maintaining that setup is not.
[15:54] <Adri2000> rbasak: I know, but I'd like to offer users (internal IaaS/OpenStack users) images that work out of the box, and therefore do not require them to add userdata if they don't need anything specific
[15:54] <Adri2000> rbasak: of course I'll have to maintain my custom images, that's why I need to automate the process
[15:55] <Adri2000> mount-image-callback may be part of the solution
[15:57] <rbasak> Adri2000: look into vendordata. It lets you provide defaults that userdata can override, but if no userdata is used your users will get your apt mirror by default.
[15:57] <Odd_Bloke> Adri2000: If you're on OpenStack, you could use vendor... that.
[15:58] <rbasak> (unless users actually touch that setting in userdata)
[17:07] <strikov> rbasak: could you change status of this bug to won't fix please: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1438788
[17:07] <strikov> rbasak: i don't have permissions to do this
[17:09] <strikov> rbasak: i investigated this and (a) upgrade from ubuntu4 to ubuntu5 runs smoothly (issue reported was observe with the previous version of the package I assume) (b) i can observe the issue when removing the package but it's a result of previously created symlink which requires manual actions
[17:09] <rbasak> strikov: yes, but please could you first explain the bug why the bug should be Won't Fix?
[17:09] <rbasak> explain in the bug
[17:09] <teward> rbasak: i was about to ask that too xD
[17:09]  * teward was about to hit "Won't Fix" too xD
[17:14] <teward> rbasak: stupid question for you with regard to freezes, but a bug of mine got poked saying "Shouldn't the fix for this be SRU'd?" on nginx, and it's not in Vivid yet - it'd set the thing to build as position independent - would that even qualify for SRU or even a bug that'd get past featurefreeze?
[17:14] <rbasak> teward: what's the bug?
[17:15] <rbasak> teward: if it's a security bug, then the normal SRU process doesn't apply. An update would go via security sponsorship itself, and the security team would judge security impact vs. regression risk themselves.
[17:16] <teward> rbasak: i'll poke mdeslaur in either case, but the other problem is the fix isn't even in Debian yet - just committed
[17:16]  * teward digs for the bug
[17:17] <teward> wow i still had it open from 2 hours ago xD
[17:17] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1315426
[17:17] <teward> rbasak: it reads as a feature request, but i'm not sure if it needs to be a security bug that mdeslaur / security team would review
[17:17] <mdeslaur> teward: what do you need me for?
[17:17] <teward> mdeslaur: oop forgot you're here xD
[17:17] <mdeslaur> nah, that's an SRU, not a security vulnerability
[17:17] <teward> that's what i thought
[17:18] <rbasak> If it's not a security vulnerability, then what's the user impact that necessitates an SRU?
[17:18] <teward> rbasak: AFAICT there isn't one
[17:18] <teward> not unless package policy starts pushing for PIE as a requirement for inclusion anywhere
[17:18] <rbasak> Then an SRU isn't appropriate IMHO.
[17:18] <teward> mhm
[17:19] <rbasak> Unless mdeslaur says it's worthwhile as an SRU for security reasons even if it shouldn't go through a security upload.
[17:20] <teward> mdeslaur: the question goes back to you, whether it'd be worthwhile as an SRU for security reasons or not.  (Note the changes are committed in Debian but not implemented anywhere, not even in Vivid)
[17:20] <teward> so it'd need a nitpick pull from Debian git, added to Vivid, then SRU'd.
[17:21] <mdeslaur> I don't think it's worthwhile as an SRU, no
[17:21] <teward> rbasak: and since it'd be needed in Vivid, the question then becomes whether FeatureFreeze prevents this, or whether i have to go poking the release team for an FFe
[17:21] <mdeslaur> it's just hardening, it has no direct benefit
[17:21] <strikov> rbasak: teward: is it okay to close the bug with 'won't fix' if the root cause of the bug is in different project? in our case this issue arises from the fact that debhelper can't handle aliases in systemd's unit config.
[17:22] <rbasak> strikov: no, I don't think so. If the bug cannot be fixed in this package, then the bug should be reassigned to the correct package, or a new task added and the mysql-5.6 task marked Invalid.
[17:23] <strikov> rbasak: okay, so let me look into debhelper bug tomorrow; will see then what to do
[17:23] <mdeslaur> turning on PIE in stable releases will have a detrimental performance impact on 32-bit platforms, which may piss off people who are specifically using nginx for it's performance
[17:23] <rbasak> strikov: if the bug *can* be fixed in this package but it isn't worth doing it because it affects development release users only in a way that they can workaround, and it isn't worth going to the trouble to fix it for that set of users, then I think it's OK to explain this and then mark Won't Fix against mysql-5.6.
[17:23] <mdeslaur> s/it's/its/
[17:24] <teward> mdeslaur: rbasak: OK that's what i thought (not SRU worthy, no significant benefit).  I'm considering leaving Vivid's status alone though, in the interim, once Vivid is released marking it as "Won't Fix" and setting a "Triaged" state for the next release later (because there may be a merge in that cycle from Debian, which would likely include the PIE changes)
[17:24] <rbasak> teward: I think "PIE isn't turned on though expected for security-sensitive packages" is a reasonable bug to fix under feature freeze without needing an exception. I would be OK to sponsor that. But see mdeslaur's comment on whether we should do that or not.
[17:25] <teward> rbasak: right, given that, i'm considering leaving Vivid's status alone
[17:25] <teward> but i was going to "Won't Fix" for the earlier releases
[17:25] <rbasak> Maybe it's fine to do, and those who are performance sensitive can switch to amd64 when upgrading to Vivid for production use.
[17:25] <mdeslaur> and we'll likely be turning on PIE by default on amd64 for V+1
[17:26] <teward> i'm thinking at this point V+1 might be the target.  at some point after Vivid's release it's likely Debian will get an update in its package that turns on PIE by default
[17:26] <teward> since it's in the git, but not yet released due to Debian freeze
[17:27] <teward> (at least from what the nginx maintainers in Debain told me)
[17:31] <teward> mdeslaur: rbasak: i'm going to use those statements as "blocking points" for a vivid fix for now, and will wait to see what Debian does on this - just because it's Fix Committed there means nothing - it's not even 'tested' there afaict
[17:31] <teward> (net)
[17:31] <teward> s/net/yet/
[17:38] <teward> rbasak: mdeslaur: i'm comfortable leaving the change out of Vivid and waiting to V+1 to get the fix in with the likely merge i'll do during that cycle.  Around that same time I'll make a blog post on my blog (which'll end up in Planet.u.c's list) indicating that for V+1 we recommend that performance-sensitive use cases should be switching to amd64 architectures instead of staying on 32-bit architectures, for the performance hit reason we just
[17:38] <teward> discussed
[17:38] <teward> wow i hate irc truncation
[17:38] <teward> (that PIE bug's been there for a while now)
[17:39] <teward> (I posted as such on the bug just now)
[17:40] <teward> thank you both for the discussion on it, sometimes it helps to have a second viewpoint / opinion :)
[17:45] <strikov> rbasak: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1438788/comments/5
[17:45] <strikov> rbasak: how about that?
[18:03] <rbasak> strikov: looks good. Done.
[18:16] <strikov> rbasak: thanks!
[18:21] <teward> rbasak: mdeslaur: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1315426/comments/5
[18:22] <teward> rbasak: mdeslaur: looks like htere's pushback for no Vivid inclusion - opinions on putting it in Vivid other than us having to say "Those who have performance-sensitive setups should move to amd64 for the upgrade to Vivid", assuming the release team approves an upload to enable PIE?
[18:22] <mdeslaur> teward: if you want comments from disgruntled people, I can fill your inbox if you'd like
[18:22] <teward> mdeslaur: sure, feel free, i have 500 today
[18:22] <teward> mdeslaur: on top of 6000 aprils fools jokes
[18:23] <teward> and 10000 spam messages in my PMs here
[18:23] <mdeslaur> teward: just upload it to vivid
[18:23] <teward> i'll go nitpicking then
[18:29] <teward> mdeslaur: uploaded, it's going to need approval
[18:42] <teward> and there's the accept.
[18:48] <teward> ooo apparently the debian changes FTBFS
[20:17] <adam_g> zul, ping
[20:18] <zul> adam_g: yo
[20:19] <adam_g> zul, can you go through and remove all your -2's from https://review.openstack.org/#/q/reviewer:chuck.short%2540canonical.com+status:open,n,z ?
[20:20] <zul> adam_g:  sure gimme a sec
[20:22] <zul> adam_g:  done
[20:30] <adam_g> zul, thanks
[22:25] <keithzg> Huh, one of my servers is offset from correct time by a tad over -161 seconds, I wonder what would cause that?