IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 December 2013 (all times are UTC)
| 00:06 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 00:37 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 00:42 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out) | |
| 01:08 | nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 265 seconds) | |
| 01:13 | nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn) | |
| 01:17 | nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 260 seconds) | |
| 01:24 | nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn) | |
| 02:08 | clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto) | |
| 02:11 | ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 248 seconds) | |
| 02:20 | nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 240 seconds) | |
| 02:21 | nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn) | |
| 02:23 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 02:24 | SmallR2002 has joined IRC (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net) | |
| 02:31 | mattcen_ has joined IRC (mattcen_!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 02:34 | sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, *.net *.split) | |
| 02:34 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, *.net *.split) | |
| 02:34 | SmallR2003 has left IRC (SmallR2003!~Robert@c-98-253-173-240.hsd1.il.comcast.net, *.net *.split) | |
| 02:34 | mattcen_ is now known as mattcen | |
| 02:41 | sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173) | |
| 02:42 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 02:43 | * vagrantc waves to sbalneav | |
| 02:44 | <vagrantc> sbalneav: alkisg and i have been doing a virtual hackfest this week!
| |
| 02:47 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds) | |
| 03:44 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 03:48 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds) | |
| 04:45 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 04:50 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 248 seconds) | |
| 04:56 | alkisg has joined IRC (alkisg!~alkisg@ppp089210206186.access.hol.gr) | |
| 04:56 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 04:57 | <alkisg> Good morning
| |
| 04:59 | * vagrantc waves | |
| 04:59 | * vagrantc noticed a half-dozen failed builds | |
| 04:59 | <vagrantc> can i unsubscribe from some of those?
| |
| 05:00 | it's basically because the changes in ltsp-trunk require changes to the packaging...
| |
| 05:01 | but i don't want to make the corresponding changes to the packaging until I upload the next ltsp version
| |
| 05:01 | also fixed the one bug i found in cdpingerless ltspfs
| |
| 05:02 | <alkisg> vagrantc: I disabled them so that they don't send mails to ltsp-committers
| |
| 05:02 | <vagrantc> alkisg: have you gotten a chance to test newish ltspfs?
| |
| 05:02 | <alkisg> I'll either temporarily change their owner, or create my own so that they don't bother people with mails
| |
| 05:02 | <vagrantc> alkisg: ok, thanks.
| |
| 05:03 | in theory, i like the idea of automated builds, but my packaging branch isn't always targetted at -trunk
| |
| 05:03 | and it'd be a bit too much work to maintain multiple packaging branches
| |
| 05:03 | <alkisg> No, I was thinking of doing as many changes as I could now that I still have some time to code, and test/debug all of them a bit later, as testing time is more easy for me to find than development time...
| |
| 05:04 | <vagrantc> alkisg: i was thinking of trying to wrap up the ltsp-update-kernels stuff and uploading a new version...
| |
| 05:04 | <alkisg> I.e. finish pxelinux first...
| |
| 05:04 | Cool
| |
| 05:04 | <vagrantc> also, ltspfs could use a new point release with that bugfix and additional cdpinger removal cleanups
| |
| 05:05 | <alkisg> If you get the packaging ready without bumping the changelog, it makes it much easier for me to test it...
| |
| 05:05 | <vagrantc> that i could probably finish up pretty quickly
| |
| 05:05 | haven't been bumping the changelog lately
| |
| 05:06 | <alkisg> What I mean is, let's try to finish ltsp-trunk, ltspfs-trunk, AND their packaging, and test them, and _then_ to do the new releases...
| |
| 05:06 | <vagrantc> basically, ltsp needs packaging changes tha taccount for -trunk's lack of xatomwait
| |
| 05:07 | <alkisg> vagrantc: so, does http://wiki.ltsp.org/wiki/Dev:PXEConfig sound sane? Is it time to send a mail to ltsp-devs?
| |
| 05:08 | <vagrantc> alkisg: i *think* ltspfs is ready, no packaging changes needed.
| |
| 05:08 | alkisg: the overall premise is sane, i'd like to re-use the old variables for CMDLINE_*
| |
| 05:08 | <alkisg> OK let me update the page for that...
| |
| 05:09 | <vagrantc> and leave the initrd= out of the CMDLINE_, that way it's easier to remove it if there's no initrd.
| |
| 05:10 | and the server-side reads /etc/ltsp/ltsp-update-kernels.conf, as well as the /opt/ltsp/*/etc/ltsp/update-kernels.conf ?
| |
| 05:10 | ah, it already mentions the latter part
| |
| 05:12 | <alkisg> I think I mention both of them, just in separate places
| |
| 05:12 | <vagrantc> hrm.
| |
| 05:12 | <alkisg> vagrantc: is ip=dhcp necessary? isn't it the default anyway?
| |
| 05:12 | <vagrantc> alkisg: the first server-mention only mentions update-kernels.conf, not ltsp-update-kernels.conf ... want to mak sure i'm not misunderstanding
| |
| 05:12 | <alkisg> That's because it the "client-side" paragraph
| |
| 05:12 | <vagrantc> alkisg: for the theoretic initrd-less install, it should be there.
| |
| 05:13 | <alkisg> So it only mentions update-kernels and update-kernels.conf, not ltsp-update-kernels
| |
| 05:13 | <vagrantc> server-side mentions update-kernels.conf
| |
| 05:13 | <alkisg> Sorry let me re-read...
| |
| 05:13 | <vagrantc> first paragraph... just making sure it's a typo vs. a misunderstanding of implementation
| |
| 05:14 | alkisg: so both pxelinux.cfg/ltsp and ltsp-all are always regenerated?
| |
| 05:15 | <alkisg> Yup
| |
| 05:15 | vagrantc: copy/paste the line that you're mentioning, I'm still not getting it
| |
| 05:15 | For each chroot (or loop-mounted image), ltsp-update-kernels sources $CHROOT/etc/ltsp/update-kernels.conf, if it exists, and does the following steps:
| |
| 05:15 | This one?
| |
| 05:15 | <vagrantc> The ltsp-server package may ship /etc/ltsp/update-kernels.conf,
| |
| 05:16 | first paragraph in the server section
| |
| 05:16 | <alkisg> Right, the BOOT_METHODS go there
| |
| 05:16 | And the distro may or may not decide to ship it
| |
| 05:16 | <vagrantc> shouldn't they go in ltsp-update-kernels.conf ?
| |
| 05:16 | <alkisg> Meh
| |
| 05:16 | <vagrantc> since it's being implemented by ltsp-update-kernels?
| |
| 05:16 | <alkisg> OK something's really wrong here. Probably lack of coffee. :D
| |
| 05:17 | Sorry!
| |
| 05:17 | <vagrantc> it's a minor detail, really.
| |
| 05:18 | * alkisg is more worried about the time it took him to understand what vagrantc was saying :D | |
| 05:18 | <alkisg> OK, updated
| |
| 05:19 | If we're not careful in the code, the (older) chroot BOOT_METHODS might end up being interpreted as server-side BOOT_METHODS... maybe we should rename that?
| |
| 05:19 | <vagrantc> both the client and server-side will have BOOT_METHODS defined
| |
| 05:19 | * vagrantc nods | |
| 05:20 | <vagrantc> same thought process :)
| |
| 05:20 | it'd be good to know what the client's preferred BOOT_METHODS are
| |
| 05:20 | so maybe SERVER_BOOT_METHODS ?
| |
| 05:20 | or BOOT_METHODS_SERVER ?
| |
| 05:20 | that can be how the client tells the server which methods it can support.
| |
| 05:21 | maintains full backkwards compatibility
| |
| 05:21 | the server can choose to honor them or not
| |
| 05:21 | but especially, it should error out if there are no matches, but both are defined
| |
| 05:22 | <alkisg> OK, when I was writting it I was trying to eliminate the need to ship a config file, but yeah if we're shipping it/upgrading it anyway what you're saying does make more sense
| |
| 05:23 | <vagrantc> well, in absense of a defined value, we use the defaults.
| |
| 05:23 | and if the defaults don't work, the sysadmin with a corner-case situation needs to specify something :)
| |
| 05:23 | which is reasonable
| |
| 05:24 | <alkisg> vagrantc: why does the client need to list BOOT_METHODS, if it lists the CMDLINE_* variables? Just to make it easier to loop through them?
| |
| 05:24 | <vagrantc> alkisg: are we putting off supporting /opt/ltsp/i386 and /opt/ltsp/images/i386.img till ltsp6, you think?
| |
| 05:24 | alkisg: preference order
| |
| 05:25 | alkisg: i.e. BOOT_METHODS="NFS NBD" tells it to default to NFS
| |
| 05:25 | * alkisg was thinking where it's the correct place to declare the preference, server-side or chroot-side... | |
| 05:25 | <vagrantc> alkisg: also, it's currently used to determine which CMDLINE_* variables to look for.
| |
| 05:25 | alkisg: both can declare their preferences
| |
| 05:27 | alkisg: a little curious why splitting pxelinux.cfg/ltsp and pxelinux.cfg/ltsp-all into separate files ... could just define ltsp-all as a submenu ...
| |
| 05:27 | <alkisg> vagrantc: for translation
| |
| 05:27 | "Previous Linux Versions" => submenu
| |
| 05:27 | <vagrantc> alkisg: the server shouldn't serve up chroots the client doesn't know how to support, and vice-versa.
| |
| 05:27 | <alkisg> And include ltsp-all
| |
| 05:28 | But I do want to test INCLUDEs a bit before going ahead with the implementation...
| |
| 05:28 | <vagrantc> alkisg: ok, not attached either way, really.
| |
| 05:28 | INCLUDES work pretty well.
| |
| 05:28 | i used them extensively at freegeek
| |
| 05:28 | maybe painfully so
| |
| 05:29 | https://github.com/freegeek-pdx/netboot-config/tree/master/pxelinux.cfg
| |
| 05:30 | the only downside i see with includes is multiple tftp hits, but i'd be surprised if that was what overloaded your server compared to nfsroot/nbdroot
| |
| 05:31 | the other downside is you can loose yourself in complexity :)
| |
| 05:31 | layers upon layers of includes
| |
| 05:32 | alkisg: another minor thing, regarding the chroot generating pxelinux.cfg ... it shouldn't generate it, but if it does, it won't hurt anything, other than wasted time
| |
| 05:32 | i.e. old chroots that do generate it
| |
| 05:33 | <alkisg> Yes, that's what I meant, not sure what I wrote though... /me looks...
| |
| 05:33 | <vagrantc> like i said, minor
| |
| 05:35 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Read error: Connection reset by peer) | |
| 05:36 | <alkisg> Updated... btw vagrantc wherever my wording isn't good enough, feel free to update it: http://wiki.ltsp.org/mediawiki/index.php?title=Dev:PXEConfig&action=edit
| |
| 05:36 | <vagrantc> this is not far off from what I implemented for wheezy, but I made the mistake of wanting to avoid using the includes and always regenerating all the files...
| |
| 05:36 | * vagrantc rummages around for login credentials | |
| 05:37 | <vagrantc> alkisg: partly, i'm just checking in to make sure it's not just a misunderstanding :)
| |
| 05:39 | just to minimize downtime, we should probably update all the files in a separate dir...
| |
| 05:39 | and then move it into place when everything is done
| |
| 05:39 | mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 05:39 | <vagrantc> handling multiple tftp dirs also really is starting to feel stupid.
| |
| 05:40 | <alkisg> If we're shipping ltsp-update-kernels.conf, we can easily drop support for multiple tftp dirs ...
| |
| 05:41 | <vagrantc> i think it already allows overriding the tftp dirs
| |
| 05:41 | but safer to support all of them by default
| |
| 05:41 | * alkisg would even prefer NOT updating the files that are the same in CHROOT vs TFTP | |
| 05:42 | <alkisg> I've seen people that have 30 older kernels in their tftp...
| |
| 05:42 | * vagrantc nods | |
| 05:42 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 246 seconds) | |
| 05:42 | <alkisg> rsync could easily do that,
| |
| 05:43 | ...and cp does have an "update only" parameter, but then it's difficult to see which files to delete in TFTP
| |
| 05:47 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 05:51 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
| 06:17 | <alkisg> Maybe we should postpone changing our tftp cleanup code until all the configuration files have been moved out of TFTP/ltsp/ARCH and into /etc/ltsp/lts.conf and TFTP/pxelinux.cfg...
| |
| 06:48 | <vagrantc> it seems like what you have is actually fine
| |
| 06:49 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 06:49 | <vagrantc> we can get a list of files we're going to include, and then delete all the other files, and then run cp -u
| |
| 06:49 | but it does lack simplicity
| |
| 06:49 | rsync --delete?
| |
| 06:50 | well, really, the only problem is re-copying everything
| |
| 06:50 | which yeah, 30 some kernels/initrds would be kind of wasteful...
| |
| 06:51 | and time consuming, at some point, when you account for multiple chroots
| |
| 06:51 | * alkisg would leave the cleanup code as it is for ltsp5, and for ltsp6 he'd use rsync -delete, yeah | |
| 06:51 | <vagrantc> honestly, the purge and re-copy isn't so awful.
| |
| 06:51 | <alkisg> Or cp --update, and rm the non-existing files via shell afterwards
| |
| 06:52 | <vagrantc> yeah, that's not too bad
| |
| 06:52 | whitelist it from the old dir.
| |
| 06:53 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
| 06:53 | <vagrantc> oh, if the server creates the symlinks in the tftp dir, then it needs to exclude them from the purge
| |
| 06:54 | that's what got me started on the whole purging code
| |
| 06:54 | because it was deleting the symlinks created in the chroot
| |
| 06:54 | but if you create them on the server, the symlinks need to be excluded from the purge patterns
| |
| 06:55 | <alkisg> Aren't they created after the purging?
| |
| 06:55 | <vagrantc> this seems like 95% done... i think we can come up with something
| |
| 06:55 | alkisg: ah, you could do that on the server-side, sure.
| |
| 06:55 | alkisg: although it increases the amount of time the missing symlinks are there.
| |
| 06:55 | er, arren't there
| |
| 06:55 | <alkisg> We don't touch $CHROOT/boot/*, do we?
| |
| 06:56 | <vagrantc> with the new implementation, not yet
| |
| 06:56 | <alkisg> I mean, ltsp-update-kernels will be the only thing creating symlinks... ok
| |
| 06:56 | <vagrantc> but say someone boots a client near the time you're running ltsp-update-kernels ... we want the window of time for files to be missing to be small
| |
| 06:57 | that's why i was thinking some sort of copy to a tempdir and move approach
| |
| 06:57 | as long as it's on the same filesystem, the move can happen very quickly
| |
| 06:57 | <alkisg> The temp dir would be under $TFTP, to ensure it's in the same disk and fast to move afterwards?
| |
| 06:57 | * vagrantc nods | |
| 06:57 | <alkisg> Sounds good
| |
| 06:58 | <vagrantc> which in general, i'm not fond of tempdirs in tftp
| |
| 06:58 | but it doesn't solve the problem of copying redundant data multiple times
| |
| 06:59 | is there some way to do a copy that uses a dir as a reference dir, but copies the changed files to a different location?
| |
| 06:59 | <alkisg> What if we whitelist files to keep instead of blacklisting files to delete?
| |
| 06:59 | I.e. TFTP_WHITELIST="pxelinux.cfg,lts.conf" in /etc/ltsp/ltsp-update-kernels.conf
| |
| 06:59 | <vagrantc> we'd have to generate the list of files to whitelist dynmaically, since we don't have static symlink names
| |
| 07:00 | <alkisg> Symlinks shouldn't be hard to maintain separately
| |
| 07:00 | I.e. just run the symlinking code and remove all dangling symlinks after that
| |
| 07:01 | <vagrantc> could generate the list of files to be symlinked from $chroot/boot/ ...
| |
| 07:01 | and/or updated
| |
| 07:01 | * alkisg doesn't follow | |
| 07:01 | * vagrantc is chasing vagrantc's own tail | |
| 07:02 | <vagrantc> to generate a whitelist, we can basically whitelist lts.conf, pxelinux*, the symlinks we're going to generate, and the files from $chroot/boot
| |
| 07:02 | all other files should be purged, yes?
| |
| 07:03 | <alkisg> Yes, we're saying the same thing, except I define the whitelist as the 2 first things you're saying, and just special-case the 2 last ones
| |
| 07:03 | cp --update from boot to TFTP, then create symlinks, then delete all files that only exist in tftp and not in boot, then delete all dangling symlinks
| |
| 07:03 | <vagrantc> that sounds good.
| |
| 07:05 | the current code would delete the symlinks... well, i actually committed a workaround to that
| |
| 07:06 | it just doesn't bother purging symlinks, but leaves dangling symlinks around
| |
| 07:06 | <alkisg> With that last line I said above ^, do we still need the temp dir?
| |
| 07:06 | Or we can do it in-place?
| |
| 07:07 | <vagrantc> i think that works fine without the temp dir.
| |
| 07:07 | <alkisg> (to avoid re-copying everything...)
| |
| 07:07 | <vagrantc> somewhere in there we should (re)generate the pxelinux
| |
| 07:07 | i liked the complete purge for how simple it was to implement, but has the drawback of re-copying too much data.
| |
| 07:08 | <alkisg> Btw can we depend on rsync?
| |
| 07:08 | Maybe it has a one-line for what we want...
| |
| 07:08 | <vagrantc> alkisg: pxelinux.cfg updates should happen in between creating symlinks and purging files
| |
| 07:09 | <alkisg> Yeah deletions should be last
| |
| 07:09 | <vagrantc> i think that makes sure everything is always in a bootable state.
| |
| 07:09 | i would be fine with depending on rsync, but i'm not sure it actually gains us much.
| |
| 07:09 | <alkisg> I think some race conditions exist, but they should be rare...
| |
| 07:10 | <vagrantc> what it could gain us is more cpu-intensive, i think.
| |
| 07:11 | unless we put the symlinks back into the chroot ....
| |
| 07:11 | then it would be pretty simple to use.
| |
| 07:11 | <alkisg> vagrantc: the concept is the same wheather we use a whitelist or a blacklist (cp --update etc etc), which one would you prefer? I think I prefer the internal blacklist...
| |
| 07:12 | vagrantc: touching the chroot means we assume it's readable...
| |
| 07:12 | That's not the case for ltsp-pnp (cow), for .vdi, nfs exports...
| |
| 07:12 | (touching the chroot from ltsp-update-kernels, that is...)
| |
| 07:13 | <vagrantc> right, i was talking about from a kernel install hook
| |
| 07:13 | $chroot/usr/share/ltsp/update-kernels
| |
| 07:13 | <alkisg> Hmm sure why not, that does make sense
| |
| 07:14 | <vagrantc> since the symlinks only need to be (re)generated when you install or update a kernel...
| |
| 07:14 | but it doesn't have backwards compatibility with old chroots
| |
| 07:14 | since the old chroots won't generate them
| |
| 07:14 | but then you can just fall back to newest kernel version
| |
| 07:14 | yes?
| |
| 07:14 | or the sysadmin installs a hook in the chroot to generate them...
| |
| 07:15 | * alkisg would prefer to have the symlink generating code *once*, not both in the server and the client | |
| 07:15 | * vagrantc nods | |
| 07:15 | <alkisg> Ah, another thing... suppose I run ltsp-update-kernels,
| |
| 07:15 | then realize my chroot is broken, then restore a backup, then run ltsp-update-kernels again,...
| |
| 07:15 | <vagrantc> this little bit of code is sure getting a lot of airtime :)
| |
| 07:16 | <alkisg> ...that won't work with cp --update, will it?
| |
| 07:16 | <vagrantc> yeah, cp --update will need to have a force-overwrite mode or something
| |
| 07:16 | i.e. ltsp-update-kernels --force-update or something
| |
| 07:16 | <alkisg> So, simplicity +1, let's go with the copying everything idea
| |
| 07:16 | * vagrantc forgets what we do now... | |
| 07:17 | <vagrantc> cp -a "$chroot/boot/." "$tftpboot/$name/"
| |
| 07:17 | so that wouldn't be a regression
| |
| 07:17 | <alkisg> Why -a instead of -r?
| |
| 07:18 | <vagrantc> yeah, that's what i'm wondering
| |
| 07:19 | i think -r might "fix" our "chmod +r" problem.
| |
| 07:19 | <alkisg> Yup
| |
| 07:20 | So, ltsp-update-kernels copys boot to tftp/ltsp/arch.NEW, creates pxe configuration, symlinks etc etc, everything ready,
| |
| 07:20 | <vagrantc> still might want --no-dereference
| |
| 07:21 | subdirs can be copied too.
| |
| 07:21 | oh, but you wanted to save some space...
| |
| 07:21 | i.e. /boot/grub and whatnot
| |
| 07:22 | <alkisg> I don't mind
| |
| 07:22 | That was back when we wanted to avoid copying pxelinux.cfg
| |
| 07:22 | Now we're keeping it until ltsp6
| |
| 07:22 | <vagrantc> but we're still planning on generating it server-side?
| |
| 07:22 | and wiping out the client-side generated pxelinux.cfg stuff?
| |
| 07:22 | <alkisg> Yes, we'll overwrite any files there
| |
| 07:23 | <vagrantc> even default?
| |
| 07:23 | <alkisg> Ouch
| |
| 07:23 | <vagrantc> well, that's easy enough to support
| |
| 07:24 | ChadLepto has joined IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net) | |
| 07:24 | ChadLepto has joined IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto) | |
| 07:24 | <vagrantc> part of updating tftp/ltsp/arch.NEW involves cp tftp/ltsp/arch/pxelinux.cfg/default tftp/ltsp/arch/pxelinux.cfg/default
| |
| 07:24 | we can copy over whatever whitelist we want to "save"
| |
| 07:25 | same with lts.conf
| |
| 07:26 | <alkisg> The problem is that we won't generate the first appropriate pxelinux.cfg/default then
| |
| 07:26 | <vagrantc> so: cp -r "$chroot/boot/." "$tftpboot/$name.NEW/" ; cp $tftpboot/$name/$WHITELIST $tftpboot/$name.NEW/ ; generate symlinks ; update updated pxelinux.cfg*
| |
| 07:26 | <alkisg> We'll use the old one from the chroot
| |
| 07:26 | Nah, I think I prefer it if chroot doesn't have anything to do with pxelinux
| |
| 07:26 | I.e. it can even not have syslinux installed
| |
| 07:26 | <vagrantc> sure, that's fine.
| |
| 07:27 | but that seems like a non-sequitor :P
| |
| 07:27 | <alkisg> So, for simplicity again, I say that we shouldn't have an update-kernels in the chroot at all... :D
| |
| 07:27 | <vagrantc> blashpemy
| |
| 07:27 | <alkisg> Just a .conf file
| |
| 07:27 | Haha
| |
| 07:27 | clepto has left IRC (clepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 264 seconds) | |
| 07:27 | <alkisg> OK ok we need it for nbi etc
| |
| 07:27 | <vagrantc> it's like the one stable thing in ltsp5
| |
| 07:29 | <alkisg> For ltsp6, will we be using pxelinux.0 from the server or from some random chroot?
| |
| 07:29 | * vagrantc wonders how the various parallel universes have turned out that have used all the various schemes we've come up with in the last 24 hours | |
| 07:29 | <alkisg> Hehehe!!
| |
| 07:29 | <vagrantc> alkisg: at least on debian, pxelinux.0 is installable on any architecture, so that shouldn't be a problem
| |
| 07:29 | i mean, it's an arch:all package
| |
| 07:30 | and even it if wasn't, worst case is you could install it multi-arch, i think.
| |
| 07:30 | <alkisg> OK back to where we were... do we copy subdirs or not? If yes, how do we handle pxelinux.cfg/default?
| |
| 07:30 | I vote for "we don't copy subdirs"
| |
| 07:31 | <vagrantc> i don't have any installs with stuff in subdirs...
| |
| 07:31 | * vagrantc wonders about other distros | |
| 07:32 | * vagrantc downloaded a bunch of live CDs earlier today | |
| 07:32 | <vagrantc> although who knows how "normal" those are.
| |
| 07:32 | alkisg: what's wrong with copying the pxelinux.cfg/default from an existing tftp dir?
| |
| 07:32 | i guess, upgrading from an older chroot?
| |
| 07:33 | <alkisg> vagrantc: so you would "merge" tftp.new with tftp.old and boot ?
| |
| 07:33 | Err I didn't say that correctly
| |
| 07:34 | <vagrantc> merging individual files, i.e. lts.conf and pxelinux.cfg/default
| |
| 07:34 | <alkisg> Suppose you have a pxelinux.cfg/default in boot, and one in (the older) tftp
| |
| 07:34 | And also suppose that you have some 01-mac-address files there
| |
| 07:34 | <vagrantc> manual configuration for the sysadmin to support old choorts is not unreasonable.
| |
| 07:34 | ah, yes, other random files...
| |
| 07:35 | ok, so copy pxelinux.cfg/* and regenerate the files we know are safe to regenerate
| |
| 07:35 | <alkisg> Copy pxelinux.cfg from where? the chroot?
| |
| 07:35 | <vagrantc> the tftp dir
| |
| 07:35 | tftp.old to tftp.new
| |
| 07:36 | <alkisg> Sure, but what do you copy from the chroot the first time?
| |
| 07:36 | You have a clean tftp and an old chroot with pxelinux.cfg/default
| |
| 07:37 | The correct thing to do there is to generate a new default
| |
| 07:37 | <vagrantc> copy $chroot/boot to $tftpdir/$arch.new, copy $tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, regenerate auto-generated pxelinux.cfg/ stuff
| |
| 07:37 | <alkisg> That leaves you with the old default
| |
| 07:37 | <vagrantc> yes, so if there's no file in $tftpdir/$arch/pxelinux.cfg/default, generate it
| |
| 07:38 | <alkisg> OK
| |
| 07:38 | <vagrantc> copy $chroot/boot to $tftpdir/$arch.new, copy $tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, generate pxelinux.cfg/default if not present, regenerate auto-generated pxelinux.cfg/ stuff
| |
| 07:39 | that's fairly simple for what we're trying to accomplish
| |
| 07:39 | <alkisg> tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, ==> do you mean $arch.new there?
| |
| 07:39 | <vagrantc> oops, yeah.
| |
| 07:40 | <alkisg> So you'd generate pxelinux.cfg/default in the .new directory?
| |
| 07:40 | <vagrantc> yes.
| |
| 07:40 | <alkisg> That might make the paths a bit complicated, but only a bit
| |
| 07:40 | <vagrantc> unless it was already present in the old directory
| |
| 07:40 | not if they're relative
| |
| 07:40 | <alkisg> /ltsp/arch.new/file
| |
| 07:41 | While the correct would be /ltsp/arch/file
| |
| 07:41 | Ah we don't have a master pxelinux yet
| |
| 07:41 | * vagrantc nods | |
| 07:41 | <vagrantc> that's for ltsp6... unless it isn't.
| |
| 07:41 | <alkisg> Sure, sure
| |
| 07:42 | <vagrantc> this is a bit simpler from a "what to purge" perspective
| |
| 07:42 | <alkisg> I think it still has a problem
| |
| 07:42 | <vagrantc> downsides would be upgrading a server with old chroots ... sysadmin will need to regenerate pxelinux.cfg/default
| |
| 07:42 | or remove it, and let ltsp-update-kernels update it
| |
| 07:42 | <alkisg> And the fact that I'm not sure if it does, ...tells me it's not as simple as it sounds at first glance....
| |
| 07:43 | Right, that problem
| |
| 07:43 | <vagrantc> it gives us a very simple set of whitelist files
| |
| 07:43 | lts.conf, pxelinux.cfg/* (pxelinux.cfg/default is a little bit special) ... everything else must go!
| |
| 07:45 | <alkisg> So we'd delete the user'ss "lts.original"?
| |
| 07:45 | <vagrantc> guess so.
| |
| 07:45 | <alkisg> ..when he's just testing with an empty lts.conf?
| |
| 07:45 | * alkisg likes the blacklist better, until ltsp6 | |
| 07:46 | <vagrantc> so, at this point, we're trying to get to ... an editable pxelinux.cfg/default ... that's the only remaining goal, yes?
| |
| 07:46 | or the semi-stable symlinks?
| |
| 07:46 | <alkisg> I think our main difference is that I prefer to keep the existing blacklist, while you prefer to switch it to a whitelist...
| |
| 07:47 | That then differentiates the implementation just a bit, on the order of copies/deletions etc
| |
| 07:47 | <vagrantc> sure.
| |
| 07:47 | overall, i'm not attached either way, honestly.
| |
| 07:48 | i just want some clarification on what the exact problem we're trying to solve, at this point, since we've kind of gone around in circles a bit
| |
| 07:48 | <alkisg> For ltsp6 I'd go with "no blacklist, no whitelist - delete everything"
| |
| 07:48 | For now, I'd just try to keep things similar to what they currently are, and only change the stuff that will bring us something that we want
| |
| 07:49 | * vagrantc chants "what do we want?" | |
| 07:49 | <alkisg> So, goals: (1) symlinks, (2) static pxelinux.cfg/default
| |
| 07:49 | We don't care about whitelisting or blacklisting, so I wouldn't change that without good reason
| |
| 07:50 | ...more so when we'll change that again for ltsp6, to "no list at all, delete everything"
| |
| 07:50 | <vagrantc> sounds good.
| |
| 07:50 | or we'll probably come up with something else in a week or two :P
| |
| 07:50 | <alkisg> Haha
| |
| 07:50 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 07:50 | <vagrantc> that we'll postpone for ltsp7
| |
| 07:51 | <alkisg> Yeah I'm starting to wonder if ltsp5 is worth it, to get those pxe configuration changes
| |
| 07:52 | <vagrantc> well, the symlinks are not that hard.
| |
| 07:52 | well, the symlinks are not that hard.
| |
| 07:52 | oops
| |
| 07:52 | * alkisg said that 2 days ago too, that he mainly cares about the symlinks :) | |
| 07:52 | <vagrantc> we've already got a partial implementation in the chroot-code, which is more similar to currently released ltsp 5.4.x implementations
| |
| 07:53 | that's because ubuntu changes versions all the time, isn't it?
| |
| 07:54 | <alkisg> Yup
| |
| 07:54 | <vagrantc> debian doesn't break abi compatibility very often at all ... often not even once during a release cycle
| |
| 07:54 | <alkisg> So if a client needs "nomodeset", the teacher has no real way to handle it
| |
| 07:54 | <vagrantc> only a single client... right
| |
| 07:55 | <alkisg> ...ok, there's a vmlinuz symlink, but if one wants pae/non-pae then he can't do it
| |
| 07:55 | <vagrantc> so, maybe we focus on integrating the symlinks, and treat the other re-work separately
| |
| 07:55 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 248 seconds) | |
| 07:55 | <vagrantc> if it's even worth doing
| |
| 07:55 | (i mean, the pxelinux.cfg/default changes)
| |
| 07:55 | <alkisg> I think it's worth doing, but now I don't think it's worth doing anything related about it for ltsp5...
| |
| 07:56 | I do think we should move to a static /pxelinux.cfg
| |
| 07:56 | <vagrantc> abandoning it during ltsp5 ?
| |
| 07:56 | wait for ltsp6, rather?
| |
| 07:56 | <alkisg> Yup
| |
| 07:56 | <vagrantc> feel like we're so close...
| |
| 07:56 | <alkisg> New branch time? :)
| |
| 07:56 | <vagrantc> the symlinks are already there in trunk ...
| |
| 07:57 | just needs better code for version-splitting
| |
| 07:57 | <alkisg> vagrantc: will we still have the vmlinuz symlink for ltsp5?
| |
| 07:57 | Or did that change to vmlinuz-generic-pae now?
| |
| 07:58 | <vagrantc> alkisg: it won't break any of those
| |
| 07:58 | alkisg: i.e. if it was there before, it doesn't get rid of it
| |
| 08:00 | <alkisg> OK, nice. So, everything is supposed to be working, and we only need testing.
| |
| 08:00 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 08:00 | <alkisg> And then we can fork to ltsp6...
| |
| 08:00 | Right?
| |
| 08:00 | <vagrantc> that's my hope
| |
| 08:00 | the pxelinux.cfg/default stuff isn't there at all, though.
| |
| 08:00 | and dangling symlinks aren't dealt with
| |
| 08:00 | <alkisg> Same as it was before, isn't it?
| |
| 08:01 | <vagrantc> think so
| |
| 08:01 | <alkisg> Sounds fine
| |
| 08:02 | <vagrantc> so really, at this point, it's just a matter of tweaking the symlink code in client/share/ltsp/update-kernels
| |
| 08:03 | the menu generation code doesn't use the symlinks
| |
| 08:04 | it only uses versioned kernels
| |
| 08:05 | but you could create pxelinux.cfg/01-$macaddr that uses the symlink
| |
| 08:06 | <alkisg> Right, that's more than enough, we can leave the rest for ltsp 6:)
| |
| 08:06 | <vagrantc> it's also hardcoded for vmlinuz and initrd-img
| |
| 08:07 | probably wouldn't be too hard to generate an unversioned pxelinux.cfg
| |
| 08:08 | * alkisg would just ship it from the distro and let the user do whatever changes he wanted, manually... :D | |
| 08:08 | <alkisg> Hehe
| |
| 08:08 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds) | |
| 08:09 | <alkisg> Editing menu.lst with the vmlinuz symlinks was way easier than now with grub2,
| |
| 08:09 | where we need to edit /etc/default/grub, /etc/grub.d/*, run update-grub... it sucks
| |
| 08:10 | So, I'd generate the symlinks and provide a static pxelinux.cfg file, and whatever else the user wants, nbd, nfs, pae etc, he'd do them manually, it's just static content with the symlinks there
| |
| 08:11 | Anyways, our current plan is good enough, let's not change it
| |
| 08:11 | <vagrantc> it's way easier for packages to add menu entries with the grub2 hooks, though.
| |
| 08:11 | <alkisg> But there are no packages that add menu entries to ltsp
| |
| 08:11 | <vagrantc> alkisg: so, just symlinks, no pxelinux.cfg/default ?
| |
| 08:12 | <alkisg> For ltsp5? Yup.
| |
| 08:12 | <vagrantc> alkisg: sure, but i appreciate the grub2 menu generation method
| |
| 08:12 | <alkisg> That would be up to pxelinux to define a menu generation method, not up to ltsp
| |
| 08:12 | <vagrantc> yes
| |
| 08:13 | didn't get much response when i asked about that
| |
| 08:13 | so we have to write a bunch of code to generate the menus...
| |
| 08:14 | while we change our minds all the time, at least syslinux hasn't changed syntax much
| |
| 08:15 | if we're putting symlinks in the last ltsp 5.x generations, we may as well generate the corresponding menus.
| |
| 08:15 | <alkisg> We support menus in the current code, right?
| |
| 08:15 | <vagrantc> yes.
| |
| 08:15 | actually ...
| |
| 08:16 | it woudln't be hard to make pxelinux.cfg/default not autogenerated anymore
| |
| 08:16 | would be trivial, actually
| |
| 08:16 | because it's regenerated every time now...
| |
| 08:17 | <alkisg> To make it not-autogenerated, you need to put INCLUDE in it
| |
| 08:17 | <vagrantc> right. which shouldn't be hard at all.
| |
| 08:17 | <alkisg> But how do you know if that's the last auto-generated version, that you need to overwrite with the static content?
| |
| 08:18 | grep for this? # This file is regenerated when update-kernels runs.
| |
| 08:19 | <vagrantc> yup.
| |
| 08:20 | i'll give it a shot, it's what i should've done last time we did this.
| |
| 08:22 | <alkisg> Actually `head` should be a bit safer than `grep` in this...
| |
| 08:38 | <vagrantc> alkisg: think this should do it: http://paste.debian.net/72589/
| |
| 08:39 | i guess ltsp-update-kernels also needs some special-casing to copy and/or not copy it over
| |
| 08:39 | * vagrantc -> sleep | |
| 08:41 | <vagrantc> well, that handles the pxelinux.cfg/default being editable
| |
| 08:41 | it doesn't add the symlinked versions in
| |
| 08:42 | and doesn't handle yaboot or the other boot methods :)
| |
| 08:45 | <alkisg> Good night vagrantc, see you tomorrow
| |
| 08:46 | * alkisg is doing morning chores... | |
| 08:47 | <vagrantc> we could also just symlink pxelinux.cfg/default -> pxelinux.cfg/ltsp ...
| |
| 08:47 | and if the sysadmin wants to use includes, they could
| |
| 08:47 | by deleting the symlink and updating the file.
| |
| 08:48 | would be virtually identical to now, but easier to convert into an editable mode.
| |
| 08:48 | hrm... but then we're back to is the chroot the editable version, or the tftp dir ... hrm.
| |
| 08:48 | it's still more feasible to fix.
| |
| 08:52 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 08:56 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
| 09:04 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 272 seconds) | |
| 09:04 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 09:07 | <vagrantc> alkisg: i'd like to upload ltspfs-trunk as 1.2.1-1 soonish, if you could test on ubuntu, that'd be good to know. otherwise i might just patch in a fix or two for 1.2-2
| |
| 09:07 | alkisg: i know you wanted to test stuff later
| |
| 09:07 | <alkisg> vagrantc: i'll test this evening
| |
| 09:07 | <vagrantc> but i'm curious if it works at all.
| |
| 09:08 | and agains tmy better judgement, i've got a branch with the editable pxelinux.cfg/default ... although there's still the problem of the cchroot overwriting the tftp dir.
| |
| 09:09 | i think that's the thing i never resolved and why i decided to not bother with editability.
| |
| 09:10 | i guess the chroot could just not generate pxelinux.cfg/default at all, and rely on ltsp-update-kernels to do it...
| |
| 09:10 | and by default, it could just symlink pxelinux.cfg/ltsp -> default
| |
| 09:10 | that's pretty simple. and doesn't much change behavior
| |
| 09:11 | then it doesn't even need to get into includes.
| |
| 09:11 | and ltsp-config pxe could replace the symlink with an editable include-based config.
| |
| 09:11 | and then we throw it all away for ltsp6 :)
| |
| 09:13 | <alkisg> Hahaha
| |
| 09:14 | Yeah you're putting way too much though into it, when it'll not be an issue for ltsp 6
| |
| 09:14 | *thought
| |
| 09:16 | <vagrantc> well, i think that'll work, and it's an improvement, and fixes what felt like unfinished business, without getting too messy.
| |
| 09:17 | it has some of the qualities of the new system, without totally breaking compatibility with the old.
| |
| 09:18 | aaaaanyways...
| |
| 09:18 | * vagrantc waves | |
| 09:18 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 09:21 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 09:37 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 09:42 | imox has joined IRC (imox!~imox@p4FC5D41D.dip0.t-ipconnect.de) | |
| 09:43 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
| 10:08 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 10:27 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 10:36 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
| 10:36 | Gremble is now known as Guest59986 | |
| 11:20 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 248 seconds) | |
| 11:35 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 11:43 | Guest59986 has left IRC (Guest59986!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave) | |
| 12:41 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-118.dsl.scarlet.be) | |
| 14:32 | nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Quit: ZNC - http://znc.in) | |
| 14:49 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Quit: http://www.twelvetribes.org) | |
| 15:00 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 15:11 | imox has left IRC (imox!~imox@p4FC5D41D.dip0.t-ipconnect.de, Quit: imox) | |
| 15:20 | imox has joined IRC (imox!~imox@p57A1F1E2.dip0.t-ipconnect.de) | |
| 15:33 | PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124) | |
| 15:41 | cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) | |
| 15:57 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 16:03 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 260 seconds) | |
| 17:25 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 17:32 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 18:25 | imox has left IRC (imox!~imox@p57A1F1E2.dip0.t-ipconnect.de, Quit: imox) | |
| 18:40 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.249.22, Ping timeout: 272 seconds) | |
| 18:42 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.58.138) | |
| 19:20 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 19:29 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 19:58 | cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Remote host closed the connection) | |
| 20:06 | PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving) | |
| 20:43 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 20:53 | alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Ping timeout: 246 seconds) | |
| 20:55 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 20:56 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 21:00 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds) | |
| 21:00 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 21:19 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 22:10 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 22:21 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 22:25 | khildin has left IRC (khildin!~khildin@ip-213-49-87-118.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 23:05 | clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto) | |
| 23:05 | shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com, Read error: Operation timed out) | |
| 23:06 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com) | |
| 23:06 | mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net, Ping timeout: 240 seconds) | |
| 23:06 | mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net) | |
| 23:07 | ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 240 seconds) | |
| 23:22 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |