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


Channel log from 20 May 2019   (all times are UTC)

01:09nickolai has left IRC (nickolai!1f2b0d7f@gateway/web/freenode/ip.31.43.13.127, Ping timeout: 256 seconds)
01:14nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection)
01:15nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242)
01:26nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection)
05:12os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
06:25ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:38pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
07:05pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
07:09SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
08:11statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
08:41pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood)
08:43pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
08:50jeblesh has joined IRC (jeblesh!2e78d540@gateway/web/freenode/ip.46.120.213.64)
08:51
<jeblesh>
im comfused, on clients mashines i can only access the user folder, i use a folder for sherd worck with other users and on the server it works
08:53
what's the best way to allaw users to shere and worck on the same files in ltsp setup ?
08:53
<alkisg>
!lts.conf
08:53
<ltsp>
lts.conf: (#1) http://manpages.ubuntu.com/lts.conf, or (#2) lts.conf manpage is available in the ltsp-docs package
08:53
<alkisg>
LOCAL_APPS_EXTRAMOUNTS
08:54
<jeblesh>
ty
08:57pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood)
08:58pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
09:00
<jeblesh>
i need to reset server after changing simthing in that files ?
09:00
<alkisg>
reset clients
09:00
<jeblesh>
oky ty
09:15
i set "LOCAL_APPS_EXTRAMOUNTS=/home/sher" still cant c it on clients S:
09:19
oky put it in the wrong place in the file NVM me newbieness P:
09:19
thenx alot alkisg
09:19
<alkisg>
np
10:29kjackal has joined IRC (kjackal!~quassel@2.152.183.208.dyn.user.ono.com)
12:01kjackal has left IRC (kjackal!~quassel@2.152.183.208.dyn.user.ono.com, Ping timeout: 248 seconds)
12:32Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:06nabin has joined IRC (nabin!d4af967d@gateway/web/freenode/ip.212.175.150.125)
13:06
<nabin>
hello
13:07
we want to implement LTSP project in our company
13:07
but i would like to know how can test it as demo ?
13:23nabin has left IRC (nabin!d4af967d@gateway/web/freenode/ip.212.175.150.125, Quit: Page closed)
14:00os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a)
14:04kjackal has joined IRC (kjackal!~quassel@195.235.52.105)
14:23vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
14:40gdi2k has joined IRC (gdi2k!~gdi2k@host86-181-225-59.range86-181.btcentralplus.com)
15:02spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
15:09
<quinox>
I suppose a demo-in-a-docker could work
15:11gdi2k has left IRC (gdi2k!~gdi2k@host86-181-225-59.range86-181.btcentralplus.com, Read error: Connection reset by peer)
15:18
<||cw>
would it? what with all the DHCP?
15:18
<alkisg>
!install
15:18
<ltsp>
install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
15:18
<alkisg>
This takes 10 mins after os installation
15:18
I doubt docker can do it faster
15:18
And it doesn't touch dhcp
15:19
<||cw>
I mean would docker play nice with the dhcp proxy
15:19gdi2k has joined IRC (gdi2k!~gdi2k@host86-181-225-59.range86-181.btcentralplus.com)
15:19
<alkisg>
if it's bridged, sure
15:20
<||cw>
personally I've found docker to be more of a pain than its worth for one offs. I can see the value if you're doing dozen identical things tho
15:23
<sutula>
...all this discussion isn't doing nabin any good (since "nabin has quit (Quit: Page closed)") but perhaps they will check the logs...
15:24
But my thought is that if they care about performance/responsiveness, they will need to set up some demo that's at least close to what they might implement in terms of server, network, and client
15:28
<alkisg>
Sure it's just chatting, we're not helping nabin :)
15:28
I have 10 VMs and I'm testing things with these, it requires minimal maintenance
15:29
<quinox>
but it requires understanding!
15:29
a single docker command can be ran without a brain :D
15:31
deleting a docker container is easier and less risk than purging an installation
15:34
(I like dockers for development / demo, I strongly dislike them for production)
15:36
<alkisg>
Deleting a vm in vbox is right click delete :)
15:36
And installing one, is exactly like a normal installation
16:10nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242)
16:15
<nehemiah>
alkisg: Just read in the irc logs that you're planning on using iPXE. Which sounds very encouraging to me. I wanted to give it a spin. Will this still work witn dnsmasq in proxy mode?
16:20
<alkisg>
nehemiah: yes, and a lot better
16:21
<nehemiah>
So, do you use chain loading then?
16:22
<alkisg>
nehemiah: busy now, let's talk a bit later please...
16:22
<nehemiah>
np
16:27
<alkisg>
nehemiah: have a look, and we can talk details later: https://github.com/eellak/gsoc2019-ltsp/tree/master/ltsp/configs
16:29
vagrantc: OK with the kernel variables, it now supports spaces. Awk to the rescue again: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/ltsp.sh#L102
16:29
ltsp.loop="/path/to ltsp.vbox=1" becomes LTSP_LOOP="/path/to ltsp.vbox=1"
16:30
(trying spaces and equals inside quotes, to make things harder, it still works)
16:30
Also, I'm setting journal max size = 1M, and disabling syslog, which can grow up indefinately
16:31
journal is a superset of syslog anyway, so there will be nothing missing
16:33adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.159.199)
16:35adrianorg has left IRC (adrianorg!~adrianorg@177.18.100.191, Ping timeout: 246 seconds)
16:53SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
17:19
<nehemiah>
alkisg: Thank you for that link. That makes things clear. That quite the improvement!
17:19
<alkisg>
np :)
17:23
!nfs_home
17:23
<ltsp>
Error: "nfs_home" is not a valid command.
17:23
<alkisg>
!nfs
17:23
<ltsp>
nfs: to enable NFS home directories for localapps and fat clients, install nfs-kernel-server on your server, nfs-common on your client (don't forget ltsp-update-image), and put this in lts.conf: FSTAB_1="server:/home /home nfs defaults,nolock 0 0"
17:57josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: The Lounge - https://thelounge.chat)
18:10josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
18:24woernie has joined IRC (woernie!~werner@pD9E8BFBD.dip0.t-ipconnect.de)
18:33statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
18:34
<alkisg>
nehemiah: I can chat now, if you need more info
18:45
<nehemiah>
alkisg: I just wondered how to do it using the chain loading. I was looking for reference online but nobody seemed to got it right using proxy mode. You're example made it clear right away.
18:45
This is a lot more powerful with the variables and you could even dynamically generate a boot file.
18:56
<alkisg>
nehemiah: true,if someone wanted to create an "ltsp-web-server" service, it could dynamically send kernel, initrd, ltsp.img, and lts.conf to each client
18:56
But that's for ltsp22.04 :P
18:57
Indeed it took me weeks to compare ipxe/grub/syslinux, get them working with uefi and ipv6, and generate a very good config
19:00
<nehemiah>
I guess that ipxe would make it easier to boot from iSCSI too as it can generate an initiator name dynamically
19:07
<alkisg>
it needs to be dynamic, not static per client?
19:09* alkisg hasn't used iscsi
19:09
<nehemiah>
It doesn't have to be static per client dynamic is fine. When an initiator connect using the same initiator name. The server wants to reconnect that's why each client has to introduce itself with an unique initiator name.
19:11
I've created an iscsi lun on my nas and have been booting some clients from it. But with syslinux you'd have to create a separate boot file for each client because of the initiator name.
19:11
<alkisg>
If it can be static, then one can just pass it in ipxe by using a variable
19:13
<nehemiah>
Yes, that works. I guess that's what I mean. U can add the mac of the client as the unique part in the initiator name.
19:14
<alkisg>
But an initramfs script could also do that easily
19:14
with pxelinux
19:16
<nehemiah>
true
19:17
<vagrantc>
but maybe by passing arguments from ipxe to the initramfs the initramfs will do the right thing out of the box
19:18* vagrantc speculates wildly
19:20
<nehemiah>
I guess what happens now, in my test setup, is that ipxe connects tot the san. and initrd repeats that step. But the lun is already available so there's no need for that.
19:21
<alkisg>
nehemiah: what's the cmdline for iscsi?
19:21
your ipxe script line?
19:23
<nehemiah>
Here's setting the initiator name: set initiator-iqn iqn.2005-01.org.lab:${mac}
19:24
And sanboot: sanboot iscsi:192.168.88.22:::1:iqn.2005-02.org.lab:buster
19:24
This is not ltsp it's just a test right now.
19:25
<alkisg>
nehemiah: no i mean the kernel cmdline
19:25
Like we do for nfsroot=xxx
19:25
what do you put for iscsi?
19:26
<nehemiah>
Oh, I see, since the lun is already up. it's the UUID of the block device.
19:26
<alkisg>
kernel xxx root=/dev/nfs nfsroot=ip etc etc
19:26
That line from your ipxe script
19:26
That has the "kernel" word
19:26
<nehemiah>
I let grub take over in my test at the moment.
19:27
<alkisg>
OK, the linux line from grub
19:27
linux <params here>
19:36
<nehemiah>
https://pastebin.com/tY5XMDKy
19:36
<alkisg>
Ah, there's no mention of iscsi at all in the cmdline?
19:37
strange
19:37
<nehemiah>
No as ipxe already connects
19:37
But then there is /etc/iscsi/iscsi.initramfs
19:37adrianor1 has left IRC (adrianor1!~adrianorg@186.213.159.199, Ping timeout: 258 seconds)
19:37
<alkisg>
You manually need to edit that?
19:38adrianorg has joined IRC (adrianorg!~adrianorg@186.213.159.199)
19:38
<alkisg>
I imagine that ipxe connects and runs kernel/initrd from there using sanboot,
19:38
Hrmm not exactly, I mean, ipxe runs grub, which loads the kernel, still using sanboot,
19:39
but that's not enough, the kernel shall need to know where iscsi is too
19:39
<nehemiah>
No, in fact, since ipxe already established the connection, there is no need for initramfs to do it. After ipxe the computer could boot as if it has an internal hdd.
19:39
<alkisg>
So I guess the important file will be that iscsi.initramfs, which must be different per client?
19:39
nehemiah: sanboot is like the old bios int 16
19:39
It doesn't work after the kernel boots
19:39
Can you pastebin that iscsi.initramfs?
19:40
<nehemiah>
I see, so it is mandatory.
19:40
<alkisg>
E.g. if you put break=mount in the cmdline, you won't have a "disk" at that point
19:47
<nehemiah>
https://pastebin.com/Yh9zwExg
19:49
And then there is '/etc/iscsi/initiatorname.iscsi', which afaik has to be unique.
19:49
https://pastebin.com/0d4sWZXn
20:00
<alkisg>
Sounds easy enough
20:00
Does it support authentication?
20:03
So, without using ssh/sshfs, we can do nfs, nfs4, local homes, iscsi and samba
20:03
Maybe they're enough...
20:13woernie has left IRC (woernie!~werner@pD9E8BFBD.dip0.t-ipconnect.de, Remote host closed the connection)
20:18ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
20:23
<nehemiah>
Iscsi supports authentication but you can not use it form home directories, of course.
20:27adrianorg has left IRC (adrianorg!~adrianorg@186.213.159.199, Ping timeout: 255 seconds)
20:28adrianorg has joined IRC (adrianorg!~adrianorg@186.213.159.199)
20:28
<alkisg>
nehemiah: btw, why "multiple initiators" etc? Can't multiple clients connect to a single iscsi "disk", in a read-only manner?
20:28
Would we need to clone the ltsp image multiple times?
20:31
OK google says it's possible, and that initiators is just the client name, not related to the server export
20:46
<nehemiah>
If I don't change the initiator name, only one machine boots. The others get stuck in boot until I specify an initiator name as kernel parameter.
20:47
<alkisg>
nehemiah: yeah sorry I got confused by the terminology. You only have a single image for all clients, right?
20:47
<nehemiah>
There is some logic the iscsi target applies to the initiator name.
20:47
Yes
20:47
just by changing the initiator name
20:47
<alkisg>
I see that iscsi doesn't support encryption though
20:47kjackal has left IRC (kjackal!~quassel@195.235.52.105, Ping timeout: 255 seconds)
20:48
<alkisg>
I was wondering if we could use it as a block device for homes (an ext4 file somewhere in the iscsi target), but it's no better than nfs3 then
20:48
I'll check if nfsv3+ipsec is any easier than all the nfs4+ldap+kerberos thing...
20:52
<nehemiah>
You can not use a block device for home unless you give every user it's own block device.
20:52
<alkisg>
Yup, to be connected/unlocked when he enters the password
20:52
It also helps in enforcing quotas
20:53
<vagrantc>
there were some per-user encryption that wasn't perfect, but encrypted all files under a certain directory per-user ...
20:53
<alkisg>
But it's complicated... sshfs is easier, but it requires a DM or PAM...
20:53
<vagrantc>
it wasn't as good as a lot of the other stuff, but ...
20:54
<alkisg>
vagrantc: I think we could easily use ecryptfs over nfs3, having encryption but not uid protection; so an intruder could delete but not read
20:54
Local homes are fine, but not everyone will want those
20:55
Live sessions are fine too; but even if we offer all those options, some users will still miss the ldm/sshfs combination
20:55
<vagrantc>
local homes are annoying to have backups
20:56
alkisg: maybe it was ecryptfs
20:56
<alkisg>
In the future storage will be cheap and very fast compared to networking; people can have 2 disks, one for backup, or users can have usb 3.0 sticks that are fast as ssds, for carrying /home/username with them,
20:57
...yet for now I'm not sure if we'll manage to avoid reimplementing ldm
20:57
<vagrantc>
in the future we'll have flying cars!
20:57
<alkisg>
You can get SSDs now with 20euros
20:57
<vagrantc>
oh, LDM...
20:57
alkisg: they might even have the advertised capacity!
20:57
<alkisg>
I'm OK with offering all those *except* ldm/sshfs; as it allows us to not have a dm,
20:57
but I'm guessing you won't be ok with those options :D
20:57Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:58
<alkisg>
live; local home; nfs3; or manually setup nfs4 etc for security
20:58
<vagrantc>
i'm not sure what i think ... i really want to say goodbye to ldm
20:58
<alkisg>
That's won't fly, will it?
20:59
<vagrantc>
my last setups were primarily kiosk-style desktops without persistant homedirs ... so in that sense...
20:59
that's probably the easiest to implement
21:00
<alkisg>
It definitely is
21:00
<nehemiah>
Would webdav for /home be an option?
21:00
<vagrantc>
and local home and nfsv3 are also pretty easy
21:00
<alkisg>
vagrantc: Ah btw, I think I already asked you this, but let me make sure: it's ok to send passwd (but not shadow, ok) to the clients, before they authenticate, so that they have the users list/uid/gids, right?
21:01
I.e. we could send/merge them before the DM starts, so that it displays the correct list and everything
21:01
<vagrantc>
alkisg: that's not terrible
21:01
<alkisg>
OK. And I guess we can store passwd in local disk?
21:02
(local homes of course mean that users can't easily migrate to other clients)
21:02
<vagrantc>
not sure on all the implications of storing the passwd on the local disk
21:02
<alkisg>
It's like having a local linux installation, except you only have passwd there :D
21:03
<vagrantc>
and yeah, local homes definitely has issues with portability and backups and such
21:03
<alkisg>
(and swap and home)
21:03
It does; but it also has 10-100 times better speed
21:03
<vagrantc>
right
21:04
<alkisg>
With all those options we cover a lot of use cases, but we still lose the main one, "secure default"
21:04
<vagrantc>
haven't seen anything that can just use a disk as a transparent cache
21:04
yeah, the "secure" default really is sad to miss
21:04
<alkisg>
My users are ok with nfs3 for everything, and they won't mind at all if shadow is sent in ltsp-initrd.img
21:05
One other possibility is to have the normal DM autologin,
21:06
as an "ltsp" user, then show up an ldm reimplementation, and then connect to the server and launch the session,
21:06
...that just allows us not to bother with overriding services and screen.d things
21:06
<vagrantc>
heh
21:06
<alkisg>
It's just a bit simpler
21:07
<vagrantc>
so there's an autologin user that display a login manager sort of thing?
21:07
<alkisg>
Right
21:08
And the real user session runs on top of that; or if needed, the dm can be restarted with the new user as the autologin user
21:08
<vagrantc>
not sure how you'd prevent users from leaving keyloggers running
21:08
<alkisg>
The dm restarts for each user
21:09
<vagrantc>
just run the user session in Xnest :)
21:10
<alkisg>
Btw today I managed to get an ubuntu live cd netbooted into ltsp mode, with a user and his nfs home coming from the server
21:10
nfsmount from klibc is enough for all that
21:11
So no other packages were needed; whatever's already there in the initramfs
21:11
sshfs isn't preinstalled though, so that won't work for live cds
21:12
<vagrantc>
nice!
21:12
i did think you could "chroot /target apt install sshfs" and such
21:12
but that would slow boot a lot
21:13
<alkisg>
And need internet access which isn't always there, and bandwidth, and ram for apt update
21:13
<vagrantc>
yeah
21:13
<alkisg>
As sshfs might not be available (previous version in apt lists, newer on mirrors)
21:13
<vagrantc>
well, we could also generate an overlay fs layer and ship that from the initrd
21:14
<alkisg>
The simplicity of nfs is unbeatable :D
21:14
<vagrantc>
but still, very cool to hear you got the livecd working
21:14
<alkisg>
For the others, eh, let them use ltsp-update-image+chroot, or just use VMs
21:14
<vagrantc>
fair enough
21:15
<alkisg>
With what I have currently, we could create a package "ltsp-with-live-cds", and have people up and running ltsp "live" labs in 1 minute or so
21:15
...the authentication then makes it a nightmare :D
21:15
<vagrantc>
authentication for non-live setups?
21:16
<alkisg>
Yeah
21:16
<vagrantc>
yeah, not having to support authentication makes all sorts of things possible
21:17
<alkisg>
Btw there's also cifs frequently in the live cds, I want to see if we can use this for homes... I think samba supports encryption too
21:18
Enough for a day though; night all :)
21:20
<vagrantc>
yeah, i've definitely heard about cifs for homedirs
21:20* vagrantc waves
22:39GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 244 seconds)
23:01GodFather has joined IRC (GodFather!~rcc@143.59.184.72)