LDM_PASSWORD_HASH: LDM_PASSWORD_HASH=True in lts.conf saves the password hash to /etc/shadow on login, so that the users can unlock the screensaver etc. If they happen to change their password though, that only takes effect until logout.

18:57

<Sleaker>

hmm, so I can get my thinclient to boot the image just fine, but it's not getting into a graphical login.

18:58

what's the best place to start troubleshooting which area is the problem

18:59

<quinox>

does control+alt+f1 / control+alt+f2 work?

18:59

<Sleaker>

yup

18:59

<quinox>

if so you can poke around in the logs

18:59

<Sleaker>

I have syslog forwarding working too

18:59

<quinox>

smart

18:59

<Sleaker>

and ssh directly into the box

18:59

bcg has left IRC (bcg!~b@82-128-233-166.bb.dnainternet.fi, Quit: bcg)

19:00

bcg has joined IRC (bcg!~b@82-128-233-166.bb.dnainternet.fi)

19:00

<Sleaker>

not sure if it's problematic but I am getting a pam issue with dbus-org.freedesktop.login1.service not found.

19:01

oh also looks like the nbd client is getting disconnected after the system boots.

19:01

that's odd

19:02

https://pastebin.com/51Vv8ppg

19:09

<vagrantc>

that's normal

19:09

<Sleaker>

mkay. it looks like it gets remounted later on.\

19:09

<vagrantc>

the nbd disconnect ... it's just a check to compare if the image you're running is different than the available image

19:10

to prevent people from running outdated images

19:10

<Sleaker>

makes sense. should there be 2 client processes still running nbd-client though? 2 of them look hung

woernie_ has left IRC (woernie_!~werner@x4db411d6.dyn.telefonica.de, Remote host closed the connection)

20:02

<Sleaker>

alkisg: yah wanted to bake it into a deb package along with me turning off a read-edid script he had written for us too. wanted to pair down anything running in between when it was laucnhing stuff.

20:02

cool

20:03

seems pretty slow though. might need to turn vesa back on haha

20:03

<alkisg>

So your thin clients have a couple of GB RAM, and an atom processor, yet you're working them as thin, not fats?

20:03

How so?

20:04

<Sleaker>

alkisg: we don't get them with HDs built internally.

20:04

<alkisg>

No, ltsp fat clients are diskless

20:04

!fatclients

20:04

<ltsp`>

fatclients: Nowadays LTSP supports thin and fat clients. They are both diskless and netbooted from the same LTSP chroot, but while thin clients run the session on the server and transfer the screen, fat clients run the session locally with their own CPU/RAM, thus performing amazingly better. See also !ltsp-pnp and https://help.ubuntu.com/community/UbuntuLTSP/FatClients

20:04

<Sleaker>

ah, I probably need to swap to fat client then

20:04

or look at it.

20:04

<alkisg>

What are the exact cpu/ram specs?

20:05

<Sleaker>

alkisg: our software stack need to run off the server though.

20:05

<alkisg>

You can use remoteapps for a few apps if you want

20:05

<Sleaker>

not like a few..

20:05

<alkisg>

If you do want the session on the server, then go for thins

20:05

<Sleaker>

might be more problematic, but I can try it out.

20:06

but yah, we have a bunch of apps that require talking to a flatfile database on the local server.

20:06

so thin client was always just architecturally where we went.

20:06

<alkisg>

If it's already multiuser enabled, they could also access it via sshfs

20:06

<Sleaker>

it's not.

20:06

well...

20:07

it's complicated :P

20:07

<alkisg>

How does it run with multiple thin client users then?

20:07

Haha

20:07

OK

20:07

<Sleaker>

I could probably write a wrapper app that sshd into the box and displayed the application, but that would only get like partway there.

20:07

and wouldn't work for where we are going in the future.

20:08

<alkisg>

Fat clients are already using ssh and sshfs

20:08

<Sleaker>

yup

20:08

<alkisg>

Usually wrapper apps are not needed

20:08

<Sleaker>

app constraints.

20:08

I'll look into it, but probably will cause problems.

20:08

<alkisg>

Just LOCALAPPS_EXTRAMOUNTS=/srv/the-required-dir, to forward the database dir

20:08

np; sounds like your setup is complicated, so you know better :)

20:09

<Sleaker>

https://www.zotac.com/dk/product/mini_pcs/zbox-ci323-nano#spec

20:09

but yah the TCs are powerful enough to be fats.

20:09

our support department replaced all the tech computers with them :P

20:09

<alkisg>

up to 8GB RAM => doesn't say

20:10

<Sleaker>

oh I think we ship them with 2gb

20:10

<alkisg>

Good enough for fats, yeah

20:11

<mwalters>

I still think 4-8 is best for chrome/chromium :P

20:11

<Sleaker>

accurate

20:11

we played around with local apps.

20:11

2gb was fine for chromium.

20:12

<mwalters>

our agency document management is a webapp... but we're also a gSuite shop... we have a few tabs open on each box, usually ;)

20:12

<Sleaker>

but then we're comparing a server system with only 8GB of ram running 2-4 TCs to running the browser on the TC via local app.

20:12

alkisg: on the slowness thing, it was rendering white boxes on the screen all over and not refreshing it quickly.

20:12

like X was only updating part of the screen at a time and slowly.

20:13

<alkisg>

Eh, thin clients have a lot of issues nowadays

20:13

Xorg doesn't care much for its remote implementation

20:13

<Sleaker>

host system is an i7-6700 w/ 16GB

20:29

<vagrantc>

Sleaker: i seem to recall issues where the app you needed to run also called other apps, and basically everything ended up running on the server

20:29

<Sleaker>

vagrantc: yup

20:29

<vagrantc>

so even if you did remote apps for that one thing, it would end up running everything remotely...

20:30

<Sleaker>

yup

20:30

<vagrantc>

everything except the window manager, anyways... which maybe that would still take some load off the server

20:38

<Sleaker>

on the bright side, I got the ltsp boot image generation all automated in our build process now. which makes it a lot easier to deal with

20:38

<vagrantc>

nice

20:39

<Sleaker>

oh hmm, something changed, rebooted and no just at a blank screen lol.

20:41

<vagrantc>

is it maybe not actually reading the lts.conf ?

20:42

<Sleaker>

nah /etc/lts.conf on the TC matches the one on the server

20:42

and it changes if I reboot the TC after changing the server one.

20:43

that was the first thing I started with. cause I wasn't 100% on where it was supposed to go

20:43

<vagrantc>

right

20:45

Sleaker: i just realized from your paste, you're working on a stretch/9 system ... i don't know what your timeline is, but buster/10 is likely to release in a few months

20:45

<Sleaker>

yup

20:45

<vagrantc>

would give you a longer support cycle ... if it works

20:45

<Sleaker>

I think I have everything to a point where I can just download all the packages and have it just work.

20:46

took a lot of time removing all of the os-specific stuff we have and making it detect the os name automatically so I can just build a buster image when ready