ok, many thanks guys
see you soon ;-)
just one last thing
LIMIT_ONE_SESSION directive work the same way on fat/thin?
I'm not sure on that one
|00:10||nikoh77 has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|00:50||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|02:24||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|05:20||kjackal has joined IRC (email@example.com)|
|05:38||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 258 seconds)|
|05:54||spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 244 seconds)|
|06:01||vsuojanen has left IRC (email@example.com, Ping timeout: 268 seconds)|
|06:03||vsuojanen has joined IRC (firstname.lastname@example.org)|
|06:20||kjackal has joined IRC (email@example.com)|
|06:32||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 258 seconds)|
|07:25||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|07:36||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|08:35||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-jthvxojahwjictrc)|
|08:48||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|08:55||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|09:32||kjackal has left IRC (kjackal!quassel@conference/canonical/x-jthvxojahwjictrc, Ping timeout: 246 seconds)|
|09:58||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-sbuotvzmrbpqbvfy)|
|10:04||kjackal has left IRC (kjackal!quassel@conference/canonical/x-sbuotvzmrbpqbvfy, Ping timeout: 272 seconds)|
|10:23||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-mkdkuihhyqwdexdg)|
|10:53||kjackal has left IRC (kjackal!quassel@conference/canonical/x-mkdkuihhyqwdexdg, Ping timeout: 268 seconds)|
|11:53||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-gawcmrebxonbmpfo)|
|12:02||kjackal has left IRC (kjackal!quassel@conference/canonical/x-gawcmrebxonbmpfo, Ping timeout: 272 seconds)|
|12:03||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-duxrcunecwbnjrsu)|
|13:02||kjackal has left IRC (kjackal!quassel@conference/canonical/x-duxrcunecwbnjrsu, Ping timeout: 272 seconds)|
|13:42||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-ddwadyaehrgmnnst)|
|13:57||nikoh77 has joined IRC (email@example.com)|
Hi guys, to swap from fat to thin client configuration for all clients i have added LTSP_FATCLIENT=FALSE is it right?
in default sectio
|14:02||kjackal has left IRC (kjackal!quassel@conference/canonical/x-ddwadyaehrgmnnst, Ping timeout: 258 seconds)|
Ok, and now client dont start.... at the end of the boot "freez" on "Starting Update UTMP about System Runlevel Changes..."
i have a complete journalctl log but i dont see errors....i think
|14:30||spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)|
I only added LTSP_FATCLIENT=FALSE in ltsp.conf some idea?
|14:46||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-nfzqfocqcxpngciu)|
|15:06||kjackal has left IRC (kjackal!quassel@conference/canonical/x-nfzqfocqcxpngciu, Ping timeout: 250 seconds)|
|15:25||kjackal has joined IRC (kjackal!quassel@conference/canonical/x-cdoxxlvmjzbsitax)|
|15:29||nikoh77 has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|15:44||kjackal has left IRC (kjackal!quassel@conference/canonical/x-cdoxxlvmjzbsitax, Ping timeout: 258 seconds)|
|15:47||nikoh77 has joined IRC (email@example.com)|
nikoh77: upload your current lts.conf so that we see
alkisg: how can I upload it here
paste: To avoid channel flooding, please upload text longer than 3 lines to http://paste.debian.net. Don't forget to paste the resulting URL here.
Error: "logging" is not a valid command.
I do not know about 'log', but I do know about these similar topics: 'logs', 'irclogs', 'changelog', 'rsyslog'
rsyslog: To enable remote client logging in Ubuntu (it possibly also works on Debian), see https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/697387/comments/9
looks like this is outdated for 18.04... uncomment l17 and l18 now I think
nikoh77: try commenting out #LDM_THEME
And, and, try UNcommenting #X_SMART_COLOR_DEPTH=False
if i comment LTSP_FATCLIENT=False all work fine
(07:14:58 μμ) alkisg: And, try UNcommenting #X_SMART_COLOR_DEPTH=False
alkisg: in chrootlees environment i dont need to build clients right?
You don't need to run ltsp-build-client, if that's what you're asking
..a question.. whe i modify lts.conf, i need to update image to apply?
|17:36||bengoa has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
mwalters: thi is the log https://paste.debian.net/1060666/
the boot sto one second before start login page (xsession?), about when NDB_DISCONNECT
and... if i comment LTSP_FATCLIENT=False all work fine...
alkisg: sorry, I was commenting on something unrelated
mwalters: sure, I know, it's nikoh77 that didn't understand that you weren't talking to him
nikoh77: please read this line:
(07:14:58 μμ) alkisg: And, try UNcommenting #X_SMART_COLOR_DEPTH=False
ops, meant to tag nikoh77 not you
That means, remove the # from that line in your lts.conf, and reboot the client
ok i try
Hey Guys, work perfectly :-))))))
just last question: is possible to limit one session so that second thin client with same user dont gain access?
that limit one session line should work for thin clients at least. It will ask them if they would like to close/kill other sessions when they log onto another computer
I'm not sure if/how it works for fat clients
ok many thanks ;-)
|18:29||nikoh77 has left IRC (email@example.com, )|
|19:07||bengoa has joined IRC (firstname.lastname@example.org)|
|19:25||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|20:04||nikoh77 has joined IRC (email@example.com)|
|20:15||kjackal has joined IRC (firstname.lastname@example.org)|
alkisg: any idea on this? I have one EFI client that boots to tty1 instead of ldm. If I hit ctrl+alt+f7, it shows ldm just fine.
Try SCREEN_DEFAULT=07 in lts.conf
thanks, I'll give that a shot
The screen code design doesn't match the systemd era, it needs rethinking
ah I see
shouldn't matter if I put that under [default], I'm thinking?
(I don't have any clients that *shouldn't* default to ldm)
I'm not sure that this will work; just a try...
defaulted to ldm that boot, thanks!
It's strange, I was pulling my hair out w/ this intel NUC7... it absolutely refuses to boot using the EFI image. iPXE grabs it fine... I have other efi clients grabbing it fine... (not asking for help, just commenting/venting)
There's no option for legacy boot in the bios =/
I can see the image being offered, the silly thing just refuses to grab it
I'm using it as my personal desktop right now with iPXE on a usb stick... otherwise it's a solid little computer for a fat client
I still have to figure out how to make this iMac do network boot
|20:59||kjackal has left IRC (email@example.com, Ping timeout: 268 seconds)|
SCREEN_DEFAULT should be set to the highest defined SCREEN_NN
really odd that that would break; it's pretty straightforward code
it was on this nuc, so who knows ;)
vagrantc: I'm starting to design the new tftp layout/code for ltsp6... I'm thinking we could default to ipxe, and only document syslinux/grub as manual options for those rare cases where ipxe doesn't fit
I got both uefi and non uefi working
ipxe can't load a 32bit kernel from an uefi booted 64bit client
|21:20||nikoh77 has left IRC (firstname.lastname@example.org, Ping timeout: 268 seconds)|
But I think we can ignore that combination...
A question about architectures... now we say "i386/amd64", I'm thinking of switching to `uname -m`
This is i686 for 32bit, x86_64 for 64bit, and armv7l for raspberrys, in all distros that I tested with
ipxe will allow us to only put a couple of static files in tftp, and boot the kernel/initrd via http
Scenarios I've tested: (1) BIOS > TFTP undionly.kpxe > boot.ipxe script, (2) BIOS > grub > ipxe.lkrn > boot.ipxe script, (3) UEFI > TFTP snponly.efi > boot.ipxe script, (4) UEFI > grub > ipxe.efi > boot.ipxe script
So the server only has undionly.kpxe, snponly.efi, and our static boot.ipxe script, which supports "if" and variables, so it can be a static example that the user will manually modify if the defaults don't work for him
No more smart logic with 3 layers, too difficult for users to figure it out :D
using 'uname -m' requires a running system and may return unexpected output in a number of circumstances
But https://wiki.debian.org/SupportedArchitectures is debian specific, while uname -m is kernel specific, right?
So uname -m should be "cross distro"...
The client requesting the chroot will have running code (initramfs), yeah
uname -m may return i586 or i686 or a number of other things ... it's generally distro-specific, actually
armv7l is the kernel, not the userspace
and depending on what kernel you're running, you may get a different result
And that would be a good thing because we would want to differentiate between those, right?
really, you want to query the distro's idea of architecture, otherwise you'll get something wrong
Another example... dnsmasq/ipxe can see if a client is bios/uefi 32bit/uefi 64bit
We can then direct it to load a kernel based on that information only,
now, if we keep using distro-defined names like now, the code is a mess,
but what userspace do you give it, if there are more than one userspace supported by that kernel?
while, if we require specific symlinks, it makes things easier, e.g. "vmlinuz.i686" or "vmlinuz.x86_64" etc
The chroot is configured in dnsmasq
The same chroot can be booted with different kernels
Sure. So, if the symlink exists, then it can be used, if not, it's not available
But to make things easier in the tftp stage, we'd want all the distros to use the same symlink names
Imagine writing the "ltsp-update-kernels" code as an ipxe script, chaos
|21:47||adrianor1 has joined IRC (email@example.com)|
I.e. in the ltsp-client package, instead of the kernel postinst generating /boot/pxelinux.cfg, it would just create the appropriate kernels/initrd symlinks, with cross-distro names
Anyways it got a bit late... g'night for now, let's continue some other time
|21:51||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 268 seconds)|
|22:16||nikoh77 has joined IRC (email@example.com)|
|22:48||spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Quit: Leaving)|
hi, is possible to use raspberry pi 3 as a thin client?
|23:05||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)|
nikoh77: yes, but don't have high expectations
you might be better off using them as fat clients, and even then, they're quite slow
it's a bit more complicated to do right
but technically possible
|23:30||nikoh77 has left IRC (firstname.lastname@example.org, Quit: Leaving)|