[01:31] <Nicolas_Leonidas> how do I stop this Enter passphrase for key '/home/foo/id_rsa' from showing up when I try to ssh?
[01:32] <escott_> Nicolas_Leonidas, don't set a passphrase on the key
[01:33] <Nicolas_Leonidas> escott, it's too late it's already there
[01:33] <Nicolas_Leonidas> but there is something that remembers ssh passphrases I just can't remember it's name
[01:33] <escott_> Nicolas_Leonidas, so make a new key
[01:33] <escott_> Nicolas_Leonidas, ssh-agent
[01:34] <Nicolas_Leonidas> yeah, can't I use ssh-agent? changing the key is difficult because the key is distributed on other servers
[01:49] <gdeeble> Hey is anyone familiar with Ser2Net in here? While it sounds retarded, I'm just trying to figure out if it's possible to have it pull the serial port of the local host, where the console log is being pushed to. For example, it's being pushed to ttyS0 in the parameters, and I want ser2net to allow me to connect to that port to capture what's going on, but this is on the same server that
[01:49] <gdeeble> it's running on.
[01:50] <patdk-lap> sure, it works great
[01:50] <patdk-lap> I use it for phonesystems and other things to make the software work over tcp/ip
[01:51] <gdeeble> In this case it covers my servers and such, but I want it to do kind of like a loop back to itself as well.
[05:36] <Gletob> I'm having an issue with two servers/init scripts not starting correctly on reboots, how can I diagnose these issues.  One is mumble-server from the repos, and the other is an init script I use for a minecraft server.
[05:59] <semcentro> I have problems to send key gnuPG to server
[06:14] <Nicolas_Leonidas> join #freelance
[08:00] <rsthelord> Hello Guys!! i am getting /install/vmlinuz error when i am booting from a usb. how do i solve the issue?
[12:26] <Guest6722> HEYO!
[12:27] <Guest6722> RoyK:  will you ping me when you have a minute?
[12:27] <RoyK> ping
[12:27] <RoyK> (one minute only)
[12:27] <Guest6722> lol
[12:27] <Guest6722> you were saying my swap was on slowest part of drive
[12:28] <RoyK> and I said never mind
[12:28] <RoyK> no, you can't move it without a lot of partitioning magick
[12:29] <LargePrime> oh.  as in never mind, this is not an issue
[12:29] <LargePrime> magic or just effort
[12:29] <RoyK> swap use will be slightly slower
[12:29] <RoyK> but then, swap is always slow, and excessive swap is a killer
[12:30] <LargePrime> yes
[12:30] <LargePrime> another minute?
[12:30] <RoyK> no - gotta go and catch a train
[12:30] <LargePrime> ok later then if you can thanks
[13:02] <zul> jamespage/yolanda: https://code.launchpad.net/~zulcss/cinder/rc2/+merge/155218
[13:06] <RoyK> LargePrime: back
[13:07] <LargePrime> missed you
[13:07] <LargePrime> short train
[13:07] <RoyK> LargePrime: no, I'm on the train ;)
[13:07] <LargePrime> ofc
[13:13] <LargePrime> any thoughts on kernals you would like to share?
[13:14] <zul> jamespage:  http://people.canonical.com/~chucks/ca/
[13:15] <LargePrime> RoyK:
[13:20] <RoyK> LargePrime: what do you mean?
[13:20] <LargePrime> I have a grsec kernel on my server, and I am thinking to replace it.  and then i find i have a bunch of options
[13:21] <LargePrime> should i just do a generic kernel?
[13:23] <RoyK> that works well for 99% of machines
[13:23] <RoyK> I haven't used a custom kernel for years
[13:24] <LargePrime> RoyK:  How would i move the swap partition?  what would i google?
[13:24] <RoyK> but if you want/need the grsec added security, then use it
[13:25] <RoyK> LargePrime: don't think about it - the easiest way is to reinstall. everything else will be very hard. also, how much swap do you really use/need?
[13:27] <RoyK> LargePrime: and if you use a lot of swap, you have too little memory
[13:27] <RoyK> LargePrime: better just forget about it. it doesn't matter!
[13:29] <RoyK> LargePrime: pastebin output of "free"
[13:33] <zul> jamespage/yolanda: https://code.launchpad.net/~zulcss/cinder/rc2-fix/+merge/155223
[13:34] <LargePrime> how do i pipe into pastebin again?
[13:34] <RoyK> !pastebinit | LargePrime
[13:38] <LargePrime> http://paste.ubuntu.com/5646361/
[13:38] <LargePrime> RoyK:
[13:39] <RoyK> ic
[13:39] <LargePrime> swap seems small
[13:40] <RoyK> it's still ~2GB free
[13:40] <RoyK> memory
[13:40] <RoyK> that is, it's not "free", but allocated as buffers/cache
[13:40] <RoyK> but that's usable for applications
[13:40] <tobin> Is the euca200ls package in the awstools-dev PPA the replacement for the ec2-api-tools ?
[13:41] <RoyK> it's swapped out a wee bit, but so long as everything runs ok, it's no reason to worry
[13:41] <jamespage> zul, cinder is still auto-generating a dependency on python-rtslib is that correct?
[13:42] <zul> jamespage:  yep
[13:42] <zul> babel as well
[13:42] <jamespage> zul, thats somewhat counter to the -0ubuntu1 changelog entry
[13:42] <zul> jamespage:  it is
[13:42] <jamespage> ??
[13:43] <zul> jamespage:  erm..
[13:44] <zul> jamespage:  im not sure where that is coming from
[13:47] <zul> jamespage:  seems to be coming from the tarball
[13:49] <zul> jamespage:  http://paste.ubuntu.com/5646390/
[13:49] <jamespage> zul, its still in pip-requires
[13:49] <zul> jamespage:  yeah
[13:50] <zul> jamespage:  lemme bug ttx
[13:50] <jamespage> zul, thats not really 'dropping the dependency' is it :-)
[13:50] <zul> jamespage:  right
[13:50] <zul> ttx: ^^^
[13:51] <ttx> o/
[13:52] <ttx> zul: rtslib still in pip-requires ?
[13:52] <ttx> awesome
[13:52] <zul> ttx: looks like it
[13:52] <ttx> zul: care to file a bug ? I'll make sure jgriffith sees it
[13:53] <zul> ttx: just checked the git tree and its not in  the tools/pip-required
[13:53] <zul> er...tools/pip-requires
[13:54] <zul> https://github.com/openstack/cinder/blob/master/tools/pip-requires
[13:54] <ttx> zul: it's in the milstone-proposed branch though
[13:54] <ttx> I suspect half backport
[13:54] <zul> ttx: it is
[13:54] <ttx> https://github.com/openstack/cinder/blob/milestone-proposed/tools/pip-requires
[13:55] <zul> ttx: ill file a bug
[13:55] <ttx> Missing backport for https://github.com/openstack/cinder/commit/7bb449aa5a0a069cc6df918acc33bf550fbd5834
[13:56] <jamespage> zul, I've +1'ed that MP
[13:56] <jamespage> guess we can fix this up with rc3
[13:56] <zul> yep yep
[13:56] <zul> ill get it fixed upstream
[13:58] <zul> ttx: https://bugs.launchpad.net/cinder/+bug/1159798
[13:59] <zul> ttx: you just cherry-pick that git hash right?
[14:00] <ttx> yeah, but would like to make sure there are no other leftovers
[14:00] <zul> ttx: ack
[14:09] <zul> hallyn_:  im going to backport that libvirt-lxc bug today
[14:10] <hallyn_> zul: which one is that?
[14:10] <zul> hallyn_:  the one that shutsdown the hose
[14:11] <hallyn_> oh yeah
[14:14] <RoyK> zul: backporting a bug or bugfix? ;)
[14:14] <zul> RoyK: bug fix
[14:15]  * RoyK thought perhaps it was a wee bit counterproductive to backport a bug
[14:15] <RoyK> zul: what bug, btw?
[14:16] <zul> RoyK:  lxc container can shut down the host due to a bug in libvirt
[14:16] <RoyK> ouch
[14:18] <hallyn_> zul: but really if /dev is shared between host and guest that's a setup bug anyway
[14:20] <RoyK> doesn's sound very secure to me
[14:20] <hallyn_> and since we don't have a /dev/initctl, i'm not sure it actually affects us...  or maybe i'm misremembering the details of the bug
[14:37] <zul> hallyn_:  anyways im building the fix now, do you want to have a look at the debdiff after?
[14:52] <zul> hallyn_:  http://paste.ubuntu.com/5646549/
[15:19] <Goranek>  /query skofo
[15:19] <Goranek> sorry
[15:26] <zul> hallyn_:  alright uploading
[15:26] <hallyn_> zul: looking :)
[15:27] <hallyn_> zul: misspelled containers int he changelog fwiw
[15:29] <hallyn_> zul: the fix is kinda silly really.  it doesn't stop the container from shutting down the host int hat case, it only tries to stop 'virsh shutdown' fromdoing it
[15:30] <zul> hallyn_:  yeah i know
[15:30] <hallyn_> but i gues the devcg stops that
[15:32] <hallyn_> but <shrug> looks good, thx :)
[15:39] <hallyn_> stgraber: what do you make of bug 1159817 ?
[15:39] <stgraber> hallyn_: I'm looking at it now
[15:40] <stgraber> hallyn_: I first thought of some pyc corruption as I've already seen that on arm, but I can reproduce it here...
[15:40] <ScottK> I'd have guessed a bytes/string issue.
[15:42] <stgraber> ScottK: so my guess is that it's blowing up on my firstname ;)
[15:43] <stgraber> but I can't explain why it does that on armhf and not on x86
[15:43] <ScottK> That is odd.
[15:43] <stgraber> hmm, actually, no, it's the C module that's failing to import
[15:44] <stgraber> python3 -c "import _lxc"
[15:50] <stgraber> hmm, I really can't find anything that'd explain thi in the code... let me try a rebuild on my panda, maybe we can just blame cosmic rays
[15:52] <hallyn_> in buildds are those build with cross compiler, or natively?  i'm assuming natively?
[15:53] <ScottK> Native.
[15:59] <stgraber> corrupted binaries aren't completely unheard of on armhf, so there's a reasonably good chance that a rebuild will fix it
[16:00] <stgraber> especially as ~alpha3 worked fine on armhf and I only added one function to the python binding which isn't even called on import...
[16:02] <hallyn_> that is...  disconcerting.
[16:02] <hallyn_> (the inherent unreliability, that is)
[16:07] <caribou> jamespage: howdy, remember last week my query about changing Suggest to Depends on nova-novncproxy
[16:07] <caribou> jamespage: looks like it triggered something bigger but then I sorta lost track of your discussion (i.e. in-flight SRU, security fixes etc)
[16:25] <jamespage> zul, hmm - I think I have a regression in libvirt with regards to live-migration with attached ceph rbd volumes
[16:25] <jamespage> appears to work OK with the 0.9.x we had in folsom CA - but not so happy in 1.0.x (I held it back in staging whilst I checked stuff in proposed)
[17:21] <boedy> Hi
[17:23] <boedy> I just rented a vps server and transfered my website to it.
[17:24] <boedy> I have the feeling curl and wget are not working properly
[17:24] <boedy> when I do a request to the facebook api. I only get partial results
[17:25] <boedy> if I run it via a proxy server I get the correct results
[17:26] <boedy> Is this a problem with the server or the source I'm fetching the data from?
[17:46] <Datz> Hi. I'm wondering how to tell whether my server needs a restart after certain updates: Can't find anything really definitive here: http://ubuntuforums.org/archive/index.php/t-1012637.html
[17:47] <Datz> Doesn't look like there would be any cause for a restart, only thing I'm wondering about is why: "linux-headers-server linux-image-server" was updated..
[17:48] <Datz> if no new kernel
[17:50] <sarnold> Datz: it's unfortunately difficult to tell when a machine needs to be restarted to apply updates -- running services will usually keep old versions of libraries loaded, for example
[17:51] <Datz> ah. I see. That's what the post seemed to indicated. It would be nice if the GUI program to tell whether a restart was needed would be available for server.
[17:51] <Datz> Thanks anyhow sarnold
[17:51] <sarnold> Datz: for libc updates, there is some magic to restart long-lived services, but not everyhting will be restarted. a reboot is the easiest way to get the new code rnning everywhere. but, of course, not all problems are so horrible that the machine needs tobe restarted to fix it -- eventually is Good Enough.
[17:51] <Datz> yea, I'm going to go with the eventual method this time :)
[17:52] <sarnold> Datz: for kernel updates, it does say "please restart". I think I've seen non-kernel updates trigger that too, but I can't recall how to make it happen :) so perhaps I'm mistaken.
[17:52] <Datz> humm, never noticed that. WHere would it say this?
[17:53] <Datz> after installation I'm guessing..
[17:55] <sarnold> Datz: I've only seen it on the happy gui updater. Dunno about servers.. that's a different ball of wax. :)
[17:55] <Datz> oh I got ya. Thanks. ;)
[17:58] <stgraber> hallyn_: so much for cosmic rays... a no change rebuild didn't fix it, so I'm now wondering what I broke in the python binding of liblxc or what changed in python that broke it :)
[17:58] <hallyn_> hm
[17:59] <hallyn_> if you install the old pkg and just copy liblxc.so.0.whatever over from the broken pkg, does that break?
[17:59] <stgraber> good question. I'll grab the alpha3 and test some combinations of liblxc+the binding module
[18:00] <stgraber> I was almost worried we woudln't have a critical bug to fix for the final 0.9 ;)
[18:00]  * hallyn_ trying to figure out why his pkg gives him empty ARCH in
[18:00] <hallyn_> /usr/bin/make -C /home/serge/z/sparc-cross-toolchain-base-1.101ubuntu1/linux-source-3.8.0 O=/home/serge/z/sparc-cross-toolchain-base-1.101ubuntu1/linux-source-3.8.0/debian/tmp-headers KERNELVERSION=3.8.0-14 INSTALL_HDR_PATH=/home/serge/z/sparc-cross-toolchain-base-1.101ubuntu1/linux-source-3.8.0/debian/tmp-headers/install SHELL="/bin/bash -e" ARCH=
[18:00] <hallyn_> stgraber: perish the thought :)
[18:01] <hallyn_> oooh, i think i see
[18:15] <stgraber> hallyn_: new liblxc + old python binding => works
[18:16] <stgraber> hallyn_: other way around doesn't but I'm using some new symbols so that was expected... I'll try to bisect my python binding changes
[19:04] <timmo> help! files are copying at 100KB/s disk to disk
[19:08] <sarnold> timmo: is that hundreds of thousands of little tiny files? has either filesystem been filled completely to capacity in the past? are there any errors in dmesg? ...
[19:10] <timmo> sarnold: each drive tested is less than 10% capacity most are freshly formatted ext4, sped is for both ntfs to ext4 and ext4 to ext4, dmesg show nmdb respawning but the rest looks fine
[19:12] <timmo> sarnold: hdparm shows all disks running @ udma 6 and buffered read speeds over 90MB/s
[19:14] <sarnold> timmo: somewhere along the way, the default IO scheduler changed from cfq to deadline -- or the other way around, I forget details -- you might want to try changing the scheduler used via /sys/devices/*/*/ata*/host*/*/*/block/*/queue/scheduler files  (ugh, hate that path. just type find /sys -name scheduler ...)
[19:15] <sarnold> timmo: I've heard some complaints from people with the new scheduler with their workloads. it might be worth cargo-cult changing it :)
[19:19] <timmo> sarnold: /sys/devices/pci..../block/sdc/queue/scheduler is noop [deadline] cfq
[19:21] <sarnold> timmo: oooh! hey, /sys/block/ has symlinks that are way friendlier. :) /sys/block/sdc/queue/scheduler ought to work too, just with less annoyance.
[19:21] <sarnold> timmo: from a root shell (e.g., sudo -s)  'echo cfq > /sys/block/sdc/queue/scheduler' -- and re-test..
[19:23] <timmo> sarnold: still at 100KB/s
[19:23] <sarnold> timmo: damn. sorry for the rabbit-hole.
[19:24] <timmo> sarnold: no worries, thanks for the thought
[19:26] <timmo> can't believe I didn't check but copying to IDE boot drive is normal speed, all SATA slow on PCI-x controller
[19:41] <sarnold> timmo: woah, odd. but at least you've got something to look for..
[20:14] <Dulcin> hi
[20:15] <Dulcin> I'm running the percona wizard for mysql my.cnf (https://tools.percona.com/wizard) and it asks which version of mysql I'm running (enterprise, community, percona, maria, other). However, is it possible that I have the 'ubuntu' version of mysql? Because looking up the version I can not determine wether I have the enterprise or community version... community sounds likely but it doesn't state so when i run mysql or look up the version in the
[20:15] <Dulcin>  database
[20:15] <Dulcin> So maybe I should choose other? Or is community the one I want anyway?
[20:16] <koolhead17> hallyn_, around
[20:16] <hallyn_> yeah
[22:18] <sliddjur> What happens when a users logs out or loses connection? What should I look into if I want to execute a script each time a user does either of those?
[22:23] <sarnold> sliddjur: that's some .. old and cranky code, involving process groups, sessions, and soforth. Advanced Programming in the Unix Environment is the best description of all those APIs, though the 'setpgrp', 'tcsetpgrp', and 'setsid' manpages do a decent job...
[22:23] <sarnold> sliddjur: you might be able to just use pam_exec to do what you want, but I wouldn't be surprised if there were conditions that it doesn't handle perfectly.
[22:25] <stgraber> hallyn_: so it looks like the problem with python3 on armhf is related to the new get_version function
[22:27] <stgraber> (I did a test build with just the new get_config_path and it's fine)
[23:17] <hallyn_> stgraber: oh, our get_version, not the python one :)
[23:21] <stgraber> hallyn_: right
[23:22] <hallyn_> _?  why _?  hm
[23:25] <hallyn> stgraber: got any idea what it might be?
[23:30] <hallyn> i susepct it's another header include snafu
[23:31] <hallyn> note there is version.h in both src/ and src/lxc/
[23:34] <stgraber> hallyn: I'm not sure yet, I'm busy with other things at the moment :( I tried a very quick check in C and it worked (using get_version from lxccontainers.h), so it may be some python weirdness.
[23:35] <hallyn> stgraber: ok
[23:36] <hallyn> (i'm going to play around later, but dinner first)
[23:38] <hallyn> lol, forgot this was on arm
[23:41] <stgraber> haha, yeah, it's armhf only, would be way too easy to debug otherwise