Subject:
Re: [Proposal] PXE Server HOWTO
From:
Jason Bechtel ####@####.####
Date:
30 Jan 2002 10:58:40 -0000
Message-Id: <3C57D1E4.6060401@iig.uni-freiburg.de>
Cicero,
I will give you that LTSP is much easier to set up for remote apps. For
local apps you have to setup and configure NIS, which is no small task
and usually requires some testing and debugging to get logins working
correctly. But after that, all that is required is to install programs
relative to the NFS-root directory (/opt/ltsp/{i386|sparc|...}) for the
architecture of your station. With RPM, this involves the trivial
addition of a '--root <dir>' option to the install command. According
to section 8.6 of the Network-boot HOWTO, dpkg has the same option and
it also mentions using 'chroot' as an option. Althought, now that I
look, the LTSP docs fail to mention any of these options (only covers
copying binaries and using their prepared "Local Netscape" package).
In LTSP 3.0, the intention is to no longer export all of the major app
dirs (/bin, /usr, ...) and to instead install all programs under the
LTSP tree. This is simultaneously a small configuration savings and a
security improvement.
Then there is the problem of library dependencies, however, which can
lead some to give up. But the LTSP docs already contain information on
how to find out which libraries an app needs. Unfortunately they stop
there. When one has support for the station architecture in the server
libs (e.g. i586 is covered by i386), then copying the libraries is the
end of the problem. But with incompatible architectures, one must then
find and download all dependent libs for the station architecture and
install those in the LTSP-NFS-root tree as well. If you have apt
(Debian) this is probably pretty easy. I'm also led to believe that
this is somehow possible with RPMs when one uses the rpmfind and
rpm2html tools:
http://rpmfind.net/linux/rpm2html/
though I have yet to try it myself.
LTSP 3.0 also means that you have to rsh to the client and call up the
app. But the LTSP docs cover this with a two-line script example:
HOST=`echo $DISPLAY | awk -F: '{ print $1 }'`
rsh ${HOST} /usr/bin/gaim -display ${DISPLAY}
The exception to all of the major difficulties remains that the server
and client can have the same architecture (or close enough, as with x86)
and share libs. This is usually the case with Red Hat shipping
everything compiled for i386.
And the LTSP kernel arch has nothing to do with it. If you want/need to
change the arch of your kernel, this has nothing to do with whether you
are using local or remote apps.
So, it's a bit more work, and it does add to the LTSP docs, but I think
a good portion of the LTSP users do use local apps and have managed.
The LTSP docs could stand a little rounding out, but I don't think it
would explode their size by any means.
Your suggestion a few mails ago was to start a unifying diskless GUIDE
at the LDP:
> I agree that the documentation about disk-less workstation is much
scattered
> along different howtos. An unifying GUIDE should be of great interest
for the
> Linux community.
Your concern was that it address both remote and local applications,
where LTSP might not address that latter situation adequately. I agree
that we need a application location agnostic document. I also, after
looking over them while writing this email, I think that the
documentation at LTSP might benefit from a complementary document at the
LDP.
If there were a general "Diskless-Workstations-HOWTO" that picks up
where the existing Diskless-HOWTO (which should perhaps carry the name
used internal to itself: Disless-Nodes-HOWTO) leaves off and goes
through various techniques of managing and providing *post*-boot
services for diskless clients. The Network-boot-HOWTO mostly
complements the Diskless-HOWTO with a few "tips and tricks" in its
Chapter 8. Once the station has booted and init runs, the user is on
their own (unless they're using LTSP, which covers some further topics).
I think this "Diskless-Workstations-HOWTO" which covers everything
from X-Windows and XDMCP to applications (remote & local) and printing
is what would be of great interest for the Linux community. It would be
something that the LTSP project could reference and would complete the
LDP documentation for people not taking the LTSP route. I can also see
it covering topics such as security (ssh, encrypted filesystems,
encrypted traffic), remote control of stations (some apps for this have
already been written), monitoring of stations (SNMP, homebrew monitors,
remote syslog), and transparent clustering (MOSIX, et al.). These
topics have all come up many times on the LTSP list, but they do not
have a proper place in the official docs. Some people write up some
docs and submit them and Jim puts them on the site, but separately:
http://www.ltsp.org/documentation/index.php
I think that an LDP document (HOWTO or GUIDE) would be a great place to
collect and distill all of these topics.
Jason
Cicero Mota wrote:
> Yes,
>
> One can do it, of course. But then, LTSP configuration is not as
simple as it
> use to be, anymore. One does need to export and mount directories, or
install
> new libraries, use rsh, the kernel is compiled for arch i381,
etc...In other
> words, one needs at least blows the LTSP documentation up.
> Don't you think so?
>
> On Tuesday 29 January 2002 06:06, you wrote:
>>LTSP is not limited to an X-terminal (all apps on the server) mode.
>>That is only the default mode. A few settings and your LTSP workstation
>>is running all apps locally... local RAM and local CPU. And you can
>>mix local and server apps simultaneously with a little custom
>>configuration. There is already some documentation describing this at
>>the LTSP site:
>>
>>http://www.ltsp.org/documentation/ltsp-3.0.0/ltsp-3.0.html#AEN1372
