01:09 | nickolai has left IRC (nickolai!1f2b0d7f@gateway/web/freenode/ip.31.43.13.127, Ping timeout: 256 seconds) | |
01:14 | nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection) | |
01:15 | nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242) | |
01:26 | nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection) | |
05:12 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
06:25 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
06:38 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
07:05 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
07:09 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
08:11 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
08:41 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood) | |
08:43 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
08:50 | jeblesh 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:57 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Excess Flood) | |
08:58 | pppingme 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:29 | kjackal has joined IRC (kjackal!~quassel@2.152.183.208.dyn.user.ono.com) | |
12:01 | kjackal has left IRC (kjackal!~quassel@2.152.183.208.dyn.user.ono.com, Ping timeout: 248 seconds) | |
12:32 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
13:06 | nabin 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:23 | nabin has left IRC (nabin!d4af967d@gateway/web/freenode/ip.212.175.150.125, Quit: Page closed) | |
14:00 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Quit: os_a) | |
14:04 | kjackal has joined IRC (kjackal!~quassel@195.235.52.105) | |
14:23 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
14:40 | gdi2k has joined IRC (gdi2k!~gdi2k@host86-181-225-59.range86-181.btcentralplus.com) | |
15:02 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
15:09 | <quinox> I suppose a demo-in-a-docker could work
| |
15:11 | gdi2k 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:19 | gdi2k 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:10 | nehemiah 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:33 | adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.159.199) | |
16:35 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.100.191, Ping timeout: 246 seconds) | |
16:53 | SYS64738 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:57 | josefig has left IRC (josefig!~josefig@unaffiliated/josefig, Quit: The Lounge - https://thelounge.chat) | |
18:10 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
18:24 | woernie has joined IRC (woernie!~werner@pD9E8BFBD.dip0.t-ipconnect.de) | |
18:33 | statler 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:37 | adrianor1 has left IRC (adrianor1!~adrianorg@186.213.159.199, Ping timeout: 258 seconds) | |
19:37 | <alkisg> You manually need to edit that?
| |
19:38 | adrianorg 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:13 | woernie has left IRC (woernie!~werner@pD9E8BFBD.dip0.t-ipconnect.de, Remote host closed the connection) | |
20:18 | ricotz 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:27 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.159.199, Ping timeout: 255 seconds) | |
20:28 | adrianorg 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:47 | kjackal 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:57 | Faith 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:39 | GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 244 seconds) | |
23:01 | GodFather has joined IRC (GodFather!~rcc@143.59.184.72) | |