UbuntuHelp:UbuntuLTSP/TroubleShooting

文章出处:

https://help.ubuntu.com/community/UbuntuLTSP/TroubleShooting

点击翻译:

English

请不要直接编辑翻译本页，本页将定期与来源同步。

<<Include(Tag/Unsupported)>> <<Include(Tag/Deletion)>> This is a brief guide to troubleshooting an LTSP setup based on our own experiences of a small to medium scale setup with a mix of printing and clients. Updated_Version_For_Feisty Experiences with which release ? [OliverGrawert] (primarily with Dapper, however most of this also [we find] relates to Fiesty)

WARNING: Depreciation of this document

NOTE: As per Oliver Grawerts request below, we have copied this document into our internal (private) wiki. If you wish us to keep updating this page, please advise here, otherwise we may update this page periodically, but there is no guarantee.

Introduction

We've found some bugs in a number of components in the Ubuntu LTSP kit, hopefully some of the developers will take a look at this page at some point and possibly integrate some of our fixes back into the mix. Until then however, below we detail how we got around some of the more interesting issues. If you want the attention of any developer, please file bugs in Launchpad! This can easily be done with the following command

ubuntu-bug ltsp

in a terminal. I only got aware of this page by accident [OliverGrawert] (there was really 'too much' to file as bugs)

PXE Boot

If you are PXE booting off an LTSP server through a single switch, typically things will be just fine and dandy. When however you attempt to move your installation to an existing client site with a mix of 100Mbit and Gbit switches, you may encounter problems with PXE boot becoming unreliable. In particular, hanging either while transferring your images to the client via TFTP, or while trying to mount and load information via NFS. This problem will manifest itself at a lower level by displaying "ICMP fragmentation" errors (if you tcpdump the traffic). Apparently this is caused by some devices on your network not conforming to RFC, thus corrupting your "UDP" traffic. Note that confusingly, this does not affect TCP traffic in the slightest. Unfortunately NFS runs over UDP, which is the root of the problem. My fix is to make clients mount their NFS root filesystems via TCP - this (for me) cures the problems with no noticeable downsides.

On the DHCP server

1. chroot /opt/ltsp/i386 /bin/bash --login
2. cd /etc/mkinitramfs/ (Feisty: cd /etc/initramfs-tools/ )
3. vi initramfs.conf
4. NFSOPTS="-o retrans=10,tcp"

These are the defaults used by the nfsmount script in initramfs (all 2.6 kernels default to tcp for nfs, for the retrans value see /usr/share/initramfs-tools/scripts/nfs, there is no need at all to put them in the config file additionally, your problem is located elsewhere [OliverGrawert](great tip, however this does fix the problem. If we had known there was a better method, we would obviously use it, which goes to documentation - on the premise that we can actually read.)

1. Save / quit
2. mkinitramfs -o /boot/initrd.img-2.6.15-23-386-tcp 2.6.15-23-386
3. exit (the chroot)
4. ltsp-update-kernels (this copies the new initramfs to /var/lib/tftpboot)
5. cd /var/lib/tftpboot/ltsp
6. ln -sf initrd.img-2.6.15-23-386-tcp initrd.img

The latter two lines are already executed in ltsp-update-kernels already, also update-initramfs should be used, dont use mkinitramfs directly [OliverGrawert] (if it worked without the latter two lines, we wouldn't have quoted them. If it works on Feisty without the latter two lines, great) You may need to tweak the kernel versions as time goes by (!)

dhcpd.conf for good measure

 ddns-update-style none;
 ignore client-updates;
 default-lease-time              86400;
 max-lease-time                  86400;

 subnet 10.1.0.0 netmask 255.255.255.0 {
   interface eth1;
   range 10.1.0.100 10.1.0.199;
   option domain-name "mydomain.co.uk";
   option domain-name-servers 10.1.0.1;
   option broadcast-address 10.1.0.255;
   option routers 10.1.0.4;
   option subnet-mask 255.255.255.0;
   filename "/ltsp/pxelinux.0";
   option root-path "/opt/ltsp/i386";
 }

Sound Configuration

I'm not sure how this "should" work in the default configuration, however the fix appears to work quite happily on the systems we're running it on. Take a look in /etc/X11/Xsession.d and add a file called 40turnmysoundon

And insert;

REMOTESOUNDIP=`echo $SSH_CLIENT | cut -d" " -f1`
REMOTESOUNDPORT="16001"
export ESPEAKER=${REMOTESOUNDIP}:${REMOTESOUNDPORT}

Not sure why this isn't in place by default, maybe I'm missing something, but this is an easy fix. Simply because we dont support insecure protocols like XDMCP in ltsp5 (neither upstream ltsp nor in ubuntu, even though its possible to use them), sound support via alsa emulation is implemented in ldm (since dapper) as well as local device support (edgy) [OliverGrawert] (yes, but last time we looked at ldm it was crap, we use gdm because it does the job and in context, security is not an issue. XDMCP is supported and used a lot!)

USB Client Printers

Ok, this sounds quite hard, but it's actually really easy, or it would be if the code was in place by default. First you need to setup your printer details in lts.conf - everyone knows this bit because it's well documented. Here's a sample;

 [Default]
        SERVER             = 10.1.0.4
        XSERVER            = auto
        X_MOUSE_PROTOCOL   = "PS/2"
        X_MOUSE_DEVICE     = "/dev/psaux"
        X_MOUSE_RESOLUTION = 400
        X_MOUSE_BUTTONS    = 3
        USE_XFS            = N
        XkbLayout          = gb
        SOUND             = Y
        PRINTER_0_DEVICE   = /dev/usblp0
        PRINTER_0_TYPE     = P

The SERVER variable should only be set if the SERVER actually differs from the bootserver in ltsp5, setting XSERVER to auto (which is the default anyway) is pointless and just slows down the boot, the same goes for: X_MOUSE_PROTOCOL, X_MOUSE_DEVICE, X_MOUSE_BUTTONS. Why is the usb printer set to type 'P' (parallel) here ? [OliverGrawert] (this config was pulled from a working system where the address was required. We could have put up something that should work that we'd not tested .. but this is something we don't generally do as a matter of principle.

Notes

• I'm using a UK keyboard
• The device showing up in the client is /dev/usblp0 and NOT /dev/usb/lp0 (!)
• I have sound turned on
• Ubuntu loads all the required modules for me

And of course this is where we expect printouts to appear .. unfortunately .. :-(

Now you need to edit /opt/ltsp/i386/etc/inittab and add the following line to the foot of the file;

a:2345:respawn:/usr/lib/ltsp/start_printer 0

And it should work! This file doesnt exist in ubuntu since several releases already, please see the upstart documentation, beyond that the ltsp-client initscript cares for executing the start_prionter script if there are no errors with the configuration (i.e. if the device matches the protocol (should be 'U' above)) [OliverGrawert] (Getting a dapper ltsp source tree working was such a pain, we're still using it live. Currently we're debugging the Feisty version, will post something when we're done.)

Well, it should

If you edit /usr/lib/ltsp/start_printer and correct the include path of ltsp_functions from /etc/ to /usr/lib/ltsp/ then it will. You can use ALT-CTRL-F1, cd /usr/lib/ltsp/start_printer 0 to test it. This assumes of course you have set up a host printer, it needs to be of type HP Laserjet on port 9100 pointing at the IP address of your thin client. (which I'm afraid will need a static IP address!)

Notes for Edgy & Feisty Users

Note: I have yet to test sound in feisty, so have not your milage may vary with sound. However, you DO need to follow the GDM instructions if you wish to use GDM instead of ldm.

Just to make life interesting, you need to make a couple if tweaks if you want Edgy to work properly. To get SOUND working try adding this to your /etc/profile on your *LOGIN SERVER*;

REMOTESOUNDIP=`echo $DISPLAY | cut -d":" -f1`
REMOTESOUNDPORT="16001"
export ESPEAKER=${REMOTESOUNDIP}:${REMOTESOUNDPORT}

GDM

Yes, some people want to run a local GDM chooser as opposed to the naff ldm application. To do this you will need to;

chroot /opt/ltsp/i386 /bin/bash --login
apt-get update
apt-get install gdm
chown root /var/lib/gdm
chmod 1770 /var/lib/gdm
vi /etc/default/ltsp-client-setup

add to the end;

rw_dirs="$rw_dirs /var/lib/gdm /var/run/network"
copy_dirs="$copy_dirs /home"
vi /etc/X11/gdm/gdm.conf

Comment out the 0=Standard and uncomment 0=Chooser And you're ready to roll. .. You might find you want to install usplash themes and rebuild your initramfs as described above .. if you want splash screen! usplash is installed by default since dapper in ltsp clients, themes will only be missing if you installed in a commmandline system (which you shouldnt do for varoius reasons) [OliverGrawert] (we do, welcome to the real world!)

Graphics Problems

Using some machines (HP Thin clients with via chipsets for example) you may see some problems with screen display when using GLX or accelerated graphics. Why would I want GLX on a thin client I hear you ask?! Newsflash: Google Earth is quite usable on HP Thin client boxes !! (ok, it was news to me)

To make this work properly, you need to fix the screen rubbish that you'll see by default by adding the following options to your xorg.conf file.

Option "XaaNoPixmapCache" "true"
Option "XaaNoOffscreenPixmaps" "true"
VideoRam 16384

If there would have been filed a bug about that, it could have been fixed in the graphics driver for this card so you wouldnt need to set the options anymore [OliverGrawert] (mmm, Ok, I sort of figured if HP hadn't done it there'd be a reason) Debconf seems to not to want to do this for me (!) so I've just hacked /usr/bin/dexconf and added the lines under the "Device" section - seems to do the trick. (just reboot your client after making the changes .. obviously .. :) )

Failure to Launch

There's a new problem of Feisty, people who've been running quite happily now find that when they run rdesktop and get a windows 2000 login, as soon as they click on anything interesting, their application (rdesktop) SEGV's. This is a REALLY NASTY bug to track down, so if your windows / rdesktop applications start falling over - start here! For some reason, it's caused by lack of bitmap depth on the client's X display. To fix, inside your chroot ltsp filesystem (/opt/ltsp/i386) edit /etc/lts.conf and add a section for your work station (or add to your default section;

X_COLOR_DEPTH = 24

see above comment [OliverGrawert] (what, about fixing graphics drivers?! ROFL. This affects about 10 different graphics cards!) Then reboot and see what happens .. 100% success rate here. If anyone has any more tips - please add them here! Yes, please file bugs and read the documentation before putting up dubious tips, the ltsp team is reachable by IRC in #ltsp as well as via the ltsp mailing list https://lists.sourceforge.net/lists/listinfo/ltsp-developer for questions and happy to help [OliverGrawert] (dubious tips?! this is a 50 user system running across DRDB backends with heartbeat / failover, multiple front-end LTSP servers, remote NX users, 25 printers, about half of which are LTSP workstation and half network, a dozen or so hardware thin clients and the remainder using CD based PXE boot on what used to be old windows boxes .. and some are using sound. So this is a fairly comprehensive system for an SME who uses nothing else, oh, and it works. THIS IS WHAT WE HAD TO DO TO GET IT WORKING! If you don't want the real-world comments - that's no problem, we thought you did. We'll move this somewhere else)

---