[Pkg-ltsp-devel] Bug#509640: ltsp-server: confusing out of the box experience

[Vagrant Cascadian]

tags 509640 pending
thanks

On Thu, Dec 25, 2008 at 11:25:37AM -0800, Ross Boylan wrote:
> On Wed, 2008-12-24 at 10:55 -0800, Vagrant Cascadian wrote:
> > On Tue, Dec 23, 2008 at 05:51:40PM -0800, Ross Boylan wrote:

apologies for the slow response...

hope to include some of the following fixes in the next upload.  it may
not address all issues mentioned. if there is anything remaining, please
file specific bug reports about each issue.

in the future, please make separate bug reports for each specific issue, as it
takes much longer to process a single bug report with many issues than to
address each issue one at a time.

> > > The reference to /opt in the package installation and man
> > > ltsp-build-client seemed odd, because Debian doesn't use that (not
> > > sure abou FHS).  I thought the defaults when I ran it would be
> > > different, but they weren't.
> > 
> > arguably, according to the FHS ltsp should probably be installed in /srv,
> > though when LTSP was first developed, /srv didn't even exist. all other LTSP
> > implementations use /opt/ltsp, so we decided to stick with it for Debian.

> One practical problem with /opt is that, since it didn't exit, it ended
> up on my small root partition, which then filled.  I suspect that may be
> pretty typical, at least for those who don't just use one giant
> partition for everything.
> 
> My suspicion is there's some reason Debian packages don't seem to
> use /opt, but I'm no authority.

i'm going to leave it as /opt/ltsp, as it doesn't seem *wrong* according to FHS
as i read it, and /srv is probably the only other appropriate location
according to FHS. /srv would suffer from the small / partition problem, too.

for consistancy with 10+ years of /opt/ltsp/, and consistancy with other
distros (and upstream documentation), i'd prefer to leave it as /opt/ltsp.

if you have more convincing arguments about why it should default to somewhere
else, please file a separate bug report.

> > > man ltsp-build-client uncertainties:
> > > Does this need to be run as root? (yes)
> > 
> > > Do "mirrors," "packages", and "distribution" refer to the usual Debian
> > > things of that name, or is it some upstream concept? (apparently
> > > Debian)
> > 
> > do you have some proposed text you would like to see added to the man page for
> > the above two items?
> > 
> For the first, "This command must be run as root." (if that's true).

for the most part, this is true. although users can run it to get a list of
help output. "This command is usually run as root." would probably be more
appropriate. added to the upstream man page.

> For the others, maybe just insert "Debian" before the word, and give an
> example.  

i removed most of the debian-specific stuff from the upstream manpage. the
--help and --extra-help options are able to display and describe all available
commandline options, and the manpage directs the user to --help and
--extra-help. i hope that is sufficient.

> For "package", maybe use "package name" to clarify that it's
> "ltsp-server" not "ltsp-server_5.1.10-2_all.deb".

this seems pedantic to me, and the package commandline options are no longer
mentioned.
 
> > > If I change base do I need to tweak the clients, or is that automatic?
> > 
> > the client doesn't need to know anything about the base location, however, some
> > of the server tools (ltsp-update-sshkeys, ltsp-update-kernels) may need to be
> > explicitly told to use the alternate locations. using an alternate base
> > location is not well tested, and there are likely bugs.

each of these issues should be separate bug reports. please file them as you
find them.

> > > To try to summarize what I think would help:
> > > 1. build an /etc/ltsp directory and populate it with sample config
> > > files, if appropriate (that is, if packages are supposed to create
> > > their /etc/ directories).
> > 
> > i would consider doing such with /usr/share/doc/ltsp-server/examples, but i'm
> > not going to populate /etc/ with configuration files unless they're actually
> > needed to function properly, as the defaults work without them.
> By samples, I meant files with comments, including commented out
> configuration statements.  I didn't mean "live" statements that might
> not be appropriate.  This could be in place of or in addition to a
> fuller man page (though I think the man page is always a good idea,
> since people can delete the file with comments).

yes, but you still run into upgrade issues if the user does modify the files in
/etc. i'll stick with /usr/share/doc/ltsp*/examples for examples of
configuration files. that's what it's for.

> > > 2. Change the default chroot to something more Debianny,
> > > e.g. /var/ltsp if appropriate (policy consistent).
> > 
> > again, i think /opt is not inappropriate according to FHS, even if /srv is more
> > appropriate.  but there is a huge amount of and cross-distro consistancy and
> > documentation lost by switching that location.

as mentioned above, i'm going to leave it as /opt/ltsp, if you feel it should
be different, please file a new bug report.

> > > 3. Provide more of an overview.
> > 
> > where do you think an overview belongs? 
> In /usr/share/doc/.

i'll dump http://wiki.debian.org/LTSP/Howto into
/usr/share/doc/ltsp-server/Howto or something like that.

> > is http://wiki.debian.org/LTSP/Howto
> > insufficient?

> That was helpful when I found it.  It would also be helpful if it
> included a description of the different packages and how they fit
> together, e.g., the roles of the different servers (dhcp, tftp, nbd,
> nfs, inet).

> More info on the construction of the chroot would be good too.

there's also more upstream documentation now, and i linked to it from the
http://wiki.debian.org/LTSP/Howto page.

> One step further back, the basic setup this is aiming for would be
> useful.  I'm slowly realizing it's aiming for something different from
> what I was intending.  I wanted to have the remote computer act as an X
> terminal that had an X server and little else: it would get the login
> screen from kdm running on my server.  So after login it would be
> running on my server (except for the X server itself).  

this is the default behavior of LTSP, although instead of using KDM with the
XDMCP protocol, it uses SSH and X11 Forwarding by default. it can be configured
to use KDM+XDMCP fairly easily, but not all features (local devices, local
sound) will work.

> I think ltsp is setting up something different, in which the X terminal is
> running inside the chroot + some writable space served by nbd.

it can also be configured this way, but is not the default.

> > > 4. Provide more details in the man pages, including the format of the
> > > configuration files (I found ltsp.conf configuration on the web, but
> > > nothing for the builder).

> > they're all NAME=value pairs, though a brief overview in the manpages
> > would be a good idea, 
> also, do the values need to be quoted? are there comments?

i added to the ltsp-build-client man page information about
ltsp-build-client.conf.

> > it would be hard to write in a distro-agnostic
> > way, 
> Do you mean the values for NAME (e.g., BASE) are distro dependent, or
> the values on the right of the assignment are distro dependent?

some of both. i think my updates to the man page should partially help with
that.

> > as the relevent values would be totally different. so i might just
> > stick with example configuration files.
> I thought ltsp was intended to be customized for each distro.

yes, it is customized for every distro, but not *every* aspect of it. we do
make attempts to share as much as possible across distros, and so forking the
man page for each distro is undesireable, in my opinion. man pages don't
provide much of a plugin structure, though it might be possible to come up with
something at build time. patches welcome. :)

> > > 5. Use ltsp consistently for file names (or lts).
> > 
> > lts.conf is kept as is for historical consistancy, everything else uses "ltsp".
> > 
> > > There's probably a lot I'm misunderstanding, but it would be nice if
> > > it were easier to understand :)
> > 
> > it always is, yes. :)
> >  
> > > I'm also a little puzzled that both nbd-server and a tftpd server are
> > > necessary (and an nfs server), though I'm willing to take it on faith.
> > 
> > tftp is needed to boot with PXE, nbd-server is needed to provide network swap,
> > and nfs-kernel-server is used for the root filesystem.
> > 
> > i hope these explanations help. i'll try and address some of the issues, though
> > probably post-lenny, as we're in freeze.
> Terrific.

working on it... 

> By the way, after doing everything, the client hung up after contacting
> the tftp server.  The tftp server appears to be responsive from other
> clients on the network, so I'm not sure if this is a result of something
> else being off (I've done nothing to setup nbd, and there was a warning
> message about its not having a config file on install), or if the PXE
> boot ROM program I'm using (from http://rom-o-matic.net/) isn't working.
> The harware rom doesn't support PXE, nor can I get it to boot from a CD.

if you're still having these problems, please file a separate bug report.

live well,
  vagrant