[00:35] <DR_Moreau> hi everyone
=== Guest85432 is now known as IdleOne
[01:13] <lunaphyte> hi.  hostname --fqdn and dnsdomainname don't work, but it appears to me that by all accounts they should: http://dpaste.com/17VP3HP.txt
[01:13] <grendal_prime> hola
[01:13] <grendal_prime> peaches
[01:15] <nacc> lunaphyte: that's almost certainy a configuration or local network issue ... what does `hostname --all-fqdns` provide, if anything?
[01:16] <lunaphyte> nacc: aha, that returns the desired result:  "foo.example.com"
[01:17] <nacc> lunaphyte: read `man hostname` :)
[01:17] <nacc> lunaphyte: iirc, it says to never use --fqdn :)
[01:17] <lunaphyte> i have been
[01:17]  * lunaphyte looks again
[01:18] <nacc> lunaphyte: under "THE FQDN"
[01:18] <lunaphyte> "If a machine has multiple network interfaces/addresses or is used in a mobile environment" - it's not
[01:19] <lunaphyte> it's a bare bones, minimal server install, with only eth0 and lo, and a single address for each
[01:20] <lunaphyte> the actual symptom which led me here is sudo complaining: "sudo: unable to resolve host foo"
[01:21] <nacc> lunaphyte: anything funky in /etc/hosts?
[01:21] <sarnold> it might be easiest to ensure the hotsname is in /etc/hosts
[01:21] <nacc> sarnold: ack
[01:22] <sarnold> it's customary to give the hostname 127.0.1.1 and leave 127.0.0.1 for 'localhost'.
[01:23] <lunaphyte> http://dpaste.com/1W52WFC.txt
[01:25] <sarnold> nacc: bingo :D
[01:25] <sarnold> lunaphyte: add 127.0.1.1 foo foo.example.org  to your /etc/hosts :)
[01:25] <lunaphyte> heh, sort of
[01:25] <lunaphyte> there should be no need to
[01:25] <lunaphyte> the hostname is perfectly resolvable
[01:26] <lunaphyte> doing that causes other problems, and the presence of that silly pretend address is only to satiate bugs in certain software [e.g. gnome]
[01:26] <sarnold> good poiunt
[01:27] <sarnold> but it's been a decade or more since i've seen a host without the 127.0.1.1 alias for the hostname, so I can't really say one way or another if what you're seeing is strange or not
[01:27] <nacc> lunaphyte: you could strace `hostname` to see what's complaining
[01:27] <lunaphyte> nacc: i was just thinking that, yeah
[01:27] <sarnold> lunaphyte: maybe this means your /etc/nsswitch.conf needs fiddling?
[01:28] <tarpman> lunaphyte: just to double check, reverse dns is working as well as forward? i.e. hostname -> ip -> fqdn round-trip
[01:28] <lunaphyte> ah, let's try putting dns first
[01:28] <lunaphyte> tarpman: yeah, both are good
[01:30] <lunaphyte> http://dpaste.com/26G71D1.txt
[01:31] <nacc> lunaphyte: where are you current defining your hostname and domain? /etc/hostname?
[01:32] <lunaphyte> yes, /etc/hostname contains "foo"
[01:32] <lunaphyte> sudo seems to ignore the nsswitch config somehow
[01:33] <lunaphyte> nsswitch.conf looks typical to me: http://dpaste.com/35RRWD8.txt
[01:34] <lunaphyte> [well, i just switched the hosts db order]
[01:34] <lunaphyte> i've tried both "hosts: dns files" and "hosts: dns"  sudo doesn't seem to care
=== KnownSyntax_ is now known as KnownSyntax
[01:35] <lunaphyte> i've just installed a kernel update, so time for a quick reboot and then i'll see what strace reveals
[01:40] <lunaphyte> if there's interest in complete hostname strace output, i'll pastebin it.  it's not too long, but if not, that's fine
[01:40] <sarnold> you've piqued my curiosity :)
[01:44] <lunaphyte> sure, one moment
[01:44]  * patdk-lap never uses 127.0.0.1 for the local hostname
[01:44] <patdk-lap> would totally break my software that bind to the ip, and not localhost
[01:47] <lunaphyte> http://dpaste.com/3TEJW3Z.txt
[01:47] <lunaphyte> i see dns queries with tshark too
[01:47] <lunaphyte> i have to step awayfor just a bit
[01:47] <lunaphyte> *away for
[01:48] <lunaphyte> http://dpaste.com/18NQXT8.txt
[01:57] <sarnold> lunaphyte: is that second paste showing that the dns server doesn't know the address?
[02:00] <nacc> sarnold: lunaphyte: does `hostname` actually parse /etc/hosts? looking at the strace, it feels like it read in the file, didn't find what it wanted and errored out
=== King is now known as prince
[02:20] <patdk-lap> indirectly, libc did that
[02:35] <lunaphyte> sarnold: yeah, i noticed that too.  i'll look at the logs on the dns server answering those queries.  it seems odd at first glance
[02:49] <lunaphyte> oh no.
[02:50] <lunaphyte> ugh.  this is awful.  i have just wasted 1+ hours of everyone's time :(
[02:51] <sarnold> ooh did you solve it?
[02:51] <lunaphyte> template-ubuntu-1404 != ubuntu-1404-template
[02:51] <sarnold> doh :)
[02:51] <lunaphyte> my most sincere apologies.  that is woefully absurd
[02:55] <lunaphyte> i guess i was probably overdue for a "you're an idiot" moment.  seems i need a few of those every now and again to ensure my humility remains intact.  :)
[02:56] <sarnold> somehow they happen more frequently _after_ going on irc, don't they? :)
[02:56] <sarnold> oh well, you got it sorted out.
[02:58] <lunaphyte> yeah, all is well.  thanks for enduring
=== athairus is now known as afkthairus
[04:46] <Starn88> hello, i've been running into issues with Citadel server. as the citserver stuff is running webcit is running but when i try to connect to say localhost or the ip or domain the webcit gives me it's little error "This program was unable to connect or stay connected to the Citadel server. Please report this problem to your system administrator."  i've followed all of their instructions
[04:46] <Starn88> netsta -lpn shows all the citserver's running shows webcit is running and on the proper port. i had everything working but i wanted to do a reboot to clarify in a sitiaution of crash power outage or other unforseen events that everything would work after booting back up that's when everything stopped working like it should that's when webcit started giving me the error and netstat -lpn
[04:46] <Starn88> is showing everything is running. a simple test email from my web server was able to send a varification email. so smpt is working.
[04:47] <Starn88> i just can't get webcit working right
[04:48] <sarnold> is there any chance that they give you a useful error message in a log file somewhere?
[04:49] <sarnold> "unable to contact or stay connected" is nearly useless
[04:49] <sarnold> no, I take that back, it is useless..
[04:49] <Starn88> sarnold, i completely agree that it's useless. if they do have a log file i cannot find it
[04:49] <sarnold> damn
[04:50] <Starn88> sarnold, i've been working on trying to resovle this issue my self for the past couple days even eventually said eff it and tried postfix and dovecot but my webserver didn't like those two
[04:50] <sarnold> is the server bound to the proper IP address? is the client running on the same system or a different system?
[04:50] <sarnold> is a firewall blocking it? local to the server, local to the client, or on any systems between?
[04:51] <Starn88> i've tried client locally and externally. the server is on a proper ip. with domain. and the ports are open
[04:51] <sarnold> can you connect to the server from the client using a simple tool like netcat or telnet?
[04:51] <Starn88> to help the server runs on NFOServers.
[04:51] <Starn88> yeah telnet connect to the citserver stuff. the website sends emails using the citserver.
[04:51] <sarnold> is that a cloud provider thingy? or more traditional vps provider? you may need to fiddle with "security groups" there.. (AWS terminology, sorry)
[04:52] <Starn88> only thing telnet isn't getting a communications from is the webcit
[04:52] <Starn88> traditional vps and dedicated.
[04:52] <Starn88> they leave all ports open they leave it to the end user to close the ports
[04:52] <sarnold> was it working for a while and then stopped? or has it never worked? or..
[04:53] <Starn88> it worked perfect when i first installed it. rebooting ubuntu is when issue arise.
[04:53] <Starn88> it's been driving me bonkers. i'm half tempted to pay someone to properly setup and secure postfix and dovecot
[04:55] <Starn88> sarnold, by the way their error page does give you a link to " http://www.citadel.org/doku.php/faq:generalquestions:webcit_unable_to_connect "
[04:56] <Starn88> sarnold, but even after following those and doing as they said to varify servers are running.  if postfix and dovecot have a web-based user interface i'll happily use it i do believe it can work with spamassassin and clamav
[04:56] <sarnold> hah that's just as useless -- a consequence of the original error message being useless. sigh.
[04:57] <sarnold> Starn88: web-based thing.. roundcube seems popular, squirrelmail (used to be?) popular.. there's probably more choices in the archives, but I don't know them by name..
[04:58] <Starn88> sarnold, hmm i'll investigate roundcube. i have a deadline to get this stuff setup by sunday fully functional.
[05:00] <Starn88> sarnold, this roundcube looks nice. very nice
[05:02] <Starn88> sarnold, give me about ten minutes i'll varify that it works
[05:06] <sarnold> Starn88: \o/ :)
[07:25] <norc> Hi. How can I change the current nameserver directly?
[07:25] <Starn88> sarnold, i got that roundcube working ontop of the citadel server.
[07:26] <Starn88> sarnold, also fixed my dns mx records to allow it to receive emails. thank you so much! this roundcube will allow the admin and their staff to reply to emails.
[07:58] <jamespage> Odd_Bloke, around?
[08:08] <jamespage> Odd_Bloke, gaughen: hey - so we just tripped on an issue with final xenial testing of openstack
[08:09] <jamespage> Odd_Bloke, gaughen: the naming of network devices on cloud instances is no longer ethX
[08:11] <jamespage> was that an intentional change?
[08:19] <frickler> jamespage: what interface names are you seeing? I'm getting "virtio_net virtio0 ens3: renamed from eth0" but only with debian-testing, so I was blaming their image for that. I'm still running from a week-old snapshot though, so I might be missing some more recent changes
[08:19] <jamespage> frickler, latest xenial cloud image on an openstack cloud
[08:19] <jamespage> syslog:Apr 20 08:06:00 ubuntu kernel: [    3.491798] virtio_net virtio0 ens2: renamed from eth0
[08:20] <frickler> jamespage: looks similar to mine, let me recheck with a recent image
=== dosaboy_ is now known as dosaboy
[08:28] <frickler> jamespage: o.k., I'm also getting ens3 with build 20160418. with build 20160412 everything was still fine
[08:29] <frickler> jamespage: the other image I am seeing the same behaviour with is http://cdimage.debian.org/cdimage/openstack/testing/debian-testing-openstack-amd64.raw which is from 2015-10-05, so I doubt that this is a recent change or something done intentional on the Ubuntu side
[08:30] <Odd_Bloke> frickler: So Ubuntu Server has used the systemd interface naming this entire cycle.
[08:30] <Odd_Bloke> frickler: But because clouds tend to assume that interfaces will be named eth0, we needed some work in cloud-init to enable that in the cloud images.
[08:30] <Odd_Bloke> frickler: That work landed ~2 weeks ago, so we made the change last week.
[08:30] <Odd_Bloke> frickler: So it is an intentional change. :)
[08:31] <Odd_Bloke> Albeit a late one. :(
[08:31] <jamespage> Odd_Bloke, shame its broken all of our xenial functional testing for openstack...
[08:31] <jamespage> on the day before release..
[08:31] <frickler> ah, just found https://bugs.launchpad.net/ubuntu-on-ec2/+bug/1510345
[08:31] <ubottu> Launchpad bug 1510345 in cloud-init (Ubuntu Xenial) "[SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules" [High,Triaged]
[08:33] <Odd_Bloke> frickler: Right, see comment #17 from Martin Pitt; that's what we're now doing.
[08:33] <Odd_Bloke> jamespage: Urgh, I'm sorry. :(
[08:35] <frickler> Odd_Bloke: can you point me to the patch that you did? so you had net.ifnames=0 and are now doing exactly what?
[08:36] <frickler> it is also sad that the cloud images are hardcoded to using just one interface, we regularly use multiple ones and have to amend the images in order to do DHCP on all of them
[08:36] <Odd_Bloke> frickler: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1365 is the livecd-rootfs change.
[08:37] <Odd_Bloke> There are cloud-init changes that meant we could stop having ENI.d/eth0.cfg; let me track those down.
[08:37] <Odd_Bloke> (FWIW, we would now expect cloud-init to consume network_data.json correctly.)
[08:38] <frickler> looks like the cloud-init changes do not work, the image still is trying to do networking on eth0: "networking[194]: Cannot find device "eth0""
[08:39] <Odd_Bloke> frickler: So there isn't really one cloud-init commit to point to, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/net/ contains some of the relevant bits.
[08:40] <jamespage> Odd_Bloke, can you confirm exactly which cloud image build picked up this change? I'm trying to bisect why we only just started seeing this today...
[08:41] <Odd_Bloke> jamespage: So we were _also_ having some sync problems due to rotating SSH keys because of a leaving team member; those only got fully resolved (we hope ¬.¬) in the last 48 hours.
[08:41] <jamespage> Odd_Bloke, so up until the last 48 hours, our cloudimages did eth0
[08:41] <Odd_Bloke> jamespage: So "older than today" cloud images probably had it, but either weren't getting to cloud-images.u.c or weren't in streams.
[08:42] <frickler> jamespage: 20140416 is working, but it does indeed set up networking properly on ens3 instead of eth0
[08:42] <jamespage> frickler, when did that get into the streams?
[08:42] <jamespage> frickler, our cloud feeds off stream data, so if the stream was old, then we would not have got new images...
[08:42] <frickler> jamespage: I just downloaded that from https://cloud-images.ubuntu.com/xenial/20160416/
[08:43] <jamespage> frickler, sorry - those questions where mean't to be directed at oddbloke
[08:43] <jamespage> Odd_Bloke, ^^ ?
[08:44] <frickler> still interesting that it was working with ens3 intermediately, while it was using eth0 earlier
[08:45] <Odd_Bloke> frickler: Can you pastebin the cloud-init.log from a 20160418 instance that you're seeing bad behaviour on?
[08:45] <Odd_Bloke> jamespage: We can't see the sync logs, so I'm asking IS on #is if they can.
[08:50] <frickler> Odd_Bloke: jamespage: it seems that 20160418 is indeed working, too, see http://paste.ubuntu.com/15943256/ . I only checked for the interface rename happening earlier and did not check whether the instance configured its network correctly in the end
[08:50] <Odd_Bloke> frickler: OK, phew.
[08:51] <frickler> so in fact all is well, at least from my side, except some people may get confused when they see ens3 now instead of eth0
[08:51] <frickler> Odd_Bloke: yeah, sorry for giving you a bit of adrenaline rush here :D
[08:51] <Odd_Bloke> frickler: :)
[08:52] <frickler> just by the similarity of the message with what I had seen earlier in debian-testing I was false assuming that the error would be the same
=== hxm- is now known as hxm
[11:12] <YamakasY> ok, any good alternatives compared to PandoraFMS ?
[11:13] <hateball> YamakasY: have you tried Zabbix
[11:13] <hateball> I did not like Zabbix. But it's an alternative :p
[11:14] <hateball> Depends what you need to get done, nagios or icinga works just fine as well
[11:23] <YamakasY> hateball: yeah never liked it
[11:24] <YamakasY> I think opennms is ok
[13:36] <Impaloo> Which clock does the cron service run against?
[13:36] <Impaloo> It's either misconfigured by 6 hours, or it's running on a different timezone that I've configured elsewhere (looking at timestamps in logs).
[13:37] <Impaloo> s/that/than/
[14:14] <ddellav> coreycb cinder point release ready for review/push lp:~ddellav/ubuntu/+source/cinde
[14:14] <ddellav> r
[14:15] <jamespage> bug 1569035
[14:15] <ubottu> bug 1569035 in python-formencode (Ubuntu) "Packaging error causing installation to /debain/usr/..." [Undecided,New] https://launchpad.net/bugs/1569035
[14:19] <jamespage> lamont, roaksoax: bug 1569035
[14:19] <ubottu> bug 1569035 in python-formencode (Ubuntu) "Packaging error causing installation to /debain/usr/..." [High,Confirmed] https://launchpad.net/bugs/1569035
[14:25] <coreycb> ddellav, me looks
[14:27] <coreycb> beisner, when you get a chance, python-oslo.messaging 2.5.0-1ubuntu2~cloud0 is ready to be promoted to updates in the liberty UCA.  the wily versions were just promoted.
[14:33] <jamespage> coreycb, already done it
[14:33] <coreycb> jamespage, awesome thanks
[14:42] <ddellav> also coreycb my neutron is passing now, not sure why it was failing before
[14:42] <coreycb> ddellav, ok let me know when it's ready for review.  cinder is uploaded and awaiting sru team review.  once we get all the packages uploaded can you subscribe the sru team to the bug?
[14:43] <ddellav> coreycb it's ready, same repo i gave yo ubefore
[14:43] <ddellav> coreycb sure
[14:43] <coreycb> ddellav, ok
[15:00] <lamont> jamespage: interesting
[15:19] <hallyn> rharper: smb: gah, i'm having a failure to load architectural diagram in my head.  How does 'qemu64' relate to 'pc-i440fx-trusty' ?
[15:20] <smb> hallyn, I think its basically the effect of using that compat_bla_... function. It keeps the previous hw definitions as is but changes stuff for newer ones
[15:21] <rharper> qemu64 is the cpu
[15:21] <rharper> unrelated to the system collection of devices
[15:21] <smb> hallyn, roughly... from my memories which might be tainted
[15:21] <rharper> qemu64 is an alias for a subset of cpu features (meant to have greater compat across migrations) hiding vendor specific flags
[15:22] <hallyn> rharper: so when i start a pc-i440fx-trusty machine type on an amd host,
[15:22] <rharper> the pc-i440fx-trusty is a machine alias
[15:22] <smb> rharper, I just think that the upstream change meddles with the definition of the cpu based on what hw type one uses
[15:22] <hallyn> can it be qemu64 cpu type?  or is it a different one?
[15:22] <rharper> which specifies a set of configurations (which devices)
[15:22] <rharper> smb: it's been a while since I examined in detail but it shouldn't be variable w.r.t host cpu
[15:23] <rharper> hallyn: yes, the -M  is independent of -cpu
[15:23] <hallyn> we currently force VMX on for qemu64.  wondering whether i can add both VMX and SVM to the same thing :)
[15:23] <smb> rharper, it kind of is that and the other as well just to make it more fun for you
[15:23] <rharper> try it out -cpu qemu64,svm
[15:23] <rharper> err, +svm
[15:24] <rharper> smb: hallyn , maybe they do per-vendor stuff like +svm instead of +vmx if host cpu is amd
[15:24] <rharper> there's a definition file for the cpu types..
[15:24]  * rharper runs find 
[15:24] <smb> hallyn, which is already kinda ugh (qemu64 is modelled from a non-exiting amd cpu)
[15:25] <hallyn> well kvm -cpu qemu64,+svm -m 1024 -cdrom xenial-desktop-amd64.iso seems fine
[15:25] <hallyn> waiting for terminal
[15:25] <smb> rharper, additionally it gets more complex as kvm_amd not only wants the svm flag but also requires to read some amd specific cpuid leaf
[15:26] <rharper> well, of course
[15:26] <rharper> the cpuid stuff is where it determines cpu virt capabilities etc;  what's going on ? ie, the bug ?
[15:27] <hallyn> rharper: bug is https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1561019
[15:27] <ubottu> Launchpad bug 1561019 in libvirt (Ubuntu) "copied cpu flags don't match host cpu" [Medium,New]
[15:27] <hallyn> qemu historicaly always set svm on for nesting
[15:27] <hallyn> then they decided to change that
[15:27] <hallyn> we didn't notice bc noone uses amd :)
[15:27] <smb> hallyn, and as I found out today on top of that libvirt is too smart for its own good...
[15:27]  * hallyn wouldn't be surprised if it was an intel person who made that change to diss their competitor :)
[15:29] <rharper> no, in general, redhat and nested has been unsupported
[15:29] <rharper> they don't want to have to support it so they've disabled it upstream
[15:29] <jamespage> coreycb, seed update ready to go...
[15:29] <coreycb> jamespage, that was quick :)
[15:29] <rharper> the comment in the commit is wildly off since nested svm is *far* more functional and performant than intel
[15:29] <jamespage> coreycb, they are super easy todo
[15:29] <rharper> but as you say, no one has amd (or not enough of them and also want to do nested)
[15:30] <coreycb> jamespage, let me know how to do one if you can
[15:30] <smb> was playing with xenial today and found that even if I use something like model="phenom" and feature forced on svm this won't work because libvirt detects that phenom would have svm enabled (not seeing that qemu will disable it) and so never adds the +svm to the qemu command line
[15:30] <smb> rharper, except those who report the bugs about it.. ;-P
[15:30] <jamespage> coreycb, bzr branch lp:~ubuntu-core-dev/ubuntu-seeds/platform.xenial
[15:30] <rharper> right
[15:30] <jamespage> and read...
[15:31] <hallyn> rharper: no, come on - qemu community used to talk about how great amd's nesting support was and how terrible intel was for not having good support
[15:32] <rharper> hallyn: we're in agreement, maybe I typo'ed
[15:32] <hallyn> oh, ok.
[15:32] <hallyn> but so i wonder what happened to make them say "we need to disable amd nesting by default"
[15:32] <rharper> nested svm was implemented in a weekend; svm architecturally is much much nicer for virt because it was *designed* for virt by vmware (who learned from s390)
[15:32] <rharper> that's RH
[15:33] <rharper> the "we ship it, we support it"
[15:33] <rharper> they don't want anyone to accidentially have it on in a RHEL release
[15:34] <hallyn> wonder why upstream didn't ask for a build-time configuration flag then...
[15:34] <hallyn> oh well
=== codex_ is now known as codex
[16:06] <beisner> coreycb, horizon 9.0.0-0ubuntu2~cloud0 promoted --> mitaka-updates
[16:07] <coreycb> beisner, thanks
[16:07] <beisner> coreycb, thx for the fix yo
[16:09] <coreycb> ddellav, neutron 7.0.4 upload
[16:10] <ddellav> coreycb ack
=== nodoubleg is now known as nodoubleg-lunch
=== nodoubleg-lunch is now known as nodoubleg
[17:48] <coreycb> ddellav, everything's uploaded for the liberty point releases except for neutron-lbaas: https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=
[17:48] <coreycb> ddellav, neutron-lbaas is getting test failures for me
[17:49] <ddellav> coreycb hmm ok, i'll double check, it passed error free on ppa and sbuild for me
=== Isla_de_Muerte is now known as NwS
[20:00] <coreycb> ddellav, I think neutron-lbaas needs the new neutron, it built ok for me once neutron 7.0.4 was available
=== afkthairus is now known as athairus
=== wk-work_ is now known as whitekidney
[23:16] <TAFB> how do I upgrade my ubuntu server from 15.04 to 15.10?
[23:17] <TAFB> it's a VPS (over ssh)
[23:17] <patdk-lap> https://help.ubuntu.com/community/EOLUpgrades
[23:17] <sarnold> do-release-upgrade ought to work
[23:18] <patdk-lap> 15.04 is still in the repo?
[23:18] <TAFB> sarnold: broke it REAL bad last time I tried, rsyslog or something?
[23:18] <sarnold> patdk-lap: I think it might be, between ancient snappy and ancient phones..
[23:18] <TAFB> I just re-installed "ubuntu-15.04-x86_64-minimal" fresh so will try the upgrade again.
[23:18] <patdk-lap> I just remember it's like 9 months now
[23:18] <patdk-lap> and it's been longer than 9 :)
[23:19] <patdk-lap> Ubuntu 15.04
[23:19] <patdk-lap> 	
[23:19] <patdk-lap> Vivid Vervet
[23:19] <patdk-lap> 	
[23:19] <patdk-lap> Rel
[23:19] <patdk-lap> 	
[23:19] <patdk-lap> April 23, 2015
[23:20] <patdk-lap> 	
[23:20] <patdk-lap> February 4, 2016
[23:20] <patdk-lap> damn, sorry, formatting was bad on that
[23:21] <TAFB> patdk-lap: that looks like a lot of work :(
[23:21] <patdk-lap> heh?
[23:22] <patdk-lap> if your install is broken, well, you have to fix it first
[23:22] <patdk-lap> but otherwise, it's just a single sed command, and upgrade
[23:22] <TAFB>  <TAFB> I just re-installed "ubuntu-15.04-x86_64-minimal" fresh so will try the upgrade again.
[23:22] <patdk-lap> why would you install 15.04?
[23:22] <patdk-lap> it hasn't been supported for 2months now :)
[23:22] <patdk-lap> just install 15.10 or 16.04 :)
[23:22] <TAFB> patdk-lap: because that's the only source available for re-intalling my VPS
[23:23] <patdk-lap> that vps provider needs help
[23:23] <TAFB> they are retarded, no worried (dedistation)
[23:23] <TAFB> sudo sed -i 's/vivid/wily/g' /etc/apt/sources.list
[23:23] <TAFB> that all I run?
[23:23] <patdk-lap> no
[23:24] <patdk-lap> that will defently break things
[23:24] <patdk-lap> you need to point to the archive/old-releases repo
[23:24] <patdk-lap> and do an upgrade
[23:25] <TAFB> my vps is running SolusVM, no way I an like remotely mount an image of 15.10 and just install it fresh? It has a serial console available.
[23:32] <bekks> TAFB: SolusVM is the VPS platform, not an OS.
[23:32] <TAFB> I know, I figured it'd have the option to mount ISO images or something to boot the VPS from
[23:32] <sarnold> you know you may wish to just wait a day and install from 16.04 LTS instead
[23:33] <patdk-lap> na, his vps won't have it for atleast 2 years :)
[23:33] <bekks> Or ask your hoster for providing a 14.04 / 16.4 image.
[23:33] <patdk-lap> most likely they won't update from 15.04 till 17.04 comes out
[23:33] <sarnold> patdk-lap: hehe
[23:33] <TAFB> they have a 14.04 image
[23:33] <bekks> TAFB: So use it.
[23:33] <TAFB> instead of 15.04? what sense does that make??
[23:34] <bekks> TAFB: Then, you can update to 16.04.1 when it comes out.
[23:34] <patdk-lap> 15.04 is not support, much more sense
[23:34] <TAFB> oh, I see :)
[23:34] <sarnold> 14.04 has had security support for the lsat three months, when 15.04 has been unsupported for three months.
[23:34] <patdk-lap> it's only security
[23:34] <TAFB> will 16.04 come out before 11am EST tomorrow?
[23:34] <patdk-lap> not like any openssl/samba/libc/kernel/... issues to worry about
[23:35] <patdk-lap> I think around 2pm
[23:35] <patdk-lap> though, I'm running it on a few now
[23:35] <patdk-lap> already had to backport freeradius to it :(
[23:36] <sarnold> heh :/
[23:36] <TAFB> damn, I got a big event I gotta stream at 11am tomorrow. I'll see if I can get 14.04 working well
[23:36] <patdk-lap> 2.2 kept giving me issues, 3.0 just worked
[23:38] <sarnold> TAFB: heh if it were me i'd definitely go with 14.04 in this situation :)
[23:39] <TAFB> it's installing now :) I'll let ya know how it goes. just need to get nginx and php working before tomorrow
[23:39] <sarnold> patdk-lap: dang, 3.0.11? I wonder why debian is still on 2.2.x.
[23:39] <patdk-lap> no one cares
[23:39] <patdk-lap> it's good enough, for what they are doing
[23:41] <TAFB> Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 2.6.32-042stab113.11 x86_64)
[23:42] <sarnold> 2.6.32
[23:42] <sarnold> smells like an openvz system
[23:42] <patdk-lap> :)
[23:42] <patdk-lap> or lxc, but kindof old for that
[23:42] <bekks> Stinks. :P
[23:43] <tarpman> last I heard, systemd still wouldn't work on openvz kernels
[23:44] <sarnold> tarpman: ahhh that could explain why they don't have 15.10
[23:44] <sarnold> and why it may take them two years to get 16.04 LTS :)
[23:44] <tarpman> the solusVM homepage claims to support kvm and xen as well, but no idea what this particular hoster runs ofc
[23:45] <tarpman> actually nothing about openvz in particular, just that openvz hasn't been ported to anything newer than 2.6.32 :)
[23:50] <TAFB> is there a way to install the latest nginx without having to compile it?
[23:50] <bekks> TAFB: Why do you need the latest version?
[23:51] <TAFB> for the RTMP streaming fixed stuff.
[23:51] <patdk-lap> locate an ppa
[23:51] <patdk-lap> I'm sure one exists
[23:52] <tarpman> I'd put money on teward having a good one for 14.04
[23:53] <TAFB> 14.04 doesn't come with nano? wtf were they thinking :(
[23:53] <TAFB> what is the "codename" for 14.04?
[23:54] <tarpman> TAFB: trusty
[23:54] <TAFB> thx. adding some "mainline" sources
[23:54] <tarpman> "mainline"?
[23:54] <TAFB> as apposed to "stable"
[23:55] <tarpman> yeah, having stuff work and be reliable is highly overrated
[23:55] <tarpman> btw, https://launchpad.net/~nginx/+archive/ubuntu/stable is probably the ppa you want for nginx
[23:55] <tarpman> or I guess https://launchpad.net/~nginx/+archive/ubuntu/development if that's what you're into :)
[23:55] <TAFB> how can I tell what's bound to port 80?
[23:56] <patdk-lap> just pick a random persons ppa :)
[23:57] <tarpman> TAFB: netstat -lpt and look for the 'http' port
[23:58] <TAFB> 1.9.15-1~trusty is what it's going to install, looks good.
[23:58] <TAFB> apache2 :(
[23:59] <sarnold> feel free to apt-get purge it
[23:59] <TAFB> should I stop it first?
[23:59] <sarnold> and i'm surprised it didn't come with nano -- that's the first package I apt-get purge
[23:59] <sarnold> probably doesn't matter :)