[02:01] <chengyan> hello,every ,i want to learn ubuntu ,how should i do?
[02:01] <sarnold> what do you want to learn about? why?
[02:02] <chengyan> find a job
[02:03] <chengyan> System Operation Engineer
[02:06] <sarnold> chengyan: you may find this presentation useful; it extensively covers the performance analysis tools that are available: http://techblog.netflix.com/2015/08/netflix-at-velocity-2015-linux.html
[02:07] <chengyan> thanks
[03:32] <arrrghhh> jak2000, sup
[04:42] <jak2000> arrrghhh are you there?
[05:05] <arrrghhh> jak2000, going to sleep soon
[05:05] <arrrghhh> what's up?
[05:20] <jak2000> arrrghhh ok tomorrow
[05:20] <jak2000> contact
[05:21] <arrrghhh> ok...
[05:21] <jak2000> not working the scp copy command ask me a password :(
[05:21] <arrrghhh> you can ask your question in here and someone else may be able to help
[05:21] <jak2000> ok, yes tomorrow
[05:21] <arrrghhh> maybe there's something else missing, dunno.  keys works great for me following that site tho
[05:28] <jak2000> yes i too
[05:28] <jak2000> setup otrher pair of servers
[05:28] <jak2000> :(
[07:47] <YamakasY> ubuntu 14.04 doesn't have a glibc update ?
[07:49] <henkjan> YamakasY: http://www.ubuntu.com/usn/usn-2900-1/
[07:49] <henkjan> YamakasY: 14.04 is also mentioned
[07:54] <YamakasY> henkjan: I don't see it ?
[07:54] <YamakasY> at least not in apt-get upgrade ?
[07:56] <henkjan> YamakasY: what version do you see when you run dpkg -l|grep libc6 ?
[07:57] <YamakasY> 2.19-0ubuntu6.7
[07:57] <YamakasY> seems to be ok than
[07:57] <YamakasY> I think my puppet update went ok
[07:57] <henkjan> nice
[07:57] <henkjan> now just restart to finish it :)
[07:57] <YamakasY> heh on 300 servers yes :)
[07:58] <YamakasY> yap
[07:58] <YamakasY> need to do them batched
[08:02] <YamakasY> henkjan: as far as you know it's only affected directly to public servers ?
[08:12] <henkjan> YamakasY: al servers running the vulnerable libc version are affected. it just seems not so easy to exploit
[08:12] <henkjan> see https://00f.net/2016/02/17/cve-2015-7547/
[08:17] <YamakasY> henkjan: yeah as there is lots of rumor these days when there is a fix and not when there is non :)
[10:52] <dvdjaco> the USN for the glibc vuln states that "After a standard system update you need to reboot your computer to make all the necessary changes". I guess this is a standard paragraph and does not necessarily apply in this case¿
[10:59] <henkjan> dvdjaco: a restart ensures you that every program uses the new version of libc
[11:00] <henkjan> you could something like 'checkrestart' to check which program is still using old libs
[11:00] <andol> dvdjaco: Well, it kind of applies, depending on what additional manual steps you are willing to take. The Debian Security Announcements has a slightly longer, slightly better phrasing: "While it is only necessary to ensure that all processes are not using the old glibc anymore, it is recommended to reboot the machines after applying the security upgrade."
[11:05] <dvdjaco> henkjan andol yeah that was my line of thought. I have a couple of nodes that would be annoying to reboot right now, it would be easier to restart services that may make calls to getaddrinfo
[14:38] <kully> hey all - is there any way to remove the use of a single command from /usr/bin to just a select group of users?
[14:38] <kully> trying to remove the ability for 3 users to run the command "berks"
[14:47] <sdeziel> I dist-upgraded my Xenial system yesterday to notice that bind9 (named) was installed behind my back
[14:48] <sdeziel> the dist-upgrade pulled new versions of bind9-host and dnsutils but it should not have brought bind9 IMHO
[14:54] <sdeziel> lamont: it seems like bind9-host 9.10.X now depends on bind9, is this intentional?
[15:01] <gimmic> Anyone been using maas and have any concerns/complaints about using it to manage a lot of nodes? Looking at 100-300 nodes or so
[15:02] <lamont> sdeziel: it is not.
[15:02] <lamont> sdeziel: file a bug?
[15:04] <sdeziel> lamont: thanks: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1547052
[16:18] <ickyfeet> Hey everyone.  I'm having problems with my log files.  They're blowing up in size but when you look at the log files it's the same messages (with the same time stamps) repeated over and over and over.
[16:20] <ickyfeet> I can "tailf syslog" and it doesn't show anything but it continues to grow in size.
[16:22] <gimmic> you mean tail -f ?
[16:22] <ickyfeet> yup
[16:22] <gimmic> if the size is growing, the log file is growing
[16:23] <ickyfeet> but there's no new messages in the log, it's the same few lines repeated
[16:23] <ickyfeet> the time stamp on the messages isn't incrementing.
[16:24] <gimmic> delete or move the log and see if it is recreated?
[16:25] <sdeziel> deleting a log file that is being written to can cause more problem
[16:25] <ickyfeet> I've deleted the files and the don't reappear but the show back up after a reboot with the same messages as before and grow continuously.
[16:25] <sdeziel> if the log content is not import, I'll truncate the file
[16:25] <ickyfeet> I stopped rsyslog before deleting
[16:27] <ickyfeet> kern.log auth.log and syslog combined grew to 3+TB over night.
[16:29] <sdeziel> does your rsyslog.conf has "$RepeatedMsgReduction on" ?
[16:29] <ickyfeet> Checked that.  It is on.
[16:30] <sdeziel> are there other process than rsyslogd writing to those files?
[16:31] <ickyfeet> Nope.
[16:34] <ickyfeet> Welp, I'm a dope.  Was actually going to use this box as a syslog server.  Fat fingered a line to create a separate folder for individual hosts.  Removed the line and things cleared up.
[16:34] <ickyfeet> In rsyslog.conf
[17:02] <jamespage> ddellav, coreycb: the googleapi MIR - do we really want that in main? its used for cinder backup - we could look to disable tests for now, and have it as a suggests
[17:03] <coreycb> jamespage, I think we'd be happy to drop it if you don't think it's necessary
[17:03] <jamespage> coreycb, +1
[17:03] <jamespage> see if that is possible
[17:03] <coreycb> ok
[17:14] <coreycb> ddellav, I'll work on dropping googleapi from cinder.  sorry for having you do all that MIR work.
[17:16] <sdeziel> rharper: awesome work on the strongswan refresh, many thanks!
[17:18] <jamespage> coreycb, ddellav: it might not be possible
[17:18] <gavincmi> With respect to the current glibc issue: http://www.ubuntu.com/usn/usn-2900-1/ Curious is sysadmins are doing a full apt-get upgrade or possible to patch via apt-get install libc6 libc6-dev libc-bin (on ubuntu 14.04) ?
[17:18] <jamespage> just saying its always a good idea to look at this stuff
[17:19] <coreycb> jamespage, gotcha, hard to tell where to draw the line sometimes though
[17:22] <jrwren> gavincmi: i'd do either, depending on teh apps running on the system in question.
[17:30] <rharper> sdeziel: thanks!   please use it and break it so we can find any bugs for the release
[17:34] <gavincmi> For the updates outlined here: http://www.ubuntu.com/usn/usn-2900-1/ Is a full apt-get update & upgrade required or can one simply sudo apt-get install libc6 libc6-dev libc-bin (on ubuntu 14.04)?
[17:35] <teward> gavincmi: i would suggest doing a standard upgrade, rather than just relying on installing the individual packages on their own
[17:35] <teward> because there may be other things that need included in addition to just the libc6 items (not 100% sure but...)
[17:37] <gavincmi> Understood and normally I'm all for it. But being asked to explore alternative methods and limit scope of upgrade process (if possible)
[17:38] <gavincmi> So trying to see if others have found simply sudo apt-get install libc6 libc6-dev libc-bin  satisfies the patching criteria
[17:38] <gavincmi> Lastly, seeing others suggesting this as an alternative http://askubuntu.com/questions/735825/which-ubuntu-releases-have-fixes-for-cve-2015-7547-extremely-severe-bug-with?lq=1
[17:39] <sdeziel> gavincmi: for the patch to be effective, every application using the patched files need to be restarted
[17:39] <gavincmi> Sure so sudo apt-get install libc6 libc6-dev libc-bin & a server reboot is most likely in order
[17:40] <sdeziel> gavincmi: if you are too reboot, why not pull in all the available updates ;)
[17:40] <gavincmi> Because on some servers, don't have easy choice of pulling in all updates. Could introduce new issues not tested
[17:40] <gavincmi> hence the original question
[18:33] <xevious> Is there a kernel parameter I can pass to have Ubuntu skip the "Waiting for network configuration..." phase when I'm booting without a network connection? I'd like to avoid editing /etc/network/interfaces since I'll need to boot without the network infrequently.
[18:34] <xevious> That was a bit of x/y the way I phrased that.
[18:34] <xevious> Is there a way to disable network configuration at boot without altering /etc/network/interfaces?
[18:45] <Razva> is there any way to tail a juju deployment via autopilot? I cannot really find any logs of the ingoing installation...
[18:49] <coreycb> zul, can you upload aodh, barbican, and designate master branches to xenial from https://code.launchpad.net/~ubuntu-server-dev/+git ?
[18:50] <coreycb> zul, it's all prep work to get them into main
[18:50] <jak2013> hi all i want do this tsk( automatize: http://postimg.org/image/f8gmnnloj/ ) copy a file from swManzana to svrChaol, with scp command and without a password, how do it?  (a friend tell me use: ssh-keygen -t rsa -b 4096) any advice or link for follow? i followed: https://help.ubuntu.com/community/SSH/OpenSSH/Keys   but not luck thanks
[18:53] <iulianpojar> hello, i have MAAS installation, but i can not deploy any pc's, please help me, here are maas logs: [INFO] srvbal02a: Status transition from READY to ALLOCATED
[18:53] <iulianpojar> Feb 18 20:31:15 srvbal02b maas.node: [INFO] srvbal02a: allocated to user iulianpojar
[18:53] <iulianpojar> Feb 18 20:31:15 srvbal02b maas.interface: [INFO] Allocated automatic static IP address 192.168.5.3 for eth0 on srvbal02a.
[18:53] <iulianpojar> Feb 18 20:31:15 srvbal02b maas.node: [INFO] srvbal02a: Status transition from ALLOCATED to DEPLOYING
[18:53] <iulianpojar> Feb 18 20:31:16 srvbal02b maas.dns: [INFO] Generating new DNS zone file for norbalmaas
[18:53] <iulianpojar> Feb 18 20:31:16 srvbal02b maas.dns: [INFO] Generating new DNS zone file for 5.168.192.in-addr.arpa
[18:54] <iulianpojar> Feb 18 20:31:16 srvbal02b maas.power: [INFO] Changing power state (on) of node: srvbal02a (node-6cfbf14c-d416-11e5-9f63-00237d57f070)
[18:54] <iulianpojar> Feb 18 20:31:26 srvbal02b maas.import-images: [INFO] Started importing boot images.
[18:54] <iulianpojar> Feb 18 20:31:26 srvbal02b maas.import-images: [INFO] Finished importing boot images, the region does not have any new images.
[18:54] <iulianpojar> Feb 18 20:31:30 srvbal02b maas.bootsources: [INFO] Updated boot sources cache.
[18:54] <iulianpojar> Feb 18 20:31:30 srvbal02b maas.bootresources: [INFO] Started importing of boot images from 1 source(s).
[18:54] <iulianpojar> Feb 18 20:31:31 srvbal02b maas.bootresources: [INFO] Importing images from source: http://maas.ubuntu.com/images/ephemeral-v2/releases/
[18:54] <iulianpojar> Feb 18 20:31:34 srvbal02b maas.bootresources: [INFO] Finished importing of boot images from 1 source(s).
[18:54] <iulianpojar> Feb 18 20:31:34 srvbal02b maas.import-images: [INFO] Started importing boot images.
[18:54] <iulianpojar> Feb 18 20:31:35 srvbal02b maas.import-images: [INFO] Finished importing boot images, the region does not have any new images.
[18:54] <iulianpojar> Feb 18 20:31:36 srvbal02b maas.drivers.power.ipmi: [WARNING] Failed to change the boot order to PXE 192.168.5.206:
[18:54] <roaksoax> !pastebin
[18:54] <iulianpojar> Feb 18 20:31:38 srvbal02b maas.power: [INFO] Changed power state (on) of node: srvbal02a (node-6cfbf14c-d416-11e5-9f63-00237d57f070)
[18:54] <iulianpojar> Feb 18 20:34:25 srvbal02b maas.node: [INFO] srvbal02a: Status transition from DEPLOYING to FAILED_DEPLOYMENT
[18:54] <roaksoax> !pastebin > iulianpojar
[18:54] <iulianpojar> Feb 18 20:34:25 srvbal02b maas.node: [ERROR] srvbal02a: Marking node failed: Installation failed (refer to the installation log for more information).
[18:54] <iulianpojar> Feb 18 20:34:45 srvbal02b maas.node_query: [INFO] srvbal02a: Power is on.
[18:55] <roaksoax> iulianpojar: also, check the installation log on the WebUI of the node
[18:55] <roaksoax> iulianpojar: go all the way to the button and you can see if there in the drop down
[18:56] <Razva> roaksoax any hints on what to tail in order to see what juju is doing on the remote node...?
[18:56] <Razva> because at this point i'm...ehm...looking at the screen, with no idea of what is happening
[18:56] <roaksoax> Razva: i'd ping andreas or dpb1  :)
[18:57] <roaksoax> dpb1: ^^ ?
[18:57]  * Razva pings dpb1 :D
[18:57] <zul> coreycb: ugh..
[18:58] <thebwt> Hey guys, trying to get correct information on CVE-2015-7547 . http://people.canonical.com/~ubuntu-security/cve/pkg/glibc.html has "--" for prcise and trusty, and marked DNE. Yet we can confirm that the versions are 2.9 and higher there.
[18:59] <zul> coreycb: its not like i had to do anyting this afternoon anwyays :)
[18:59] <iulianpojar> sorry here is the maas logs: http://paste.ubuntu.com/15116147/ and latest machine events: http://paste.ubuntu.com/15116397/
[18:59] <coreycb> zul, should be fairly simple
[18:59]  * thebwt derps and scrolls up a bit
[19:00] <coreycb> zul, I'm on the DMB agenda for a week from monday for more upload priveleges
[19:00] <coreycb> privileges
[19:00] <zul> coreycb: the date is circled in my calendar :P
[19:00] <coreycb> zul, oh mine too believe me
[19:02] <Razva> roaksoax great: http://pastebin.com/5RicTdhw :D any idea why? another node was already deployed...
[19:02] <sdeziel> thebwt: http://people.canonical.com/~ubuntu-security/cve/pkg/eglibc.html
[19:08] <zul> coreycb: use me...abuse me....done
[19:08] <coreycb> zul, thanks
[19:15] <dpb1> Razva: sec, I have an article
[19:15] <dpb1> Razva: http://askubuntu.com/questions/606422
[19:18] <Razva> dpb1 thanks for the link, but my question was how can I see the log files while Juju is "working", while it's "working". not before it failed.
[19:19] <dpb1> Razva: I don't follow
[19:19] <sarnold> Razva: juju debug-log perhaps? https://jujucharms.com/docs/1.21/troubleshooting
[19:20] <Razva> dpb1 at this point I'm deploying OpenStack via MAAS + Juju. At this point Juju is "working", but I have no idea what it's doing :)
[19:20] <dpb1> Razva: you can get access to the juju environment to see what it's doing by following the instructions I pasted.
[19:21] <Razva> aaaand if the env is not deployed yet?
[19:21] <dpb1> did you try? :)
[19:21] <dpb1> if it's passed bootstrap, you can access it.
[19:21] <dpb1> s/passed/past/
[19:24] <Razva> trying right now
[19:28] <Razva> dpb1 by tech guy is telling me that "we are not using manual juju bootstrap process. for us bootstrap was being  run  by autopilot. and our environment is still in bootstrap, it has not passed this step"
[19:29] <dpb1> ok
[19:29] <dpb1> until then, there is nothing to see.  If that fails, there will be somethign printed by the autopilot
[19:29] <Razva> dpb1 haha, he told me the exact same thing. isn't this wonderful? :))
[19:30] <dpb1> :)
[19:31] <Razva> is this technically impossible or...why didn't the persons who wrote all this made a way to monitor stuff? it's the first time I'm hearing about a "thing that cannot be monitored"...
[19:33] <sarnold> Razva: have you had any success with juju debug-log?
[19:33] <Razva> sarnold right now my colleague/tech is trying to deploy again. previously it failed because of this: http://pastebin.com/5RicTdhw
[19:33] <Razva> aaand we have the same issue.
[19:34] <Razva> http://pastebin.com/8zmJaQdr
[19:34] <Razva> any hints guys?
[19:35] <sarnold> Razva: hmm, I can connect to streams.canonical.com:443 just fine.. is it firewalled off? does it need to go through a proxy of some sort?
[19:36] <sarnold> .. and I can download the trusty-amd64 tgz tools that are referenced in the second paste; it's slow, but downloading..
[19:37] <Razva> sarnold it downloaded ok all files UNTIL that one.
[19:37] <Razva> it crashed on that specific file, for two times in a row.
[19:40] <Razva> we're changing mirrors at this point.
[19:41] <Razva> and now we need to wait 10-15 minutes again, without knowing if it will work or crash. this is *so* frustrating.
[19:42] <sarnold> Razva: hmm, I asked our IS guys, those systems are apparently fine, that file served up fine from multiple locations..
[19:43] <Razva> ok, trying right now from a London mirror (the servers are physically located in Maidenhead)
[19:44] <Razva> if it crashes again I have a feeling that you'll see some monitors high in the sky.
[19:44] <sarnold> Razva: suggested "mtr --report -T -P 443 streams.canonical.com" debugging aide from IS :)
[19:45] <Razva> from maas I suppose?
[19:46] <sarnold> I think so; probably any host on that network ought to suffice
[19:48] <Razva> I'll do it from the maas/juju server, just to be sure
[19:48] <Razva> sarnold: http://pastebin.com/SCiQuiBK
[19:49] <sarnold> Razva: zounds, 40% packetloss on the first hop, 10% on the last; maybe run a few more? that's staggering..
[19:50] <Razva> doing it from my local server
[19:51] <Razva> guys, I *really* need an advice here. should I go with 14 or 15, for a fresh maas+autopilot+juju+whatever_ubuntu_cloud_openstack ?
[19:52] <Razva> sarnold: tests from local and maidenhead again - http://pastebin.com/xpEDs2gF
[19:52] <jrwren> Razva: do you want to upgrade every 6-9mo or every 2-5yrs?
[19:52] <sarnold> Razva: I'd think 14.04 unless you want to upgrade again soon
[19:53] <Razva> jrwren update everything in general...?
[19:53] <jrwren> Razva: yes, only LTS releases are supported for more than 9mo.
[19:53] <Razva> or just the OS, or just OpenStack
[19:53] <sarnold> Razva: interesting, maybe I'm misinterpreting the packetloss numbers for TCP..
[19:54] <Razva> sarnold: refresh http://pastebin.com/xpEDs2gF please, I've inserted the "table" headers also
[19:55] <Razva> jrwren will 14 pe upgradable to 16 LTS?
[19:55] <Razva> or I'll need to start everything from scratch...?
[19:56] <jrwren> Razva: yes, upgradable
[19:56] <sarnold> 14.04 LTS can be upgraded to 16.04 LTS but I don't think I'd jump on that upgrade for the "cloud" layer of the system -- it'd probably require a fair amount of work. unless you needed new features from the newer offering..
[19:56] <Razva> theeeen I suppose I should stick with 14?
[19:57] <Razva> sarnold that applies also to 15?
[19:57] <sarnold> Razva: yeah, upgrading from 15.10 to 16.04 LTS is probably going to require some effort too
[19:58] <Razva> so the advice is to stick with 14 'till 2017 then move everything up to 16 LTS, because I suppose at that time it'll be "debugged"?
[19:59] <Razva> or I have the option to stay with 14 'till 16 is out, then move everything to 16 (I won't have *that* much data in the next 6 months anyway...)
[19:59] <sarnold> we start notifying 14.04 LTS users that there's a new LTS release available and offer it for upgrade when the 16.04.1 point release is available ;) it's normally a few months..
[19:59] <sarnold> you can do that too
[20:00] <sarnold> you can also stay on 14.04 LTS until 2019 if you're lazy :)
[20:00] <Razva> sarnold: can you please take a look at the refreshed http://pastebin.com/xpEDs2gF ?
[20:00] <sarnold> Razva: it's nice the 10% at the cloud-images server is fixed.. but this is worrying:
[20:00] <sarnold>   1.|-- 217.19.1.1                50.0%    10  3002. 1000.   0.6 3002. 1224.2
[20:00] <Razva> sarnold: well, at this point I have a single client for OpenStack, which I badly need to serve. so I can stick with 14 'till 16 is out, but I'm "afraid" that 16 will be buggy. :|
[20:01] <sarnold> Razva: that line either means that I don't know what the "Loss%" line means when mtr is run in -T mode, but 50% packetloss on a network will make things _miserable_. try ping floods between hosts, smokeping, mtr between pairs of hosts, etc, try to figure out if you've got a bad switch or cable or NIC or routing loop or something else strange
[20:02] <Razva> 217.19.1.1                20.0%
[20:02] <sarnold> Razva: aha; then you may wish to deploy on 14.04 LTS and upgrade to 16.04.1 when it is released
[20:03]  * Razva is contacting the data-center regarding that huge loss
[20:04] <sarnold> Razva: hmm, first run mtr for a while
[20:04] <sarnold> Razva: it appears to be fairly lossy at the start; after ~100 packets between two hosts in my home network, it's settled down a bit
[20:08] <Razva> it got down from 50% to 20%
[20:08] <Razva> doesn't wants to go lower than 20%. I just wrote the DC guys.
[20:09] <sarnold> Razva: how many requests were sent? now that i'm 385 packets into my mtr probe of my network I'm at 0.3%
[20:10] <Razva> no idea, how can I see that please?
[20:10] <Razva> should I keep it going?
[20:11] <Razva> I have constant 20-30% loss, but hey...it's not 50%!
[20:11] <Razva> wooow 50% again.
[20:12] <sarnold> Razva: remove the --report option and re-run
[20:12] <sarnold> that'll have it run forever..
[20:13] <Razva> ah ok!
[20:14] <Razva> 18%
[20:15] <sarnold> let it get to 200 packets or so before bugging the datacenter staff :)
[20:16] <Razva> hah, something "clicked", it jumps between 0.9 and 7000 last ping
[20:16] <Razva> sent 200 and going down
[20:16] <Razva> so weird.
[20:18] <Razva> "I will need to escalate this to our Data Centre Technicians for further investigation. Once we have a further update we will be back in touch." < oh I loooove these predefined answers :))
[20:18] <sarnold> very odd.. I wonder if TCP may also increase the stddev compared to icmp -- it takes more effort to reply to tcp packets than icmp packets. but 7000 ms is an eternity
[20:18] <sarnold> heh
[20:20] <Razva> it usually crashed at ~1300-1400 seconds
[20:21] <Razva> we're at 850, so in 550 seconds will see if it crashes again at the same file.
[20:21] <sarnold> heh
[20:22]  * Razva is singing "it's the final countdoooooown"
[20:22] <Razva> or somebody could do a darn thing that could log autopilot's stuff!!! :))
[20:27] <Razva> aaaaaaaaaaaaand it failed again, at the exact same file.
[20:28] <Razva> sarnold: http://pastebin.com/3vtP0wvP
[20:29] <xevious> Is there a way to prevent the system from configuring the network interface during boot without altering /etc/network/interfaces?
[20:29] <sarnold> Razva: can you wget https://streams.canonical.com/juju/tools/releases/juju-1.25.3-trusty-amd64.tgz  that file directly?
[20:29] <Razva> BUT if I wget the file directly...it works like a charm!
[20:29] <sarnold> Razva: dude.. sigh.
[20:29] <Razva> sarnold just did that, yes I can: 00%[[20:29] <sarnold> Razva: nice network :)
[20:29] <sarnold> heh
[20:30] <Razva> 1gbps
[20:30] <Razva> BUT the file it's not downloaded on maas, but on the deployed server, right?
[20:30] <jrwren> is it that your maas server can access that url, but this controller node you are bootstrapping cannot?
[20:30] <Razva> jrwren exactly
[20:30]  * Razva is pulling his hair
[20:30] <jrwren> so could be an iptables config issue.
[20:30] <jrwren> or proxy issue.
[20:31] <Razva> no proxies
[20:31] <jrwren> maas should act as a proxy and configure the juju nodes to use it as proxy, IIRC
[20:31] <Razva> ok, how can we check the settings on maas?
[20:32] <sarnold> Razva: I think it's time to file a bug report, you've done a fair amount of debugging..  if you followed these instructions, http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot then I'd suggest 'ubuntu-bug openstack'
[20:32] <Razva> I'm asking my colleague/tech guy to join here
[20:32] <Razva> I need to take a break, or else some PC components will suffer.
[20:33] <sarnold> good luck Razva, see ya
[20:33] <saket_> Hi Razva
[20:33] <iulianpojar> Razva: maybe you had network setup after MAAS setup? try this: sudo dpkg-reconfigure maas-cluster-controller && sudo dpkg-reconfigure maas-region-controller
[20:33] <sarnold> hey saket_ -- I just mentioned to Razva that it's probably worth filing a bug at this point -- if you followed the instructions at http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot then I'd suggest "ubuntu-bug openstack"
[20:33] <Razva> sarnold, jrwren, saket_ is my colleague/tech-guy :)
[20:34] <saket_> yes I will
[20:34] <saket_> I had configured the network and all other setup as per document
[20:34] <Razva> at this point we'll reinstall maas. AGAIN.
[20:34] <saket_> and followed instruction according to that
[20:34] <Razva> but in 5 mins, I really need to get some fresh air.
[20:34] <sarnold> Razva: go walk the dog before you lose another monitor :)
[20:42] <Razva> sooo. anti-stress ball: checked. hot milk: checked. cookies: checked. let's get back to business! :)
[20:42] <jak2013> arrrghhh done
[20:43] <sarnold> ooh cookies :)
[20:43] <Razva> sarnold aha, those with sugar on top, packaged in a round metal box!
[20:44] <sarnold> ooh those buttery ones from .nl? or that pretend to come from .nl? :)
[20:44] <Razva> these one *really* are from NL :D
[20:45] <Razva> btw sorry for my bad english, I'm not a native...
[20:45] <Razva> saket_ for how many times did we reinstalled Ubuntu in the last 3 days? I think we passed the 10 mark...?
[20:46] <sarnold> that's quite alright :) much better than my romanian.. :)
[20:46] <sarnold> lunch, good luck ;)
[20:46] <Razva> sarnold will you be back? the entire galaxy is waiting for you to come back!
[22:31] <sarnold> Razva: hmm, check those systems for dmesg entries, log entries, etc. look for something unusual
[22:45] <jeeves_moss> is there a way to turn on circular logging (like syslog) for a specific log file?
[22:47] <Razva> sarnold seems that my colleague fixed it with a BIND caching server
[23:01] <jrwren> Razva: DNS?!? huh. figures.
[23:02] <Razva> yyyyyyyyyyyup.
[23:03] <Razva> hint: DON'T remove/dismiss nodes when Autopilot is bootstraping. It will fail when providing the second node.
[23:03] <Razva> I can write a novel: the struggles of deploying Ubuntu Cloud
[23:04] <Razva> I hope that the guy who developed autopilot will at least catch a flu, for all the trouble he's causing to the world! :))
[23:05] <Razva> I'm out, cheers
[23:07] <jrwren> no way, its 1000X better than the alternative.
[23:53] <ddellav> coreycb let me know if i should delete the MIR