[00:25] <Icar> r the servers down ?
[00:33] <iflymyhelishigh> hellooo
[00:40] <Aw0L> are there major differences in packages between the 6month release of Ubuntu server and LTS?
[00:41] <iflymyhelishigh> Probably not, but its a good idea to install it anyway
[00:41] <iflymyhelishigh> newest version is the best
[00:42] <iflymyhelishigh> I'm trying to install VHCS through apt-get
[00:42] <iflymyhelishigh> but its giving me predepends errors
[00:42] <Aw0L> iflymyhelishigh: you mean installing LTS instead of the 6mo release?
[00:42] <iflymyhelishigh> whichever one is the newest
[00:51] <uvirtbot`> New bug: #453599 in whois (main) "Catastrophic error while querying a .biz domain with -H flag" [Undecided,New] https://launchpad.net/bugs/453599
[02:29] <VousDeux> It would appear that I broke slapd while trying to setup TLS. I've tried 'aptitude --purge remove slapd' but it doesn't appear to remove everything. How do I rid myself completely of slapd so I can install clean?
[02:46] <VousDeux> Uh-oh...I think I did a dumb-dumb. A document I found said to delete /etc/default/slapd (which I did), but I also deleted some slapd related files from /var/backup. I reinstalled slapd and It seems to be working now, but it did not recreate the /etc/default/slapd. I have no idea what it was for.
[03:04] <pmatulis> VousDeux: 'sudo aptitude purge slapd' should have done the trick
[03:05] <VousDeux> I had to delete files from /var/backup...then it worked, but now I'm missing the /etc/default/slapd file and I'm not sure how to replace it.
[03:15] <pmatulis> VousDeux: what version of ubuntu?
[03:44] <VousDeux> 9.04
[03:44] <VousDeux> Sorry...I was collecting end-of-day market data. Thanks for your help.
[03:58] <pmatulis> VousDeux: reinstalling slapd should have given you that file
[04:00] <VousDeux> That's what I would have thought too, but it didn't. I guess I'm not sure it's needed with the cn=config.
[04:01] <pmatulis> VousDeux: anyway, this is /etc/default/slapd for jaunty -> http://pastebin.com/f3fc0be8d
[04:01] <VousDeux> On the other hand, how did it get there in the first place.
[04:01] <VousDeux> Awesome, thanks!
[04:02] <pmatulis> VousDeux: using 'apt-file find /etc/default/slapd' gives 'slapd' as package
[04:03] <VousDeux> I sure don't know why it wasn't installed...I tried twice.
[04:03] <pmatulis> VousDeux: you should also be able to download the slapd source package and find that file
[04:04] <VousDeux> I've also seen that the slapd install only executed the --configure the first time I install it. After that it doesn't execute anymore even if I do a --purge.
[04:04] <VousDeux> Ahhh...that's a good idea.
[04:04] <VousDeux> Thanks again!
[04:05] <pmatulis> VousDeux: yes, 'apt-get source slapd'
[04:06] <VousDeux> Maybe someday I'll know some of these tips and tricks too :)
[04:06] <pmatulis> VousDeux: you could try 'dpkg-reconfigure slapd'
[04:07] <VousDeux> ...but for now I've spent the last three weeks on trying to figure this thing out and really don't have anything to show for it.
[04:07] <edulacomadreja> does anyone have an idea for this http://serverfault.com/questions/75430/netcat-connection-refused-on-localhost ?
[04:07] <pmatulis> VousDeux: ldap is hard to learn
[04:07] <VousDeux> Yeah, that dpkg-reconfigure slapd is what I do, but it's supposed to execute --configure when it's installed.
[04:08] <VousDeux> Yeah, and that manual is pretty dry reading too.
[04:12] <VousDeux> goodnight...thanks again
[04:13] <pmatulis> VousDeux: bye
[06:51] <Exuro> Can anybody help me change the port ISPConfig listens on?
[06:51] <Exuro> when I set my router to forward port 80 to my webserver, it changes the router admin port to 8080
[06:51] <Exuro> the port ISP config listens on
[09:06] <uvirtbot`> New bug: #365832 in whois (main) "whois command result Timeout" [Undecided,Fix released] https://launchpad.net/bugs/365832
[09:40] <uvirtbot`> New bug: #375569 in samba (main) "gnome-screensaver failure - can't access samba password database - not running as root " [Low,Won't fix] https://launchpad.net/bugs/375569
[10:39] <Bilge> How can I see which ports UDP packets are coming in on?
[10:46] <TeLLuS> tcpdump or iftop -P
[13:56] <Bilge> Thanks TeLLuS
[13:57] <Bilge> How can I stop ufw spamming my syslog?
[13:57] <jdstrand> Bilge: sudo ufw logging off
[13:58] <Bilge> No, I want to see the logs
[13:58] <Bilge> Just not in my syslog
[13:58] <jdstrand> Bilge: iptables/netfilter on linux logs to kern.log
[13:58] <Bilge> I don't know what that means
[13:59] <Bilge> What is netfilter?
[13:59] <jdstrand> Bilge: it means there is not a way to log ufw/iptables messages somewhere else, other through through the normal /etc/syslog.conf mechanism
[14:00] <jdstrand> Bilge: they are kernel messages
[14:00] <Bilge> Why wouldn't I want to use the normal syslog.conf mechanism?
[14:00] <Bilge> Or did you just assume I was already familiar with it
[14:01] <jdstrand> Bilge: netfilter is the name of the implementation for filtering packets on linux. iptables is the command to interface with netfilter in the kernel. ufw is an abstraction over iptables to make firewalling easier to use
[14:02] <jdstrand> Bilge: your question was 'How can I stop ufw spamming my syslog?' My answer is that you can't 'stop it' other than by using syslog.conf
[14:02] <Bilge> I want to use syslog.conf to reroute the messages to another log file
[14:02] <jdstrand> Bilge: you can reduce what is logged by using explicit deny rules in ufw
[14:03] <Bilge> Can I do that?
[14:03] <jdstrand> Bilge: then see 'man syslog.conf' or on 9.10 'man rsyslog.conf'. These are kern.* messages
[14:04] <Bilge> Yeah I'll be sure to check out the manual if I know I'm going down the right path
[14:04] <jdstrand> these messages logged with the kern facility. that can be 'rerouted' however you want via syslog.conf
[14:05] <Bilge> But is kern.* any message generated in the kernel?
[14:05] <jdstrand> yes
[14:06] <Bilge> Well I would want to see kernel messages in my syslog, just not UFW blocks
[14:06] <Bilge> I'm not really sure why that is tied into the kernel
[14:06] <jdstrand> Bilge: that is what I'm saying. there is not a way to do that
[14:06] <jdstrand> Bilge: because it isn't 'ufw' that is blocking the packets, it is the kernel. ufw is just a way to tell the kernel what to block
[14:06] <Bilge> I might understand if these were netfilter messages but they are tagged with UFW and I would not expect iptables nor netfilter to know or care about the existence of ufw
[14:07] <jdstrand> Bilge: ufw is a frontend to iptables, and iptables is the command used to manipulate netfilter
[14:07] <Bilge> Which I understand
[14:08] <Bilge> So if I see messages in my syslog tagged with ufw then it must be generated by ufw directly, I would think
[14:08] <jdstrand> Bilge: the messages are tagged with UFW so you now that a) ufw is doing the blocking and b) you can add rules to adjust this with ufw
[14:09] <Bilge> Why can't ufw generate log messages that are not tied into kern.*
[14:09] <jdstrand> Bilge: depending on the version of ufw you are using, you can do various things with logging (or not logging) packets with ufw. see 'man ufw'
[14:09] <jdstrand> Bilge: because ufw isn't blocking the packets. the kernel is
[14:09] <jdstrand> Bilge: ufw is just a command to tell the kernel what to do
[14:09] <Bilge> Yet you can still turn that logging off with ufw logging off?
[14:10] <jdstrand> Bilge: of course. ufw logging off tells the kernel to not log packets
[14:10] <Bilge> So ideally you would turn kernel logging off and a separate ufw logging loop on
[14:10] <jdstrand> Bilge: there isn't a way to tell the kernel to log packets, but not use the kern facility
[14:10] <Bilge> Except that such a logging style does not exist
[14:11] <Bilge> This seems like a shortcoming of the implementation to me
[14:11] <Bilge> I'll just have to turn the logging off altogether because I am using the earliest version in 8.04
[14:11] <jdstrand> if it is a shortcoming, it is of the linux kernel
[14:12] <Bilge> If it were me, I'd have ufw do its own logging
[14:12] <Bilge> If I wanted it to appear in my syslog I could route it there myself
[14:12] <qman__> that's simply not possible due to the way the kernel and netfilter work
[14:13] <jdstrand> Bilge: the kernel does the logging. there isn't anything ufw can do about that
[14:13] <Bilge> qman__: you mean ufw can't see what is blocked?
[14:13] <qman__> no, it can't
[14:13] <Bilge> I see
[14:13] <Bilge> Well that is a pity
[14:13] <qman__> ufw simply configures netfilter
[14:13] <qman__> netfilter handles all of that, including packet logs
[14:13] <Bilge> So it is too high level to do its own logging
[14:13] <qman__> yes
[14:14] <Bilge> But netfilter is still before the kernel and it can see it
[14:14] <jdstrand> Bilge: that isn't a limitation of ufw, it is of all firewall frontends on linux
[14:14] <qman__> netfilter is _in_ the kernel
[14:14] <qman__> so, it's logged through the kernel
[14:14] <qman__> you can use syslog to organize the messages
[14:15] <jdstrand> Bilge: it sounds like you may want to add a specific deny rule to reduce 'spam' in your logs
[14:15] <Bilge> No, I don't want to change the way I use my firewall to influence logging output
[14:16] <jdstrand> well that is fine. but it is an option to turning it off completely
[14:16] <jdstrand> for example, I use:
[14:16] <Bilge> Are you suggesting that instead of deny by default I should allow by default
[14:16] <qman__> no
[14:16] <Bilge> Because that is a completely different approach
[14:16] <jdstrand> sudo ufw deny to 192.168.2.255 port 631
[14:16] <qman__> that you should deny by default AND use a specific deny rule to prevent most of the packets from hitting the default deny
[14:16] <jdstrand> Bilge: not at all
[14:17] <qman__> more specifically, use explicit deny rules for what you don't want logged
[14:17] <Bilge> Are only default denies logged?
[14:17] <jdstrand> Bilge: deny by default. then add your allow rules, then add a deny rule for packets you don't want logged
[14:17] <jdstrand> Bilge: in 8.04 LTS, yes
[14:17] <jdstrand> Bilge: well, anything against your default policy
[14:17] <Bilge> Unfortunately I can't do that because the ones that are logged are all over the place
[14:17] <jdstrand> which is in your case, deny
[14:17] <Bilge> They're just people spamming every imaginable port and IP trying to gain access
[14:18] <Bilge> So I have just turned it off now
[14:18] <Bilge> I need to be able to see clearly the things that matter in my syslog
[14:18] <jdstrand> Bilge: then it is an administrative decision of whether you want to monitor those denials. it sounds like you don't and 'ufw logging off' is suitable
[14:18] <Bilge> It should be suitable, yes, but my preference, were it trivial, would have been to just reroute them instead
[14:19] <qman__> you can change what gets logged to which files in syslog configuration
[14:19] <Bilge> So that if I ever had issues I could grep something relevant out of it
[14:19] <Bilge> qman__: yes, we started off with that, but save for firewall blocks, kernel messages generally ARE important and SHOULD appear in my syslog!
[14:20] <qman__> yes, but you can get more specific than just all kernel messages
[14:21] <Bilge> Specific enough to filter only firewall messages?
[14:21] <Bilge> I don't know how you know what the type of message is called
[14:22] <Bilge> For example jdstrand said that kernel messages are of type kern.* but I don't know how you're meant to know this
[14:23] <qman__> well, unfortunately you can only filter by log level, so you'd have to find out what level ufw is configuring it to use, and filter that level out into a different file
[14:24] <qman__> and there would be no guarantee that no other messages would be caught, hopefully they chose a level with little else
[14:26] <qman__> rsyslog contains functionality you could use to pull out the ufw messages specifically
[14:26] <qman__> but I don't think the one on 8.04 does
[14:27] <jdstrand> qman__: I was not aware of that functionality in rsylog. I've made a note of it to look at it in the future
[14:34] <Bilge> jdstrand: do you have something to do with the development of ufw?
[14:36] <jdstrand> Bilge: yes
[14:36] <jdstrand> Bilge: I am the author
[14:36] <Bilge> Haha oh wow
[14:37] <Bilge> By the way, wasn't it yourself that helped me out with replacing my kernel with the stock Ubuntu kernel?
[14:37] <jdstrand> I don't recall. possibly
[14:38] <Bilge> Well someone suggested I install linux-image-server and edit my boot conf
[14:38] <jdstrand> oh. I don't think that was me
[14:38] <Bilge> OK
[14:38] <Bilge> Well it worked anyway
[14:38] <Bilge> Might have been jmarsden, there's a lot of j names that I get confused by
[14:39] <jdstrand> maintaining one's own kernel outside of Ubuntu packaging is a maintenance headache I would advise only in the most extreme circumstances
[14:39] <Bilge> I was doing the reverse
[14:39] <Bilge> Restoring the stock kernel
[14:39] <Bilge> My provider forces a modified kernel without modules support onto customers
[14:39] <Bilge> Because it is patched with grsec and some other patches that they think are good
[14:40] <jdstrand> ah. I misunderstood. still doesn't sound familiar, but glad to hear the Ubuntu kernel is working for you
[14:40] <Bilge> Well it does work but if I lock myself out of the box and have to do a remote recovery they I have to use one of their kernels again and depending on how much functionality I am relying on from the Ubuntu kernel, things can get into a mess
[14:40] <Bilge> So the key is not to lock yourself out of the box ;p
[14:41] <jdstrand> hehe
[14:41] <Bilge> So about ufw
[14:41] <Bilge> I like that I can do allow port/protocol
[14:41] <Bilge> But why can't I do allow to address port/protocol
[14:42] <jdstrand> sure you can
[14:42] <Bilge> No, I mean in that format
[14:42] <jdstrand> you just need the extended syntax
[14:42] <jdstrand> oh
[14:42] <Bilge> The syntax suddenly becomes so much more verbose
[14:42] <Bilge> I don't really see the benefit of having to type really long commands
[14:42] <jdstrand> you don't need to specify everything when using the extended syntax
[14:42] <Bilge> No, I realise that
[14:42] <Bilge> But I can't use the port/protocol format any more
[14:43] <jdstrand> that's true
[14:43] <Bilge> In fact I'd really like to be able to do address:port/protocol
[14:43] <jdstrand> the extended syntax is based on OpenBSD's PF
[14:43] <Bilge> Another problem I have is that I created a rule to permit all udp inbound traffic
[14:44] <Bilge> ufw allow proto udp from any
[14:44] <Bilge> But in my udp status, this shows up as:
[14:44] <Bilge> Anywhere                   ALLOW   Anywhere
[14:44] <Bilge> I have absolutely no way of knowing that's only allowing udp traffic
[14:44] <Bilge> But fortunately it does at least work as intended
[14:45] <Bilge> I can see that it is set up correctly only by viewing iptables -L or /var/lib/ufw/rules
[14:45] <jdstrand> Bilge: that is fixed in a later release
[14:45] <jdstrand> $ sudo ufw status
[14:45] <jdstrand> ...
[14:45] <jdstrand> Anywhere/udp               ALLOW       Anywhere/udp
[14:45] <Bilge> Is it possible for me to install a newer ufw on 8.04 without messing things up?
[14:46] <jdstrand> Bilge: yes, but newer versions need iptables 1.4 for certain functionality
[14:46] <Bilge> OK but if it finds iptables is not high enough will the other things still work properly
[14:46] <Bilge> I mean does it degrade gracefully
[14:46] <jdstrand> Bilge: ufw will still work and simply tell you that the functionality is not available
[14:47] <Bilge> OK, that sounds good
[14:47] <Bilge> So how would I actually get it?
[14:47] <jdstrand> Bilge: that is the trick
[14:47] <jdstrand> you see, there are tests included in the sources
[14:48] <jdstrand> those tests fail with iptables 1.2 (as in hardy)
[14:48] <Bilge> I have 1.3.8
[14:48] <jdstrand> the ubuntu packaging aborts the build if the tests fail
[14:48] <jdstrand> (ah right, forgot, 1.3.8 in hardy, same problem though)
[14:49] <Bilge> Well yes it is still pre 1.4
[14:49] <Bilge> Maybe I could even upgrade iptables as well?
[14:49] <jdstrand> so you have to build with 'DEB_BUILD_OPTIONS=nocheck'
[14:49] <jdstrand> I do not recommend upgrading iptables on a hardy machine. it is very involved and error prone
[14:49] <Bilge> I feared as much
[14:50] <jdstrand> it has been long on my todo list to better support iptables 1.3 in the test suite
[14:50] <jdstrand> all that said, it is not hard to build your own package:
[14:50] <jdstrand> $ sudo apt-get build-dep ufw
[14:50] <jdstrand> $ sudo apt-get source ufw=0.29-4ubuntu1
[14:51] <jdstrand> $ cd ./ufw-0.29
[14:51] <jdstrand> $ DEB_BUILD_OPTIONS=nocheck debuild
[14:51] <jdstrand> of course, you'll need the 9.10 deb-src lines in sources.list for 'apt-get source' to work
[14:52] <Bilge> I can get them
[14:52] <jdstrand> one of these days, I am going to fix the shortcoming in the test suite so that ufw can be built more easily in hardy-backports
[14:52] <Bilge> Can I append them or do I need to replace existing lines
[14:52] <jdstrand> actually, the packaging will also need to be adjusted
[14:53] <jdstrand> before the debuild, you'll need to adjust debian/control from:
[14:54] <jdstrand> Depends: debconf, ${python:Depends}, ${misc:Depends}, iptables (>= 1.4.0), ucf
[14:54] <jdstrand> to
[14:54] <jdstrand> Depends: debconf, ${python:Depends}, ${misc:Depends}, ucf
[14:55] <jdstrand> Bilge: I also haven't tested the upstart stuff on hardy
[14:55] <jdstrand> Bilge: you may want the version in jaunty instead
[14:55] <Bilge> I don't know what upstart is
[14:56] <jdstrand> Bilge: upstart is a replacement for sysv init that is used on Ubuntu
[14:56] <jdstrand> Bilge: ufw in 9.10 uses it
[14:56] <jdstrand> ufw in 9.04 and earlier uses sysvinit
[14:56] <Bilge> Oh good, a replacement
[14:57] <Bilge> That sysv stuff did seem a bit crappy
[14:57] <jdstrand> upstart has been in Ubuntu for many, many releases
[14:57] <jdstrand> but only lately has it been a priority to get other services to use it
[14:57] <jdstrand> it has to do with the boot performance enhancements in 9.10
[14:58] <jdstrand> you could fiddle with debian/rules to not use upstart and build ufw without it
[14:58] <Bilge> I look forward to upgrading my distroy when the new LTS arrives next year
[14:58] <Bilge> distro*
[14:58] <jdstrand> but if you aren't comfortable with that, then just use the 9.04 version
[14:59] <Bilge> Do you recall if the 9.04 version fixes the bug I mentioned in ufw status?
[14:59]  * jdstrand adds to his todo list to look at ufw backporting on hardy again
[14:59] <jdstrand> ufw (0.23) intrepid; urgency=low
[14:59] <jdstrand> * show protocol in status when no ports are specified (LP: #263308)
[14:59] <Bilge> For allowing all inbound udp
[14:59] <Bilge> OK so I could even use 8.10
[15:00] <jdstrand> yes
[15:00] <jdstrand> I have to go now though
[15:00] <jdstrand> have fun and good luck!
[15:00] <Bilge> Thanks for your help and time
[15:00] <Bilge> Can I publish the steps on a blog or something?
[15:00] <jdstrand> sure
[15:00] <Bilge> I look forward to the backport
[15:00] <jdstrand> please put appropriate warnings in place and that it isn't officially supported
[15:01] <Bilge> Of course
[15:01] <jdstrand> well, I would support it as an upstream, but not in Ubuntu
[15:02] <jdstrand> I am definitely interested in bugs in ufw on earlier python versions and iptables
[15:02] <jdstrand> anyway, really gotta go
[15:08] <Bilge> upstart sounds really good
[17:32] <UnixDawg> hey there
[17:32] <UnixDawg> I need some help with missing php-extensions
[17:32] <UnixDawg> php5-xml php5-json php5-xmlwriter php5-xmlreader php5-posix php5-iconv php5-hash php5-simplexml php5-pcre php5-filter php5-dom php5-session php5-spl
[17:33] <UnixDawg> I need them for my project
[17:33] <UnixDawg> but non are in the repos
[17:35] <UnixDawg> anyone alive ?
[17:38] <UnixDawg> I have the php 5.2.4 src
[17:38] <UnixDawg> but I need the modules to build for deb
[18:11] <uvirtbot`> New bug: #445154 in backuppc (main) "package backuppc 3.1.0-4ubuntu1.1 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Low,Confirmed] https://launchpad.net/bugs/445154
[18:40] <aubre> heola
[18:41] <aubre> hola
[19:14] <[diablo]> evening all
[19:15] <[diablo]> guys, anyone know if there LXC support in either 8.10, 9.04 or 9.10 please?
[19:47] <netbrain> can anyone tell me what is going on with xen? is xen being phased out in ubuntu?
[19:48] <jmarsden> [diablo]: rmadison lxc shows there is support in karmic:    lxc |    0.6.3-1 | karmic/universe | source, amd64, i386
[19:50] <jmarsden> netbrain: rmadison xen-3.3 seems to show support in karmic:  xen-3.3 | 3.3.0-1ubuntu11 |        karmic | source
[19:53] <netbrain> jmarsden: linux-image-xen?
[19:54] <jmarsden> netbrain: That was only in Hardy, IIRC... the approach to packaging xen has changed since then, I think.
[19:56] <netbrain> jmarsden: so xen should actually work better in karmic?
[19:57] <jmarsden> I can't guarantee that :)  But there should still be xen support, as far as I know it is not being "phased out".  Obviously KVM is the officially supported virtualization approach these days, so that gets more attention.
[19:57] <jmarsden> You may get more detailed info if you ask in #ubuntu-virt
[19:58] <netbrain> jmarsden: thank you
[19:59] <jmarsden> netbrain: No problem.
[20:06] <uvirtbot`> New bug: #454164 in likewise-open5 (universe) "likewise-open5-eventlog doesn't properly install" [Undecided,New] https://launchpad.net/bugs/454164
[20:10] <[diablo]> jmarsden, sorry back now... mmm but at kernel level, its patched?
[20:32] <jmarsden> [diablo]: I think you still need to get a Xen dom0 kernel from Debian
[20:33] <[diablo]> xen? you think?
[20:34] <[diablo]> I read somewhere that LXC was going into the upstream kernel
[20:36] <jmarsden> https://help.ubuntu.com/community/Xen points to http://www.chrisk.de/blog/2008/12/how-to-run-xen-in-ubuntu-intrepid-without-compiling-a-kernel-by-yourself/  but that may be slightly out of date now...
[20:37] <jmarsden> LXC... I don't know what the status of getting that into the official kernel source tree is (nor Xen into the official kernel source tree, for that matter).  Would be nice to see :)
[20:37] <[diablo]> nod
[20:37] <[diablo]> chroot is a touch outdated when you look at the likes of OpenVZ, and LXC etc
[20:38] <[diablo]> not saying that it does not suffice for a lot of stuff, but containers can be nicer
[20:40] <[diablo]> I guy in ##kernel tells me its there
[20:40] <[diablo]> nice
[21:04] <UnixDawg> hey guys
[21:05] <UnixDawg> need some help if you have  a min
[21:11] <jmarsden> !ask | UnixDawg
[22:51] <iarp> i'm having a problem with LVM, i added 2 hdd's to a volume group and expanded it and it says it's the proper size to go across all drives, but ubuntu server 9.04 still reports the old size
[22:59] <LyonJT> Whats the equivelent to active directory on linux?
[22:59] <jmarsden> iarp: You may be confusing filesystem size with partition size.  Now you have a large partition you probably need to resize the filesystem to fill it?
[23:01] <iarp> jmarsden: i get so lost using lvm, that maybe my problem, althought i thought lvm would've resized the filesystem
[23:01] <jmarsden> LyonJT: There are several directory services for Linux.  One is the 389 directory service, see http://directory.fedoraproject.org/
[23:01] <jmarsden> iarp: Why? lvm itself has no idea what kind of filesystem is there on that chunk of disk space...
[23:03] <iarp> i'm somewhat new to ubuntu, whats best to use to expand the filesystem
[23:05] <LyonJT> cheers jmarsden
[23:06] <LyonJT> jmarsden: can you run 389 on a ubuntu server or does it have to be fedora
[23:07] <jmarsden> LyonJT: You can run it on Ubuntu.  I think it is officially packaged for Karmic 9.10, which will be released in a few days, but you can find packages of it for Ubuntu in a PPA.
[23:07] <LyonJT> Thanks mate
[23:07] <jmarsden> iarp: resize2fs .  See http://www.howtoforge.com/linux_resizing_ext3_partitions for some ideas, although that may be a bit old.
[23:08] <iarp> ty
[23:08] <jmarsden> LyonJT: No problem.
[23:49] <stas> hi, anybody using apt-mirror tool?