Search:  
Gentoo Wiki

LTSP_Configuration

Image:Ltsp_logo.jpg

Pages

  1. LTSP Client
  2. LTSP Server
  3. LTSP Desktop
  4. LTSP Configuration
  5. GNU Modular Network Management System
edit

Contents

LTSP Configuration

This is the software that doesn't really belong anyware. It is housed on the server, but runs on the terminal. Thus it occupies this strange middleground within the network. Mostly this is out here because it's the least necessary, the most troublesome, and I didn't want to make the server section bigger.

Install

Review the installation and extremely basic configuration of LTSP here:

LTSP Server#net-misc.2Fltsp

Server Effective Configuration

There isn't much LTSP configuration that affects the server. Just this, AFAIK:

File: /etc/ltsp.conf
 LTSP_ETH_INTERFACE=eth0

Client Effective Configuration

General Settings

File: /opt/ltsp/i386/etc/lts.conf
[Default]
       SERVER             = 10.0.0.12
       XSERVER            = auto
       X_MOUSE_PROTOCOL   = "PS/2"
       X_MOUSE_DEVICE     = "/dev/input/mice" # /dev/psaux with kernel 2.4
       X_MOUSE_RESOLUTION = 400
       X_MOUSE_BUTTONS    = 5
       USE_XFS            = Y
       XFS_SERVER         = 10.0.0.11
       SCREEN_01          = startx
       SCREEN_02          = shell
       SOUND              = Y
       SOUND_DAEMON       = esd
       LOCAL_DEVICE_01    = /dev/hdc:cdrom
       LOCAL_DEVICE_02    = /dev/fd0:floppy
       LOCAL_DEVICE_03    = /dev/uba:usb
       HOTPLUG            = Y

NOTE: The default configuration is only appropriate for MOST systems... luckily that is true for the clients I am using, but it isn't true for some of our newer machines with LCDs.

X (Video)

Please leave a comment if you have some info on LTSP on how to get a DIN5 (non-ps/2, non-ps2) keyboard working in X. I'd also be really interested in a tutorial on a complete custom ltsp setup with xorg and certain local apps.

If you have a particular machine that has a goofy monitor that isn't probed correctly, I would suggest booting up with knoppix, copying the knoppix config file to the server in /opt/ltsp/i386/etc/XF86Config.monitor-model then you can modify the configuration to suite that machine.

File: /opt/ltsp/i386/etc/lts.conf
[ws100]
        XF86CONFIG_FILE = XF86Config.monitor-model

This becomes a real pain in the behind when you're dealing with a bunch of machines you're pulling out of a basement that each have their own old goofy monitors which aren't probed correctly. CONCEPT LTSP Management

mkxf86config

Another solution for this might be to add knoppix's mkxf86config as a local app and have it run on the ltsp client to create an XF86Config file dynamically so that clients with funky monitors are more likely to work. I've never had a monitor that knoppix couldn't cheat into working correctly!

accelerated graphics support

The following worked for me for the nVidia driver -

Compile a custom kernel - follow documentation at ltsp.org.

No initrd or patches applied with a 2.4.26 kernel worked OK

Set /usr/src/linux symlink to the 2.4.26 directory

Run NVIDIA installer with option "-k 2.4.26" (run NVID*.sh --advanced-options for details)

Depmod fails - continue anyway

emerge mknbi if not already installed

Tag kernel with: mknbi-linux --rootdir=/opt/ltsp-4.1/i386 --ip=rom /usr/src/linux/arch/i386/boot/bzImage > tftpboot/lts/kernel-2.4.26

This worked; mknbi-elf not tried.

Create a custom xorg.conf file to suit nVidia driver

Copy *all* the modules required to the corresponding locations in /opt/ltsp... tree.

Create symlinks.

Locating new modules just created by the NVID*.sh installer by date helped.

Set ltsp.conf file for shell on screen 02, and to use correct XF86Conf file and kernel

Add "/lib/modules/2.4.26/kernel/drivers/video/nvidia.o:" to /opt/ltsp..../lib/modules/2.4.26/modules.dep

CTRL-ALT-F2 to local machine after start up, and view the Xorg.0.0.log using more (or scp the file to the server to view in full) and find log record of missing modules

HTH - will tidy up when more time - Graham

Sound

I don't particularly care that our users have sound on the thin-clients, but since I haven't found out how to disable the error generated by Gnome when you log in with no sound device I'm doing the only thing I can - make a sound device.

esd

desktop

On the Desktop, you'll need to enable esd support if you haven't already. You may need to edit /etc/make.conf add USE="esd" and then run

Code: Adding esd to the Desktop
 USE="esd" emerge --newuse -a world
File: lts.conf
[Default]
   SOUND = Y
   SOUND_DAEMON = esd
server

LTSP must be emerged with esd support as well

Code: Adding esd to the Desktop
 echo "net-misc/ltsp esd" >> /etc/portage/packages.use
 USE="esd" emerge --newuse -a world

I tried in vain to get either esd or nasd to work with either pci or isa sound cards. After manually editing /opt/ltsp/i386/etc/modules.conf and modprob'ing sound modules, I was able to get the system to create /dev/dsp -> /dev/sound/dsp but got no sound. "/usr/X11R6/bin/nasd -aa &" complained about "Cannot establish any connection to socket", so I checked my xdmcp server's firewalls and made sure to allow connections from nasd (:8000) and esd (:16001) ports to the ltsp workstations. But the firewall was not the problem. nasd still complained about not being able to connect to a socket and esd didn't complain but I still got no sound.

So I decided to switch from OSS to ALSA following the guide http://wiki.ltsp.org/twiki/bin/view/Ltsp/WorkInProgress#esd_ALSA_sound_on_LTSP_4_2 I downloaded http://downloads.sourceforge.net/symbiont/LTSP-esd-alsa_1.0.0-2.tgz?use_mirror=osdn unpacked the tarball and manually ran the "install" script. Esd sound worked perfectly afterwards!

nas

KDE sound

Using sound on LTSP-stations is somewhat tricky. This short text is about configuring sound on the clients running KDE. It's just quick and dirty for I got it working in this very moment. Since the artsd is only able to run once, it's a problem to get sound working on several workstations at the same time. Especially KDE system notifications usually depend on artsd. To get this working, follow these steps:

1. Configure your clients for esd support following the steps above.

2. On the LTSP server compile mplayer with esd support. The executable should be found in /usr/bin.

Code:
USE="esd" emerge mplayer

3. Hack this little script, name it MYplayer and put it in /usr/bin on the server system:

File: MYplayer
	#!/bin/sh
	mplayer -ao esd -vo null "$1"

4. Make script executable

Code:
chmod 755 /usr/bin/MYplayer

5. Start KDE. Disable artsd by unchecking Control Center->Sound System->Enable the sound system.

6. Change player for system notifications under Control Center->System Notifications->Player Settings to "Use an external Player": /usr/bin/MYplayer.

This hack is necessary, because putting the parameters right here won't work for some reason. This entry has to be made for every user!

7. Now system notifications can be heard on every client system the esound-daemon is running on properly.

What else?

Video players like xine, mplayer, kaffeine all should work using esd for sound and xv for video. To get amarok (which is the best) working on the clients, compile it with gstreamer support and configure it to use the esdsink. Using Amarok with xine as a backend and setting it to use esd also works and I think it has much less latency than gstreamer.
This way you should be able, never having to start artsd again.

TG.

I tried this on KDE 3.4.3. Sadly it didn't work.
I managed to get sound working by telling the KDE sound server to use the Enlightemnet Sound Daemon as audio output. I also made sure that I had esound started. Nothing more was required!

/Jocke!

Well it's super easy to deploy all the configuration you need to the clients by modifying the /etc/skel directory to hold the .mplayer and .kde and then create the users.

inf

Local Device Access

First we need to install FUSE. Either install FUSE directly to the kernel or emerge fuse module:

emerge fuse

If you have installed FUSE as a module, add FUSE to the modules.autoload list and start it now:

echo fuse >> /etc/modules.autoload.d/kernel-2.6
modprobe -v fuse

Gnome users might also need this:

echo user_allow_other >> /etc/fuse.conf

Then we need X11-protocol for perl:

emerge -av X11-Protocol

You need to set on host names in dhcpd.conf - either

use-host-decl-names         on;

or

get-lease-hostnames         true;

Last step on the server side is to install LTSP localdev support package. Unfortunately it's .deb/.rpm only. Let's convert it to .tar.gz then:

wget http://ltsp.mirrors.tds.net/pub/ltsp/utils/ltsp-server-pkg-fedora-0.1-1.i386.rpm
rpm2targz ltsp-server-pkg-fedora-0.1-1.i386.rpm

Note: I'm not sure how well the server package will fit to your system. An appropriate ebuild for local device support should be made. Follow the following instructions only at your own risk.

Let's extract the package (as root):

tar -xvf ltsp-server-pkg-fedora-0.1-1.i386.tar.gz -C /

The script does not automatically start up on Gentoo. You need to manually hack xinitrc (e.g. /etc/X11/xinit/xinitrc). Add the following line before executing the window manager:

sh /etc/X11/xinit/xinitrc.d/lbus-start.sh

Luckily a more elegant solution for KDE users exists:

cd /usr/kde/3.x/env/
ln -s /etc/X11/xinit/xinitrc.d/lbus-start.sh .

Now that you have succesfully installed necessary packages, LTSP requires some additional configuration in lts.conf. Here's a sample configuration for clients with a floppy drive, cdrom as secondary IDE master and an usb drive:

File: /opt/ltsp-4.2/i386/etc/lts.conf
[Default]
       LOCAL_STORAGE      = Y
       LOCAL_DEVICE_01    = /dev/hdc:cdrom
       LOCAL_DEVICE_02    = /dev/fd0:floppy
       LOCAL_DEVICE_03    = /dev/uba:usb
       HOTPLUG            = Y

(The desktop machine must have /usr/sbin/ltspinfo on it in order for the scripts to work.) - don't know about this Demise.

Read more on LTSP 4.2 local device support here. Wiki page for pre-4.2 documentation can be found here.

Retrieved from "http://www.gentoo-wiki.info/LTSP_Configuration"

Last modified: Fri, 23 Mar 2007 04:17:00 +0000 Hits: 19,982