IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 18 February 2012 (all times are UTC)
| 00:00 | <alkisg1> vagrantc: cool, but I think filing a bug to initramfs-tools is the way to go
| |
| 00:00 | <uskerine> vagrantc, what about accessing the server from windows, what can be used for that?
| |
| 00:01 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Disconnected by services) | |
| 00:01 | alkisg1 is now known as alkisg | |
| 00:01 | <vagrantc> uskerine: vnc, nx, rdesktop ...
| |
| 00:01 | er, RDP and xfreerdp
| |
| 00:02 | er, xrdp
| |
| 00:02 | <alkisg> :)
| |
| 00:02 | <vagrantc> not too familiar with the windows side of things
| |
| 00:02 | <uskerine> no i mean
| |
| 00:02 | which client should i use as "thin client" in windows?
| |
| 00:02 | <alkisg> x2go
| |
| 00:02 | <uskerine> for example, for XDMCP i used Xmin
| |
| 00:02 | for example, for XDMCP i used Xming
| |
| 00:03 | ok
| |
| 00:03 | is LTSP it faster or slower than XDMCP?
| |
| 00:03 | in a LAN environment I mean
| |
| 00:03 | with no network bandwidth issues
| |
| 00:03 | <vagrantc> no idea what xming is
| |
| 00:03 | <alkisg> An x server for windows
| |
| 00:04 | uskerine: fat clients == faster screen updates than thin clients == xdmcp when ldm_directx=true
| |
| 00:04 | <vagrantc> uskerine: LTSP can be configured to use XDMCP (though i wouldn't recommend it) ... you're comparing apples to oranges.
| |
| 00:05 | uskerine: LTSP is not a protocol, it is a mechanism for booting thin clients (and recently fat clients) off the network.
| |
| 00:05 | <uskerine> i see
| |
| 00:05 | i see
| |
| 00:05 | so basically it opens ssh connections, tunnels the X11 stuff
| |
| 00:05 | and runs the whole session
| |
| 00:05 | <vagrantc> it is the thin client operating system, which can use any protocols that your software supports.
| |
| 00:05 | <uskerine> ok o
| |
| 00:05 | understood
| |
| 00:05 | <vagrantc> uskerine: that's the default behavior
| |
| 00:06 | default is to make an SSH connection to the server and tunnel X traffic through it.
| |
| 00:06 | but it also supports many other options...
| |
| 00:06 | <uskerine> ok
| |
| 00:08 | * alkisg pumpkin goes to bed :) | |
| 00:09 | <uskerine> i will look to the page alkisg gave me, probably i will try first with thin client before going to the alpha release
| |
| 00:09 | and the fat client
| |
| 00:09 | but i like the idea of the fat client
| |
| 00:09 | <alkisg> uskerine: personally I wouldn't bother with thin clients if I had such good clients like the ones you're planning to get, but whatever suits you :)
| |
| 00:09 | 'night all
| |
| 00:09 | <highvoltage> night alkisg
| |
| 00:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 00:10 | <uskerine> i did not decide which thin client to buy yet
| |
| 00:10 | actually any recommendation for really cheap ones would be welcomed
| |
| 00:13 | <vagrantc> anything that's not ancient will probably work well as a fat client these days...
| |
| 00:13 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.107.166) | |
| 00:14 | <uskerine> understood
| |
| 00:23 | <vagrantc> filed bug against initramfs-tools with patch ... back to readying this upload...
| |
| 00:24 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds) | |
| 00:35 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 00:41 | <vagrantc> huh. i don't have the huge /var/cache/apt/ problem when using NBD...
| |
| 00:42 | switching back and forth between NBD and NFS is now trivially easy...
| |
| 00:42 | this is goooood.
| |
| 00:53 | rthomson has left IRC (rthomson!~rthomson@mars.pet.ubc.ca, Quit: Reached EOW) | |
| 00:56 | muppis has left IRC (muppis!muppis@viuhka.fi, Read error: Operation timed out) | |
| 00:57 | muppis has joined IRC (muppis!muppis@viuhka.fi) | |
| 00:58 | hughessd has left IRC (hughessd!~steve@173-164-117-109-Oregon.hfc.comcastbusiness.net, Quit: gone for some reason) | |
| 01:23 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds) | |
| 01:58 | shamino has joined IRC (shamino!shamino@hilla.kapsi.fi) | |
| 02:03 | darkpixel_ has left IRC (darkpixel_!~darkpixel@65.100.44.217, *.net *.split) | |
| 02:03 | veloutin has left IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca, *.net *.split) | |
| 02:03 | klausade has left IRC (klausade!~klaus@cm-84.215.157.180.getinternet.no, *.net *.split) | |
| 02:03 | shamino_ has left IRC (shamino_!shamino@hilla.kapsi.fi, *.net *.split) | |
| 02:07 | <vagrantc> if the screen.d/kiosk or kioskSession did a little more, we could make the ltsp-build-client plugin so much simpler.
| |
| 02:12 | darkpixel_ has joined IRC (darkpixel_!~darkpixel@65.100.44.217) | |
| 02:31 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.107.166, Ping timeout: 255 seconds) | |
| 02:43 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16) | |
| 02:47 | risca has left IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca, Quit: Lämnar) | |
| 02:48 | risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca) | |
| 02:55 | freedomrun has left IRC (freedomrun!~quassel@89.142.254.248, Remote host closed the connection) | |
| 03:10 | alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.15.11, Quit: Хана X'ам !!!) | |
| 03:17 | <vagrantc> wow, metacity pulls inn an extra 773MB of disk space ... gotta find something else to use for kiosk mode.
| |
| 03:19 | i wonder if we could use evilwm from ldm...
| |
| 03:33 | aewm kind of works, although window decorations still happen, but you can lock it down to not start much.
| |
| 03:50 | i guess i could install metacity without recommends... that's somewhat reasonable
| |
| 04:05 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.105.16, Ping timeout: 248 seconds) | |
| 04:15 | * vagrantc wonders how getltscfg handles multiple SCREEN_08 entries | |
| 04:15 | <vagrantc> the last one wins?
| |
| 04:16 | presuming it processes it in top-to-bottom order...
| |
| 04:17 | stgraber: i'd like to do some considerable re-writing of the kiosk stuff ... do you think that will be too invasive for you?
| |
| 04:19 | <stgraber> vagrantc: well, last I checked it wasn't really working, so I guess that could go as bugfix ;)
| |
| 04:19 | <vagrantc> i think we could move more of it into the screen.d script and kioskSession at runtime, which would turn the ltsp-build-client plugins intto simply package selection
| |
| 04:19 | i seem to have it basically working for debian now, only slightly modified from what ubuntu has.
| |
| 04:19 | just pushed the commit
| |
| 04:20 | !seen gadi
| |
| 04:20 | <ltsp> vagrantc: gadi was last seen in #ltsp 6 weeks, 3 days, 12 hours, 41 minutes, and 24 seconds ago: <Gadi> :)
| |
| 04:20 | <vagrantc> eesh
| |
| 04:20 | gadi, we expect you to read all that backscroll!
| |
| 04:21 | i'd really like to get an idea of why gadi made so many layers with the kiosk stuff
| |
| 04:22 | i.e. we could create the user at runtime and populate the homedir at runtime (if not already present) ...
| |
| 04:59 | risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) | |
| 05:35 | <vagrantc> hrm.
| |
| 05:36 | something in LTSP still assumes squafs with NBD...
| |
| 05:36 | or i haven't restarted nbd-server
| |
| 05:46 | staffencasa has left IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu, Ping timeout: 244 seconds) | |
| 05:50 | Parker955 is now known as Parker955_Away | |
| 05:52 | <vagrantc> hrm... it's getting a weird negotiated size error...
| |
| 05:52 | maybe it's because it's a sparse file...
| |
| 05:56 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 06:13 | freedomrun has joined IRC (freedomrun!~quassel@89.142.254.248) | |
| 06:28 | <vagrantc> ok, got that sorted out... wasn't using nbdroot=:ltsp_${CHROOT}
| |
| 06:34 | komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk) | |
| 06:48 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:01 | loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net) | |
| 07:27 | killermike has joined IRC (killermike!~killermik@2.26.100.159) | |
| 07:49 | <vagrantc> well, no Debian ltsp upload just yet, but did some needed cleanup
| |
| 07:52 | the bug in initramfs-tools 0.100 triggered some other odd behavior ... 00-kernel-env figured we must be on an NFS server even when using NBD, and other weirdnesses that didn't actually do much harm, from what i could see.
| |
| 08:02 | <alkisg> We could make a sanity check in 00-check-sanity if you're worried about it...
| |
| 08:08 | !learn epoptes-fat-clients as To launch epoptes from a fat client, follow this documentation page: http://www.epoptes.org/documentation/fat-clients
| |
| 08:08 | <ltsp> alkisg: The operation succeeded.
| |
| 08:13 | loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep) | |
| 08:24 | <vagrantc> alkisg: i figured we could cache /proc/cmdline somehow, even stick in in a variable.
| |
| 08:25 | alkisg: basically do what we do for net-*.conf
| |
| 08:25 | though hopefully this bug will get fixed and it doesn't really matter... it mostly works without it, anyways, just a few quirks.
| |
| 08:25 | <alkisg> Right... but since it's only a temporary workaround for some bug, I think I'd prefer to mount -t proc proc /proc instead, so that the changes are gathered in a single file (init-ltsp)
| |
| 08:26 | <vagrantc> might even not bother with the workaround
| |
| 08:27 | yeah, that might be simpler.
| |
| 08:27 | <alkisg> vagrantc: currently for nfs you're using aufs, not bindmounts, right?
| |
| 08:27 | Does that work ok? Did you try overlayfs?
| |
| 08:27 | <vagrantc> alkisg: don't have overlayfs in debian yet, but aufs seems to work fine on both NFS and NBD-based setups.
| |
| 08:28 | <alkisg> Very nice... so if we find a way to do the cow mounting from init-ltsp itself, then we won't need anything at all in the initramfs
| |
| 08:28 | <vagrantc> that'll be awfully messy.
| |
| 08:28 | <alkisg> Why?
| |
| 08:28 | <vagrantc> try mounting your own root out from under yourself.
| |
| 08:28 | <alkisg> In the future, we'll only need cow over /run
| |
| 08:29 | Not over /
| |
| 08:29 | (and /etc, in our case :D)
| |
| 08:29 | <vagrantc> that presumes everything writeable ends up in /run
| |
| 08:29 | <alkisg> But I think that we can do it now too
| |
| 08:29 | <vagrantc> i don't see why the push to get everything outside of the initramfs...
| |
| 08:29 | <alkisg> First make all the mounts to some system other than root, e.g. in one of the tmpfs's and then pivotroot to that
| |
| 08:30 | <vagrantc> it doesn't really seem to make the code much better than running from init-bottom ...
| |
| 08:30 | i guess it's in theory easier to make cross-distro?
| |
| 08:31 | <alkisg> I think so, but it also makes the code simpler, if we had nothing initramfs-related
| |
| 08:32 | <vagrantc> i don't see how the code is really any simpler, it's just the same code in a different place.
| |
| 08:32 | <alkisg> Having less and specific hook points == simplicity
| |
| 08:32 | <vagrantc> sure
| |
| 08:33 | <alkisg> I remember myself 2 years ago when I couldn't discriminate between initramfs scripts and initscripts :)
| |
| 08:33 | <vagrantc> though during this transition, it seems *way* more complicated :)
| |
| 08:34 | <alkisg> It'd be much easier for me to help with the code if it all was being started from 1 or 2 hook points
| |
| 08:34 | <vagrantc> it seems like init-ltsp.d and ltsp_config.d have a lot of overlapping potential.
| |
| 08:34 | <alkisg> Even later on I had to put debug echo's in ltsp_config to see how many times it gets called on boot (by ltsp-client-setup, but ltsp-client-core etc)
| |
| 08:34 | <vagrantc> and i really want to simplify the kiosk stuff so all the ltsp-build-client plugin handles is installing the appropriate packages.
| |
| 08:35 | and do most of the configuration at run-time...
| |
| 08:35 | <alkisg> I think ltsp_config and ltsp_config.d are a mess now, no cleanly specified functionalit
| |
| 08:35 | That'd be great
| |
| 08:35 | Even user creation
| |
| 08:36 | <vagrantc> right
| |
| 08:36 | <knipwim> speaking of cross-distro, my goal is to port the initramfstools scripts to dracut
| |
| 08:36 | <vagrantc> right now, with the shared uid/gid space, users on the system could edit the kiosk user's files...
| |
| 08:36 | <knipwim> dracut is the initramfs creation tool from fedora, but also used by gentoo
| |
| 08:37 | <vagrantc> knipwim: we're moving most of our functionality out of initramfs-tools lately, so that sshould be easier, i hope.
| |
| 08:37 | dracut is also available in debian
| |
| 08:38 | <knipwim> let me see if i understand correctly:
| |
| 08:38 | <vagrantc> but default is to use initramfs-tools
| |
| 08:38 | <knipwim> the bindmount/aufs functionality is going to init-ltsp
| |
| 08:38 | * vagrantc isn't convinced about that part | |
| 08:38 | <knipwim> and init-ltsp resides in the initramfs?
| |
| 08:38 | <alkisg> knipwim: no, it was just an idea
| |
| 08:39 | knipwim: we're using a custom init now as a kernel parameter
| |
| 08:39 | <vagrantc> knipwim: init-ltsp replaces /sbin/init for early execution of some parts
| |
| 08:39 | * alkisg leaves the explanation to vagrantc :) | |
| 08:40 | <vagrantc> knipwim: and then hands it off to the real /sbin/init when it's done ... hopefully that will work ok for you?
| |
| 08:40 | <knipwim> trying to wrap my head around it, what the actual boot process looks like
| |
| 08:40 | <vagrantc> knipwim: currently the initramfs just handles mounting the root filesystem, setting it up for writeability somehow, and then handing it off to /sbin/init-ltsp, which runs some hooks in /usr/share/ltsp/init-ltsp.d
| |
| 08:41 | <knipwim> like boot, load initramfs, start init-ltsp from that, which load the initramfs scripts, and then go to /sbin/init
| |
| 08:41 | ?
| |
| 08:41 | <vagrantc> that's a basic overview, yes.
| |
| 08:41 | <alkisg> Er, no?
| |
| 08:41 | <vagrantc> knipwim: actually, initramfs-scripts was renamed to init-ltsp
| |
| 08:41 | if that's what you're referring to as initramfs-scripts ...
| |
| 08:42 | <knipwim> yes
| |
| 08:42 | <alkisg> It's boot => initramfs => non-ltsp scripts mounting root => an ltsp script doing the cow thing => end of initramfs, we go to the real system, but not to the real init, to /sbin/init-ltsp instead,
| |
| 08:42 | ...so the previous initramfs scripts now run on the real system, not in the initramfs
| |
| 08:42 | <vagrantc> right.
| |
| 08:43 | <knipwim> ah, alkisg, that explains a lot
| |
| 08:43 | i thought the init-ltsp scripts were running in the initramfs
| |
| 08:43 | makes sense too
| |
| 08:43 | <alkisg> You can do that too, we even have code for it, but we don't use it
| |
| 08:43 | <vagrantc> that's the change alkisg made in the last few days.
| |
| 08:44 | <knipwim> i saw the different options in init-bottom/ltsp
| |
| 08:44 | it might be easier to implement than i tought
| |
| 08:45 | just have to get the bind mounting or aufs in dracut
| |
| 08:45 | <vagrantc> i've pretty much abandoned bind mounting at this point...
| |
| 08:45 | too hard to keep track of all the bits and pieces that need writeability
| |
| 08:45 | i sure hope it is stable.
| |
| 08:46 | <knipwim> aufs would also be my prefered choice
| |
| 08:47 | it's a bit of a hassle to include it in the initramfs
| |
| 08:47 | since gentoo doesn't include it in the kernel
| |
| 08:47 | <alkisg> You can do it from the real system if you put it over the few different root dirs like /usr, /etc, /bin
| |
| 08:48 | 3 cows instead of 1...
| |
| 08:48 | Maybe it can be done with pivot root too, dunno
| |
| 08:48 | (with 1 cow)
| |
| 08:50 | <vagrantc> knipwim: maybe you could consider building from source? :)
| |
| 08:51 | alkisg: i've switched back and forth between NBD and NFS and it's relatively easy now!
| |
| 08:52 | <alkisg> (basically we only write in /var and /etc, right? so 2 cows...)
| |
| 08:52 | vagrantc: what do you need for it, except change the kernel parameters?
| |
| 08:52 | <knipwim> vagrantc: yeah, something like that, there is a aufs package so i can build the kernel, install the module package, and build the initramfs after that
| |
| 08:52 | just written an aufs dracut module :)
| |
| 08:52 | <vagrantc> pretty much just have to: rm ${chroot}/etc/ltsp/update-kernels.conf && ltsp-chroot /usr/share/ltsp/update-kernels && ltsp-update-kernels
| |
| 08:53 | knipwim: although i guess upstream is moving towards overlayfs?
| |
| 08:53 | pretty similar, overall
| |
| 08:54 | <alkisg> vagrantc: err why do you have to run ltsp-update-kernels?
| |
| 08:54 | <vagrantc> alkisg: on ubuntu, you'd probably have to tweak the BOOTPROMPT_OPTS rather than removing them, but still pretty easy
| |
| 08:54 | alkisg: to push the pxelinux.cfg changes to the tftp dirs
| |
| 08:54 | <alkisg> Ah, ok, but if it's just to switch temporarily, you can manually edit pxelinux.cfg/default, no?
| |
| 08:54 | Without updating kernels...
| |
| 08:55 | <vagrantc> alkisg: sure
| |
| 08:55 | <alkisg> OK, so the same initramfs can boot both of them, that was the idea. Nice
| |
| 08:55 | <vagrantc> alkisg: but i've burned myself by doing "temporary" changes that then become the default, and then get switched back unexpectedly
| |
| 08:55 | <alkisg> We should fix ltsp-update-kernels to not do that :)
| |
| 08:55 | <vagrantc> so i prefer to know all the steps to change back and forth.
| |
| 08:56 | <alkisg> There's no point in calling update-initramfs just to make a pxelinux.cfg change
| |
| 08:56 | <vagrantc> alkisg: then it would fail to update when you need it to.
| |
| 08:56 | alkisg: it doesn't call update-initramfs
| |
| 08:56 | <alkisg> Ah, it doesn't? OK, good enough, I guess...
| |
| 08:57 | Why does the chroot need to know about the kernel parameters we're using?
| |
| 08:57 | (theoretically, not as we do it now)
| |
| 08:57 | <vagrantc> because it's building the pxelinux configuration, and we get the version of pxelinux that's "compatible" with the version we're booting.
| |
| 08:58 | also makes cross-architecture stuff easier.
| |
| 08:58 | i.e. each architecture is responsible for setting up it's own booting configuration.
| |
| 08:59 | <alkisg> Hmmm I don't like it...
| |
| 08:59 | The chroot can't know if the server uses nfs or nbd
| |
| 08:59 | <vagrantc> also, in theory, it could obviate the need for ltsp-update-kernels, if tftp were pointed directly at the chroot's boot files..
| |
| 08:59 | alkisg: it's a communication issue either way.
| |
| 09:00 | alkisg: either the chroot needs to know something about the server, or the server needs to generate arbitrary configurations for a chroot that it may not understand.
| |
| 09:00 | the server's job is to server up files, the chroot's job is to prepare those files for a particular arch/distro/release
| |
| 09:01 | <alkisg> OK, but I'm not talking about building the initramfs, but only about the kernel command line
| |
| 09:01 | <vagrantc> which varies by release...
| |
| 09:01 | <alkisg> But not all of it
| |
| 09:01 | <vagrantc> and i freuqently host multiple releases on a single server...
| |
| 09:02 | <alkisg> So I think the chroot should only have 1 configuration file with the *additional* kernel parameters it wants
| |
| 09:02 | And leave everything else up to the server
| |
| 09:02 | <vagrantc> in addition to what?
| |
| 09:02 | <alkisg> So no chroot involved to update pxelinux.cfg/deafult
| |
| 09:03 | <vagrantc> you're assuming a homogenous chroot environment ... what if the parameters are incompatible?
| |
| 09:03 | <alkisg> Let's see... which of those belong to the server, and which to the chroot?
| |
| 09:03 | append ro initrd=initrd.img root=/dev/nbd0 init=/sbin/init-ltsp nbdroot=:ltsp_i386 quiet splash plymouth:force-splash vt.handoff=7
| |
| 09:03 | Even if all of that belongs in the chroot, why does the server need to update it then?
| |
| 09:03 | Previously, we had the port stuff, ok, which was a problem
| |
| 09:04 | But we solved that problem by suggesting the IANA assigned port for nbd
| |
| 09:04 | The nfs path shouldn't be a responsibility of the chroot
| |
| 09:04 | <vagrantc> in order to change between NFS and NBD?
| |
| 09:04 | <alkisg> That's still a server responsibility
| |
| 09:04 | The chroot doesn't need to know about it
| |
| 09:05 | <vagrantc> but the server needs too know what the client can support, and vice-versa.
| |
| 09:05 | <alkisg> OK then the chroot can have a static configuration file to inform the server what it supports
| |
| 09:06 | E.g. nfsroot=$NBSROOT, nbdroot=$NBDROOT, and the server can replace the knows variables or strip the unknown ones, etc
| |
| 09:06 | <vagrantc> and maybe one chroot neeeds a particular version of pxelinux, and another chroot needs an entirely different bootloader...
| |
| 09:06 | markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, ) | |
| 09:06 | <alkisg> We don't have support for serving multiple pxelinux.0 versions
| |
| 09:06 | <vagrantc> and i could host an ubuntu, fedora, gentoo chroot all on the same server.
| |
| 09:06 | <alkisg> So that would still be a server thing, to provide a menu for the possible pxelinux.0 of the clients
| |
| 09:06 | <vagrantc> alkisg: sure we do... each chroot ships it's own copy of pxelinux
| |
| 09:06 | <alkisg> *of the chroots
| |
| 09:06 | VectorX has joined IRC (VectorX!knight@unaffiliated/vectorx) | |
| 09:06 | VectorX has left IRC (VectorX!knight@unaffiliated/vectorx) | |
| 09:07 | <alkisg> vagrantc: but our dhcpd.conf only points to one
| |
| 09:07 | <vagrantc> sure
| |
| 09:07 | <alkisg> So there's no point in "update-kernels" to run inside the chroot, it doesn't help with that
| |
| 09:07 | <vagrantc> admittedly, i usually ship one outside of ltsp entirely.
| |
| 09:08 | <alkisg> While, server-side, one could write the code to handle even multiple pxelinuxes
| |
| 09:08 | So my main question remains, why do we need to run code inside the chroot to update the kernel command line...
| |
| 09:08 | <vagrantc> the other task update-kernels does is prepare the nbi.img files, which aren't really used much anymore, and the obscure arches probably don't work.
| |
| 09:08 | <alkisg> Right
| |
| 09:09 | <vagrantc> so that i can sleep :)
| |
| 09:09 | <alkisg> Hehe
| |
| 09:09 | 'night vagrantc :)
| |
| 09:09 | <vagrantc> alkisg: also ran it inside the chroot so that the chroot was something you could easily drop on another server, and it was "ready to go" essentially ...
| |
| 09:10 | <alkisg> I don't think that helps anywhere...
| |
| 09:10 | The "other server" would again read the chroot desired command line from the configuration file
| |
| 09:10 | <vagrantc> powerpc needs to ship yaboot, which isn't available on i386, for example.
| |
| 09:11 | and the server would need to know how to parse the yaboot configuration
| |
| 09:11 | <alkisg> Still, the server side script copies that
| |
| 09:11 | It's just a matter of where you put the code, it's not like we can run binaries in a mac chroot anyway
| |
| 09:11 | <vagrantc> (well, you can with arm, but that's another story)
| |
| 09:12 | <alkisg> The best thing that would come out of moving the scripts server-side, is that the server would be able to provide pxelinux etc menus
| |
| 09:12 | So, multiple chroots => automatic boot menus
| |
| 09:12 | <vagrantc> right, that would be a good thing.
| |
| 09:13 | well, it's not like any distros are in freeze any time soon, right?
| |
| 09:13 | <alkisg> :D
| |
| 09:13 | Nah, there are more significant things to do first
| |
| 09:13 | Like being able to install ltsp-client to a normal pc
| |
| 09:13 | The pxelinux menus should go in a separate package, not in the ltsp code tree
| |
| 09:14 | E.g. in pxelinux itself
| |
| 09:14 | <vagrantc> it has gotten klunky, i'll admit. at the time i changed it, it seemed like i had good reasons (the most attractive being the chroot's /boot being served up from tftp directly and always being current)
| |
| 09:14 | <alkisg> That's just the kernel again, not the configuration
| |
| 09:14 | <vagrantc> i really hate having to run ltsp-update-kernels after doing a kernel update in the chroot ... it just seems like busywork.
| |
| 09:15 | <alkisg> So without --secure in tftpd-hpa, and with the pxelinux-menus package, one could still serve the /boot directly from the chroot
| |
| 09:15 | <vagrantc> but i haven't gotten it together well enough to make that viable.
| |
| 09:15 | by using symlinks?
| |
| 09:15 | those annoying security defaults, though... meh.
| |
| 09:15 | <alkisg> One way to do it, ye
| |
| 09:15 | s
| |
| 09:15 | * alkisg really thinks that dnsmasq is more suitable for ltsp | |
| 09:16 | <alkisg> At some point I'd like to convince you and stgraber to switch to it by default
| |
| 09:16 | <vagrantc> like you say, there are some larger things to tackle first
| |
| 09:16 | alkisg: does it help any that i've done all my ltsp development using dnsmasq for the last few months?
| |
| 09:16 | <alkisg> Hehe :D
| |
| 09:16 | Really, why dhcpd3 and tftpd-hpa then?
| |
| 09:16 | <vagrantc> i like dnsmasq, i've just stuck with all the others due to historic inertia
| |
| 09:17 | <alkisg> Large setups have big sysadmins that get annoyed by the ltsp dhcp override
| |
| 09:17 | Small setups have routers as the dhcp servers, where dnsmasq can do proxydhcp
| |
| 09:17 | <vagrantc> i don't do the override.
| |
| 09:17 | <alkisg> (or can work with 2 nics in the same time)
| |
| 09:17 | Let's try it for the next releases
| |
| 09:17 | <vagrantc> i don't default the override, i always thought that was crazy.
| |
| 09:18 | <alkisg> The ltsp-server.postinst could install dnsmasq, and create an appropriate configuration file,
| |
| 09:18 | i.e. if it detects dhcpd, only use it as tftp server,
| |
| 09:19 | if it detects no dns, use it as dns too for the clients,
| |
| 09:19 | if it doesn't detect dhcpd, use it as a dhcpd too
| |
| 09:19 | If it detects a single nic, with external dhcpd, use proxy, etc etc
| |
| 09:19 | <vagrantc> sounds good to me.
| |
| 09:19 | <alkisg> Out of the box for most cases
| |
| 09:19 | OK, we'll tackle it in the future
| |
| 09:20 | <vagrantc> although i'm always very conservative about autoconfiguration
| |
| 09:20 | <alkisg> We'll make it behave well :)
| |
| 09:21 | * vagrantc still hasn't invested the time to make ltsp-update-image behave well | |
| 09:21 | <vagrantc> although i gutted some pointless calls recently...
| |
| 09:21 | <alkisg> The major problem there is still the kernel command line etc, isn't it?
| |
| 09:21 | <vagrantc> yeah.
| |
| 09:21 | <alkisg> I think to properly solve it, we need to create a pxelinux-menus package
| |
| 09:22 | And depend on that
| |
| 09:22 | <vagrantc> recommend...
| |
| 09:22 | <alkisg> And hope other packages can start using it too, maybe even put it in the pxelinux package
| |
| 09:23 | risca has left IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net, Ping timeout: 248 seconds) | |
| 09:23 | <vagrantc> although with the new switch-over, ltsp-update-image isn't nearly as much of a takeover your system sort of thing as it used to be.
| |
| 09:23 | * vagrantc is still tempted to ship /etc/ltsp/ltsp-update-image.conf with "exit 0" | |
| 09:23 | <alkisg> Haha
| |
| 09:24 | Just put a big warning inside an "if ltsp-update-image detects that we're using nfs..."
| |
| 09:24 | <vagrantc> but there's not really a good way to detect if you're using nfs
| |
| 09:25 | i might want to use both NFS and NBD from the same chroot, depending on what i'm doing.
| |
| 09:25 | i.e. test new features from NFS, release using NBD for the speed improvements.
| |
| 09:26 | <alkisg> We should be able to detect what the chroot used last time
| |
| 09:26 | <vagrantc> i think that's a very reasonable use-case... and forcing the updated plxelinux.cfg each run is problematic
| |
| 09:26 | <alkisg> I.e. if it had nbdroot= in its kernel command line or not
| |
| 09:26 | <vagrantc> what about concurrently?
| |
| 09:26 | i don't think there is a meaningful "last time"
| |
| 09:26 | <alkisg> If you need multiple pxelinux menu entries for the same chroot, you should have multiple entries in its configuration
| |
| 09:27 | You'd e.g. ship with nfs as the default entry
| |
| 09:27 | veloutin has joined IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca) | |
| 09:27 | <vagrantc> now that would be cool, to generate your choice...
| |
| 09:27 | i.e. if it supports both, allow selecting either at boot
| |
| 09:27 | <alkisg> Then, on the first time the user runs ltsp-update-image for that chroot, you'd ask him about generating a new entry or not
| |
| 09:27 | <vagrantc> we're way closer to being able to do that
| |
| 09:27 | <alkisg> And if so, it'd generate 2 menu entries
| |
| 09:28 | And it wouldn't need to ask again on later calls
| |
| 09:28 | <vagrantc> anyways, i need to break this habit of staying up way too late...
| |
| 09:28 | <alkisg> :)
| |
| 09:28 | 'night again
| |
| 09:28 | <vagrantc> heh
| |
| 09:28 | maybe i can push 5.3.1 on monday...
| |
| 09:28 | * vagrantc still hasn't tested on squeeze | |
| 09:29 | * alkisg will have pushed the changes for bootable ltsp-client by then | |
| 09:31 | <alkisg> OK, let's try installing ltsp-client in a xubuntu vm...
| |
| 09:35 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 252 seconds) | |
| 09:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds) | |
| 09:41 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 09:41 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16) | |
| 09:43 | risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) | |
| 09:56 | risca has left IRC (risca!~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net, Quit: Lämnar) | |
| 09:57 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 09:58 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 10:26 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 10:27 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 10:47 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 10:48 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 10:53 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 11:09 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 11:10 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 11:53 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 11:54 | freedomrun_ has joined IRC (freedomrun_!~quassel@89.142.254.248) | |
| 11:54 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 11:54 | freedomrun_ has left IRC (freedomrun_!~quassel@89.142.254.248, Read error: Connection reset by peer) | |
| 11:55 | freedomrun has left IRC (freedomrun!~quassel@89.142.254.248, Ping timeout: 276 seconds) | |
| 12:23 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Read error: Operation timed out) | |
| 12:35 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 13:00 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds) | |
| 13:08 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 13:10 | khildin has joined IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be) | |
| 13:30 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 13:49 | staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu) | |
| 13:49 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Read error: Operation timed out) | |
| 13:50 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 14:00 | komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.) | |
| 14:12 | staffencasa has left IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu, Ping timeout: 240 seconds) | |
| 14:38 | bakytn has joined IRC (bakytn!~bakytn@80.72.176.101) | |
| 14:44 | bakytn has left IRC (bakytn!~bakytn@80.72.176.101, ) | |
| 14:44 | bakytn has joined IRC (bakytn!~bakytn@80.72.176.101) | |
| 15:02 | mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Ping timeout: 260 seconds) | |
| 15:02 | mistik1_ has joined IRC (mistik1_!mistik1@184.170.1.113) | |
| 15:02 | mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1) | |
| 15:02 | mistik1_ is now known as mistik1 | |
| 15:05 | Parker955_Away is now known as Parker955 | |
| 15:10 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 272 seconds) | |
| 15:14 | bakytn has left IRC (bakytn!~bakytn@80.72.176.101, ) | |
| 15:21 | markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it) | |
| 15:24 | zamba has joined IRC (zamba!marius@flage.org) | |
| 15:40 | * alkisg just installed lubuntu 12.04 in vbox, then installed ltsp-client on top of it, exported the result to the ltsp server, and booted a fat client using that chroot! | |
| 15:43 | <markit> alkisg: I don't understand fully.. but seems good news :)
| |
| 15:44 | alkisg: btw, 12.04 is feature freeze... are you still in time for ltsp "improved version"?
| |
| 15:44 | <alkisg> markit: it means that when we get to support that, you'll be able to maintain fat chroots using virtualbox
| |
| 15:44 | <markit> or kvm? :9
| |
| 15:44 | <alkisg> Sure, or real clients
| |
| 15:44 | <markit> or none of the above, if the server does not support decent virtualization?
| |
| 15:44 | <alkisg> You'll be able e.g. to install ubuntu in a powerpc, install any proprietary drivers that you need, use the software center to install programs, and then copy the result to the ltsp server
| |
| 15:45 | * markit orrifies when reads "proprietary" ;P | |
| 15:45 | <alkisg> Hehe... there are devices that _only_ have proprietary drivers though :)
| |
| 15:46 | <markit> btw, today the server frooze, all clients were running, and at teh end of teh hour all childred logged out... but some was unable and I discovered the server was frozen
| |
| 15:46 | alkisg: I don't buy them then :)
| |
| 15:46 | btw, performances will be the same, only much easier to mantein for "no tecnicians" if I understand correctly
| |
| 15:47 | <alkisg> I'm afraid that this functionality won't make it for 12.04
| |
| 15:47 | Yes, performance will be the same
| |
| 15:47 | No virtualization needed on the server
| |
| 15:48 | <markit> urgh, not for 12.04, that is a bad news :( so 12.04 will have almost the current ltsp I'm used to?
| |
| 15:48 | (with some new bug, of course ;P)
| |
| 15:48 | <alkisg> Hehe, and lots of bug fixes too
| |
| 15:48 | LTSP 5.3 has many changes
| |
| 15:48 | <markit> great, thank very very much for your work
| |
| 15:49 | btw, do you have a list handy of ports that have to be kept open among (fat/thin) clients and the server?
| |
| 15:49 | I'd like to pur more restrictive rules in the firewall (shorewall) but without compromise functionality ;)
| |
| 15:50 | <alkisg> You really need a firewall in your internal network? Or are you using a single nic setup?
| |
| 15:50 | <markit> so I need to know that traffic let flow and in what direction connection are estabilished
| |
| 15:50 | I don't really need
| |
| 15:50 | and single nick is something I've yet to look at
| |
| 15:51 | I prefer dual nic, but as you told me time ago, you are not always in the better (ideal) condition, so better be prepared
| |
| 15:52 | <alkisg> you need ssh, tftp, dhcp, dns, nbd, ldminfod and some others that I don't remember. Better check your firewall for which ports are trying to get accessed.
| |
| 15:56 | <markit> alkisg: sure, I asked just in case sch-script already did this
| |
| 15:57 | <alkisg> Nope, we don't care about security :)
| |
| 15:57 | <markit> I love that man ;P
| |
| 15:57 | now I'm in troubles with a joomla problem, see you later and happy hacking :)))
| |
| 15:58 | <alkisg> bb
| |
| 16:08 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 16:18 | freedomrun has joined IRC (freedomrun!~quassel@89.143.187.23) | |
| 16:21 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.105.16, Ping timeout: 252 seconds) | |
| 16:29 | komunista has joined IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk) | |
| 16:49 | killermike has left IRC (killermike!~killermik@2.26.100.159, Remote host closed the connection) | |
| 16:50 | killermike has joined IRC (killermike!~killermik@2.26.100.159) | |
| 17:00 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 265 seconds) | |
| 17:27 | markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, ) | |
| 17:34 | ltsp` has joined IRC (ltsp`!ltspbot@middelkoop.cc) | |
| 17:35 | sunson_ has joined IRC (sunson_!~suraj@li290-74.members.linode.com) | |
| 17:36 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
| 17:36 | Kevin`_ has joined IRC (Kevin`_!~kevin@router.kwzs.be) | |
| 17:37 | ltsp has left IRC (ltsp!ltspbot@middelkoop.cc, Ping timeout: 240 seconds) | |
| 17:37 | Kevin` has left IRC (Kevin`!~kevin@router.kwzs.be, Ping timeout: 240 seconds) | |
| 17:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
| 17:37 | Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, Ping timeout: 240 seconds) | |
| 17:37 | Hyperbyte has left IRC (Hyperbyte!jan@middelkoop.cc, Ping timeout: 240 seconds) | |
| 17:37 | sunson has left IRC (sunson!~suraj@li290-74.members.linode.com, Ping timeout: 240 seconds) | |
| 17:37 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Ping timeout: 240 seconds) | |
| 17:37 | gentgeen__ has left IRC (gentgeen__!~kevin@c-98-236-71-64.hsd1.pa.comcast.net, Ping timeout: 240 seconds) | |
| 17:37 | sutula has left IRC (sutula!sutula@nat/hp/x-oiokfitkauoygjwn, Ping timeout: 240 seconds) | |
| 17:37 | khildin has left IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be, Ping timeout: 240 seconds) | |
| 17:37 | SmallR2002 has left IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net, Ping timeout: 240 seconds) | |
| 17:37 | gentgeen__ has joined IRC (gentgeen__!~kevin@c-98-236-71-64.hsd1.pa.comcast.net) | |
| 17:37 | alkisg1 is now known as alkisg | |
| 17:37 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 17:37 | SmallR2002 has joined IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) | |
| 17:38 | sutula has joined IRC (sutula!sutula@nat/hp/x-ficyrhegrxvmfakb) | |
| 17:38 | khildin has joined IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be) | |
| 17:38 | Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw) | |
| 17:49 | r0cketeer has joined IRC (r0cketeer!~r0cketeer@189.194.242.97) | |
| 17:50 | <r0cketeer> what kind of server computer do i need for a classroom about 12 computers?
| |
| 17:50 | <alkisg> How much RAM on the clients?
| |
| 17:51 | <r0cketeer> 512MB
| |
| 17:51 | <alkisg> A normal PC would do just fine, some dual or quad core with about 3 gb ram
| |
| 17:51 | You'd probably want to run some localapps for better efficiency
| |
| 17:52 | Gigabit networking is also strongly suggested
| |
| 17:53 | <r0cketeer> ok, so what do you think about the cost of the infraestructure between LTSP and each computer running EDUbuntu?
| |
| 17:54 | is cheapper LTSP?
| |
| 17:54 | <alkisg> You can't run edubuntu efficiently with 512 mb ram clients
| |
| 17:54 | So you'd have to buy new ones, so ltsp will be cheaper, yes
| |
| 17:55 | And it's also easier to manage after you learn a few things about it
| |
| 17:55 | <r0cketeer> All right, I'm trying to implement EDUBuntu in poor child schools here in Mexico, and Iḿ trying to know wich topology fits better
| |
| 17:56 | thank you very much
| |
| 17:59 | <alkisg> r0cketeer: is it just for 1 school, or for many?
| |
| 17:59 | * alkisg has put ltsp in about 250 greek schools, with 12 pcs per class and 1 server... | |
| 18:04 | <alkisg> r0cketeer: (replying to pm) yes, ltsp is very flexible, it supports thin clients, fat clients, localapps etc
| |
| 18:07 | <r0cketeer> | |
| 18:07 | <alkisg> r0cketeer: start one installation, and whenever you have questions, you can come back in the channel and ask
| |
| 18:07 | No need to take it all in now
| |
| 18:08 | Parker955 is now known as Parker955_Away | |
| 18:10 | <r0cketeer> great, Probably we will be back for sure, to share experience about it. Next week we start our first class about it with child rescue for familiar violence
| |
| 18:10 | so wish us luck
| |
| 18:10 | We think that we will change they reallity about life with ths distro
| |
| 18:11 | <alkisg> Don't worry children learn fast
| |
| 18:11 | Good luck!
| |
| 18:12 | <r0cketeer> Thank you very much alkisg, see you around!
| |
| 18:13 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 18:15 | r0cketeer has left IRC (r0cketeer!~r0cketeer@189.194.242.97, Quit: Saliendo) | |
| 18:23 | freedomrun has left IRC (freedomrun!~quassel@89.143.187.23, Remote host closed the connection) | |
| 18:25 | freedomrun has joined IRC (freedomrun!~quassel@89.143.187.23) | |
| 18:39 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 18:40 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 18:58 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 19:29 | ||cw has left IRC (||cw!~chris@phpgroupware/cw, Read error: Connection reset by peer) | |
| 19:29 | ||cw has joined IRC (||cw!~chris@gateway.wilsonmfg.com) | |
| 19:30 | ||cw has joined IRC (||cw!~chris@phpgroupware/cw) | |
| 19:38 | risca has joined IRC (risca!~risca@wi-secure-8039.cc.umanitoba.ca) | |
| 19:46 | Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc) | |
| 20:16 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 20:24 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 20:31 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 20:34 | staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-241.oregonstate.edu) | |
| 20:43 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.105.16) | |
| 21:05 | khildin has left IRC (khildin!~khildin@ip-80-236-222-61.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 21:08 | mistik1_ has joined IRC (mistik1_!mistik1@unaffiliated/mistik1) | |
| 21:09 | mistik1 has left IRC (mistik1!mistik1@unaffiliated/mistik1, Remote host closed the connection) | |
| 21:09 | mistik1_ is now known as mistik1 | |
| 21:10 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 21:12 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 21:19 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 21:20 | killermike has left IRC (killermike!~killermik@2.26.100.159, Remote host closed the connection) | |
| 21:20 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 21:29 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 21:37 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 21:37 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 22:00 | vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 240 seconds) | |
| 22:04 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 22:05 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 22:05 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 22:09 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds) | |
| 22:20 | Parker955_Away is now known as Parker955 | |
| 22:23 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 22:23 | uskerine has joined IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net) | |
| 22:45 | uskerine has left IRC (uskerine!~uskerine@210.Red-2-138-168.dynamicIP.rima-tde.net, Read error: Connection timed out) | |
| 22:46 | Parker955 is now known as Parker955_Away | |
| 22:47 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 23:20 | vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Quit: leaving) | |
| 23:28 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 23:33 | komunista has left IRC (komunista!~slavko@adsl-195-098-015-242.dynamic.nextra.sk, Quit: Leaving.) | |