kiwi-ltsp-users — Kiwi-ltsp-users posts

[Kiwi-ltsp-users] kiwi-ltsp - slave printer setup

[Michel D. <do...@te...>]

On a Suse server
I'm trying to setup an USB slave printer to a work station
here below are my configuration files.
When I boot a station, i can see on the lower right  the identification 
of the station as
localhost(192.168.0.101) +time  stamp

The printer is configured in cups as ipp://192.168.0.101:9100
my problem is when I send a print out the print stays on cups and stall.
the print  system  doesn't find the station
On a terminal I can Identify the printer with 'lsusb'

On an Ubuntu system with the same configuration as below I can send a 
print and the printer receive it (it's working)
On the Ubuntu station on the lower right, the station is identified as 
ws101(192.168.0.101) + the time stamp

Where do I am wrong on the Suse server

---------------------------------------------------------------------------------
*dhcpd.conf*

option domain-name "Donais.ca";
option domain-name-servers 8.8.8.8, 8.8.4.4;
option routers 192.168.0.1;
option broadcast-address192.168.0.255;
default-lease-time 14400;
ddns-update-style interim;
use-host-decl-nameson;
subnet 192.168.0.0 netmask 255.255.255.0 {
   option tftp-server-name "192.168.0.1";
   option bootfile-name "/pxelinux.0";
   default-lease-time 14400;
   max-lease-time 172800;
   range dynamic-bootp 192.168.0.2 192.168.0.253;
   next-server 192.168.0.1;

   host ws101 {
     hardware ethernet F0:4D:A2:ED:35:D0;
     fixed-address 192.168.0.101;
     option host-name "ws101";
   }
   host ws114 {
     hardware ethernet 84:2B:2B:89:6C:E0;
     fixed-address 192.168.0.114;
   }
}
--------------------------------------------------------------------------------
*/etc/hosts*
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
192.168.0.1     suse.localhost suse
192.168.0.101ws101
192.168.0.102ws102
192.168.0.103ws103
192.168.0.104ws104
192.168.0.105ws105
192.168.0.114ws114.donais.ca ws114
-----------------------------------------------------------------------------
*/srv/root-i386.17.12.19-20.25/etc/lts.conf*

# This is the default lts.conf file for ltsp 5.
# For more information about valid options please see:
# man lts.conf

[default]
LDM_SERVER = 192.168.0.1
DNS_SERVER = 8.8.8.8
SOUND = True
LOCALDEV = True
SERVER = 192.168.0.1
SCREEN_07 = ldm
LOCAL_APPS = true
LTSP_FATCLIENT = false
LDM_PASSWORD_HASH = true
ENCRYPT_SWAP = false
XRANDR_DISABLE = True
X_MODE_0 = 1024.x768
X_MODE_1 = 1280x1024
X_MODE_2 = 1440x900

#
[ws101]
MODULE_01= usb-uhci
MODULE_02= printer
PRINTER_0_TYPE = U
PRINTER_0-_DEVICE = /dev/usb/lp0
#PRINTER_0_PORT = 9100‎
----

Michel Donais

[Kiwi-ltsp-users] Playing existing chroot into newer distro

[Rolf-Werner E. <rw...@os...>]

Hi folks (hope anyone will read this),

As nobody had an answer to my question about the non-running kernel for 
Leap 42.3, I had the idea to use an image file which is definitely 
running, and it proved to be running fine.

I understand that LTSP is simply file-orientated, so I just copied the 
complete /srv directory from the functioning server with Leap 42.2 to 
the newer one with Leap 42.3.

Of course, currently there are not the user directories, and I have not 
yet adapted the /etc/... files, but it runs smoothly here.

My question is, do you see any reason why this might be "dangerous", 
lead to some conflict in the future or whatever?

Basically, chroot and server should be two different worlds, and for 
example, if I update the chroot which stems from 42.2, I should not 
produce any problem with the server running on 42.3, do you agree?

Thank you for any advice!

Regards
Rolf

[Kiwi-ltsp-users] Client booting stopped

[Rolf-Werner E. <rw...@os...>]

The initial server is up and running, but with all my experience I made 
with it I would like to setup another, clean install which avoids some 
of the mistakes I made over the months.

I set up another Suse Leap 42.3, network is as with the first one: two 
NICs, one internal ..11.1 for the clients and one external ..10.1. IP 
forwarding is on, Masquerading is on, firewall running, everything ok so 
far.

I downloaded LTSP from the repos as described in the documentation:

zypper ar...
zypper in... (installs 102 packets)

rpm -Uvh ... - for 32bit, "boot" first, then the other one, and same for 
64bit.

As the network is already running, I started kiwi-ltsp -c and it ran 
through without errors but one: It says it is missing the ssh-key for 
the 11.1 port. Looking it up, I find that openssd has been installed and 
is up and running, so...

I boot a client, it gets an IP from the .11.x network, and loads, but 
after pre-booting it stops. When booting in Debug mode, I get an error 
message "Failed to setup DHCP network interface !" "Press enter for 
maintenance" and it goes to Ctrl-D state.

I remember I had this issue on my second trial, but the initial one 
would not have this problem. So what have I done wrong?

Regards
Rolf

[Kiwi-ltsp-users] Yast network options

[Rolf-Werner E. <rw...@os...>]

Hi guys,

I'm still unsure if anyone can read my posts here, so please send a 
confirm. I don't receive any of my own mails back here, only some answers.


Just trying to setup a clean install, if possible with nearly the same 
network as before. This is what I typed in, is it correct or do you see 
any problem?

eth1 = 192.168.10.1 = external = server.eilert
eth0 = 192.168.11.1 = internal = server.intern

As you can see, I swapped eth1 and eth0, just for a technical reason, I 
guess the network won't really care.

Global:
- Wicked service
- IPv6 off
- Change standard route via DHCP service OFF

Hostname/DNS:
- Hostname: server, Domain: eilert
- Assign hostnames to loop address: yes
- nameservers from IN provider
- domain search: eilert

Routing:
- Gateway 192.168.10.2 (= my router), Device: eth1 (= external NIC)
- IPv4 Forwarding ON
- IPv6 Forwarding OFF

I am especially unsure about the routing settings. Yast doesn't say if 
the choice for ethX is for the device pointing to the router or the 
router itself. I assumed the first.

When I started, I just assigned "server.extern" and "server.intern", and 
Yast assigned Domain "extern" and Domain Search "extern" automagically. 
As I didn't like that, I changed to "eilert", but it was deleted  by 
Yast until I changed eth1 to "server.eilert" and typed in "eilert" for 
Domain and Domain Search manually. Hope it is ok?

Do you think when I run LTSP setup script, it will get along with these 
settings. What do you think?

Regards
Rolf

[Kiwi-ltsp-users] Lost routing

[Rolf-Werner E. <rw...@os...>]

kiwi-ltsp -c said, there is a problem with /etc/sysconfig/SuSEfirewall2 
and too many symbolic links.

Browsing the file I found that the two mysterious NICs eth2 and eth3 
were mentioned, so I deleted them.

Running kiwi-ltsp -c again still says there are too many symbolic links 
and it cannot care about the firewall.

I switched off the firewall, but still routing doesn't run. Trying "ip 
route list" doesn't show anything wrong. The clients can ping the NIC 
which has the external net, but nothing is left beyond that point. When 
I am directly at the server, everything runs fine.

Any idea where else I could search?

Regards
Rolf

[Kiwi-ltsp-users] Routing has broken

[Rolf-Werner E. <rw...@os...>]

All of a sudden, there is no more routing. Clients don't find anything 
behind the external NIC. I don't remember anything I changed with 
networking.

Network has 2 NICs,

eth0 192.168.10.1 for external and
eth1 192.168.11.1 for internal zone on the firewall. Firewall is 
running, external port is closed from outside, internal one is open. 
Clients boot and run.

IP forwarding is on. Masquerading is on. Everything seems ok.

When I ping 192.168.10.1, I get answers, but when I ping 192.168.10.2 
(the router), the line is dead. Calling websites from the server (not 
from a client) runs.

Where would you start to search? I'm completely lost here. Would you 
dare to delete the two NICs in Yast and setup everything from scratch, 
starting kiwi-ltsp -c again? Maybe there is a simpler way.

Regards
Rolf

Re: [Kiwi-ltsp-users] Handling epoptes from within a client

[CyberOrg <jig...@gm...>]

> ltsp-remoteapps epoptes
>
>
Hm. Nothing happens if I type that in a console (as user of epoptes group
logged into GUI). I mean, no error message, nothing.


Try ltsp-remoteapps xterm, if that does not work then enable remoteapps
from lts.conf(man for details). If it still does not work, use ssh -X
server to launch epoptes.

[Kiwi-ltsp-users] Scary things with btrfs image

[Rolf-Werner E. <rw...@os...>]

I open the subject here because I don't know if it is Suse specific.

I told about the strange reaction when I wanted to install epoptes under 
yast.

What happened before: I had another fat client running under an older 
user account where I had not yet switched off the screensaver/powersaver 
in the GUI. So after a while it would blank the screen. When you return, 
"X screensaver" will ask for your password. A few times that is ok, but 
after some while it will no longer accept the password (saw this before).

So I decided to log in with the other client and switch the first one 
off via epoptes. Then I found there was no epoptes, so I tried to 
install one, and when I went into chroot I got an error with btrfs image 
and read-only etc. Exit from chroot said "nothing to exit".

After a complete reboot of the server, everything runs fine again.

The question is, does this error occur from the X screensaver, can this 
client block the image, or is this X-screensaver error just a result 
from another, deeper error?

This hasn't been the first time, each time was in conjunction with 
X-screensaver, but back then I was just confused, and I had not the 
second client running to check for it.

Any idea what could cause this? Or should I post this in the main 
mailing list?

Regards
Rolf

[Kiwi-ltsp-users] Handling chroot from within a client terminal

[Rolf-Werner E. <rw...@os...>]

Currently on my install, I found that epoptes is only installed on the 
server side, not within the chroot. If I want to start it from one of 
the clients (teacher's desk), it cannot be found. So I decided to 
install it in the chroot.

 From the fat client, from within the GUI, I open a console.

ssh to the server

Then su - to become root.

kiwi-ltsp --chroot i386

Then start yast, software, and ask for epoptes. Some 0.92 or so version 
is offered, I want to install, but it says "read-only file system".

What could be the problem here?

Regards
Rolf

[Kiwi-ltsp-users] Problem generating custom image on 42.3

[Givanildo R. D. S. <giv...@ca...>]

Dear folks,

 

I'm trying to make a custom image for my system, and it generates all steps,
but when the new image tries to boot, it stucks in "Checking for config
file". Before that comes a strange message of PXE download server: not
found. The system is working fine, when I use the precompiled images. I can
even see the ping and the tftp tries on tcpdump. Most strange is that the
compilation was ok just last month.

 

Regards,

 

Givanildo R. D. Souza

 

Re: [Kiwi-ltsp-users] Another two questions

[Rolf-Werner E. <rw...@os...>]

Am 13.10.2017 04:24, schrieb Jigish Gohil MSS:
> On 12-Oct-2017 21:09, "Rolf-Werner Eilert" <rw...@os...
> <mailto:rw...@os...>> wrote:
>
>     Thank you Jigish,
>
>     but still it does not run.
>
>     I downloaded x86_64 image ONLY (to avoid mix-up).
>
>     I can change it from squashfs to btrfs, so -l2 runs fine.
>
>     But if I want to enter into the chroot, it says
>
>     cp: cannot create regular file 'etc/': no such file or directory
>     mount: mount point dev does not exist
>     mount: mount point sys does not exist
>     .
>     .
>     .
>     and so on, and it does not enter.
>
>     Maybe something wrong with that image? Maybe that is the reason for
>     the original server to keep booting into the i386 image only?
>
>  > Reinstall image, try to boot client without customizing image.
> rpm -Uvh
> http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp64-13.2.1-37.4.noarch.rpm
> http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp-boot64-13.2.1-37.4.noarch.rpm
>
> rcklaoe restart(or reboot server)
>
> Change /etc/sysconfig/kiwi-ltsp image type to squashfs, then try to
> customize.
>
>
>

Tried to do this, even forced re-install, but still it hangs before LDM. 
Maybe I should try it the way I did first: installing both i386 AND 
x86_64, then it might run better. Just a guess...

On the other hand: As the first run was successful, why not just copy 
everything over to a new HDD? The only reason is that for the first 
trial, I used an old HDD with btrfs, and I don't like btrfs that much. 
So wouldn't it be easier to copy everything to a new HDD with ext4 
instead of setting up everything from scratch?

But I still would like to understand where the chroot programs are 
(which I installed with --chroot i386 for the clients). After all, I can 
even "mount i386.img /mnt" and see everything there. I had expected all 
32bit binaries under i386.img and all 64bit binaries in the x86_64.img. 
But when I choose x86_64.img on start, I get everything installed in 
i386, but with 64 bit. Where do I think wrong?


Regards
Rolf

Re: [Kiwi-ltsp-users] Another two questions

[Rolf-Werner E. <rw...@os...>]

Now I found something that makes me confused and happy at the same time :)

- I used the Zotac client which has 8 GB RAM to test for 64 bit kernel.

- I used the original installation which has i386 and x86_64 images.

Starting with "KIWI-LTSP" from the list (default), LDM comes and I go 
into LXDE. Then start a konsole, and top shows 2 GB RAM. So I got a 
32bit kernel, right? I expected that.

Starting with "x86_64" from the list, LDM comes too, and I go into LXDE. 
Then start a konsole, and top shows 8 GB RAM! So I got a 64bit kernel, 
really???

When choosing 64bit, I had expected to get another, new, completely 
empty image with 64 bit with no software I installed. Because I 
installed all software under

kiwi-ltsp --chroot i386

So whenever I tried to boot into 64 bit kernel and got all my installed 
environment and programs, I pretended to be automatically "deviated" 
into 32 bit mode. So I would never check for that! :)

So... sorry for my stupidness here, but how is that managed? Where are 
the binaries I installed, if not in the images (.img files)?

On the one hand I am happy that it runs, but on the other hand I would 
like to understand how it does - or where I was thinking the wrong way...

Regards
Rolf


Am 13.10.2017 04:32, schrieb Jigish Gohil MSS:
> On 13-Oct-2017 07:54, "Jigish Gohil MSS" <jig...@my...
> <mailto:jig...@my...>> wrote:
>
>     On 12-Oct-2017 21:09, "Rolf-Werner Eilert" <rw...@os...
>     <mailto:rw...@os...>> wrote:
>
>         Thank you Jigish,
>
>         but still it does not run.
>
>         I downloaded x86_64 image ONLY (to avoid mix-up).
>
>         I can change it from squashfs to btrfs, so -l2 runs fine.
>
>         But if I want to enter into the chroot, it says
>
>         cp: cannot create regular file 'etc/': no such file or directory
>         mount: mount point dev does not exist
>         mount: mount point sys does not exist
>         .
>         .
>         .
>         and so on, and it does not enter.
>
>         Maybe something wrong with that image? Maybe that is the reason
>         for the original server to keep booting into the i386 image only?
>
>      > Reinstall image, try to boot client without customizing image.
>     rpm -Uvh
>     http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp64-13.2.1-37.4.noarch.rpm
>     <http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp64-13.2.1-37.4.noarch.rpm>
>     http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp-boot64-13.2.1-37.4.noarch.rpm
>     <http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp-boot64-13.2.1-37.4.noarch.rpm>
>
>     rcklaoe restart(or reboot server)
>
>     Change /etc/sysconfig/kiwi-ltsp image type to squashfs, then try to
>     customize.
>
>  > When using squashfs you also need "kiwi-ltsp --unpack-image x86_64"
> before you can chroot.
>
>

Re: [Kiwi-ltsp-users] Another two questions

[Jigish G. M. <jig...@my...>]

On 12-Oct-2017 21:09, "Rolf-Werner Eilert" <rw...@os...> wrote:

Thank you Jigish,

but still it does not run.

I downloaded x86_64 image ONLY (to avoid mix-up).

I can change it from squashfs to btrfs, so -l2 runs fine.

But if I want to enter into the chroot, it says

cp: cannot create regular file 'etc/': no such file or directory
mount: mount point dev does not exist
mount: mount point sys does not exist
.
.
.
and so on, and it does not enter.

Maybe something wrong with that image? Maybe that is the reason for the
original server to keep booting into the i386 image only?

> Reinstall image, try to boot client without customizing image.
rpm -Uvh
http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp64-13.2.1-37.4.noarch.rpm
http://download.opensuse.org/repositories/server:/ltsp/openSUSE_Tumbleweed/noarch/kiwi-image-ltsp-boot64-13.2.1-37.4.noarch.rpm

rcklaoe restart(or reboot server)

Change /etc/sysconfig/kiwi-ltsp image type to squashfs, then try to
customize.

Re: [Kiwi-ltsp-users] Another two questions

[Rolf-Werner E. <rw...@os...>]

Thank you Jigish,

but still it does not run.

I downloaded x86_64 image ONLY (to avoid mix-up).

I can change it from squashfs to btrfs, so -l2 runs fine.

But if I want to enter into the chroot, it says

cp: cannot create regular file 'etc/': no such file or directory
mount: mount point dev does not exist
mount: mount point sys does not exist
.
.
.
and so on, and it does not enter.

Maybe something wrong with that image? Maybe that is the reason for the 
original server to keep booting into the i386 image only?

Regards
Rolf



Am 12.10.2017 12:32, schrieb Jigish Gohil MSS:
> On Wed, Oct 11, 2017 at 9:10 PM, Rolf-Werner Eilert <rw...@os...> wrote:
>> Starting with a fresh install this afternoon, there remain two issues:
>>
>> 1.
>>
>> When kiwi-ltsp -c runs through, it keeps saying it prepares a 32bit image
>> ONLY. But then, why is there a 64bit image? ;)
>
> It is just for information, if you build image locally and not install
> via rpm then it builds i386 only.
>> Last time I began with the i386 image, then downloaded the amd64 one. But
>> each time I chose another image on client start (like the 64 bit one) or a
>> copy of them, it would end up in the original i386 one.
>>
>> This time I only downloaded the 64bit image to test this, and it refuses to
>> start. The client hangs at the error message (from my other mail) and does
>> not start LDM.
>>
>> On one of the clients, there is more RAM and I could need a 64bit kernel,
>> that's why I ask.
>>
>> 2.
>>
>> I would like to use ext4 rather than btrfs for the image, is there a way to
>> change that? (The reason is the strange error with the blind file entries I
>> reported on the other list. I suspect btrfs to be the reason.)
>>
>>
> If you have not customized the image from rpm, it is using squashfs.
> It switches to btrfs when you customize as it is easier to modify, you
> can switch image type in /etc/sysconfig/kiwi-ltsp, run kiwi-ltsp -l2
> after making change.
>
>

Re: [Kiwi-ltsp-users] Another two questions

[Jigish G. M. <jig...@my...>]

On Wed, Oct 11, 2017 at 9:10 PM, Rolf-Werner Eilert <rw...@os...> wrote:
> Starting with a fresh install this afternoon, there remain two issues:
>
> 1.
>
> When kiwi-ltsp -c runs through, it keeps saying it prepares a 32bit image
> ONLY. But then, why is there a 64bit image? ;)

It is just for information, if you build image locally and not install
via rpm then it builds i386 only.
> Last time I began with the i386 image, then downloaded the amd64 one. But
> each time I chose another image on client start (like the 64 bit one) or a
> copy of them, it would end up in the original i386 one.
>
> This time I only downloaded the 64bit image to test this, and it refuses to
> start. The client hangs at the error message (from my other mail) and does
> not start LDM.
>
> On one of the clients, there is more RAM and I could need a 64bit kernel,
> that's why I ask.
>
> 2.
>
> I would like to use ext4 rather than btrfs for the image, is there a way to
> change that? (The reason is the strange error with the blind file entries I
> reported on the other list. I suspect btrfs to be the reason.)
>
>
If you have not customized the image from rpm, it is using squashfs.
It switches to btrfs when you customize as it is easier to modify, you
can switch image type in /etc/sysconfig/kiwi-ltsp, run kiwi-ltsp -l2
after making change.

Re: [Kiwi-ltsp-users] Constant error message

[Jigish G. M. <jig...@my...>]

On Wed, Oct 11, 2017 at 8:39 PM, Rolf-Werner Eilert <rw...@os...> wrote:
> There is one error message that comes each time I boot a fat client. It is
> always there before LDM comes up, even when everything else works fine:
>
> [ 2.958010] systemd-udevd[303]: failed to execute
> '/usr/sbin/issue-generator'
> '/usr/sbin/issue-generator network add eth0': No such file or directory
>
> What does that mean? Can I avoid this?
>
you can put "ln -snf /bin/true /usr/sbin/issue-generator" in
/srv/tftpboot/KIWI/root.default/etc/init.d/boot.local

[Kiwi-ltsp-users] Another two questions

[Rolf-Werner E. <rw...@os...>]

Starting with a fresh install this afternoon, there remain two issues:

1.

When kiwi-ltsp -c runs through, it keeps saying it prepares a 32bit 
image ONLY. But then, why is there a 64bit image? ;)

Last time I began with the i386 image, then downloaded the amd64 one. 
But each time I chose another image on client start (like the 64 bit 
one) or a copy of them, it would end up in the original i386 one.

This time I only downloaded the 64bit image to test this, and it refuses 
to start. The client hangs at the error message (from my other mail) and 
does not start LDM.

On one of the clients, there is more RAM and I could need a 64bit 
kernel, that's why I ask.

2.

I would like to use ext4 rather than btrfs for the image, is there a way 
to change that? (The reason is the strange error with the blind file 
entries I reported on the other list. I suspect btrfs to be the reason.)

Thanks everyone for your help!

Rolf

[Kiwi-ltsp-users] Constant error message

[Rolf-Werner E. <rw...@os...>]

There is one error message that comes each time I boot a fat client. It 
is always there before LDM comes up, even when everything else works fine:

[ 2.958010] systemd-udevd[303]: failed to execute 
'/usr/sbin/issue-generator'
'/usr/sbin/issue-generator network add eth0': No such file or directory

What does that mean? Can I avoid this?

Regards
Rolf

Re: [Kiwi-ltsp-users] turn off ssh encrytion

[Jigish G. M. <jig...@my...>]

On Mon, Sep 18, 2017 at 1:53 AM, jef peeraer <jef...@te...> wrote:
> ok, it seems to work if i set LDM_DEBUG_TERMINAL=False and SOUND=True and
> LOCALDEV=True and with LXDE instead of KDE Plasma
> But kde-plasma does crash (krconqi or something).
>
LTSP thin clients work best with MATE, or XFCE and LXDE. If you have
beefy clients then you can run them in fatclient mode, where you have
better chance of running KDE. See
https://sourceforge.net/p/kiwi-ltsp/wiki/Customizing%20Image/

LTSP is no longer maintained on openSUSE, you may have better luck
using ltsp-pnp on Ubuntu MATE, if you are using it for school then you
can try https://sourceforge.net/projects/cyberorg-home/files/Li-f-e/

Re: [Kiwi-ltsp-users] turn off ssh encrytion

[Jigish G. M. <jig...@my...>]

On Sun, Sep 17, 2017 at 4:53 PM, jef peeraer <jef...@te...> wrote:
> I posted this in the ltsp user group, but it doesn'ts seem to get through.
> I recently upgraded (or better fresh install ) to opensuse Leap 423.
> Installed kiwi-ktsp, and appart from a couple off hickups (something with
> dnsmasq being overwritten the whole time with faulty values), i have a
> bigger issue.
> The entry LDM_DIRECTX=True doesn't seem to work anymore. If i put in
> lts.conf, then i can't login in the terminal.
> Using ssh encryption is not an option, as it seems to slow eveything down.
>
Works for me on fresh install of 42.3 following instructions from
https://en.opensuse.org/SDB:KIWI-LTSP_quick_start

See: https://imgur.com/a/VWNKe from the client.

Here is the server information. May be you didn't do the network setup
as mentioned in quick_start link.

linux-ufth:~ # cat /etc/dnsmasq.d/kiwi-ltsp.conf
#for proxy dhcp mode uncomment the line below and comment line below that
#dhcp-range=10.0.0.252,proxy
dhcp-range=10.0.0.20,10.0.0.252,1h
pxe-service=X86PC, "Boot network OS",/pxelinux
dhcp-vendorclass=pxe,PXEClient
dhcp-boot=net:pxe,/pxelinux.0
enable-tftp
tftp-root=/srv/tftpboot

linux-ufth:~ # cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.3"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.3"
PRETTY_NAME="openSUSE Leap 42.3"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.3"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

linux-ufth:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:06:76:31
          inet addr:10.0.0.252  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe06:7631/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:553121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:436120 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:502276932 (479.0 Mb)  TX bytes:313696297 (299.1 Mb)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2304 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2304 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:19268524 (18.3 Mb)  TX bytes:19268524 (18.3 Mb)

[Kiwi-ltsp-users] turn off ssh encrytion

[jef p. <jef...@te...>]

I posted this in the ltsp user group, but it doesn'ts seem to get through.
I recently upgraded (or better fresh install ) to opensuse Leap 423. 
Installed kiwi-ktsp, and appart from a couple off hickups (something 
with dnsmasq being overwritten the whole time with faulty values), i 
have a bigger issue.
The entry LDM_DIRECTX=True doesn't seem to work anymore. If i put in 
lts.conf, then i can't login in the terminal.
Using ssh encryption is not an option, as it seems to slow eveything down.

Re: [Kiwi-ltsp-users] Single $HOME "Linux"

[Rolf-Werner E. <rw...@os...>]

Thanks for your answer, Jigish,

Am 19.05.2017 15:46, schrieb Jigish Gohil:
>
>
> On Friday, May 19, 2017, Rolf-Werner Eilert <rw...@os...
> <mailto:rw...@os...>> wrote:
>  > The discussion in LTSP mailing list about the video acceleration on my
>  > new NUC brought up this question.
>  >
>  > In the chroot, there is a single home named linux. What is it good for?
>  >
> It can be removed if not needed, userdel -r linux.

But that doesn't explain to me if for instance it's an example for a 
user in chroot only, and what it could be good for. I am sure someone of 
the makers wanted to tell us some trick...

>
> All users are managed on the server, nothing in chroot. Maybe there is
> lts.conf way of adding users to other groups if adding them on server
> does not carry forward to the client.

Ok, I will look up lts.conf then. Is there an up-to-date list of options 
for it?

If LTSP in fat client setup doesn't care for user group settings on the 
server, maybe this should be cared for with priority. After all, groups 
and access rights are of major importance in all multi-user environments.

Regards
Rolf

Re: [Kiwi-ltsp-users] Single $HOME "Linux"

[Jigish G. <cyb...@op...>]

On Friday, May 19, 2017, Rolf-Werner Eilert <rw...@os...> wrote:
> The discussion in LTSP mailing list about the video acceleration on my
> new NUC brought up this question.
>
> In the chroot, there is a single home named linux. What is it good for?
>
It can be removed if not needed, userdel -r linux.

> I understand that userhomes are under the server's root and mounted to
> the chroot, providing all functionality of the userhome as within a
> standard environment. So I do not need to add users to the chroot. (From
> that point of view, "linux" is just a dummy, is that right? Or what is
> it good for?)
>
> So what would I have to do if I wanted to add a user to a specific group?
>
> We have a group "teachers" and a group "management" which is granted to
> specific users. There are directories on the server with data accessible
> only to these users via symlinks. Do I have to add these groups to the
> chroot? O do I even have to add these users to the chroot?
>
> Same thing with "video" group. The tip was to add the user to "video" to
> let the driver load acceleration. But if I add the user to "video" on
> the server, does it have any influence to the way drivers are loaded
> when the user logs in? After all, there is a "video" group in the
> chroot. But isn't it useless if there is no user in the chroot who
> belongs to this group? (At least in this case, it didn't have any
> effect, acceleration wasn't activated, but there might of course be
> another reason for failing.)

All users are managed on the server, nothing in chroot. Maybe there is
lts.conf way of adding users to other groups if adding them on server does
not carry forward to the client.

-- 
CyberOrg Info
Linux Powered Training and Solutions Provider
7 FF Unaddeep, Tower A, Susen Tarsali Road, Vadodara, India 390 010
M +91 9898092956
Web. http://www.cyberorg.info

[Kiwi-ltsp-users] Single $HOME "Linux"

[Rolf-Werner E. <rw...@os...>]

The discussion in LTSP mailing list about the video acceleration on my 
new NUC brought up this question.

In the chroot, there is a single home named linux. What is it good for?

I understand that userhomes are under the server's root and mounted to 
the chroot, providing all functionality of the userhome as within a 
standard environment. So I do not need to add users to the chroot. (From 
that point of view, "linux" is just a dummy, is that right? Or what is 
it good for?)

So what would I have to do if I wanted to add a user to a specific group?

We have a group "teachers" and a group "management" which is granted to 
specific users. There are directories on the server with data accessible 
only to these users via symlinks. Do I have to add these groups to the 
chroot? O do I even have to add these users to the chroot?

Same thing with "video" group. The tip was to add the user to "video" to 
let the driver load acceleration. But if I add the user to "video" on 
the server, does it have any influence to the way drivers are loaded 
when the user logs in? After all, there is a "video" group in the 
chroot. But isn't it useless if there is no user in the chroot who 
belongs to this group? (At least in this case, it didn't have any 
effect, acceleration wasn't activated, but there might of course be 
another reason for failing.)

Thanks for your insight!

Regards
Rolf

Re: [Kiwi-ltsp-users] Choosing the right repo

[Rolf-Werner E. <rw...@os...>]

Am 17.05.2017 03:13, schrieb Jigish Gohil:
>
>
> On May 16, 2017 21:58, "Rolf-Werner Eilert" <rw...@os...
> <mailto:rw...@os...>>
>
>     Why is that? Why would I want Tumbleweed in the image and standard Leap
>     on the server? Is this a result from the image files themselves coming
>     from Tumbleweed? Is it intentionally?
>
>
> Yes, why is explained somewhere I do not remember where, most likely in
> this list archive or wiki.
>

Ok. This time I tried zypper ref and then zypper in libreoffice, now the 
ordinary Suse repos were used, and Libreoffice is in the chroot.

Regards
Rolf