IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 October 2017 (all times are UTC)
| 00:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 00:30 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 240 seconds) | |
| 00:35 | zamba has joined IRC (zamba!marius@flage.org) | |
| 01:03 | fiesh has left IRC (fiesh!~fiesh@hq.wsoptics.de, Ping timeout: 255 seconds) | |
| 01:03 | Guest46716 has left IRC (Guest46716!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc, Changing host) | |
| 01:03 | Guest46716 has joined IRC (Guest46716!bennabiyma@unaffiliated/bennabiy) | |
| 01:03 | Guest46716 has joined IRC (Guest46716!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc) | |
| 01:04 | Guest46716 is now known as bennabiy | |
| 01:38 | adrianor1 has joined IRC (adrianor1!~adrianorg@187.115.111.239) | |
| 01:41 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.217.19, Ping timeout: 248 seconds) | |
| 03:13 | tarzeau has left IRC (tarzeau!~gurkan@mail.aiei.ch, Ping timeout: 240 seconds) | |
| 03:21 | tarzeau has joined IRC (tarzeau!~gurkan@mail.aiei.ch) | |
| 03:23 | fiesh has joined IRC (fiesh!~fiesh@hq.wsoptics.de) | |
| 03:24 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
| 03:28 | ben_nabiy has joined IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy) | |
| 03:53 | qqqqqqqq19 has joined IRC (qqqqqqqq19!~guido@p5DD6F1DE.dip0.t-ipconnect.de) | |
| 03:57 | qqqqqqqqq9 has left IRC (qqqqqqqqq9!~guido@p5DD6F1B2.dip0.t-ipconnect.de, Ping timeout: 260 seconds) | |
| 05:23 | Statler has joined IRC (Statler!~Georg@p579FEFB4.dip0.t-ipconnect.de) | |
| 05:41 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 260 seconds) | |
| 05:56 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 06:13 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:42 | stevenm__ has joined IRC (stevenm__!~stevenm@195.62.218.30) | |
| 07:43 | <stevenm__> perhaps I've got the wrong end of the stick... is LTSP meant to be a project where a) 'client' machines runa tiny bootstrap to turn themselves into thin clients and then (using some sort of protocol) use the resources of the LTSP server instead (running everything there) - similar to an MS Windows Terminal Server
| |
| 07:44 | or is it more b) the LTSP server prepares one or more disk images for the 'client' machines to boot - and they then use they're own resources (mem/cpu) except for disk (which is remote)
| |
| 07:44 | <alkisg> stevenm__: clients are diskless, the server only has one image for all clients,
| |
| 07:44 | and, 2 modes are supported, thin and fat,
| |
| 07:44 | in thin mode it's "small os + remote desktop",
| |
| 07:45 | <stevenm__> right but when the 'client' PC runs an app - does that app reside in the memory of the client or the L2TP server?
| |
| 07:45 | <alkisg> in fat mode it's "all OS runs on the client, using the image + remote /home"
| |
| 07:45 | That 'or' that you just said, are the 2 modes
| |
| 07:45 | Both are supported
| |
| 07:45 | You flip a switch in a config file and it becomes thin or fat
| |
| 07:45 | LTSP_FATCLIENT=True/False
| |
| 07:45 | <stevenm__> interesteding
| |
| 07:46 | I'd always assumed the 'TS' in LTSP answered my own question that it was just thin only
| |
| 07:46 | <alkisg> By default, autodetection is used, clients with enough RAM (>500 MB) become fat
| |
| 07:46 | <stevenm__> this looks *very* nice... http://wiki.ltsp.org/wiki/Ltsp-manager
| |
| 07:46 | <alkisg> Fat clients were supported about 10 years after the LTSP name got established :)
| |
| 07:46 | Yup, we've developed it and use it in 1000+ schools here
| |
| 07:46 | !ltsp-manager
| |
| 07:46 | <ltsp> ltsp-manager: LTSP Manager is a GUI tool that makes LTSP maintenance easy. It's the recommended way to install LTSP in common setups. More info: http://wiki.ltsp.org/wiki/Ltsp-manager
| |
| 07:47 | <stevenm__> we've got a little "Workplace Recovery Suite" with 30 pc's (all Compaq 315eu's) for companies to use in case they're main offices are inaccessible/unusable
| |
| 07:48 | at the moment I've got them all pxebooting thinstation so they just get a basic RDP client - they can then RDP to a MS term serv (what most businesses want)
| |
| 07:48 | <fiesh> "similar to an MS Windows Terminal Server"... now Microsoft invented terminal servers... o.O ;)
| |
| 07:48 | <stevenm__> but in the evenings... the company I work for... has allowed me to use the room to run a Linux User Group
| |
| 07:48 | <alkisg> https://www.cpubenchmark.net/cpu.php?cpu=AMD+Athlon+II+X2+220 => 1630 passmark, they'd work fine as diskless ltsp fat clients
| |
| 07:48 | <stevenm__> so I'm thinking LTSP would be better for that (I can just switch the network port for the whole room)
| |
| 07:49 | <alkisg> stevenm__: right, just follow the steps in the ltsp-manager wiki
| |
| 07:49 | <stevenm__> yeah will do :D
| |
| 07:49 | tbh I was thinking of using NX - which I think is a brilliant protocol
| |
| 07:49 | but it would mean all the resources need to be on the server :S
| |
| 07:50 | <alkisg> And also X is faster for LAN than NX
| |
| 07:50 | NX is good over ADSL, WAN etc
| |
| 07:50 | <stevenm__> X as in XDMCP ? is that what LTSP uses in thin mode?
| |
| 07:50 | <alkisg> Yes, or X over ssh if security is preferred
| |
| 07:50 | (preferred to speed)
| |
| 07:51 | <stevenm__> so if LTSP is in thin mode - does it even still both using the disk images it prepares?
| |
| 07:51 | <alkisg> Btw, ltsp can easily rdp to windows
| |
| 07:51 | So you can drop the thinstation client if you want
| |
| 07:51 | <stevenm__> pff don't care about windows (not for the LUG project I have in mind)
| |
| 07:51 | <alkisg> I meant for the day work of the lab
| |
| 07:51 | <stevenm__> no the thinstation is for a different purpose - thats when people (businesses) actually invoke the use of the recovery suite
| |
| 07:52 | they *will* want to RDP to their own term servs :P (windows)
| |
| 07:52 | <alkisg> Yeah, you can easily rdp or recover from ltsp. But anyway that's a different talk.
| |
| 07:52 | "- does it even still both" => do you mean "boot" there?
| |
| 07:52 | <stevenm__> yeah sorry
| |
| 07:52 | <alkisg> So, typical ltsp-manager installation:
| |
| 07:53 | <stevenm__> no wait
| |
| 07:53 | <alkisg> you install ubuntu on the server, e.g. 5 gb
| |
| 07:53 | this then gets duplicated/compressed to an e.g. i386.img squashfs image, e.g. 1 gb
| |
| 07:53 | <stevenm__> what i meant to say is... if the client is in thin mode - then is it accessing the OS that is within the disk image
| |
| 07:53 | <alkisg> both thin and fat clients boot from the same image
| |
| 07:53 | If you *only* want to support thin, and never fat, then you can use another image of e.g. 300 mb
| |
| 07:53 | <stevenm__> hmm ok so surely the server must be running that image (QEMU?) for thin clients to access it like that?
| |
| 07:54 | <alkisg> But it's not faster, so there's no reason to do that
| |
| 07:54 | No
| |
| 07:54 | The image is exported using "nbd-server", a block network protocol
| |
| 07:54 | So for the clients it's like using a usb disk
| |
| 07:54 | <stevenm__> but the thin clients are only speaking XDMCP right?
| |
| 07:54 | <alkisg> Then fat clients run the apps locally, so no issues there,
| |
| 07:55 | while thin clients login using ssh + X (and our login manager called LDM), and run the apps on the server with no qemu or other emulation
| |
| 07:55 | <stevenm__> err - yeah ... not really addressed what I'm trying to get at though
| |
| 07:56 | if the thin clients run all their apps on the server... and does so via XDMCP... then what is running the contents of the image - presumably the server?
| |
| 07:56 | <alkisg> I tried to address it but apparently I failed. Let's try again
| |
| 07:56 | <stevenm__> i.e. the server may have X on it (for admin) ... but there is also another X being used for all thin clients
| |
| 07:56 | <alkisg> 1) We don't use xdmcp
| |
| 07:56 | OK?
| |
| 07:56 | <stevenm__> stevenm__> X as in XDMCP ? is that what LTSP uses in thin mode?
| |
| 07:56 | <alkisg> Yes, or X over ssh if security is preferred
| |
| 07:56 | <alkisg> We use ssh to login, and remote X eitehr with or without ssh
| |
| 07:57 | Yes, X as in XDMCP, but we don't use it
| |
| 07:57 | We use plain remote X or X over ssh
| |
| 07:57 | The authentication is always via ssh
| |
| 07:57 | For security, because XDMCP uses plaintext
| |
| 07:57 | Then, we either use remote X without encryption, for speed,
| |
| 07:58 | or over ssh, for security (a switch for that called LDM_DIRECTX)
| |
| 07:58 | So the effect is quite similar to what XDMCP is, just more secure
| |
| 07:58 | 2) The thin clients run the apps on the server, correct
| |
| 07:58 | <stevenm__> tunnelled XDMCP - thats all I see from all that
| |
| 07:58 | <alkisg> Directly. No image involved.
| |
| 07:58 | XDMCP is an authentication protocol
| |
| 07:59 | We don't use it
| |
| 07:59 | Remote X is another protocol
| |
| 07:59 | (it's actually part of X)
| |
| 07:59 | We use it
| |
| 07:59 | XDMCP isn't the same as remote X
| |
| 07:59 | It's about logging in, display manager etc. We don't use it at all, we don't enable it on the server, etc etc
| |
| 07:59 | <stevenm__> ok
| |
| 08:00 | <alkisg> So about the processes, they run directly on the server
| |
| 08:00 | The server has a desktop OS installed, it has libreoffice and everything
| |
| 08:00 | It's a desktop installation, not a server installation
| |
| 08:00 | So the image that we are talking about, doesn't have any apps
| |
| 08:00 | It only has the netboot code
| |
| 08:00 | And after login, the clients access the apps of the server /
| |
| 08:00 | Not of the image
| |
| 08:01 | <stevenm__> so if you screw up libreoffice (for example) on the server OS (i.e. the bit your using for administration of the system) then it'll be screwed for all thin client users too?
| |
| 08:01 | <alkisg> Right
| |
| 08:01 | <stevenm__> how poo
| |
| 08:01 | <alkisg> Or, if you install e.g. htop directly on the server, it'll immediately be available to the clients, no logoff necessary
| |
| 08:01 | (or image updates or anything)
| |
| 08:01 | In any case, with your clients, you shouldn't care at all about the thin client mode
| |
| 08:02 | So forget about it and ask for the fat client mode :)
| |
| 08:02 | <stevenm__> <alkisg> If you *only* want to support thin, and never fat, then you can use another image of e.g. 300 mb
| |
| 08:02 | this implies thin clients *can* access what is within a disk image
| |
| 08:03 | <alkisg> Before login, the clients use that image
| |
| 08:03 | They boot from it, so of course they access it
| |
| 08:03 | <stevenm__> oh just to get X setup i see
| |
| 08:03 | <alkisg> Right
| |
| 08:03 | <stevenm__> so if your doing fat - they the image the client machines access... is a 100% copy of the apps from the main server?
| |
| 08:04 | <alkisg> It can be. There are multiple ways to prepare that image
| |
| 08:04 | <stevenm__> so if you screw up libreoffice (for example) on the server OS (i.e. the bit your using for administration of the system) then it *WON'T* be screwed for all fat client users too?
| |
| 08:04 | <alkisg> The old way was "ltsp-build-client", which created a separate chroot
| |
| 08:04 | The new way is "ltsp-update-image -c /", which duplicates the server at the point it runs
| |
| 08:04 | And you could even use a VM like virtualbox to maintain the image
| |
| 08:05 | <stevenm__> see I'd say it'd be cooler to get the server to BOOT it's own fat disk image (in qemu) and allow thin clients to access within that
| |
| 08:05 | <alkisg> The "new way" is the easiest, it's what ltsp-manager uses
| |
| 08:05 | <stevenm__> that way both thin and fat clients can use the same image and contents within
| |
| 08:05 | <alkisg> And you'd waste a whole lot of resources
| |
| 08:05 | <stevenm__> and the OS your running the LTSP from - is just for administration
| |
| 08:05 | <alkisg> And have 5 times less network speed
| |
| 08:06 | <stevenm__> but also have *way* more flexibility
| |
| 08:06 | <alkisg> While with `ltsp-update-image -c /`, you waste 10 mins to generate the image, but your thin/fat clients are waaay faster then
| |
| 08:06 | <stevenm__> in terms of snapshots, juggling different images, etc...
| |
| 08:06 | <alkisg> Sure, whatever suits you
| |
| 08:06 | <stevenm__> and server hardware is cheap - and virtualisation is everywhere
| |
| 08:06 | <alkisg> But VMs don't boot from squashfs
| |
| 08:06 | You need a real file system which will be 5 times slower over the network
| |
| 08:06 | <stevenm__> they can with pxelinux
| |
| 08:06 | <alkisg> squashfs is read only
| |
| 08:07 | You can't boot it the way you think
| |
| 08:07 | (i.e. as a VM that would host thin client logins)
| |
| 08:07 | You could do something a bit more efficient with compressed btrfs, but not as efficient, and it's not really ready yet
| |
| 08:08 | <stevenm__> ok so when running this LUG in the evenings... (which is what I'm look at LTSP for -- thinstation *has* to stay for my day job where the room needs to be used for businesses)... what are my options if I get some user who wants centos not ubuntu, or debian not fedora
| |
| 08:08 | do i run an LTSP server for each distro?
| |
| 08:08 | and can the fat client machines get a menu to let them choose?
| |
| 08:08 | <alkisg> ...yes, but not all distros support ltsp
| |
| 08:09 | The "new way" is easy to implement, so if you can do a bit of scripting etc, you could add support for them
| |
| 08:09 | Ubuntu and Debian are well supported, and bcg starts to maintain fedora/rhel again (it was abandoned for years), and opensuse has kiwi-ltsp...
| |
| 08:10 | So if you plan to netboot fedora, ltsp is still the best option, but you'll need to do some research
| |
| 08:11 | And of course they could run VMs inside their LTSP Ubuntu sessions, if you have enough RAM :)
| |
| 08:33 | jbal has joined IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163) | |
| 08:33 | <jbal> i have a problem
| |
| 08:33 | <alkisg> What problem?
| |
| 08:33 | <jbal> raspberry client say: no response from server, restarting
| |
| 08:33 | <stevenm__> alkisg, tbh i'll likely just do ubuntu mate 16.04 - and screw people wanting another distro :P if they want it - they can build it themselves, it is a LUG after all :)
| |
| 08:34 | alkisg, thanks for the chat
| |
| 08:34 | <alkisg> stevenm__: you're welcome
| |
| 08:34 | !keys
| |
| 08:34 | <ltsp> I do not know about 'keys', but I do know about these similar topics: 'sshkeys', 'ltsp-update-sshkeys'
| |
| 08:34 | <alkisg> !sshkeys
| |
| 08:34 | <ltsp> sshkeys: If you changed your LTSP server IP on Ubuntu, your clients will be unable to login. To fix this, you need to run: sudo ltsp-update-sshkeys && sudo ltsp-update-image
| |
| 08:34 | <alkisg> !ldm
| |
| 08:34 | <ltsp> ldm: LDM is the LTSP Display Manager, required for LTSP thin/fat clients, because it authenticates the users to the server via SSH.
| |
| 08:34 | <alkisg> !ssh
| |
| 08:34 | <ltsp> I do not know about 'ssh', but I do know about these similar topics: 'sshkeys', 'ltsp-update-sshkeys', 'INIT_COMMAND_SSH'
| |
| 08:34 | <alkisg> !INIT_COMMAND_SSH
| |
| 08:34 | <ltsp> INIT_COMMAND_SSH: To troubleshoot ssh keys issues, this lts.conf directive trusts the server on boot: INIT_COMMAND_SSH="rm -f /root/.ssh/known_hosts; ssh-keyscan server > /etc/ssh/ssh_known_hosts"
| |
| 08:35 | <alkisg> jbal: do this last one ^
| |
| 08:35 | Put it in lts.conf, if it works after client reboot then it's a keys issue
| |
| 08:40 | jbal has left IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163, Quit: Page closed) | |
| 08:41 | jbal has joined IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163) | |
| 08:41 | <jbal> hello
| |
| 08:41 | sorry
| |
| 08:42 | please,What do I have to write in the terminal? or in archive?
| |
| 08:42 | for running ltsp client in raspberry pi
| |
| 08:42 | for the problem no response fron server, restarting
| |
| 08:42 | please help
| |
| 08:43 | Statler has left IRC (Statler!~Georg@p579FEFB4.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 08:43 | <alkisg> jbal: did you read what I wrote?
| |
| 08:43 | !INIT_COMMAND_SSH
| |
| 08:43 | <ltsp> INIT_COMMAND_SSH: To troubleshoot ssh keys issues, this lts.conf directive trusts the server on boot: INIT_COMMAND_SSH="rm -f /root/.ssh/known_hosts; ssh-keyscan server > /etc/ssh/ssh_known_hosts"
| |
| 08:43 | <alkisg> (11:35:17 πμ) alkisg: Put it in lts.conf, if it works after client reboot then it's a keys issue
| |
| 08:43 | Do you know what lts.conf is?
| |
| 08:44 | <jbal> lts.conf in server or in client?
| |
| 08:44 | <alkisg> In server
| |
| 08:44 | <jbal> ok
| |
| 08:44 | thank
| |
| 08:45 | all in one line? can i copy this line? INIT_CO.........know_hosts
| |
| 08:46 | <alkisg> Yes, copy it
| |
| 09:24 | GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat) | |
| 09:24 | GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com) | |
| 09:32 | jbal has left IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163, Ping timeout: 260 seconds) | |
| 09:53 | Statler has joined IRC (Statler!~Georg@gwrz3.lohn24.de) | |
| 10:04 | <bcg> "SCREEN_02=shell" in lts.conf starts root shell on console, but what is the preferred way to start login (ask username/password) instead?
| |
| 10:05 | <alkisg> bcg: login locally won't work since the user accounts are on the server
| |
| 10:05 | !root
| |
| 10:05 | <ltsp> I do not know about 'root', but I do know about these similar topics: 'ROOT_PASSWORD_HASH'
| |
| 10:05 | <alkisg> !ROOT_PASSWORD_HASH
| |
| 10:05 | <ltsp> ROOT_PASSWORD_HASH: to be able to login as root in vt1, with password "qwer1234", put this in lts.conf: INIT_COMMAND_01="sed 's!^root:[^:]*:!root:$6$p2LdWE6j$PDd1TUzGvvIkj9SE8wbw1gA/MD66tHHlStqi1.qyv860oK47UnKcafSKqGp7cbgZUPlgyPv6giCVyCSCdJt1b0:!' -i /etc/shadow"
| |
| 10:06 | <alkisg> If you have local accounts, just switch to vt1 and login with username/pass
| |
| 10:06 | For example, that ^ way you dynamically create a password for the root user, and can login that way
| |
| 10:06 | <bcg> root is what I'm after, setting the password is not the problem.
| |
| 10:06 | <alkisg> Switching to vt1 is?
| |
| 10:07 | <bcg> vt1 asks password, so probably just commenting SCREEN_02 out might work?
| |
| 10:07 | <alkisg> You don't need SCREEN_02 so you can comment it out, yes
| |
| 10:08 | Do you mean that you want vt2 to ask for password as well as vt1?
| |
| 10:08 | That vt1 isn't enough?
| |
| 10:08 | <bcg> yes, that works. stupid me.
| |
| 10:09 | yes, vt2 to ask password too. just commenting it out worked as I wanted.
| |
| 10:09 | <alkisg> Cool
| |
| 10:10 | Debian/Ubuntu by default remove vts, but now with systemd the disabling code no longer works :D
| |
| 10:10 | Natureshadow has joined IRC (Natureshadow!~Naturesha@commu.teckids.org) | |
| 10:10 | <alkisg> (vts except vt1)
| |
| 10:10 | ./init-ltsp.d/50-disable-inittab-entries: sed -i /getty.*tty[2-6]/d /etc/inittab
| |
| 10:10 | <bcg> in rhel other consoles are spawned when switching to them, so it works nicely.
| |
| 10:11 | <alkisg> That's the same in debian/ubuntu too, now with systemd
| |
| 10:11 | It's systemd-specific, not distro-specific...
| |
| 10:12 | <bcg> yeah. fat client works again as I wanted after re-installing NetworkManager to it. It was removed because I worked with thin clients before.
| |
| 10:12 | <alkisg> Nice
| |
| 10:13 | <bcg> doing bigger upgrade here, rhel6/thin to rhel7/fat.
| |
| 10:13 | next todo is using FreeIPA for users.
| |
| 11:20 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:311f:4500:5cb5:fbe0:8156:4a35) | |
| 11:54 | adrianor1 is now known as adrianorg | |
| 12:37 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:40 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Client Quit) | |
| 12:41 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 13:21 | GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat) | |
| 13:21 | GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com) | |
| 13:26 | bengoa has joined IRC (bengoa!~alberto@2804:14d:4cdb:121e::4) | |
| 13:42 | stevenm__ is now known as stevenm | |
| 13:51 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
| 13:55 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:00 | lucascastro has joined IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br) | |
| 14:06 | lucascastro has left IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br, Remote host closed the connection) | |
| 14:14 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:311f:4500:5cb5:fbe0:8156:4a35, Remote host closed the connection) | |
| 14:58 | ragnar has joined IRC (ragnar!~ragnar@104.153.224.166) | |
| 15:16 | ragnar has left IRC (ragnar!~ragnar@104.153.224.166, Quit: leaving) | |
| 15:17 | ragnar has joined IRC (ragnar!~ragnar@104.153.224.169) | |
| 15:21 | ragnar has left IRC (ragnar!~ragnar@104.153.224.169, Client Quit) | |
| 15:37 | GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Ping timeout: 260 seconds) | |
| 16:14 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
| 16:14 | Statler has left IRC (Statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
| 16:20 | ragnar has joined IRC (ragnar!~ragnar@104.153.224.169) | |
| 16:39 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
| 16:41 | ragnar has left IRC (ragnar!~ragnar@104.153.224.169, Ping timeout: 260 seconds) | |
| 16:42 | GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com) | |
| 16:52 | lucascastro has joined IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br) | |
| 16:59 | GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat) | |
| 17:00 | GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com) | |
| 17:01 | lucascastro has left IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br, Remote host closed the connection) | |
| 17:43 | alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-jrmzgztifmeivnte, Ping timeout: 240 seconds) | |
| 17:43 | bennabiy has left IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc, Ping timeout: 246 seconds) | |
| 17:48 | lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79) | |
| 18:17 | qqqqqqqq19 has left IRC (qqqqqqqq19!~guido@p5DD6F1DE.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 18:20 | lucascastro has left IRC (lucascastro!~lucas@138.68.106.79, Remote host closed the connection) | |
| 18:23 | lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79) | |
| 18:34 | lucascastro has left IRC (lucascastro!~lucas@138.68.106.79, Ping timeout: 255 seconds) | |
| 18:47 | ragnar has joined IRC (ragnar!~ragnar@65.119.211.164) | |
| 18:53 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
| 20:06 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 20:42 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
| 20:46 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:34 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 21:36 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Client Quit) | |
| 21:59 | bennabiy has joined IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-abaimukfugftlywn) | |
| 22:00 | bennabiy is now known as Guest48256 | |
| 22:00 | bengoa has left IRC (bengoa!~alberto@2804:14d:4cdb:121e::4, Ping timeout: 264 seconds) | |
| 22:12 | bengoa has joined IRC (bengoa!~alberto@2804:14d:4cdb:121e::4) | |
| 22:16 | alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-bacmadvudbmjdyvf) | |
| 22:40 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 22:48 | bengoa has left IRC (bengoa!~alberto@2804:14d:4cdb:121e::4, Remote host closed the connection) | |