LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

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


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

00:11||cw has left IRC (||cw!~chrisw@97-87-137-194.dhcp.stls.mo.charter.com, Changing host)
00:11||cw has joined IRC (||cw!~chrisw@unaffiliated/cw/x-1182934)
02:42vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:33vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:58ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:57markit has joined IRC (markit!~marco@88-149-234-116.v4.ngi.it)
10:05
<alkisg>
Now that SSD disks are becoming very cheap and very fast, it might be a good idea to store at least /home locally
10:06
Question: how important is the ability for the users to "work in any pc", and have their /home there? Would you miss it, even if local /home access was 10 times faster?
10:06
<markit>
alkisg: the possibility to sit in any PC is very important to me
10:07
one of the main "selling point" in my 2 schools
10:07
with 20 pc and Gbit connection /home is already fast enough
10:08
<alkisg>
markit: currently, it is; but have you tried windows 10 with hdd and with ssd?
10:08
With hdd, windows needs 5 minutes for the disk activity to settle down, to make the system more workable,
10:08
with ssd, that isn't noticable
10:09
<markit>
I've ssd in the ltsp server
10:09
<alkisg>
This is going to affect more apps, even linux ones, in the future, as all people will have ssd anddevelopers will rely on them
10:09
So, gigabit networking is 10 times slower than ssd
10:09
And if you multiply that with 10 clients, that's 100 times slower
10:10
<markit>
oh, that's right, kde has some really I/O intensive boot garbage in it that developers just with local disk don't notice, but nfs makes them a nightmare
10:10
<alkisg>
Is that speed loss acceptable, for the "work anywhere" benefit?
10:10
Currently it is NOT that bad; but it will become more and more noticable in the future
10:10
<markit>
it is for me, since children can sit in any PC, and if a PC is broken can be easely replaced just plugging a "backup one" that is in every lab
10:11
<alkisg>
Well if it was a windows pc, and it was broken, the student would go elsewhere, and just lose his documents
10:11
That'll be the same now
10:11
<markit>
but /home is useful only for data (and they have nothing very big) and configuration (should be not that big either)
10:12
ltsp is better than windows because (also) of this
10:12
<alkisg>
So you would accept 100 times slower than ssd, for this benefit, ok
10:12
<markit>
if ltsp has local /home then the difference with Win10 is reduced
10:12
no one complained so far because of speed
10:12
<alkisg>
Yes, so far, I'm talking about the future
10:12
<markit>
but I've got a lot of praise because of affidability and flexibility
10:13
<alkisg>
Another idea is that in the future, one will be able to buy a 64 GB usb stick with SSD-like speeds,
10:13
so that "local home" then will mean "move your usb elsewhere"
10:13
I.e. /home/username will be in the user's pocket, as a usb pendrive
10:14
This will combine both of the benefits, but we're not there yet
10:14
<markit>
alkisg: future? 10 years from now? we have usb2 pc where we have "new ones"
10:14
<alkisg>
usb2 can do 40 MB/sec, it's already faster than gigabit
10:14
<markit>
btw, I want to try 18.04 installation this week ("pnp fashion), is the netplan stuff automatically solved by your scripts?
10:14
<alkisg>
But not all usb2 drives can do 40 MB/sec
10:15
Ubuntu doesn't use netplan by default
10:15
<markit>
really? and systemd DNS?
10:15
<alkisg>
!install
10:15
<ltsp>
install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
10:15
<alkisg>
I document the steps for systemd-resolvd there
10:15
<markit>
maybe I tried something with 19.04 (not ltsp related) and cried loud...
10:16
<alkisg>
It's basically ltsp-config dnsmasq, with or without --enable-dns
10:16
<markit>
ok, so ltsp-config takes care of systemd dns, correct?
10:16
<alkisg>
yes
10:17
By default, it does nothing
10:17
So systemd dns continues working
10:17
If you --enable-dns, then dnsmasq replaces systemd dns
10:17
<quinox>
I like home being on the server, but I'm already tying people to specific machines because of VirtualBox images that we keep on harddrives
10:19
<alkisg>
quinox: yup; also note that if you're already doing this, you can set an FSTAB lts.conf directive, which will mount the local drive as /home, so that even launching firefox etc will be faster
10:19
<markit>
alkisg: and if I want to use /etc/network/interfaces to config wan and 2 BOND interfaces for clients, does it work "out of the box"?
10:20
<alkisg>
markit: sure; but you can do this from network-manager too, so that teachers can see if the connection is alive or not
10:20
I think ubuntu mate still ships ifupdown, which is what handles /etc/network/interfaces
10:20
<markit>
alkisg: my teachers can only mess up configs and connectivity, they are dumb in technology
10:20
<alkisg>
I think some flavors don't ship it though
10:21
They can see if the cable is connected. They cannot edit configs if you don't allow them to.
10:21
So you're making things harder AND losing benefits
10:21
But sure, it'll work, go for it
10:21
<markit>
even if they have sudo rights? I'm not very found on all the permission stuff :(
10:21
<quinox>
that's an interesting idea... it would require making some changes to how we make backups, but having things be faster would be nice
10:22
I'll try it out on the next person that complains things aren't fast enough
10:22
<alkisg>
quinox: more stable too; as ext4 is the default; while sshfs has issues with file locks, atomic renames etc, they sometimes cause issues
10:22
<quinox>
yeah, for stability I've replaced SSHFS with NFS a long time ago
10:23
<alkisg>
markit: yes, you can prevent sudoers from messing with network manager. You can't prevent them from running sudo rm -rf /etc/network/interfaces :P
10:23
<markit>
quinox: do you use kde by chance?
10:23
<quinox>
We do, yes
10:23
<alkisg>
quinox: nfs3 or 4? Are you using authentication for mounts? How?
10:23
<quinox>
no authentication :(
10:24
<alkisg>
Heh, I'd go for that; but vagrantc would never accept it :P
10:24
<markit>
quinox: I have a big I/O issue at startup, I had to set nfs /home *(rw,async,nohide,insecure,root_squash,no_subtree_check)
10:24
<quinox>
I mount the complete /home on startup, and users are managed through LDAP so as long as you don't sudo you don't get access to other people's files
10:24
nearly all of my users are root on the LTSP server anyway, so it's okay
10:25
<alkisg>
quinox: so for your use case, you wouldn't object if I transfered /etc/passwd and /etc/shadow over the network, right? :) This would allow you NOT to use ldap :D
10:26
<quinox>
I wouldn't object, correct, but I'm happy with my LDAP thank you
10:26
<alkisg>
Sure sure just survying for other users
10:27
<markit>
quinox: kde at startup tries to find a lot of icons of various formats and puts in a cache file under /var/tmp/kdecache-USERNAME, did you solved it in some way to speed things up?
10:27
<quinox>
I'm looking forward to the new LTSP, I'm gonna try to get it up and running with NFS4 and Kerberos
10:27
I believe we have some hack for that, yes, let me look it up...
10:28
<markit>
alkisg: I've also the problem that with kubuntu 16.04 (and probably 18.04) epoptes video broadcast is broken... do you think you can give me some support to try to find why and, maybe, fix it?
10:28
<quinox>
cat << EOF > /etc/X11/Xsession.d/10ltspMM_rm_phonondevicesrc
10:28
rm "$HOME/.kde/share/config/phonondevicesrc"
10:28
KDEVARTMP=$HOME/.cache
10:29
export KDEVARTMP
10:29
EOF
10:29
<markit>
quinox: with NFS4 I had the problem that all home files were "nobody:nogroup"
10:29
quinox: lol that's MY hack!
10:29
<alkisg>
markit: I probably fixed it already for epoptes 1.0, and you're using the old one, 0.5.10
10:29
<quinox>
I also run this hack for KDE users: apt --yes remove print-manager
10:29
<markit>
quinox: but is not for that issue
10:30
<quinox>
KDE completely crashes, we tracked it to something it tries to do with a printer in our network
10:30
<markit>
quinox: wich kubuntu? 18.04?
10:31
<quinox>
yes, it started somewhere on 16.04, it's still happening with 18.04
10:33
<markit>
mmm does not happen to me with 16.04, I'll have to check if print manager is installed
10:33
alkisg: what about pnp if I don't want a specific (or more) packages be in the client image? Like the "print-manager" above, or epoptes "server"?
10:33
<quinox>
we found a bug report that has the same stacktrace, supposedly they fixed it upstream
10:34
<alkisg>
Instead of removing it you could probably just use RM_SYSTEM_SERVICES=...
10:34
markit: the epoptes "server" auto-disables itself
10:34
for print manager, RM_SYSTEM_SERVICES
10:34
<quinox>
idunno, I don't care for KDE, and my KDE users don't care for print-manager, so we'll just apply this fix and be done with it
10:34
<alkisg>
For /usr/share/applications/*.desktop, a simple rm command in lts.conf
10:35
<quinox>
I made some wrapper around ltsp-update-image to apply our custom hacks automatically, so it's effectively the same as RM_SYSTEM_SERVICES
10:35
<alkisg>
You can also add snippets in /usr/share/ltsp/cleanup.d
10:35
<markit>
alkisg: so for specific programs I need in lts.conf /usr/share/applications/MyProgram.desktop ? where and how put "rm" in lts.conf?
10:36
<alkisg>
INIT_COMMAND_REMOVE_PLUMA_FROM_MENU="rm -f /usr/share/applications/pluma.desktop"
10:36
INIT_COMMAND_REMOVE_PLUMA="rm -f /usr/bin/pluma"
10:36
Things like that
10:36
I.e. just a few commands to be ran on ltsp client startups
10:37
Removing doesn't cost disk space, and it's simpler to maintain one image than many images
10:37
<markit>
so the line MUST start with INIT_COMMAND or what?
10:37
<alkisg>
!lts.conf
10:37
<ltsp>
lts.conf: (#1) http://manpages.ubuntu.com/lts.conf, or (#2) lts.conf manpage is available in the ltsp-docs package
10:38
<alkisg>
Yes, INIT_COMMAND_xxx means "run this command at startup"
10:38
xxx can be anything, it's for you to remember what it is
10:39
<markit>
can't find INIT_COMMAND in http://manpages.ubuntu.com/lts.conf or am I blind?
10:39
<alkisg>
Could be; we're not very good at documenting things :D
10:39
You could also use RCFILE_xxx
10:40
<markit>
"use the source, Luke" fashion, I guess (when documentation is incomplete)
10:42
alkisg: thanks a lot as usual, I've to run now :) see you soon, I'll try screen broadcast again and let you know
10:42markit has left IRC (markit!~marco@88-149-234-116.v4.ngi.it)
10:45
<quinox>
I agree with vagrant in that the default installation should be secure, but it has to be workable as well, and finding the sweet spot isn't always easy
10:45
<alkisg>
I'm tempted to completely avoid ssh-based authentication, and sshfs
10:46
Those that use ldap/nfs4/kerberos etc will be secure,
10:46
and those that want plain nfs3 will be insecure :D
10:46
It's hard to simplify security, when distributions don't really endorse sshfs for /home/username and pamssh for authentication
10:48
And those that use local /home, will be as secure as local home is
10:49
<quinox>
When someone can physically touch a PC he can do a lot of things already
10:50
on the other hand, users will get worms and cryptolockers and shit, so having passwords on things do still help
10:50
(and backups, obviously)
10:50
<alkisg>
For the far future, I'd go with "come with your usb for /home/username, and have it encrypted"
10:50
and if they give the correct username/password that can decrypt it, they can login
10:52
<quinox>
For customer projects when it comes to security I usually start by listing the thread model, what kind of attack(ers) do we want to deal with and which ones we don't (DDoS and NSA)
10:52
it helps to crystalize the discussion, instead of going back and forth about what could possibly go wrong
10:53
I like the sound of that
10:55
USB3 goes up to 5 Gbit/s? wow
11:00
<alkisg>
And if you have 10 clients, that's 50 gbps :)
11:00
Hard to beat with a simple gigabit server...
11:01
usb 3.1 is 10 gbps, etc etc
11:01
<quinox>
it sounds like a fantastic setup: Safe, easy to understand and build
11:02
<alkisg>
And I think that's per controller, so one can use 2 usb sticks, one for caching root and one for /home
11:02
(one that belongs to the school and the other to the user)
11:02
That'll be like a dual-ssd setup, rather fast
11:03
Lunch time, later!
11:03
<quinox>
bye
11:07
since you said it's for the far future, do you think it's a lot of work to build? Would be pretty sweet for LTSP6, during installation you ask the user if he wants LTSP to be (1) perfectly safe [bring your own USB drives], (2) perfectly safe [bring your own LDAP+Kerberos+NFS4], or (3) safe enough when you can sort of trust your users [LTSP will setup NFS3]
11:11nickolai has joined IRC (nickolai!1f2b0d7f@gateway/web/freenode/ip.31.43.13.127)
11:12
<nickolai>
Hi everyone!
11:12
<quinox>
hello
11:13
<nickolai>
Alkisg is here&
11:13
?
11:14
<quinox>
he just left for lunch
11:15
5 minutes ago
11:15
<nickolai>
Can anyone help me with one question? Is it possible to make Skin of Windows on LTSP?
11:16
Im ready to pay for this
11:17
Like this one but over the LTSP https://github.com/B00merang-Project
11:17
<quinox>
after logging in it's all standard linux
11:18
The login via LDM can be skinned, but I don't know how far you can go
11:19
funny repo :)
11:19
that you should - give it a shot!
11:19
(I don't know if you already have LTSP set up)
11:19
that you should -> that should work
11:20
<nickolai>
The thing is to make user friendly interface (For users that used to usу Windows, bun only browser and Libero)
11:20
I му got LTSP set up
11:20
шму пще ше ыуееув гз
11:21
Sorry? misstype
11:21
<quinox>
okay, so try it with 1 account to use fe the Win10 theme
11:21
<nickolai>
Poor english(
11:21
<quinox>
if that works there are ways of applying that change to all users
11:22
<nickolai>
Can i ask someone more professional to do this and im ready to pay for this
11:24
There are a lot of things which i don't understand
11:25
<quinox>
sure
11:25
i don't, but maybe alkisg
11:25
just keep hanging in the chat and he'll be back at some point :)
11:26
<nickolai>
Oh thanks a lot)
12:36
Alkisg is here?
13:09
<alkisg>
nickolai: back :)
13:09
nickolai: ok since it's about a job, let's talk in private messages
16:25GodFather_ has joined IRC (GodFather_!~rcc@143.59.184.72)
16:26GodFather has joined IRC (GodFather!~rcc@143.59.184.72)
17:14
<alkisg>
!vq
17:14
<ltsp>
Error: "vq" is not a valid command.
17:25GodFather__ has joined IRC (GodFather__!~rcc@143.59.184.72)
17:27GodFather__ has left IRC (GodFather__!~rcc@143.59.184.72, Client Quit)
17:27GodFather_ has left IRC (GodFather_!~rcc@143.59.184.72, Quit: Ex-Chat)
17:28GodFather has left IRC (GodFather!~rcc@143.59.184.72, Remote host closed the connection)
17:28GodFather has joined IRC (GodFather!~rcc@143.59.184.72)
19:32woernie has joined IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de)
20:19ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
20:29woernie has left IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de, Remote host closed the connection)
21:03nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242)
22:56adrianor1 is now known as adrianorg