[00:09] <Phibs> how do I remove all partitions/LVM information during a preseed install ?
[00:23] <bekks> Phibs: by wiping the disk before installing.
[00:23] <sarnold> there's no setting for it? o_o
[00:24] <bekks> either wipe the disk or define the layout you want to have.
[00:25] <sarnold> Phibs: B.4.7 looks useful: https://www.debian.org/releases/stable/amd64/apbs04.html.en
[00:25] <bekks> thats the latter, yes.
[00:41] <Phibs> sarnold: thanks
[00:41] <Phibs> yeah, where in the preseed would i wipe
[00:42] <sarnold> Phibs: there is a preseed/early_command that might also work: https://www.debian.org/releases/stable/amd64/apbs05.html.en
[00:42] <Phibs> thanks
[01:04] <Phibs> for some reason it keeps asking me what disk to use
[01:04] <Phibs> when I specifically told it ;0
[01:04] <Phibs> http://p.bsd-unix.net/pfymj9hbe
[01:04] <Phibs> unless any of htat is wrong
[01:22] <nbastin> is there a server ISO somewhere that has a fix for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244176 ?
[01:37] <Phibs> anyone know why it is still asking me about partitioning: http://p.bsd-unix.net/pfymj9hbe
[01:43] <keee> i cannot connecte saucy to internet, no line for eth0 on 70-persistent-net.rules
[01:43] <keee> any idea?
[01:47] <sarnold> keee: check ifconfig -a to see if the interface is there; if not, check dmesg, see if you can find a module that might be needed to support the NIC
[01:53] <keee> no ethernet entry in ifconfig -a
[01:55] <keee> wait
[02:08] <keee> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[02:08] <keee> r8169 can't disable ASPM: OS doesn't have ASPM control
[02:08] <keee> r8169 irq 44 for MSI/MSI-X
[02:08] <keee> r8169 eth0: RTL8168evl/8111evl at 0xffffc90001830000, 90:b1:1c:a4:25:8d, XID 0c900800 IRQ 44
[02:08] <keee> r8169 eth0: jumbo features [frames: 9200 bytes, tx checksumming ko]
[02:11] <keee> in ther persistent-rules it doesn't show up
[09:16] <caribou> jamespage: I'm looking at the ssh_authorized_keys_b64 issue that ivoks & julian pinged you about a while ago
[09:18] <jamespage> caribou, ok
[09:19] <caribou> jamespage: the workaround they used was to force user=nova in the call?
[09:19] <jamespage> caribou, I have no idea - I can't see how that would help
[09:19] <jamespage> caribou, I think it needs a re-think on how the known hosts and ssh keys are passed around
[09:19] <jamespage> currently its a single attribute for each one of the relation
[09:20] <jamespage> quite possibly the fix is to move to a attribute for each host - one for its signature and the other for its key
[09:20] <jamespage> and then each compute host can aggregate those locally
[09:20] <jamespage> known_hosts_compute1=XXX
[09:20] <jamespage> public_key_compute1=XXX
[09:21] <jamespage> that should limit the size of the data being passed on the command line as each call can be made individually
[09:46] <caribou> jamespage: not sure how doing this will reduce the size of the known_hosts/authorized_keys if it is passed as an argument to relation_set
[09:47] <caribou> jamespage: but I'm still working at making sense of the charm...
[09:47] <jamespage> caribou, don't pass the whole file, pass fragments for each host that needs to be in it - and assemble the file on the client (nova-compute in this case)
[09:53] <jamespage> zul, https://code.launchpad.net/~james-page/neutron/vpn-fwaas-fixes/+merge/213221 when you start :-)
[09:57] <jamespage> zul, cr**p - I managed to push that direct to the branch - can you check it out? if its foobar I'll revert
[09:57] <caribou> jamespage: pardon my ignorance but I thought that compute nodes needed to be aware of all compute nodes for live migration
[09:59] <jamespage> caribou, yes - each compute node passes its key to nova-cloud-controller, and the nova-cloud-controller distributes the keys and known_hosts to all other compute nodes
[09:59] <jamespage> caribou, right now that last bit is done as a single file base64 encoded
[09:59] <jamespage> which at 80 hosts breaks
[10:00] <caribou> jamespage: ah, ok I get it, thanks for the details
[10:02] <jamespage> yolanda, thats for the grizzly nova.conf right? thats broken I think
[10:02] <jamespage> it should look like the one inthe havana conf
[10:02] <yolanda> jamespage, yes, for grizzly
[10:02] <yolanda> ok, should use same keys
[10:02] <yolanda> database_xxx
[10:03] <jamespage> yolanda, fixed
[10:04] <yolanda> thx
[11:31] <zul> jamespage:  i havent started yet but it looks fine
[12:31] <zul> jamespage:  https://code.launchpad.net/~zulcss/keystone/2014.1.rc1/+merge/213247
[12:38] <jamespage> zul, not sure the logrotate change is quite right - just checking
[12:38] <zul> jamespage:  im just adding the FFE bug number to the changelog
[12:42] <jamespage> zul, great
[12:46] <jamespage> zul http://paste.ubuntu.com/7168216/
[12:49] <zul> jamespage:  okies
[12:51] <zul> jamespage:  updated
[12:51] <jamespage> zul, looking
[12:52] <jamespage> zul, one niggle but +1 aside from that
[12:53] <zul> im pretty sure i spelled upstream right
[12:53] <zul> :)
[12:53] <jamespage> zul, tabs/spaces in logrotate
[12:54] <zul> done
[12:57] <jamespage> zul, +1
[12:57] <zul> jamespage:  just uploaded new oslo.messaging as well
[12:57] <jamespage> \o/
[12:57] <jamespage> zul, use coreycb as well - don't do them all yourself :-)
[12:57] <zul> jamespage:  so cinder should be ok as well
[12:58] <zul> jamespage:  oh i know..he will be doing the brunt of them soon enough
[12:58] <jamespage> zul, other than mongodb CA staging now in sync
[12:59] <coreycb> zul, jamespage: hey guys, I'm keeping an eye out for glance, nova and ceilometer today.  haven't seen that they're released yet.
[12:59] <jamespage> coreycb, +1 nice one
[12:59] <jamespage> zul, oh - do you want me todo horizon? I have a fixed ubuntu theme as well
[13:00] <zul> jamespage:  yes please
[13:00]  * jamespage had parked that from last week
[13:00]  * zul hates doing horizon
[13:01] <zul> ok keystone done
[13:35] <sander^work> pmatulis, I found create_table.sq for phpmyadmin inside /usr/share/doc/phpmyadmin/examples/ packed as a gz file. Thanks for pointing out the forum link!.
[13:37] <zul> Daviey:  oslo.messaging is in depwait because of python-oslotest
[13:38] <Daviey> zul: looking
[13:39] <zul> Daviey: https://launchpadlibrarian.net/171037159/buildlog_ubuntu-trusty-i386.oslo.messaging_1.3.0~a9-0ubuntu1_MANUALDEPWAIT.txt.gz
[13:45] <Daviey> zul: promoted p-oslotest, once it's published you should be good
[13:45] <zul> Daviey:  thanks
[13:47] <pmatulis> sander^work: nicely done
[13:50] <Daviey> smoser: What did you think about the distro-info idea?
[13:50] <zul> jamespage/coreycb: https://code.launchpad.net/~zulcss/cinder/2014.1.rc1/+merge/213268
[13:52] <sander^work> pmatulis, when I log into phpmyadmin.. I now see one "ok" under pmadb.. but all the others I pasted yesterday is "not ok".
[13:53] <pmatulis> sander^work: dunno, better ask the PMA guys
[13:53] <smoser> Daviey, distro-info? context ?
[13:55] <Daviey> smoser: The comment I added to curtin FFe?
[13:55] <Daviey> Storing KERNEL_VERSIONS outside of curtin?
[13:58] <smoser> oh. i'm sorry. i didn't see it. i agree that the table there sucks
[13:59] <smoser> Daviey, i think that such information woudl be good to store somewhere and disro-info is source of similar data.
[14:00] <smoser> i don't think at this point i'd want to try to shove it in elsewhere, though.
[14:00] <smoser> do you?
[14:00] <sander^work> pmatulis, Where is those?
[14:00] <sander^work> ah. in #phpmyadmin
[14:00] <Daviey> smoser: Yeah, i agree.
[14:00] <pmatulis> sander^work: in #phpmyadmin or forums or mailing lists
[14:00] <sander^work> none is responding there.
[14:02] <Daviey> smoser: Have you thought about how to update it in a timely manner as SRU?
[14:02] <Daviey> ie, it needs to be co-ordinated, right?
[14:03] <smoser> well, only kinda-sorta
[14:04] <smoser> the fallback is "do nothing"
[14:04] <smoser> and that will work fine for 14.10, 15.04, and 15.10 and even 16.04
[14:05] <smoser> the place it fails is hwe kernels.
[14:05] <smoser> so yeah, the package would have to be updated to address that.
[14:05] <smoser> but the user can in their maas update that.
[14:05] <smoser> ie, they can provide config. so its not *terrible*
[14:05] <smoser> and we can actually release the update as soon as the kernel version for a given release is known.
[14:06] <smoser> ie, as soon as kernel team says "we're using 3.15 for 14.10" we can push that curtin update.
[14:06] <smoser> the update doesn't actually *have* to happen until the hwe-u kernel for 14.04 is available.
[14:14] <Daviey> smoser: true, ok - cool
[14:39] <sarthor> Hello, using linux mint 16 32bit, Everything was working fine, since yesterday my chrome goes black, and nothing visible, where no problem with mozilla. How to fix my chrome. Please help  to guide.
[14:39] <sarthor> right one https://chromium.googlecode.com/issues/attachment?aid=1404810051000&name=chrome_black_nvidia_optimus_bug.png&token=QV2La405oXsDP0bIU2QofBsmhO8%3A1396017033249&inline=1
[14:39] <cfhowlett> !mint|sarthor, not supported here
[14:40] <sarthor> ubottu: Ohh. i was writing there in mint chan, but after the channel ubuntu-server logged in, cursor automatically came here. Sorry.
[14:41] <sarthor> hehe. I am having locked mind, so how can i think.
[14:42] <patdk-wk> explains a lot
[15:01] <RoyK> any idea how I can find how much memory the whole of apache processes are *actually* using? Adding the ps axv col 8 numbers doesn't make sense since a lot is shared during forking
[15:03] <DeltaHeavy> RoyK: Run 'htop' on your server. If it's not installed install it or alternativly just run 'top'. I think you can also run 'ps -aux | grep -i apache | grep -v grep'
[15:03] <DeltaHeavy> There will be multiple processes, you'll need to add them al up.
[15:04] <DeltaHeavy> Oh wait you already said you used 'ps'. I'm pretty sure you still add them all up. Each of those processes can have multiple workers in them still.
[15:05] <RoyK> no, using prefork with php
[15:05] <RoyK> not worker
[15:06] <RoyK> but if process x allocates 100MB and writes to it and then fork()s, the data won't be copied until it's written to, but still, both processes with show up in ps (or top or htop or...) with the same amount of "allocated" memory
[15:06] <DeltaHeavy> Regardless, what 'ps' is giving you is all the memory being used by Apache. If you're expecting a different result I'd look at your Apache configuration before 'ps' or 'top'
[15:07] <RoyK> what?
[15:07]  * RoyK gives up
[15:07] <DeltaHeavy> What 'ps' is giving you is what's being used.
[15:08] <DeltaHeavy> RoyK: "Prefork MPM uses multiple child processes with one thread each and each process handles one connection at a time." - http://stackoverflow.com/questions/13883646/apache-prefork-vs-worker-mpm
[15:08] <RoyK> I know
[15:08] <DeltaHeavy> RoyK: So yeah, you're going to see a bunch of threads for Apache in prefork mode, and it's not surprizing at all that they all have the same amoutn of allocated memory. What's the problem here exactly?
[15:08] <DeltaHeavy> Each thread needs it's own allocated amount of memory.
[15:08] <RoyK> it doesn't work like that. read what I wrote above
[15:09] <DeltaHeavy> By process 'x' do you mean the parent Apache process or it's children worker threads?
[15:10] <DeltaHeavy> Not worker, but children threads*
[15:10] <RoyK> no threads, child processes
[15:11] <RoyK> I mean any process. if a process allocates xMB memory and forks, very little new memory is used, but both are reportedly using the same amount of memory
[15:12] <DeltaHeavy> When Apache makes child processes in prefork mode , those child proceses have everything that's needed to serve up a request. They're going to be the same size most of the time, if not all the time. Theo only process that'll have a different amoutn of memory maybe is the parent Apache process. It sounds like it's working as it should.
[15:13] <DeltaHeavy> You can try asking in #httpd, but I think they'll tell you the same thing.
[15:13] <RoyK> heh - no, they won't
[15:13] <RoyK> the thing is, a lot is shared
[15:14] <RoyK> and adding up the memory "used" by the apache processes (and other processes) gives me a number twice the total amount of memory actually allocated
[15:14] <DeltaHeavy> Maybe I'm wrong but that's how I remember it. I used used to be pretty through and through solid in Apache but I'm using Nginx these days.
[15:14] <RoyK> hence the initial question
[15:14] <DeltaHeavy> If anything's wrong it's you Apache conf I'd think
[15:14] <RoyK> and this is not an apache question, it's about anything that forks
[15:14]  * RoyK really gives up
[16:17] <tcstar> I am running ubuntu 12.04 on 4 web servers with a lot of different websites on them...  What are the best practices in mirroring a server, not just the files but the virtual host configurations as well, if any?
[16:18] <DeltaHeavy> tcollins: Are there 4, individual web servers, or are you using vhosts? Nginx? Apache?
[16:20] <rbasak> tcstar: step by step, first I'd switch to managing virtual host configurations with a configuration management tool
[16:23] <tcstar> All are running Apache...  @rbasak I didn't know of any config management tools I could install so I've been doing it all manually
[16:24] <tcstar> I did create a bash script to create the configuration file, the folder, and set the right permissions though...  don't have any of the FTP stuff as I deploy using git so no user accounts per website either
[16:27] <DeltaHeavy> FTP shouldn't be used even if you're not using git IMO. SFTP/FTPS if you are going to go that sort of route.
[16:28] <tcstar> yeah, by ftp i mean i have no ftp server installed ( i'm guessing that includes ftps - but since that's ftp over ssh i could be wrong )
[16:30] <DeltaHeavy> SFTP is FTP via SSH. FTPS is FTP via SSL.
[16:30] <zul> smb: ping where is it again?
[16:36] <smb> zul, Either in my ppa or on chinstrap...
[16:36] <zul> smb:  cool thanks
[17:02] <zul> smb:  uploaded
[17:10] <Phibs> does anyone here use preseed, have an issue where it won't stop asking me about disk config even though I told it whole disk, sda
[17:10] <Phibs> with precise
[17:13] <DeltaHeavy> Hey, anybody know why these lines added to '/etc/ssh/sshd_config' make it so SSH refuses all connections? http://paste.ubuntu.com/7169485/
[17:13] <DeltaHeavy> I'm on 12.04
[17:19] <TJ-> DeltaHeavy: Have they broken the config such that the sshd hasn't started?
[17:19] <DeltaHeavy> TJ-: It seems to start fine, let me double check though.
[17:20] <DeltaHeavy> TJ-: When I restart the service it seems to be fine, but 'service ssh status' returns this - ssh stop/waiting
[17:20] <DeltaHeavy> When those lines aren't there it's - ssh start/running, process 26306
[17:21] <TJ-> DeltaHeavy: I think you're breaking the config so sshd fails. Check the log-files.
[17:22] <TJ-> DeltaHeavy: "man sshd" ... "sshd -T" == test mode
[17:23] <DeltaHeavy> I know about man pages but I do'nt really think they're the best resource for this. I'll look into sshd -T though
[17:24] <TJ-> DeltaHeavy: My first stop is the man pages; that's how I just got "-T" for you
[17:28] <DeltaHeavy> TJ-: Ah, thanks :p thought you were telling me to RTFM
[17:30] <DeltaHeavy> 'sshd -T' returns "/etc/ssh/sshd_config line 93: Directive 'UsePAM' is not allowed within a Match block". These are the last 9 lines (sans comments) of my sshd_conf - http://paste.ubuntu.com/7169570/
[17:30] <TJ-> DeltaHeavy: I was! Like I said, it's my first step whenever I'm not sure - most daemons with complex configuration syntaxes have a 'test' option
[17:30] <TJ-> DeltaHeavy: there you go :)
[17:30] <DeltaHeavy> Can probalby figure it out from here
[17:31] <DeltaHeavy> True, often I'l lbe told to RTFM when it really doesn't make sense so I'm kind of weary when people suggest man pages lol. But yeah, that was a good case.
[17:32] <TJ-> DeltaHeavy: I think the applicable lines (from "man sshd_config"!) are "Match ... until either another Match line or the end of the file...."
[17:33] <DeltaHeavy> Damn, guess it really does need to be at the end of the file. Thanks, Ill try that now
[17:36] <DeltaHeavy> Yep, it worked
[17:36] <DeltaHeavy> Thanks!
[17:36] <TJ-> :) Thank the man-pages ;P
[17:36] <DeltaHeavy> lol
[18:05] <rbasak> zul: do you mind sponsoring https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1298273 for me please? Turns out I can't upload apache2 to precise (though I can to trusty).
[18:05] <rbasak> I've tested everything and it's good to go.
[18:09] <zul> rbasak: sure
[18:16] <zul> rbasak:  done
[18:24] <DeltaHeavy> So, I have a user with restricted SSH access as to only allow SFTP. I have it set up in '/home/sublime/' with a symlink to '/srv/nginx/'. The user 'sublime' is a part of the group 'sftp' and the premissions on /srv/nginx/ are recersivly owned by 'matt' and the group 'sftp' as I want the user 'sublime' and anybody else belonging to the 'sftp' group to be able to read and write to any file in there. I have some folders/files that need
[18:24] <DeltaHeavy> to be a part of the 'www-data' group so some applications ran by the web server can write data to caches and all that. How do I allow some folders to be read and writable to only the owner, and BOTH of the groups 'sftp' and 'www-data'?
[18:25] <DeltaHeavy> I'm on 12.04
[18:27] <TJ-> DeltaHeavy: "man 5 acl" You'll need Access Control Lists, using {set,get}facl
[18:27] <DeltaHeavy> Ok, thanks. Was hoping I could do this without acl.
[18:28] <TJ-> DeltaHeavy: I can't think of how, unless you add the www-data user to the sftp group, but that might have unexpected side-effects
[18:29] <DeltaHeavy> Yeah, I think I might just make it so users in the sftp group just won't be able to read/write any files belonging to www-data. Maybe in the future I'll need to fix that but I doubt it as it's just cache files right now.
[18:41] <lordievader> Good evening.
[19:08] <DeltaHeavy> Is it best to put mounts like these in fstab: mount /out/side /chroot/point_to_outside -o bind
[19:09] <DeltaHeavy> Basically to escape a chroot jail
[19:18]  * RoyK mutters something about *real* virtualisation
[19:20] <stgraber> DeltaHeavy: or you can just access the outside through /proc/1/root
[19:21] <DeltaHeavy> stgraber: But they're chrooted. How can they access /proc/ ?
[19:22] <stgraber> so you don't have /proc mounted in your chroot?
[19:22] <DeltaHeavy> No, why would I do that?
[19:23] <stgraber> well, depends on the service, but it's not entirely unheard of for stuff to access /proc/self or /dev/fd and similar which will fail if you don't. Though if it's the service itself doing the chroot call, then the author probably made sure that won't be the case.
[19:24] <DeltaHeavy> stgraber: I'm doing this to limit what a user logging in via SFTP will be able to do.
[19:24] <sarnold> do not confuse chroot with a security mechanism.
[19:24] <DeltaHeavy> Really it's for connections made by my IDE that stores my password in plain text. It was using the main account before so I made an SFTP only account.
[19:25] <DeltaHeavy> sarnold: Am I doing something wrong?
[19:27] <sarnold> DeltaHeavy: chroot may be a convenient-ish way to try to reduce the scope of a program run amok, but chroot only changes filesystem's "root". the process can still do dbus things or ptrace things or shared memory things or whatever else to "escape" the chroot
[19:27] <DeltaHeavy> sarnold: Yeah, anybody looking into the chroot won't have shell access, they're only able to log in via SFTP.
[19:27] <DeltaHeavy> The chroot ensures they're only browsing the files I think they're browsing.
[19:27] <sarnold> DeltaHeavy: fair enough, openssh folks have probably put effort into that. :)
[19:28] <RoyK> DeltaHeavy: well, what if that php script or something had an exploit? (;
[19:28] <DeltaHeavy> RoyK: Yep, that's one thing they could do.
[19:29] <RoyK> best way to secure a server is always the simple way
[19:29] <DeltaHeavy> So what are you suggesting?
[19:29] <RoyK> turn it off and lower it into the mariana trench
[19:29] <DeltaHeavy> lol
[19:29] <RoyK> quite secure
[19:30] <DeltaHeavy> Yeah, can't ensure anything will be 100% secure. The gaping security hole I was trying to fix was a bunch of JSON files littered around my filesystem on my local Windows (ew) computer, that had my password in plain text
[19:30] <DeltaHeavy> A password for an account with full sudo privileges.
[19:31] <DeltaHeavy> Usually I don't even use SFTP anyway but for some projects I do.
[19:31] <RoyK> DeltaHeavy: sounds very secure indeed!
[19:31] <DeltaHeavy> Now all they can do is fuck up what I mount inside that chroot, so =/
[19:32] <RoyK> DeltaHeavy: why not kvm virt or something?
[19:32] <DeltaHeavy> Also, back to my original question. Would a bunch of lines like this under a descriptive comment in my /etc/fstab be the best way to allow people in that chroot to access the data in a web server's document root? - /srv/nginx/silvercreekit.com    /home/sublime/silvercreekit.com auto    bind    0   0
[19:33] <DeltaHeavy> RoyK: How would a VM solve anything?
[19:33] <RoyK> DeltaHeavy: it'll separate things better
[19:33] <DeltaHeavy> They're editing the same things though :p
[19:33] <RoyK> different kernel, different system
[19:33] <DeltaHeavy> This is already a VM
[19:33] <DeltaHeavy> It's a VPS
[19:33] <RoyK> it won't help much for whatever's on the web
[19:33] <RoyK> ah - ok
[19:34] <DeltaHeavy> I'm basically just trying to make it so if somebody finds my password that's littered all over my desktop PC they can fuck up as little as possible
[19:34]  * RoyK generally uses his own physical machines for VMs
[19:34] <DeltaHeavy> Being the projects I specifically use SFTP for.
[19:34] <RoyK> sftp/scp/sshfs is generally secure
[19:35] <DeltaHeavy> Eh, using your own machines for web hosting specifically ain't the greatest idea.
[19:35] <RoyK> DeltaHeavy: not hosting anything but my own stuff
[19:35] <DeltaHeavy> Yeah, I usually use 'git' though.
[19:35] <DeltaHeavy> Yeah, that's a good solution then.
[19:35] <DeltaHeavy> So again, is this in my /etc/fstab a good or a bad idea? - /srv/nginx/silvercreekit.com    /home/sublime/silvercreekit.com auto    bind    0   0
[19:36] <sarnold> DeltaHeavy: why not use ssh keys? :)
[19:36] <DeltaHeavy> sarnold: The plugin for Sublime Text doesn't allow that...and I'm on Windows
[19:36] <sarnold> DeltaHeavy: aww. :/
[19:36] <DeltaHeavy> Don't feel like dropping $3'000 on a Mac right now.
[21:18] <tasslehoff> Is it common sense to stay on LTS for a server?
[21:21] <sarnold> tasslehoff: it's quite popular, yes; people don't want to have to upgrade their servers every six or seven months
[21:21] <sarnold> tasslehoff: most people just want to set something up, set up some monitoring and backups, and then leave it alone for two or three years -- and either consider upgrading to the next LTS or skip an LTS release, depending upon what makes most sense
[21:23] <tasslehoff> sarnold: I'm a trigger happy upgrader, but I've managed to keep my server at 12.04. Now I am pondering how to get a newer version of Plex :)
[21:23] <tasslehoff> I guess waiting for 14.04 release and add a couple of weeks is the smart thing to do
[21:24] <sarnold> tasslehoff: hrm, I don't immediately spot plex in our archives
[21:24] <sarnold> tasslehoff: you may be able to upgrade plex separate from the rest of the system
[21:25] <tasslehoff> sarnold: I have a ppa, but it hasn't gotten any updates lately
[21:25] <sarnold> tasslehoff: on th eother hand, if you have fun upgrading and like fiddling with things, that does make you an ideal candidate for upgrading to 14.04 before release, and filing bugs along the way >:->
[21:26] <tasslehoff> sarnold: perhaps. I'll wait until tomorrow, when the whiskey is not doing the talking ;)
[21:26] <sarnold> tasslehoff: (honestly though, up to you, do whatever you like.. :)
[21:26] <sarnold> good plan :)
[22:33] <rbasak> zul: thanks!
[23:07] <Phibs> installing precise LTS, I'm setting the gateway but it is not adding it to /etc/network/interfaces, anyone know why?
[23:07] <Phibs> it adds the ip/netmask/mac....
[23:09] <Phibs> d-i netcfg/get_gateway string 10.119.226.97
[23:11] <sarnold> hrm, looks just like the example from http://d-i.alioth.debian.org/manual/example-preseed.txt
[23:49] <Phibs> lol @ the 375 worthless people in here