[00:24] <fluvvell> tomreyn,  thanks for all the help, its recovering now, looks like completing within an hour or so.  Time to take a lunch break methinks.
[00:30] <tomreyn> welcome, enoy lunch
[01:40] <drab> anybody using ldirectord or some other load balancer that can redirect queries based on src ip?
[01:41] <drab> load balancing seems the correct answer to my question from the other day re: running CF on a different box than the GW
[01:41] <drab> at this stage I'd like to run 2 CF boxes especially for upgrades
[01:42] <drab> so that I can upgrade one, and redirect some traffic to it, make sure stuff works, and then upgrade the other
[01:42] <drab> however I can't see a lb that will allow me to choose which traffic to route to a real server based on src ip
[01:42] <drab> they all seem to pick the destination based on weight or availability, which isn't helpful
[01:44] <drab> I guess I could use REDIRECT on the gw and redirect to a different service based on src ip with iptables
[01:44] <drab> that'd work
[01:50] <tomreyn> normally you'd add a custom cookie or request header to deviate from default traffic flow for testing / debugging purposes.
[01:51] <zul> jamespage:  when you get a chance https://review.openstack.org/#/c/488254/
[01:51] <tomreyn> i'm not sure which open source LBs support this, but i would assume most L7 do.
[01:55] <drab> tomreyn: good point, will take another look at the config files/man pages, altho most of these LBs are advertised as L4, not L7
[01:58] <drab> oh, LVS has KTCPVS which is L7
[02:09] <drab> nope, all those solutions seem way more work to setup and maintain than the iptables trick with multiple virtual services
[02:10] <drab> there are some new L7 balancers like one from lyft, but they aren't even packaged
[06:01] <ah-donny> Hey all, Is there any cloud storage software for Ubuntu Servers that can used on my home network to communicate with Android, iOS, Linux and Windows machines
[06:28] <lordievader> Good morning
[12:21] <zul> icey: I think you got more breakage in the nova-lxd tree, its missing wsgi-intercept as a build dependency now
[12:21] <zul> in the test-requirements.txt
[12:22] <icey> zul saw that test failure :-/
[12:26] <ivoks> zul ! :)
[12:26] <zul> ivoks: heylo
[12:28] <ivoks> how are you?
[12:37] <zul> I'm good how are you
[12:41] <icey> zul: this one is piled on behind your tracebnack fix: https://review.openstack.org/#/c/488403/1
[12:42] <zul> icey:  yeah I think you are going to have more problems though but it could be just me I think
[12:42] <icey> zul at least it passes tox with your commit and mine ;-)
[12:43] <zul> icey: coolio
[13:28] <xpistos> Hi all. I am currently running Ubuntu 16.04.02. How do I upgrade my server to the most current rev? I thought apt-get dist-upgrade would take care of that
[13:29] <rbasak> xpistos: what do you want to upgrade to?
[13:29] <xpistos> rbasak: isn't 16.04.04 out ?
[13:30] <rbasak> No, it's not.
[13:30] <rbasak> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
[13:30] <ogra_> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
[13:30] <ogra_> *snap*
[13:31] <xpistos> ok. Thanks
[13:31] <ogra_> funny ... .4 isnt even on there
[13:32] <xpistos> I thought i saw it was out but thanks for that page!
[13:33] <xpistos> So when a point rev gets released then am I correct that dist-upgrade will install that?
[13:33] <ogra_> yes
[13:34] <rbasak> Point releases are just roll ups of all updates released up to that point, together with some installer changes.
[13:34] <rbasak> If you're installing updates regularly, then upgrading to a point release is effectively a no-op for you anyway.
[13:35] <rbasak> (installer defaults can change though, such as the hardware enablement stack, which you need to opt in to if upgrading; but there's no point usually if everything works since by definition you don't need hardware enablement updates then)
[13:48] <zul> icey: you have problems with the wsgi-intercept fix
[13:51] <icey> zul and we're running a tempest test for dvsm that isn't passing :-/
[13:51] <zul> icey: *sigh*
[16:26] <DammitJim> oh man, I'm about to get bashed... I've been asked to set up an Ubuntu Server 16.04 with Unity
[16:26] <DammitJim> however, stubborn me doesn't want to install everything that comes with ubuntu-desktop
[16:26] <DammitJim> so, I did the no-install-recommends
[16:26] <DammitJim> however, I am having a very hard time configuring rdp to this desktop
[16:27] <DammitJim> do you guys have any pointers as to how to configure rdp for unity? I got it to work with xfce
[17:55] <android> how to install held packages
[17:57] <android> held because no verification gpg key
[17:59] <genii> Add the key.
[17:59] <android> I don't have it.
[18:00] <android> where can the propesed key be found in the package info?
[18:02] <android> it is going to call for a key id such as 0xFFFFFF right?
[18:03] <android> --ignore-hold didn't work
[18:04] <android> apt-get info <package>?
[18:29] <android> where can the proposed key be found in the package info?
[18:33] <nacc> android: the key is from the repository that hosts the package (if I understand what you are saying)
[18:33] <android> this is an old version
[18:34] <android> does old-versions have a signer key?
[18:34] <android> is the release upgrade going to need a new key?
[18:35] <android> this is planned for upgrade to system76
[18:37] <android> nacc the virtex shader graphics need to go
[18:38] <android> the website says the old version can be upgraded using do release upgrade
[18:39] <android> nacc you did well with an on target observation however support is taking too long
[18:40] <android> you just dont have enough energy to be support
[18:40] <android> find a new job
[18:41] <android> it doesnt need to take hours to formulate a response
[18:42] <android> do something like production line sorter
[18:42] <android> sort beans or somethinb
[18:46] <android> ok nacc
[18:47] <android> ok nacc?
[19:30] <hashwagon> Help meh, Ubuntu 16.04 system most commands result in Segmentation fault. How do I reboot this system? sudo doesn't seem to work either. Logged in as sudo user now.
[19:30] <hashwagon> It's a remote system so Ctrl+Alt+Delete isn't very accessible.
[19:31] <sarnold> you may be able to use echo something > /proc/sysrq-trigger
[19:31] <sarnold> of course the defaults for what can be done via the sysrq-trigger are pretty limited; I can't recall off-hand what is allowed vs not allowed
[19:32] <sarnold> the sysrq-trigger file takes the same commands as the sysrq key on the keyboard
[19:32] <sarnold> so u to umount, s to sync, b to boot, etc. I always used sync sync umount boot when doing a sysrq shutdown..
[19:32] <sdeziel> sound advise but IIRC, writting to sysrq-trigger requires root
[19:33] <sarnold> oh sigh I thought that was a sudo shell :/ not just sudo user. uh. that's not ideal.
[19:34] <hashwagon> Permission denied on echo to proc
[19:34] <hashwagon> cannot sudo echo
[19:35] <sdeziel> last time I ran into such situation was when I was wiping the root fs ... I hope you are no facing a similar situation
[19:35] <hashwagon> There's some keyboard command I thought could be used to reboot, not sure if that works remotely though..
[19:36] <sarnold> it might; that'd be the sysrq key; I think I heard some systems can let you send a break command to trigger it
[19:36] <sdeziel> hashwagon: for a remote system that's what the sysrq-trigger file is for but as you noticed, you need to be root to use it
[19:42] <sdeziel> hashwagon: I'd probably take a look at dmesg (if that works) just to know what's up with the machine. Regarding the reboot, there is AFAIK no way for a regular user to trigger one remotely
[20:01] <JanC> otherwise would be disastrous on any shared system  :)
[20:36] <gunix> hey guys. where was i supposed to open ticket to get the packagers to add an openstack cinder version to the package list?
[20:36] <ahasenack> nacc: hey, am I using git ubuntu lint correctly here: http://pastebin.ubuntu.com/25192910/ ?
[20:37] <ahasenack> nacc: $(pwd) is a clone of https://git.launchpad.net/~powersj/ubuntu/+source/mongodb branch fix-1584431-xenial
[20:37] <nacc> ahasenack: let me check
[20:37] <gunix> there is a big bug currently within openstack horizon on ubuntu server. when cinder is available, it doesn't allow any actions related to volumes. but it should. this was corrected with the latest dashboard patch. but it's not available. where can i open a ticket for this?
[20:37] <ahasenack> I did git remote add to add the pkg remote, then used that
[20:37] <ahasenack> before a git fetch pkg
[20:37] <ahasenack> er, after
[20:37] <ahasenack> anyway
[20:39] <ahasenack> gunix: against horizon itself perhaps?
[20:40] <ahasenack> the openstack-dashboard package in this case
[20:50] <nacc> ahasenack: fwiw, you shouldn't need to pass -d $(pwd), that's the default
[20:50] <ahasenack> ok
[20:51] <nacc> ahasenack: but still reproducing the issue (sorry network is a bit slow today for some reason)
[20:51] <ahasenack> it's Friday :)
[20:51] <nacc> ahasenack: hrm, locally (on a slightly differnet branch), i got all of them passed, let me recheck with master (need to stash some changes)
[20:52] <ahasenack> nacc: hm, they all passed now too
[20:52] <ahasenack> with or without -d
[20:52] <nacc> ahasenack: there were some fixes that went out, did the snap possibly refresh locally?
[20:52] <ahasenack> that would have been an amazing coincidence
[20:52] <nacc> ahasenack: yeah, it passes with master too
[20:52] <ahasenack> let me check the logs
[20:52] <nacc> ahasenack: :)
[20:53] <nacc> ahasenack: the linter isn't stateful, so i'm not sure why it would have changed the result otherwise
[20:53] <ahasenack> I see this from a couple of minutes ago
[20:53] <ahasenack> Jul 28 17:50:51 nsn7 git-ubuntu[7671]: cmd.go:118: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
[20:53] <ahasenack> Jul 28 17:51:41 nsn7 git-ubuntu[7777]: cmd.go:118: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
[20:53] <ahasenack> not sure yet what it means
[20:53] <ahasenack> but there is "git-ubuntu" in it :)
[20:54] <ahasenack> snap info has an old timestamp (many hours ago) for "refreshed"
[20:55] <ahasenack> well, it's working
[20:55] <nacc> ahasenack: yeah, i'm really not sure on that
[20:55] <nacc> ahasenack: but yeah, all i can say is the linter seems to be passing in my testing
[20:56] <ahasenack> even the hash in the last "git checkout" line is still the same
[20:56] <ahasenack> so yeah
[20:56] <ahasenack> let's ignore this
[20:56] <nacc> :)
[21:27] <gunix> ahasenack no, they already released the package. ubuntu has to add it to the repos
[21:32] <ahasenack> gunix: you mean they made a new source tarball release, and ubuntu has to grab it, or just backport the fix
[21:40] <gunix> yes, 11.0.3 was released but we still have 11.0.2: https://paste.gnome.org/psldpujzk
[22:39] <drab> urm, I'm trying to implement that return address thing with policy routing and it seems ip route default doesn
[22:39] <drab> 't like eth0:1
[22:39] <drab> anybody has seen that before?
[22:40] <sarnold> I don't know if the iproute2 utilities handle aliases well
[22:40] <sarnold> afterall not needing aliases any more was one of their advertising points :)
[22:40] <drab> mmmh, how would I be assigning a new ip to the same interface then?
[22:42] <drab> it seems you can do it with the ip utilities, however in network/interfaces the only supported syntax seems ethX:X kind of thing
[22:42] <sarnold> ip addr add 1.2.3.4 dev eth0 kind of thing
[22:43] <sarnold> true /etc/network/interfaces is twenty year old cruft :( gotta use up and down scripts there to use ip or add ipv6 to nics or whaetever
[22:43] <drab> yeah that worked (the ip addr, retrying the policy routing bit now)
[22:44] <sarnold> thankfully something better is coming https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-June/001215.html
[22:45] <drab> is that systemd-networkd? :P
[22:45] <sarnold> netplan
[22:45] <drab> oh, never heard of netplan, thanks for sharing
[22:45] <drab> yeah , just clicked the link
[22:45] <drab> will read up, thanks
[22:47] <drab> nope, still not working
[22:47] <drab> I'm trying to dig as a test and it complains that "reply from unexpected source"
[22:47] <drab> which is the ip of eth0
[22:47] <drab> maybe I'm messing up the PR part...
[22:51] <sarnold> drab: hrm, that reminds me a bit of
[22:51] <sarnold> arp_filter from https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
[23:01] <drab> sarnold: good idea, but still having the same problem :/
[23:02] <drab> net.ipv4.conf.all.arp_filter = 1
[23:04] <sarnold> drab: and the source routing, I've never needed to know owto do that, did you set that up as the lartc guide recommended?
[23:05] <drab> yeah, and then also found this: https://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming/23345#comment476516_23345
[23:05] <drab> which is basically confirming the same thing
[23:06] <sarnold> wow cool
[23:06] <sarnold> so that's what the separate routing tables are for :) not only containers
[23:07] <drab> what about containers?
[23:08] <drab> btw I'm in a container... I guess I should test this on the bare host just in case
[23:08] <sarnold> I've seen the multiple routing tables used with containers before but knew they long predated containers..
[23:08] <drab> I actually use that very lartc stuff on the gateway
[23:08] <drab> to balance 2 upstreams
[23:08] <drab> and works just fine
[23:09] <android> what junk are you making now?
[23:10] <android> --ignore-hold doesn't work
[23:10] <drab> I'm building a bed, a table and a shelf unit out of 2by4 and plywood
[23:10] <drab> oh, maybe wrong channel?
[23:10] <android> drab now that isnt junk
[23:11] <drab> you should see my table saw :P
[23:11] <drab> and what the output is :...(
[23:11] <drab> but it works and it's cheap
[23:12] <drab> plus hacking and hammering stuff together is the only way I can preserve sanity from working with computers... :)
[23:12] <drab> woodworking as therapy ftw
[23:12] <sarnold> sounds like you could use a lathe
[23:13] <sarnold> doesn't matter if you actually want any lathed output. but it's hypnotic and makes a mess and smells good.
[23:13] <drab> a lathe would be nice. and a jointer
[23:13] <drab> lol
[23:13] <sarnold> jointer would be more useful perhaps
[23:13] <drab> msot of the 2by4 I get are just about ready to build arches...
[23:14] <android> cover it with paint
[23:14] <drab> I still don't quite get how a jointer is going to fix that tho, if a piece of wood is bent and you pass it through a jointer at most you get uneven thickness
[23:14] <android> clear paint
[23:14] <drab> which doesn't seem useful even if it "looks
[23:14] <drab> " flat
[23:15] <drab> anyway, need to figure out this ip route thing first :/
[23:16] <android> ip route?
[23:16] <android> what of it?
[23:18] <drab> I'm migrating services from some old hw into containers
[23:19] <drab> and during the transition I need the container to have its new and final ip + the current hw's ip
[23:19] <drab> so that clients still using the old ip will work during transition
[23:19] <android> containers?
[23:19] <nacc> drab: won't they see two hosts responding to the same IP?
[23:19] <drab> however if I just add the hw's ip to the container replies will come through the container's primary ip and the client will discard them
[23:19] <android> amazon junk?
[23:19] <drab> nacc: the hw will go down as soon as I have this working
[23:19] <nacc> drab: i'm assuming there are more details being glossed :)
[23:20] <nacc> drab: ah sure
[23:20] <drab> so I flip the rule on and unplug the cable to the hw
[23:20] <nacc> drab: yep, that makes sense
[23:20] <drab> but right now I'm testing on a box and can't get it to work
[23:20] <drab> testbox*
[23:20] <drab> android: lxc containers
[23:21] <drab> they have a bunch of old hw (desktops) which fail a lot so I've been migrating all their stuff into a server grade piece of hw running lxc
[23:23] <android> drab where do you work?
[23:24] <android> it looks like I am being targetes by the app devels
[23:24] <android> when I install an app they start updating
[23:25] <android> I have plans on pulling source code for apps
[23:25] <android> when they update they change the code
[23:43] <drab> mmmh this is both interesting, useful and annoying
[23:43]  * drab scratches head
[23:43] <drab> so now unbound works
[23:43] <drab> but none of the policy routing stuff was needed
[23:44] <drab> all the examples I'm finding were using multiple nics/interfaces so I'm wondering if just one and a secondary address that just doesn't work for some reason
[23:45] <drab> what I had to change was the ip unbound listened on... using 0.0.0.0 created the routing/src ip issue
[23:45] <drab> but if I explicitly set it to listen on primary and secondary ip then it works just fine
[23:45] <drab> which makes sense I guess...
[23:46] <sarnold> drab: curious. very curious.
[23:46] <drab> on the other hand for example ssh does not seem to have a problem whatsover... set to listen on 0.0.0.0 but connections through the secondary ip work just fine
[23:46] <sarnold> 0.0.0.0 is probably not ideal for a dns server anyway
[23:47] <nacc> heh
[23:48] <drab> it's internal only with all wan traffic fw'ed so not a big of a deal and it saves me having more config tasks to handle, but I hear you
[23:58] <drab> fw'ed in hindsight was probably the wrong way to shorten firewalled :)
[23:58] <drab> anyway, all done and working \o/
[23:58] <drab> thanks all for the support, as usual nothing beats bouncing ideas around
[23:59] <sarnold> drab: sweer! :D
[23:59] <sarnold> sweet too.
[23:59] <sarnold> heh
[23:59] <nacc> sweer!
[23:59] <nacc> sarnold: i like it
[23:59] <drab> sweer... sweet beer! lol