IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 6 May 2019 (all times are UTC)
| 00:47 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 244 seconds) | |
| 00:49 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 01:10 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 01:10 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 01:24 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 01:25 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 01:31 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 01:46 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds) | |
| 01:47 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 01:59 | HeyFootey has joined IRC (HeyFootey!0ecac19f@gateway/web/freenode/ip.14.202.193.159) | |
| 02:07 | HeyFootey has left IRC (HeyFootey!0ecac19f@gateway/web/freenode/ip.14.202.193.159, Quit: Page closed) | |
| 02:08 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 248 seconds) | |
| 02:11 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 03:49 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 255 seconds) | |
| 03:50 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 03:52 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Client Quit) | |
| 03:53 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 04:23 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 04:23 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 04:40 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 248 seconds) | |
| 04:46 | jgee7 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:50 | OlliZ 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:54 | ricotz 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:59 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 06:04 | jgee7 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:06 | jgee7 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:21 | OlliZ has left IRC (OlliZ!c37a9df8@gateway/web/freenode/ip.195.122.157.248) | |
| 06:29 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds) | |
| 06:30 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 07:11 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 07:14 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 07:29 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 07:29 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 07:43 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 08:42 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4) | |
| 09:47 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 252 seconds) | |
| 09:48 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 10:01 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 268 seconds) | |
| 10:01 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
| 10:02 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 10:30 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 10:46 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 255 seconds) | |
| 10:47 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 11:16 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 246 seconds) | |
| 11:17 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 11:22 | epoptes_user3 has joined IRC (epoptes_user3!c5febf78@gateway/web/freenode/ip.197.254.191.120) | |
| 11:30 | epoptes_user3 has left IRC (epoptes_user3!c5febf78@gateway/web/freenode/ip.197.254.191.120, Quit: Page closed) | |
| 11:37 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4, Remote host closed the connection) | |
| 11:38 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4) | |
| 11:50 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:00 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Ping timeout: 246 seconds) | |
| 12:00 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 12:08 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 12:09 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 12:09 | jgee7 has joined IRC (jgee7!~jgee@190.159.118.121) | |
| 12:15 | jgee76 has joined IRC (jgee76!~jgee@190.159.118.121) | |
| 12:16 | jgee7 has left IRC (jgee7!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 12:26 | nightingale^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:53 | jgee76 has left IRC (jgee76!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 12:53 | jgee761 has joined IRC (jgee761!~jgee@190.159.118.121) | |
| 13:25 | nightingale^nigh has left IRC (nightingale^nigh!c5febf78@197.254.191.120, Quit: Ping timeout (120 seconds)) | |
| 13:34 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:95da:8757:1453:83e4, Ping timeout: 248 seconds) | |
| 13:41 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection) | |
| 13:44 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-161.isotelco.net.br) | |
| 13:48 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c) | |
| 13:58 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 13:59 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Remote host closed the connection) | |
| 14:29 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving) | |
| 14:38 | Markus123 has joined IRC (Markus123!~markus@178.112.246.123.wireless.dyn.drei.com) | |
| 14:41 | Markus123 has left IRC (Markus123!~markus@178.112.246.123.wireless.dyn.drei.com, Client Quit) | |
| 15:15 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 15:18 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 248 seconds) | |
| 15:22 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c, Remote host closed the connection) | |
| 15:22 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c) | |
| 15:22 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 15:41 | GodFather has joined IRC (GodFather!~rcc@2601:602:9e00:158c:1d31:53f6:1d07:fa36) | |
| 15:47 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 15:48 | ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra) | |
| 16:01 | vagrantc 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:22 | sutula has left IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net, Read error: Connection reset by peer) | |
| 16:23 | sutula has joined IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net) | |
| 16:27 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c, Ping timeout: 258 seconds) | |
| 16:28 | kjackal has joined IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr) | |
| 16:38 | lucascastro 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:58 | woernie 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:13 | kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 246 seconds) | |
| 17:13 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:395e:84db:4649:a50c) | |
| 17:15 | adrianorg has joined IRC (adrianorg!~adrianorg@189.58.180.113.dynamic.adsl.gvt.net.br) | |
| 17:17 | adrianor1 has left IRC (adrianor1!~adrianorg@177.18.175.228, Ping timeout: 246 seconds) | |
| 17:24 | SYS64738 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:40 | statler 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:42 | kjackal 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:35 | Faith_ has joined IRC (Faith_!~Paty_@2001:12d0:2080:200::231:49) | |
| 19:38 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 19:39 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Ping timeout: 248 seconds) | |
| 19:39 | ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 248 seconds) | |
| 19:39 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 248 seconds) | |
| 19:40 | Faith_ is now known as Faith | |
| 19:40 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 20:03 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 20:24 | woernie has left IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:26 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |
| 20:58 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 22:08 | jgee761 has left IRC (jgee761!~jgee@190.159.118.121, Read error: Connection reset by peer) | |
| 23:19 | jgee has joined IRC (jgee!~jgee@190.159.118.121) | |
| 23:26 | GodFather has left IRC (GodFather!~rcc@2601:602:9e00:158c:1d31:53f6:1d07:fa36, Ping timeout: 252 seconds) | |
| 23:47 | GodFather has joined IRC (GodFather!~rcc@c-73-11-248-113.hsd1.wa.comcast.net) | |