|00:06||afpgfeirs has joined IRC (email@example.com)|
|02:20||shored has left IRC (firstname.lastname@example.org, Read error: Connection reset by peer)|
|02:20||shored has joined IRC (email@example.com)|
|02:24||afpgfeirs has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|03:12||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, *.net *.split)|
|03:18||vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e)|
|03:18||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
(01:07:00 AM) rkwesk: I am working through updating documentation on ltsp with bullseye (will be Debian 11)
Richard, Debian 11 will probably have LTSP 19
So whatever documentation you're preparing now, won't apply. Just document Buster, not Bullseye
If a script is needed, I should include it to ltsp19; if using network manager is enough, I should documented in `man ltsp dnsmasq`; there shouldn't be much need for distro-specific tutorials in ltsp19
vagrantc: someone here claimed that we have a security issue in ltsp5; that if someone uses "fish" as a login shell, he logs in as root
Dunno if you care to test/re-release...
seems highly improbably
in fact, if someone uses an alternate shell, login generally fails completely in my experience
(09:35:23 AM) uumas: Apparently ltsp5 logs anyone whose login shell isn't /bin/bash (or is /usr/bin/fish, didn't bother testing) in as root on clients. Took a moment to hunt that one down (one user logs in as root while everyone else is normal)
easy enough to test
guess it could be error handling in one of the ldm login hooks or something
(10:12:16 AM) uumas: Was apparently much quicker to test than I thought. Submitted a report!
uumas: where? I don't see it in launchpad... I wonder if I have enough rights to see ltsp security issues though...
vagrantc: remind me please, shell is "arch:any", or "arch:all"?
|05:27||* alkisg is constantly having a hard time remembering/googling this|
could be either
The one that doesn't need rebuilding, I mean
That is built only once
"all" architectures are able to use the same package, "any" architecture could build a package.
|05:28||* alkisg tries to find a few spare bytes in his mind to store that...|
it almost makes sense in english, but it's very nuanced
Eh, "all" architectures are able to build the source package, while "any" of them can rebuild a binary if it needs... too much word playing for my non-native english...
agreed, it's too subtle a distinction
|05:30||* alkisg managed to stored that look up epoptes or ltsp19 the next time he needs it|
even for a native speaker
|05:35||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|05:56||yanu_ has joined IRC (email@example.com)|
|05:57||yanu_ has left IRC (firstname.lastname@example.org, Client Quit)|
|06:45||gdi2k has left IRC (email@example.com, Ping timeout: 246 seconds)|
|06:46||gdi2k has joined IRC (firstname.lastname@example.org)|
|07:04||gdi2k has left IRC (email@example.com, Quit: Leaving)|
alkisg: This is the bug report: https://bugs.launchpad.net/ltsp/+bug/1839431
It says "Only the security group can see this information"
I added you as a subscriber for the bug. Idk of that helps
uumas: I just tried it and I can see it, dunno if the subscription helped or not
uumas: please add vagrantc too; I'm too focused on ltsp19 now to re-focus on ltsp5...
|08:18||shored has left IRC (firstname.lastname@example.org, Read error: Connection reset by peer)|
|08:19||shored has joined IRC (email@example.com)|
|08:25||shored has left IRC (firstname.lastname@example.org, Read error: Connection reset by peer)|
|08:26||shored has joined IRC (email@example.com)|
|09:21||shored has joined IRC (firstname.lastname@example.org)|
|10:06||shored has joined IRC (email@example.com)|
|11:00||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|11:33||shored has joined IRC (firstname.lastname@example.org)|
|12:31||shored has joined IRC (email@example.com)|
|13:26||shored has joined IRC (firstname.lastname@example.org)|
|13:28||shored has joined IRC (email@example.com)|
|13:36||woernie has left IRC (woernie!~werner@2001:638:408:2013:20a5:6101:2517:9792, Remote host closed the connection)|
|14:17||shored has joined IRC (firstname.lastname@example.org)|
|14:40||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
debian/control = something like https://termbin.com/0i3b
|15:40||yanu has left IRC (email@example.com, Ping timeout: 248 seconds)|
|15:56||ZAJDAN has left IRC (ZAJDANfirstname.lastname@example.org, Quit: Konversation terminated!)|
|16:09||shored has joined IRC (email@example.com)|
|16:25||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|
|16:26||mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Client Quit)|
|16:27||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|
anyone using ltsp on lubuntu 18.04, with lxqt ?
|16:43||mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Leaving)|
|18:16||shored has joined IRC (firstname.lastname@example.org)|
|18:52||bcg has left IRC (email@example.com, Quit: bcg)|
|18:53||bcg has joined IRC (firstname.lastname@example.org)|
|19:21||shored has joined IRC (email@example.com)|
|19:53||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
vagrantc: now with the usr merge... are we supposed to write #!/bin/sh or #!/usr/bin/sh ?
alkisg: Not sure, but #/bin/sh is at least better for backwards compatibility and the symlinks aren't going away because literally everything depends on them.
uumas: I think fedora doesn't even have a /bin/sh symlink anymore; will need to re-check
That couldn't possibly be
alkisg: Yeah, Fedora, Debian and Arch all have the entire /bin symlinked to /usr/bin
Maybe I was looking in the initramfs; I do remember something weird about fedora, but not what it was
alkisg: And (debian) systems upgraded from older versions still have it only in /bin/sh so you should definitely use that.
Dracut is fine too; dunno what I'm mis-remembering...
|20:30||* vagrantc found the argument for /usr merge dubious|
would have been better to move everything from /usr into /bin and /sbin
Why did /usr/* exist in the first place when they already had equivalents in /
|20:32||* alkisg would love it if the top dirs actually meant something useful; e.g. /usr => read only; /etc => host info; /var => writeable etc etc; in this sense, /bin would go into usr...|
E.g. ideally, it should be possible to install all debian buster arches into a single disk, and netboot any number of clients off of that
/usr/share would contain the arch:all packages, while the arch:any would go in /usr/<arch> or something (or /lib)
alkisg: It's not really that common to need multiple arches under a single root. I can see that as being difficult to maintain (but could be wrong)
uumas: I think some concepts in FHS are oriented towards that separation though
Could be, haven't dug too deep into it. There's chroot and debootstrap which mostly achieve the goal for the few purposes that need it though.
|20:42||* alkisg has generated the first alpha version of "ltsp_19.08-1_all.deb"; enough for today, tomorrow the installation tests start :)|
the reason for the /usr separation is historical and made sense at the time, largely due to the price of fast disks
-rw-r--r-- 1 alkisg alkisg 55K Αυγ 11 23:37 ltsp_19.08-1_all.deb ==> 55k, not bad :D
alkisg: Oh nice :D But yeah nothing should ever depend on anything being in /usr/* that wasn't there before usr migration for the foreseeable future.
And having a very quick way to push things from /etc/ltsp/* to ltsp.img to the clients is very very handy... e.g. I put code to look for sshfs there, so that if it's not in a live cd, the sysadmin can just put the binary in /etc/ltsp/ssh-$(uname -m)
And oh hey, same timezone
In the summer only!
I think in the winder we're different; we're UTC+02 here
I think most of the world has summer time
Dunno about Asia
Or anything other than America/Europe for that matter
relying on any particular PATH layout is asking for troubles...
PATH? About /etc? No if it's there, I symlink it to /usr/bin/sshfs
assuming a system-wide PATH exists at all ... but i've been getting into more esoteric distros :)
|20:51||* alkisg googles for distros named "soul searching debian" or similarly...|
...what esoteric distros?!
GNU Guix and NixOS
Heey that thing can run gnome? nice
i think the only thing in an expected path is /bin/sh ... everything else is dynamically added to PATH at boot.
well, that's even an oversimplification... but anyways
solves the problem of weather to use /bin/foo vs. /usr/bin/foo in a very different way ... by discovery.
Well, packages could ship package/bin/ dir, package/sbin dir, package/man dir etc etc, and the "dpkg/installer/whatever" could just look there and update a master cache on installation/uninstallation
No need for global locations at all..
well, that doesn't allow different users to have different versions installed :)
but probably best not to derail #ltsp further :)
There are system services and user services; system settings and user settings; system cache and user cache; no problems there...
Yeah, it's midnight anyway; pumpkin time
|21:00||* vagrantc waves to alkisg|
|21:00||* alkisg would wave, but ogra would say "shore" again :P|
|21:23||shored has joined IRC (firstname.lastname@example.org)|
|23:07||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|