IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 27 April 2015   (all times are UTC)

00:05jgalt has joined IRC (jgalt!47697af2@gateway/web/freenode/ip.71.105.122.242)
00:06
<jgalt>
just installed ltsp on debianant clientsv
00:08
get as far as pxe loading pxe linux.... then display "connection refused" ad infintium
00:08
how may the problem be found?
00:47AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-bxrvrbfheyfsltie, Quit: Connection closed for inactivity)
00:58cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net)
01:03
<vagrantc>
jgalt: probably need to configure NFS in /etc/exports or /etc/exports.d/
01:04
"ltsp-config nfs" might work.
01:07
<jgalt>
what does it need configured to?
01:08
<vagrantc>
to allow mounting the LTSP root filesystem
01:09
unless you've configured your LTSP to use NBD or AOE instead of NFS, but NFS is the default on Debian
01:10
<jgalt>
vagrantc: ok, also after the install name resolution quit. any ideas on that?
01:11
<vagrantc>
jgalt: after running ltsp-build-client ??
01:11
jgalt: also, is this debian jessie, which was released yesterday?
01:11
for new installations, i'd definitely recommend going with jessie
01:12
<jgalt>
yes, the host has been running jessie amd64 for about 4 months
01:13
<vagrantc>
ok.
01:13
<jgalt>
the build client step built the chroot for i386 as instructed.
01:13
<vagrantc>
ok.
01:16
<jgalt>
clients come up under pxe boot and show pxelinuxas having loaded then pretty much immediately show "connection reffused"
01:16
so yes, likely name resolution died sometime after running ltsp-build-client
01:17
<vagrantc>
the server can't do name resolution, or the clients?
01:17
<jgalt>
but not totally sure. the process asked for reboot and when I did that and logged in again it couldn't find (resolve) google.com, yahoo.com, or sparkfun.com but would ping ip addresses on mylan and the internet just fine.
01:18Dsys has left IRC (Dsys!466ada6e@gateway/web/freenode/ip.70.106.218.110, Ping timeout: 246 seconds)
01:18
<vagrantc>
hard to imagine ltsp-build-cleint doing anything that would cause that problem...
01:22
<jgalt>
ok, name resolution now works. started working again after "apt-get remove resolvconf" and reboot. seems the resolvconf program was getting in the way.
01:23MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)
01:23
<jgalt>
now to get the clients to netboot...... without "connection reffused"
01:24MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer)
01:25
<jgalt>
I tried ltsp-config nfs and that does basicly nothing except output the help for ltsp-config
01:25MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)
01:25
<vagrantc>
ok, i guess i didn't get support into jessie for that ... gah.
01:26
jgalt: https://wiki.debian.org/LTSP/Howto
01:27
jgalt: step 4
01:30
<jgalt>
vagrantc: followed those steps exactly, only difference being that I had to use dnsmasq because there is already a dhcp server running on the local lan and certain other users of this network would engage upon a witch hunt if I messed with that dhcpserver.
01:31* vagrantc nods
01:31
<vagrantc>
my guess is then it's trying to connect to your router rather than the LTSP server.
01:32
<jgalt>
unfortunately isc-dhcpd aparently won't do proxy-dhcp. I would have rather used the isc tools
01:34
<vagrantc>
jgalt: you'll need to add nfsroot=ip.of.ltsp.server:/opt/ltsp/i386 to /opt/ltsp/i386/etc/ltsp/update-kernels.conf to CMDLINE_NFS="root=/dev/nfs ip=dhcp boot=nfs"
01:34
<jgalt>
what is trying to connect to my router? do you mean the net-boot client is trying to connect to my router? the net-boot client displays the proper addresses for the tftp server
01:34
ah ok
01:34
<vagrantc>
oh, also you can use IPAPPEND=3
01:34
then it won't make a second request ... might obviate the need to mess with specifying the ip address explicitly
01:34MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Read error: Connection reset by peer)
01:35MarconM has joined IRC (MarconM!~Marcelo@unaffiliated/marconm)
01:36
<vagrantc>
once you've edited update-kernels.conf, you'll need to run: ltsp-chroot /usr/share/ltsp/update-kernels
01:36
and then: ltsp-updatekernels
01:36
or rather: ltsp-update-kernels
01:36
<jgalt>
in this case does it not need to make a second request? first request to get an ip address, then second request to get tftp server info?
01:36
<vagrantc>
the first updates /opt/ltsp/i386/boot with the new values, the second copies the stuff from /opt/ltsp/i386/boot to your tftp dir.
01:37
well, it's an NFS, NBD or AOE server that the second request is looking for
01:37
but yes, IPAPPEND=3 re-uses the first DHCP request
01:38
there are typically two DHCP requests made, one for PXE boot, and one from the booted initramfs.
01:38
<jgalt>
second request of the pxe bootloader or second request of pxe linux?
01:39
<vagrantc>
pxelinux re-uses the PXE stack
01:40
1. PXE makes a DHCP request, downloads pxelinux, which downloads it's configuration files
01:40
<jgalt>
ah, ok. may need to rebootthis box to try.
01:40
<vagrantc>
2. pxelinux downloads kernel and initrd and executes them
01:40
3. running initrd makes a DHCP request to find out it's root filesystem server
01:41
4. initrd attempts to mount the root filesystem and execute init
01:42
<jgalt>
ok, on a differen't but slightly related topic how is ltsp much different than setting up a bunch of diskless netbooting x-terms?
01:42
<vagrantc>
it's a specific implementation of diskless netbooting x-terms.
01:44
<jgalt>
ah, ok. so all software runs on the ltsp host and you are left with just an x-term display on your desk, correct?
01:44
<vagrantc>
that's an option.
01:44
unforunately, there are a lot of confusing namespace clashes here, though.
01:45
<jgalt>
how can I tell or control what runs where?
01:46
<vagrantc>
well, i'm having a hard time with the terms you're using... x-term can mean about half a dozen different but related things
01:46
maybe i should just describe the typical LTSP use cases...
01:46
<jgalt>
oh, sorry x11 display
01:47
hope that's clearer
01:47
<vagrantc>
thin client: connects to the LTSP server and runs all applications on the LTSP server
01:47
fat client: boots off of LTSP server, authenticates against the LTSP server, but runs applications on the client hardware
01:48
thin client with localapps: runs most applications on LTSP server, but some applications on client hardware
01:48
fat client with remoteapps: runs most applications on client hardware, but some applications on the LTSP server
01:48
x11 display is also prone to great confusion :)
01:49* vagrantc prefers to talk in terms of LTSP servers and LTSP clients
01:49
<jgalt>
ok, so after following the debian instructions referenced I end up with......? thin client?
01:49
<vagrantc>
yup
01:50
LTSP by default uses LDM to connect to the server, which is effectively a GUI frontend to "ssh -X", although you can just use ssh for the authentication phase and use plain X11 traffic afterwards.
01:51
<jgalt>
ok, probably what I wanted as I'm using a core2 duo to get some more life out of a bunch of p3's around the house. they are really snappy running as remote x displays.
01:51
<vagrantc>
with the performance vs. security tradeoffs, of course
01:51
the available ram is almost more important than CPU for fat vs. thin clients
01:52
thin clients can squeak by with 128-256mb of ram, for a fat client you'll probably want at least 1GB ... more is better, of course.
01:53cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Read error: Connection reset by peer)
01:53
<vagrantc>
(which doesn't seem particularly thin to someone who first started doing thin clients with 8MB of ram and servers with 256MB ...)
01:53
<jgalt>
well some of those would be hurting to have 512MB of ram. more likely 128 or 256.
01:54cstk421 has joined IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net)
01:55
<vagrantc>
if you can, look at how much power they draw ... i didn't do comparisons on pIII generation stuff, but P-4 vs. Pentium D vs. core2 systems was shocking.
01:55
pentium D barely performed better than a P-4, but drew 50% more power than either the p-4 or the core2
01:59
<jgalt>
biggest thing is that the core2 will take about 4x the ram.
02:00
the p3's are crawling even running xp. this should be a nice upgrade for my housemates.
02:01
....and a good way to get them running linux.
02:02
...just set them to netboot their boxen as thin clients.
02:04
<vagrantc>
nice
02:06
<jgalt>
and if they complain too much, I can't be accused of removing windows from their prescious computers..... just reset the boot sequence and they are back to working as blisful snails.
02:20
rebooting.....
02:23cstk421_ has joined IRC (cstk421_!~cstk421@ip-64-134-190-30.public.wayport.net)
02:24cstk421 has left IRC (cstk421!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
02:24cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net)
02:25jgalt has left IRC (jgalt!47697af2@gateway/web/freenode/ip.71.105.122.242, Ping timeout: 246 seconds)
02:26cstk421__ has joined IRC (cstk421__!~cstk421@ip-64-134-190-30.public.wayport.net)
02:27MarconM has left IRC (MarconM!~Marcelo@unaffiliated/marconm, Quit: Leaving)
02:28cstk421_ has left IRC (cstk421_!~cstk421@ip-64-134-190-30.public.wayport.net, Ping timeout: 245 seconds)
02:28cstk421_ has joined IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net)
02:29cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Ping timeout: 250 seconds)
03:02cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net)
03:04cstk421_ has left IRC (cstk421_!~cstk421@173-14-40-58-Michigan.hfc.comcastbusiness.net, Ping timeout: 252 seconds)
03:21cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Remote host closed the connection)
03:21cstk421 has joined IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net)
03:30vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
03:39Eric___ has joined IRC (Eric___!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net)
03:39Eric___ is now known as jgalt
03:46map7 has joined IRC (map7!~map7@teksup41.lnk.telstra.net)
04:00
<jgalt>
opt/ltsp/i386/etc/ltsp/update-kernels.conf : http://paste.debian.net/169225/
04:02
still having trouble after a chat with vagrantc earlier today getting clients to boot
04:03
IPAPPEND=3 seems tonot quite do it.
04:04
clients still sho a connection refused message.
04:15jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection)
04:23jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net)
04:26
<jgalt>
http://paste.debian.net/169231/
04:27
same problem.....
04:28
any idea as to what's wrong and why the client connection to the server is refused?
04:28cstk421 has left IRC (cstk421!~cstk421@ip-64-134-190-30.public.wayport.net, Remote host closed the connection)
04:32jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection)
04:43jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net)
04:55
<vsuojane1>
jgalt: if you are getting connection refused after loading pxelinux it mostly means that the server where nfs/nbd/aoe images are is not available for the client machine
04:58
<jgalt>
vsuojane1: I'm a bit confused.... how is it "not available for the client machine"?
04:59
<vsuojane1>
if you could first troubleshoot the network and dhcp setup you are able better resolve is there something -- what is wrong in the ltsp server
04:59
<jgalt>
the client is netloading pxelinux from the same server
05:00
<vsuojane1>
yes, how the client connection to the server is refused ?
05:02
pxelinux is downloaded with the dhcp client (the dhcp boot parametere are conffigured in the local dhcp or proxy dhcp)
05:02
<jgalt>
the client when told to pxe boot finds the network dhcp server running on the router and gets assigned 192.168.1.4 with a /24 netmask
05:03
<vsuojane1>
oh sorry pxelinux is loaded -- not downloaded
05:04
<jgalt>
the dhcp server on the router that does that is unable to give info about the tftp server so the dnsmasq server running on the ltsp box works as a dhcp proxy and fills in that info.
05:06
<vsuojane1>
ok.. you have dnsmasq configured on the ltsp server.
05:06
<jgalt>
I can see the pxe boot client display the proper info for ip address dhcp server, gateway, netmask, tftp server, everything right
05:06
yes dnsmasq is configured on the ltspserver and seems to be working as it should.
05:07
pxelinux loads noproblem
05:08
then it displays, "connection refused" ad infintium
05:08
that's where it'sstuck
05:10
couldn't use isc-dhcp because there's already a dhcp server running on the network which I can't touch.
05:10
....but that part seems to work.
05:13
vsuojane1: any ideas?
05:15
<vsuojane1>
it doesn't get the connection to the client root system, thats the issue
05:16
<jgalt>
yes, I'm aware. but why is the question.
05:17
<vsuojane1>
and /opt/ltsp *(ro,no_root_squash,async,no_subtree_check)
05:18
do you have this on your ltsp server nfs exports ?
05:18
<jgalt>
yes, you can look at pastebin think posted it.
05:18
sec I'll paste again
05:19ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:20
<jgalt>
http://paste.debian.net/169236/
05:21
^^ /etc/exports
05:27
<vsuojane1>
can you mount the nfs exports from the server ? are you able to test the mount from different mahcine on the same network ?
05:32work_alkisg is now known as alkisg
05:33
<alkisg>
jgalt: what's your pxelinux.cfg/default like?
05:36
<jgalt>
alkisg: can you give a full path? looking at syslog it looks like that file may be missing but is that the same file?.... what's the path where it should be?
05:36
<alkisg>
jgalt: /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
05:37
(or amd64, if appropriate)
05:37
<jgalt>
vsuojane1: how would I mount the nfsmounts on another machine.... or on the ltsp server iself?
05:38
<vsuojane1>
check alkisg thing first
05:39
<alkisg>
Check nfs is useful too, both of those troubleshooting actions are
05:40
<jgalt>
http://paste.debian.net/169243/
05:40
<vsuojane1>
yes. but i would check first that pxe configs
05:41
<alkisg>
jgalt: the server's ip didn't make it into that file
05:41
<jgalt>
^^var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
05:41
<alkisg>
append ro initrd=initrd.img-3.16.0-4-586 init=/sbin/init-ltsp quiet root=/dev/nfs ip=dhcp boot=nfs nfsroot=192.168.1.3:/opt/ltsp/i386
05:41
jgalt: try changing it to this ^
05:41
Then reboot client
05:41
Or, change ipappend 2 to ipappend 3
05:42
One of them
05:42
<vsuojane1>
hmmm. ipappend 2. is it reusing the dhcp or getting new from the default/authorative dhcp ?
05:43
<alkisg>
ipappend 2 tells the client to use the same NIC as the one in PXE
05:43
Nothing more, it doesn't tell it to reuse the IP or the same server
05:45
(like ipappend 3 does)
05:46
<jgalt>
should I not change /etc/ltsp/update-kernels.conf instead asit says to?
05:47
<alkisg>
For the troubleshooting part, no
05:47
Later on to make it permanent, yes
05:50
<jgalt>
brb - gotta reboot this box so I can test the client.
05:50jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net, Remote host closed the connection)
06:11jgalt has joined IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net)
06:15
<jgalt>
changed all the ipappend 2 statements to ipappend 3 and it works.... now how to make it stay that way....
06:16
<alkisg>
You need to run update-kernels inside the chroot
06:17
Try: ltsp-chroot -m /usr/share/ltsp/update-kernels
06:17
Then check if ipappend 3 made it to /opt/ltsp/i386/boot/pxelinux.cfg/ltsp
06:23
<jgalt>
yes it did
06:23
<alkisg>
OK then whenever your run `ltsp-update-kernels` now, it'll work as you want it to
06:26
<jgalt>
....but we seem to have 2 files escentially the same.... updating /etc/ltsp/update-kernels is what seems to have made it work
06:27
...also what does ltsp-update-kernels do?
06:29
<alkisg>
/etc/ltsp/update-kernels.conf in the chroot, right?
06:29
update-kernels in the chroot updates <chroot>/boot/pxelinux.cfg
06:29stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Quit: leaving)
06:29
<alkisg>
ltsp-update-kernels outside of it copies it to tftp
06:29
man ltsp-update-kernels will tell you more
06:30stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
06:30
<jgalt>
ok, thanks. so what do I need to do now to keep this maintained and up to date?
06:31
<alkisg>
Nothing, just apt-get update, dist-upgrade etc
06:31stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host)
06:31stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
06:31
<jgalt>
sweet!
06:32
so the ltsp chroot.... why the chroot for ltsp?
06:33
<alkisg>
You need a server and a template client
06:33
The chroot is the template client
06:33
You could use a VM for that instead, but people here preferred chroots
06:33
Personally I prefer reusing the server installation
06:33
!ltsp-pnp
06:33
<ltsp`>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
06:34
<jgalt>
I would reuse the server install but the server is amd64 and the clients are 32bit p3 boxen.
06:35
<alkisg>
Install i386 on the server then
06:35
It even saves RAM
06:36
<jgalt>
hmm,so why does or should anyone run a 64bit linux install
06:36
<alkisg>
Because they don't care about netbooted clients
06:36
You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
06:36
In this case, i386 suits you better
06:37
<jgalt>
yes, but does 64bit hardware/os get you something? if so what?
06:37
<alkisg>
Also some don't know that with i386-pae kernels you can access more than 4gb ram
06:37
(09:36:40 πμ) alkisg: You can a bit more speed in math applications, and waste a little ram, it's a tradeoff
06:37
That's what
06:37
<jgalt>
ah ok.
06:39
now at the riskof committing heresy can this same basic setup be used to netboot a client to M$ windows?
06:39
<alkisg>
How do you netboot windows usually?
06:40
(because there are many methods, all of them officially unsupported, to see if the one you use can also be offered by a linux server)
06:40
<jgalt>
I havn't really tried. just thinking a menu that gave a choice of os to netboot would be kinda nice.
06:41
<alkisg>
The menu is the easy part, the hard part is that windows officially don't support netbooting
06:41
So people find workarounds with iscsi disks or VMs
06:41
<jgalt>
ah,ok got that.
06:42
<alkisg>
You can offer iscsi disks from linux, that's the easy part, google for it, it's not very related to ltsp except that you can reuse some dnsmasq settings
06:42
<jgalt>
yes,more curious than anything else.
06:42
<alkisg>
But if your PCs already have disks, I don't see why you would bother
06:43
LTSP has support for windows remote desktop, but that doesn't suit you either
06:44
<jgalt>
another interesting related project I may tackle would be getting some old mac G4's (power pc architecture) to netboot and serve as thinclients as well. any thoughts there?
06:44
<alkisg>
Another chroot
06:45
<jgalt>
prettymuch just invoke ppc in the create step?
06:47
<alkisg>
You need qemu to run ppc code under and amd64 processor
06:47
*an
06:47
<jgalt>
rdp could work if one had a windows vm running somewhere.
06:47
<alkisg>
Yes but it's slow
06:47
Kids will complain about not being able to play games
06:48
<jgalt>
why would I be running ppc code under amd64? it should run native on the mac g4's
06:49
<alkisg>
Then you'd need to install ltsp-server on the mac
06:49
In order to be able to run ltsp-build-client to generate the chroot
06:49
And then transfer the chroot to your main ltsp server, if you want to
06:50
<jgalt>
even if I was using the g4's as thin clients?
06:50
<alkisg>
The question is: how will you *create* the ppc chroot?
06:50
Not what will you do when it's ready
06:50
When it's ready, sure, you can use it to boot g4's as thin clients against an i386 server
06:51
<jgalt>
ah, thought it just downloaded those files precompiled.
06:51
<alkisg>
No, it executes code
06:51
So you need a ppc processor, either an emulated one (qemu) or a real one
06:51
<jgalt>
hmm,when I did that step it went and downloaded a bunch of stuff for the chroot
06:52
<alkisg>
It downloads packages and then executes them
06:52
It's like `apt-get install program`
06:52
That downloads program.deb _and_ executes it
06:53
<jgalt>
ah,ok - needs to execute enough of it to configure packages.
06:53
<alkisg>
That's why some .deb files are arch-specific
06:55uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
06:55
<jgalt>
I'd expect them to be arch specific as they generally contain compiled binaries but I hadn't thought about the config scripts/binaries they contain/
06:56
the reality is that packages are more than just an archive- just realized that
06:57uXus has joined IRC (uXus!~uXus@217.77.222.72)
07:09telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
07:10telex has joined IRC (telex!teletype@freeshell.de)
07:14khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be)
07:22
<jgalt>
alkisg: Thanks bunches for the help. 'bout to callit a night here in the pacific time zone.
07:22
<alkisg>
You're welcome jgalt
07:23
<jgalt>
yea, always nice on both sides when stuff finally works
07:25jgalt has left IRC (jgalt!~chatzilla@pool-71-105-122-242.lsanca.dsl-w.verizon.net)
07:25syrius has left IRC (syrius!~syrius@thunder.stormtek.net, Ping timeout: 264 seconds)
07:25syrius has joined IRC (syrius!~syrius@thunder.stormtek.net)
07:29map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net)
07:52vsuojane1 has left IRC (vsuojane1!~valtteri@83-136-248-31.uk-lon1.host.upcloud.com, Quit: leaving)
07:57khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 264 seconds)
08:07map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 248 seconds)
08:08map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net)
08:19map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 264 seconds)
08:37khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be)
08:57vsuojanen has joined IRC (vsuojanen!~valtteri@83-136-248-31.uk-lon1.host.upcloud.com)
09:18muppis_ has left IRC (muppis_!muppis@takaisin.fi, Ping timeout: 256 seconds)
09:19muppis has joined IRC (muppis!~muppis@takaisin.fi)
09:42alkisg is now known as work_alkisg
09:43work_alkisg is now known as alkisg
10:21map7_ has joined IRC (map7_!~map7@two1000979.lnk.telstra.net)
10:48map7_ has left IRC (map7_!~map7@two1000979.lnk.telstra.net, Ping timeout: 252 seconds)
11:19Faith has joined IRC (Faith!~paty@unaffiliated/faith)
11:58andygraybeal has left IRC (andygraybeal!~andy@h34.62.188.173.dynamic.ip.windstream.net, Read error: Connection reset by peer)
12:09yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
12:09yanu_ has left IRC (yanu_!~yanu@d1F05B2CD.access.telenet.be, Read error: Connection reset by peer)
14:25khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 256 seconds)
14:43khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be)
15:08telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
15:10telex has joined IRC (telex!teletype@freeshell.de)
15:10bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Read error: Connection reset by peer)
15:11bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
15:38bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Ping timeout: 256 seconds)
16:25vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:35Uzzi has joined IRC (Uzzi!5528630e@gateway/web/freenode/ip.85.40.99.14)
16:35
<Uzzi>
hi
17:19Uzzi has left IRC (Uzzi!5528630e@gateway/web/freenode/ip.85.40.99.14, Ping timeout: 246 seconds)
17:40khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Ping timeout: 265 seconds)
17:53bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
17:55khildin has joined IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be)
18:59
<lee>
.host aeogamer
18:59
erp
19:06khildin has left IRC (khildin!~khildin@ip-80-236-214-142.dsl.scarlet.be, Quit: I'm gone, bye bye)
19:37telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
19:38telex has joined IRC (telex!teletype@freeshell.de)
19:49
<Hyperbyte>
derp!
20:14AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp)
20:58Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
21:59ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
23:27AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnmllosnljseqojp, Quit: Connection closed for inactivity)