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


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

00:47jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 244 seconds)
00:49jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
01:10jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
01:10jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
01:24jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
01:25jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
01:31vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
01:46jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds)
01:47jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
01:59HeyFootey has joined IRC (HeyFootey!0ecac19f@gateway/web/freenode/ip.14.202.193.159)
02:07HeyFootey has left IRC (HeyFootey!0ecac19f@gateway/web/freenode/ip.14.202.193.159, Quit: Page closed)
02:08jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 248 seconds)
02:11jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
03:49jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 255 seconds)
03:50jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
03:52jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Client Quit)
03:53jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
04:23jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
04:23jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
04:40jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 248 seconds)
04:46jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
05:24
<alkisg>
vagrantc: re: man pages and usage. It'll be easier to maintain man pages in markdown or similar format, not inside the source code. So I'm thinking to run `man tool | extract_usage` to show a short usage for `tool --help`,
05:24
can we assume that `man` is available at runtime, or should we do that at build time?
05:25
(we can also do it at coding time, manually, if we prefer)
05:27
E.g. https://www.eddieantonio.ca/blog/2015/12/18/authoring-manpages-in-markdown-with-pandoc/
05:39
<vagrantc>
alkisg: we can depend on man at either build time or run time
05:39
<alkisg>
Great
05:40* alkisg googles for "pandoc vs sphinx"...
05:40
<vagrantc>
pandoc has a huge dependency tree
05:40
sphinx has it's issues ... which is why i went with whatever the lts.conf manpage is now rendered with
05:41
<alkisg>
vagrantc: which one are you using?
05:41* alkisg heard that ronn is to be removed from debian
05:41
<vagrantc>
go-md2man
05:42
<alkisg>
Ah, thanks, looking...
05:42
<vagrantc>
that was the other contender
05:43
<alkisg>
You already solved that part then, no need for me to google! Thanks!
05:43
<vagrantc>
it would be interesting to go from extracting the manpages from the tools to injecting the manpages from the documentation :)
05:43
<alkisg>
Well, help2man needs a separate file with all the "See also" etc sections
05:43
And writing things inside the source code isn't very nice, doesn't align very well etc
05:44
<vagrantc>
if it can be done well, generating the documentation from the code is really nice ...
05:44
er, i mean injecting the --help output from the documentation
05:45
pretty much a 180 degree change :)
05:45
<alkisg>
I gave it some thought. Ideally, distros could add or omit help sections (e.g. some distro may not support ltsp-config --dnsmasq) and command line parameters, but coding that in bash is very difficult
05:45
So the help and command line options for each tool will be static, not overridable
05:45
<vagrantc>
you end up with things like ltsp-build-client when you try to do that :)
05:46
<alkisg>
If we can use some tool to internationalize the man pages, it would be nice
05:46
<vagrantc>
the only worry is that the documentation will get out of sync with the code ... that's what's nice about generating it from the code
05:46
<alkisg>
Yeah, rather complicated
05:47
If the usage is maintained in the tool/manpage.md, the developer can't really ignore that
05:47
So it can't go much out of sync
05:47
<vagrantc>
yeah, layout might help a bit
05:47
we could also write tests to check
05:49
<alkisg>
I mean, it's still a single source for both `usage` and `man`, nothing really changed
05:49
<vagrantc>
you could have a very barebones help that all the tools support that just output all the arguments, and then test to make sure they're at least mentioned in the document
05:50OlliZ has joined IRC (OlliZ!c37a9df8@gateway/web/freenode/ip.195.122.157.248)
05:50
<alkisg>
It's not 2 sources that can go out of sync
05:50
<OlliZ>
Hallo good morning to all
05:50
<alkisg>
Hi OlliZ
05:50
<vagrantc>
well, the usage and man and code are three different things, sounds like you're talking about keeping two of them in sync
05:51
<OlliZ>
do anybody know how to use a beamer with an ltsp client
05:51
<vagrantc>
a projector?
05:51
<OlliZ>
yes
05:51
<vagrantc>
presumably like any outher video output
05:51
<alkisg>
everything is a single file, tool.md. At build time, tool.man is generated, then the ltsp-functions `usage` function runs tool.man | extract_usage to display `tool --help`
05:51
vagrantc: i.e. only one point for writing documentation text; there won't be any inside the code
05:52
<vagrantc>
alkisg: right, but then there's what the code actually supports
05:52
alkisg: unless you make usage function somehow required in order to not error out
05:53
<alkisg>
We always took care that the tool's `usage` function was in sync with what the code supported,
05:53
now, if the generic `usage` function can't run `man tool`, it will error out, sure
05:53
<vagrantc>
$tool --command-i-quickly-added-but-didnt-document could be missing from both usage/man
05:53
<alkisg>
Sure, we can't help that part; but we always manually added it to `usage` previously, we'll just continue to do so now
05:54
<vagrantc>
well, we could do programatic checks
05:54ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:54
<alkisg>
Nah, I think it gets too complicated to check "oh this short option doesn't align with that long option and oh it's in the getopts line but not in the eval arguments case/loop"
05:55
<vagrantc>
alkisg: in the wild days before you came around, people were not very good at updating these things :)
05:55
myself included
05:55
<alkisg>
Well, then we'd need to write our own getopts implementation in python
05:56
<vagrantc>
wild idea, might not be worth it
05:56
<alkisg>
Which would read the man page, extract the options from there, and make them shell variables
05:56
I don't think it's worth it, no
05:58
<vagrantc>
alkisg: well, it's that time of day again ... nice to bounce ideas again :)
05:59* vagrantc waves
05:59vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:04jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 244 seconds)
06:04
<OlliZ>
any sugestion for my problem --> Beamer projector ?
06:04
<alkisg>
OlliZ: doesn't the projector work automatically? Did you have any issues?
06:05
Projectors normally are like a second monitor, and work automatically
06:05
<OlliZ>
i bootet the thin client normaly an put the hdmi cable to it but no output to the projector
06:06
<alkisg>
Which distro/version?
06:06
<OlliZ>
Edubuntu 12.04
06:06jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
06:06
<alkisg>
Oh, that's a whole lot out of date :D
06:06
Anyway, what's the output of `xrandr` ?
06:06
On the client, run: xrandr | nc termbin.com 9999
06:07
It will show a URL, paste it here
06:07
<OlliZ>
yes i know but there is no newer distro they stopped releases
06:07
<alkisg>
There's Ubuntu
06:07
All the programs in edubuntu are in ubuntu too
06:07
That's why we stopped, there wasn't much reason for it
06:08
<OlliZ>
shall i do a distr upgrade to new ubuntu release at first ?
06:08
<alkisg>
You would need 3 dist upgrades: 12 => 14 => 16 => 18
06:08
It might be best to do a clean installation of ubuntu 18.04
06:08
!install
06:08
<ltsp>
install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
06:09
<alkisg>
Btw, what are your client specs? Which CPU exactly and how much RAM?
06:09
<OlliZ>
but i have at about 200 user accounts and their home
06:10
<alkisg>
You can import the accounts and keep the home
06:11
<OlliZ>
i have different clients they a big factory funded the older hardware for us we are a montessori shool in germany
06:11
<alkisg>
Mention a few of them. What's the lowest RAM? What's the oldest CPU?
06:12
<OlliZ>
lowest ram is 2GB and oldest Cpu is Intel Core 2
06:12
<alkisg>
Those are good enough to run as fat clients, not thin
06:12
<OlliZ>
hardware is about 5-6 years old
06:12
<alkisg>
Do a clean 18.04 installation; I can offer professional help in migrating the users and home, if you need it
06:13
<OlliZ>
how are the steps to migrate users and homes?
06:13
in short
06:13
<alkisg>
Personally I'm using a greek application that we developed for that, called "sch-scripts",
06:14
if you can't read greek for 10 minutes for the migration, you'd need to google for other methods
06:15
Keeping /home is simple, you just tell the installer not to format the target partition
06:15
<OlliZ>
yes i think i will upgrade
06:15
<alkisg>
Upgrading 3 times will probably end up in broken installation
06:15
Many of the packages will be missing or have broken dependencies
06:15
<OlliZ>
no sorry clean install
06:15
<alkisg>
Great
06:15
Do keep your old /etc/passwd, shadow, group and gshadow
06:16
<OlliZ>
my english is not the best :-k)
06:16
<alkisg>
So that it's possible to avoid recreating the users
06:16
(most tools use those files to merge the old users to the new system)
06:16
Also, it'd be best to keep the whole old installation in a subdirectory, e.g. /srv/edubuntu
06:16
<OlliZ>
and you think its better to run the old hardware as fat client ?
06:17
<alkisg>
So that you can (1) fall back to it, if the newer one doesn't work for some reason, or (2) get things from there that you forgot
06:17
5 years old hardware is new hardware, not old :)
06:17
Yes, follow the steps in this page exactly:
06:17
!install
06:17
<ltsp>
install: http://wiki.ltsp.org/wiki/Installation/Ubuntu for Ubuntu, or http://wiki.ltsp.org/wiki/Installation for other distributions
06:17
<alkisg>
This will get you the best possible system
06:17
Use the 64bit .iso mentioned there
06:18
<OlliZ>
ok nice so i will ask google to migrate my users and homes
06:18
<alkisg>
Nice
06:18
Ping me if you end up needing help
06:18
<OlliZ>
and did the projectors the work out of the box?
06:18
<alkisg>
Sure
06:19
And firefox will be showing all pages, because yours now has expired certificates etc
06:20
<OlliZ>
ok thank you very much for your help and have an nice day -- i use chromium on our system
06:20
<alkisg>
Have a nice day too
06:20
<OlliZ>
cya
06:21OlliZ has left IRC (OlliZ!c37a9df8@gateway/web/freenode/ip.195.122.157.248)
06:29jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds)
06:30jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
07:11os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
07:14SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
07:29jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
07:29jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
07:43statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
08:42kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4)
09:47jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds)
09:48jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
10:01jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 268 seconds)
10:01woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
10:02jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
10:30woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
10:46jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 255 seconds)
10:47jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
11:16ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 246 seconds)
11:17ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
11:22epoptes_user3 has joined IRC (epoptes_user3!c5febf78@gateway/web/freenode/ip.197.254.191.120)
11:30epoptes_user3 has left IRC (epoptes_user3!c5febf78@gateway/web/freenode/ip.197.254.191.120, Quit: Page closed)
11:37kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4, Remote host closed the connection)
11:38kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4)
11:50Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:00jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 246 seconds)
12:00jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
12:08mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
12:09jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
12:09jgee7 has joined IRC (jgee7!~jgee@190.159.118.121)
12:15jgee76 has joined IRC (jgee76!~jgee@190.159.118.121)
12:16jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer)
12:26nightingale^nigh has joined IRC (nightingale^nigh!c5febf78@197.254.191.120)
12:27
<nightingale^nigh>
hey, please help me to configure epoptes
12:30
hey
12:42
<mwalters>
http://www.epoptes.org/installation
12:53jgee76 has left IRC (jgee76!~jgee@190.159.118.121, Read error: Connection reset by peer)
12:53jgee761 has joined IRC (jgee761!~jgee@190.159.118.121)
13:25nightingale^nigh has left IRC (nightingale^nigh!c5febf78@197.254.191.120, Quit: Ping timeout (120 seconds))
13:34kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4, Ping timeout: 248 seconds)
13:41spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection)
13:44lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-161.isotelco.net.br)
13:48kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c)
13:58spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
13:59os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Remote host closed the connection)
14:29mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving)
14:38Markus123 has joined IRC (Markus123!~markus@178.112.246.123.wireless.dyn.drei.com)
14:41Markus123 has left IRC (Markus123!~markus@178.112.246.123.wireless.dyn.drei.com, Client Quit)
15:15mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
15:18spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 248 seconds)
15:22kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c, Remote host closed the connection)
15:22kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c)
15:22spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
15:41GodFather has joined IRC (GodFather!~rcc@2601:602:9e00:158c:1d31:53f6:1d07:fa36)
15:47ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
15:48ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
16:01vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:02
<vagrantc>
alkisg: there are two bugs filed on go-md2man, and one of them references LTSP. :)
16:03
https://bugs.debian.org/919454
16:10
a pretty minor issue
16:22sutula has left IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net, Read error: Connection reset by peer)
16:23sutula has joined IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net)
16:27kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c, Ping timeout: 258 seconds)
16:28kjackal has joined IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr)
16:38lucascastro has left IRC (lucascastro!~lucascast@177-185-139-161.isotelco.net.br, Remote host closed the connection)
16:38
<alkisg>
Great :)
16:48* vagrantc seems to recall other issues blocking ltsp from being cross-buildable
16:48
<vagrantc>
though obviously moving to architecture independent builds would solve that
16:57
<alkisg>
vagrantc: now that ltsp will be arch:any, why does it need to be cross-buildable?
16:58
(or however else the interpreted packages are called)
16:58
<vagrantc>
alkisg: you mean arch:all ?
16:58
<alkisg>
That one
16:58
<vagrantc>
it's currently arch:any + arch:all
16:58woernie has joined IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de)
16:59
<vagrantc>
alkisg: that would definitely fix the issue, yes.
16:59
<alkisg>
Nice. And, ltsp-client will be a meta-package, just to get nbd-client and the other dependencies
17:00
While the ltsp-client code will reside server-side, and support all distros from the same source
17:00
Today I did the run_parts* infrastructure.
17:00
"Most scripts are organized in directories, and numbered as follows: [0-9][09]|[09][0-9]: site and local admins [1-8][18]|[18][1-8]: distributions, their derivatives and third part programs (sch-scripts, epoptes) [2-7][2-7]: upstream "
17:01
It's somewhere between function overloading (ltsp-config, ltsp-common-functions) and ltsp-build-client modes
17:11
<vagrantc>
i thought we were planning on not having the client/server split, so that they could be installed in parallel ... ?
17:11
e.g. just an "ltsp" package
17:13kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 246 seconds)
17:13kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c)
17:15adrianorg has joined IRC (adrianorg!~adrianorg@189.58.180.113.dynamic.adsl.gvt.net.br)
17:17adrianor1 has left IRC (adrianor1!~adrianorg@177.18.175.228, Ping timeout: 246 seconds)
17:24SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 250 seconds)
17:25
<alkisg>
vagrantc: yes, it will only be an ltsp package, but the client "VM" still needs nbd-client etc
17:25
So if someone is using ltsp-update-image -c /, there's no need for ltsp-client package,
17:26
if one is using a VM as a client, he'll need nbd-client etc, so we may provide a meta-package for the dependencies
17:28
E.g. amd64 server, raspbian "chroot/vm/whatever", we need nbd-client in the raspbian initramfs; we can't provide it from an "interpreted" package
17:29
It's a pitty that nbd-client isn't always available in initramfses, as the nbd module is usually there anyway, and the nbd-client is just a socket setup/kernel function call
17:30
<vagrantc>
arch:all can depend on arch:any ...
17:30
so in that case "ltsp" should just depend and/or recommend nbd-client
17:31
well, depend or recommend, doesn't make sense to do both
17:31
and you install "ltsp" both on the server, and in the "chroot/vm/whatever"
17:31
or am i missing something?
17:40statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
17:47
<alkisg>
vagrantc: being an all/any package on amd64, you can't pull nbd-client for the armfh initramfs
17:48
We can only add interpreted things in the initramfs
17:48
if we want to be arch agnostic
17:48
<vagrantc>
so you'll want a client package for architecture-specific dependencies?
17:48
<alkisg>
Right
17:49
Either that, or just a wiki page
17:49
"install nbd-client etc"
17:51
<vagrantc>
why not just install "ltsp" in the client image, then?
17:51
not really any different from installing "ltsp-client"
17:51
<alkisg>
Because that's actually the server part, with dnsmasq and all
17:51
And it allows other clients to be netbooted
17:51
Well
17:51
<vagrantc>
i see ... extra dependencies
17:51
<alkisg>
Ideally, we can convince distros to have nbd-client preinstalled
17:51
In which case we won't need ltsp-client at all
17:51
<vagrantc>
unlikely
17:52
<alkisg>
And possibly libpam-sshauth
17:52
If we have those 2 things (or find a way to ship them in interpreted form), then we don't need ltsp-client
17:52
Until then, we need an ltsp-client empty meta-package, or a wiki page instruction "install these in any ltsp VMs/chroots"
17:52
<vagrantc>
so, the goal is to be able to build an ltsp.img from any arbitrary chroot, vm image, etc.
17:53
<alkisg>
ltsp.img is built from the server only, no chroots involved
17:53
<vagrantc>
and we either need to document the extra packages they need installed in those environments, or keep providing a meta-package?
17:53
<alkisg>
The chroot has its own initramfs; we don't touch it at all
17:53
and ipxe loads/merges both of these
17:53
(08:53:07 PM) vagrantc: and we either need to document the extra packages they need installed in those environments, or keep providing a meta-package? ==> right
17:53
ltsp.img basically only contains "init-ltsp.d" and the initramfs hooks
17:54
and lts.conf
17:54
<vagrantc>
ah, i mean /opt/ltsp/images/ARCH.img ... not to be confused with a thing you append to the initramfs
17:55
<alkisg>
The squashfs image? This isn't really related to the initramfs talk, it's just the VM in compressed form
17:55
<vagrantc>
for some architectures you might have to concatenate the "native" initramfs with the "ltsp" initramfs parts server-side, rather than relying on ipxe/syslinux/whatever
17:55
<alkisg>
Which one? syslinux/grub/ipxe/kernel all support that
17:56
<vagrantc>
u-boot ?
17:56
<alkisg>
If we do need it, ok, we can add it then
17:56
I think u-boot supports syslinux compatible files
17:56
So I would imagine it supports 2 initramfses like syslinux...
17:56
<vagrantc>
i would be surprised if it supported that syntax, but happy to be proven wrong
17:57
<alkisg>
Btw, if we have the appropriate qemu-system-arch installed, we can add nbd-client etc in the "VM" at the `ltsp-update-image -c arch` phase
17:57
So:
17:58
ltsp-update-image --install-ltsp-client -c original-raspbian.img ==> would produce a suitable armhf.img
17:58
But that's for much later on
17:59
Re: u-boot, I guess if one concats 2 proper initrds=cpio archives, it'll work, right?
18:00
I.e. no unmkinitramfs call necessary there....
18:00
<mwalters>
so... I'm back looking at ldap... this just popped into my brain: If I use ldap for auth... the user won't have a shadow entry... which means there's nothing to copy to the fatclient for things like screenlocking, right?
18:01
<alkisg>
The shadow entry is generated by ldm at login
18:01
By md5sum'ing the password he entered
18:01
<mwalters>
from user input?
18:01
<alkisg>
It's not copied from the server shadow
18:01
<mwalters>
ah ok, cool... thanks :D
18:02
(sort of... ;) )
18:03
<vagrantc>
alkisg: could probably even do it with qemu-user-static
18:04
alkisg: yes, in my experience, you can concatenate multiple cpio.gz for the initramfs and u-boot loads it fine and linux unloads all the archives
18:04
<alkisg>
If we want to do that by default, ltsp-update-initrd will need e.g. 2 seconds, to do it for all arches/initrds
18:04
If we default to seperate initrds, it'll be instant
18:05
I'd like to file a bug report against u-boot, when the need rises, first
18:05
<vagrantc>
don't really know of any platforms running u-boot that would work well for LTSP anyways, at this point
18:06
and... i have tested quite a few :)
18:06
<alkisg>
I should also test raspbian wrt that
18:06
I imagine people will keep using ltsp with rasbpian, to avoid sd cards
18:06
And it runs a bit faster too
18:07
<vagrantc>
raspbian runs faster than what?
18:07
<alkisg>
raspbian over ltsp, runs faster than raspbian over sd card
18:07
<vagrantc>
ah!
18:07
<alkisg>
I.e. squashfs'ed image over 100 mbps is currently faster than sd
18:07
being compressed,with lower overhead and all
18:08
And it avoids sd card wearing out
18:08
If at some point sd cards become as fast as ssd disk, we'll have to update our strategy! :D
18:11
<highvoltage>
that would be nice
18:11
<vagrantc>
i wonder if a sqaushfs'ed image on SD would be faster
18:12
<highvoltage>
although ethernet is also getting faster :p (2.5/5gbps might be standard in a few years too, which makes diskless an enticing option for everyone)
18:12
<alkisg>
It would, i tested that in local disks
18:12
highvoltage: I don't think it'll ever reach 500MB/sec that disks have now. That's 5 gbps *per client*
18:12
And I think they'll continue making them faster, now that they don't have moving parts
18:13
<highvoltage>
alkisg: disks are already faster than that
18:13
alkisg: ssd disks, that is, but soon that will all be that you have anyway
18:13
alkisg: spinning disks aren't keeping up with the growth in size, after that it just becomes an issue of cost
18:13
<alkisg>
Yeah, I mean that currently ssd disks are e.g. 20 times faster than networking, and I expect them to become even faster in the future
18:14
So we should invest in local cloning/caching at some point
18:14
I think the best future there would be: an ext4 local file system, with possibly /home/some-local-homes, and /srv/image1.squashfs and /srv/backup.squashfs
18:15
<highvoltage>
so yeah, I think with high speed disks and high speed networking, diskless will get some more attention again in the future
18:15
<alkisg>
...making ltsp client booting fast like ssd disks (or even faster due to compression), supporting offline booting without an ltsp server,
18:15
<highvoltage>
yeah
18:15
<alkisg>
and, ideally, those images would be automatically synched using multicasting and reusing other lan packets etc etc, very efficiently
18:16
I think diskless will get a lot of attention when google/nvidia etc make their gaming servers hardware for consumers
18:16
If we had ltsp servers with 10 hdmi-over-lan outputs... it'd be great
18:16
<vagrantc>
having an opportunistic local cache would be nice
18:16
<highvoltage>
I don't think that's so necessary. binary diffs would be easy and efficient enough at that speed
18:17
<alkisg>
I.e. hardware compressed video stream of the users screens
18:17
<highvoltage>
alkisg: have you used multihead in recent year?
18:17
<alkisg>
*not just diskless; then we'll get back at the thin client model :D
18:17
<vagrantc>
heh
18:17
<highvoltage>
I did a long time ago and a client asked for it, but so much have changed since I last used it
18:17
<alkisg>
highvoltage: I've a customer that has 200 multiseat clents
18:17
Multihead or multiseat?
18:18
Multihead = multiple monitors, nothing special...
18:18
<highvoltage>
as in, one computer, 4 (or whatever number) displays, 4 keyboards etc...
18:18
<alkisg>
Right, multiseat
18:18
He reports that it works perfectly
18:18
<vagrantc>
wow
18:18
<alkisg>
Me, I added support for that in ltsp a few years back, but I never used it in production myself
18:19
The restriction there in the current code is that you need separate graphics cards for the displays
18:19
<vagrantc>
i briefly tested it back in... late 2016 when i integrated that new upstream version
18:19
<alkisg>
Not just multiple outputs of the same card
18:19
systemd prefers it that way
18:21
<mwalters>
alkisg: any idea how much effort it would take to use sha256 instead of md5?
18:21
<alkisg>
mwalters: it's using sha
18:22
<mwalters>
oh! good :)
18:22
<alkisg>
It was just a quick sentence there
18:22
Trying to avoid to explain too much :)
18:22
<mwalters>
lol, sorry for ruining that
18:22
<alkisg>
:P
18:23
Hmmm... I think if we finish ltsp 19.09 without libpam-sshauth, then send enough lobsters to sbalneav, we'll convince him to properly integrate it and avoid all the ldap stuff. So we just need a lobster fund raising.
18:28
<mwalters>
I'm not too far from Massachusetts
18:28
;)
18:42kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c, Remote host closed the connection)
19:10
<mwalters>
The centos7 freeipa package seems to work much better out of the box, than the ubuntu 18.04 one
19:10
"Yet another VM" =/
19:27
Looks like migrating local accounts to freeipa accounts isn't too difficult... map the freeipa uid/gid to the local user... remove the user from passwd/group/shadow
19:27
seems to have worked, anyways ;)
19:35Faith_ has joined IRC (Faith_!~Paty_@2001:12d0:2080:200::231:49)
19:38ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
19:39Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Ping timeout: 248 seconds)
19:39ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 248 seconds)
19:39spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 248 seconds)
19:40Faith_ is now known as Faith
19:40Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
20:03spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
20:24woernie has left IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de, Remote host closed the connection)
20:26ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
20:58Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
22:08jgee761 has left IRC (jgee761!~jgee@190.159.118.121, Read error: Connection reset by peer)
23:19jgee has joined IRC (jgee!~jgee@190.159.118.121)
23:26GodFather has left IRC (GodFather!~rcc@2601:602:9e00:158c:1d31:53f6:1d07:fa36, Ping timeout: 252 seconds)
23:47GodFather has joined IRC (GodFather!~rcc@c-73-11-248-113.hsd1.wa.comcast.net)