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


Channel log from 19 October 2017   (all times are UTC)

00:30vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
00:30zamba has left IRC (zamba!marius@flage.org, Ping timeout: 240 seconds)
00:35zamba has joined IRC (zamba!marius@flage.org)
01:03fiesh has left IRC (fiesh!~fiesh@hq.wsoptics.de, Ping timeout: 255 seconds)
01:03Guest46716 has left IRC (Guest46716!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc, Changing host)
01:03Guest46716 has joined IRC (Guest46716!bennabiyma@unaffiliated/bennabiy)
01:03Guest46716 has joined IRC (Guest46716!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc)
01:04Guest46716 is now known as bennabiy
01:38adrianor1 has joined IRC (adrianor1!~adrianorg@187.115.111.239)
01:41adrianorg has left IRC (adrianorg!~adrianorg@187.113.217.19, Ping timeout: 248 seconds)
03:13tarzeau has left IRC (tarzeau!~gurkan@mail.aiei.ch, Ping timeout: 240 seconds)
03:21tarzeau has joined IRC (tarzeau!~gurkan@mail.aiei.ch)
03:23fiesh has joined IRC (fiesh!~fiesh@hq.wsoptics.de)
03:24lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
03:28ben_nabiy has joined IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy)
03:53qqqqqqqq19 has joined IRC (qqqqqqqq19!~guido@p5DD6F1DE.dip0.t-ipconnect.de)
03:57qqqqqqqqq9 has left IRC (qqqqqqqqq9!~guido@p5DD6F1B2.dip0.t-ipconnect.de, Ping timeout: 260 seconds)
05:23Statler has joined IRC (Statler!~Georg@p579FEFB4.dip0.t-ipconnect.de)
05:41pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 260 seconds)
05:56pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
06:13ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:42stevenm__ 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:33jbal 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:40jbal has left IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163, Quit: Page closed)
08:41jbal 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:43Statler 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:24GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat)
09:24GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com)
09:32jbal has left IRC (jbal!55c049a3@gateway/web/freenode/ip.85.192.73.163, Ping timeout: 260 seconds)
09:53Statler 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:10Natureshadow 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:20kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:311f:4500:5cb5:fbe0:8156:4a35)
11:54adrianor1 is now known as adrianorg
12:37Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:40Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Client Quit)
12:41Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:21GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat)
13:21GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com)
13:26bengoa has joined IRC (bengoa!~alberto@2804:14d:4cdb:121e::4)
13:42stevenm__ is now known as stevenm
13:51lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
13:55ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:00lucascastro has joined IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br)
14:06lucascastro has left IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br, Remote host closed the connection)
14:14kjackal_ has left IRC (kjackal_!~quassel@2a02:587:311f:4500:5cb5:fbe0:8156:4a35, Remote host closed the connection)
14:58ragnar has joined IRC (ragnar!~ragnar@104.153.224.166)
15:16ragnar has left IRC (ragnar!~ragnar@104.153.224.166, Quit: leaving)
15:17ragnar has joined IRC (ragnar!~ragnar@104.153.224.169)
15:21ragnar has left IRC (ragnar!~ragnar@104.153.224.169, Client Quit)
15:37GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Ping timeout: 260 seconds)
16:14lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
16:14Statler has left IRC (Statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
16:20ragnar has joined IRC (ragnar!~ragnar@104.153.224.169)
16:39lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
16:41ragnar has left IRC (ragnar!~ragnar@104.153.224.169, Ping timeout: 260 seconds)
16:42GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com)
16:52lucascastro has joined IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br)
16:59GodFather has left IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com, Quit: Ex-Chat)
17:00GodFather has joined IRC (GodFather!~rcc@cpe-74-75-116-248.maine.res.rr.com)
17:01lucascastro has left IRC (lucascastro!~lucas@200-217-113-173.host.telemar.net.br, Remote host closed the connection)
17:43alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-jrmzgztifmeivnte, Ping timeout: 240 seconds)
17:43bennabiy has left IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-qknhmyjazlolqszc, Ping timeout: 246 seconds)
17:48lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79)
18:17qqqqqqqq19 has left IRC (qqqqqqqq19!~guido@p5DD6F1DE.dip0.t-ipconnect.de, Remote host closed the connection)
18:20lucascastro has left IRC (lucascastro!~lucas@138.68.106.79, Remote host closed the connection)
18:23lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79)
18:34lucascastro has left IRC (lucascastro!~lucas@138.68.106.79, Ping timeout: 255 seconds)
18:47ragnar has joined IRC (ragnar!~ragnar@65.119.211.164)
18:53lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14)
20:06Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:42lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection)
20:46ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:34bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
21:36bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Client Quit)
21:59bennabiy has joined IRC (bennabiy!bennabiyma@gateway/shell/matrix.org/x-abaimukfugftlywn)
22:00bennabiy is now known as Guest48256
22:00bengoa has left IRC (bengoa!~alberto@2804:14d:4cdb:121e::4, Ping timeout: 264 seconds)
22:12bengoa has joined IRC (bengoa!~alberto@2804:14d:4cdb:121e::4)
22:16alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-bacmadvudbmjdyvf)
22:40ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:48bengoa has left IRC (bengoa!~alberto@2804:14d:4cdb:121e::4, Remote host closed the connection)