discuss: Thread: [Proposal] PXE Server HOWTO

That will come in time with the permission of the original authors
(merging), but i will be adding in links for the short term :)

thanks Nic

-----Original Message-----
From: Nicolas Chauvat ####@####.####
Sent: Tuesday, 29 January 2002 12:44 AM
To: Markus Gutschke
Cc: Charles Curley; Jason Bechtel; ####@####.####
Subject: Re: [Proposal] PXE Server HOWTO


I think it's worth mentionning in this thread that the Network-boot-HOWTO,
available from the LDP and at http://www.logilab.org/netboot-howto/ is
part of the stack of HOWTOs that deal with
Network-booting-NFS-root-ing-PXE-pre-booting, etc.

Looks like some work on merging things would be useful. Or at least giving
references in each document to point to the other ones.

--
Nicolas Chauvat

http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris
(France)


_________________________
http://list.linuxdoc.org/

Folks,

Let me get out the first draft of the Howto.  I'm still attacking it with
vigour, and have found that using epcedit is actually quite nice.  Now,  I'm
doing it in book format so it can have additions added to it later on down
the track.
But, first things first,  I'll cover PXE to start off with.... then lets ALL
look at what we can merge into it later.
I've added a Glossary so as to explain terms and terminology etc... that
should be able to help out those who aren't sure of what PXE means, or RTFM
etc etc :)

I'm not biased, there are fans of PXE, there are fans of etherboot and
whatever else exists, but what I'd like to end up with down the track, is a
document/book that incorporates everything that one could need to provide
"Network Boot Services", whether it be basic PXE, etherboot, LTSP etc etc,
they all have their function, they all are valid, and the existing
documentation is far too (no offence intended) disorganised. Ideally, there
should be one document/book that covers as much as possible regarding the
topic... and I do foresee that my initial document will get a name change
down the track.... possibly to "Network Boot Services HOWTO" I don't know.

Some of you may say that having one document covering all could be confusing
to the reader... well, that could be the case, that was how everything was
to me initially as well, but given time and a lot of fiddling around, people
do get the idea.

regarding the suggestion of a separate list for this topic.... no need
unless someone volunteers to set one up...but I don't honestly see the need.
I'd like to, but my isp prohibits use of servers behind cable connections :/
(even tho there's one there, it's in hiding:-) )

Please don't think that I'm not appreciative, I'm quite intrigued by the
amount of people and info that is flowing courtesy of my initial post to
start a new howto.  It's quite grand.

Thanks, and keep it coming

Keith Strachan

Cicero,

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

Jason


Cicero Mota wrote:

> Hi,
> 
> 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. But LTSP is X-terminal driven, which means that applications 
> will run on the server. But keep in mind that disk-less full workstations are 
> major interest since applications run locally. Probably, these two ways of 
> implementing workstations are coexisting in many installations right now (for 
> example at my department :). People at the console of powerful workstations 
> (Athlon, PIV etc) run disk-less nodes, while people sitting at old computers 
> run them as  X-terminals without even know they could be  trash. Everything 
> is clean transparent for the user.
> Anyway, maybe LDP could start thinking about a such a GUIDE.

Peter,

Comments below interspersed...

####@####.#### wrote:
 > My comment is that these are features of net booting in general and
 > *not* PXE per se. One of my contributions will be a section noting that
 > PXE is *not* synonymous with net booting, any more than the BIOSen we
 > find in our motherboards are the only way to initialise hardware, and
 > providing references on how to avoid PXE altogther, such as Etherboot
 > and LinuxBIOS. See www.linuxbios.org to learn how irrelevant Phoenix,
 > Award, AMI, etc products are to Linux.

I'm glad someone will be doing this.  (1) There needs to be a clear 
explanation of *exactly* what PXE is and does and not just what it 
happens to be used (or abused) for.  (2) It needs to be put into the 
context of the Linux world.  Clearly there are reasons for Linux users 
to avoid PXE if possible, but if they are stuck with it (employer 
already has 800 workstations with PXE) then they need to know what they 
can do with it or how to get around it.

 > PXE is just a spec for one way - Intel's way, now adopted by other
 > hardware vendors - to do net booting. A way to add clunky[*] slow[*]
 > buggy[*] network functions to a clunky[*] slow[*] buggy[*] BIOS. The
 > point of PXE for most Linux users - which therefore should, IMHO, be the
 > focus of a LDP PXE howto - is that, like the BIOS, it's what we are
 > stuck with when we take a new system out of the box.

As long as you can back up your [*]'s, as you say you can, then I think 
it would be fine to include such material and personal comments 
regarding the technology.  But as more people migrate to Linux and seek 
out documentation, I'm not sure what would be better for them.  I expect 
my documentation to be unbiased (except that it is necessarily from a 
Linux perspective) and objective.  I just want to avoid a HOWTO that 
winds up embodying one person's view and excluding options that some 
users might be looking for, however proprietary-bound and myopic those 
options may be.

 > A coherent body of LDP docs on booting in general, hardware support,
 > DHCP/TFTP, backup + recovery and so on should rightly include a PXE
 > howto. An LDP document should *not* imply that PXE is a desirable way of
 > network booting or (worse) that LDP (or the Linux project or Linus or
 > any related open source person or body) in any way recommends it. I hope
 > that the LDP reviewers would not let such a suggestion (or even a phrase
 > that might be construed as such by Intel's PR department) into a LDP
 > doc. Utopia is as free of PXE and BIOS vendors as it is of M$.

I agree.  I think the doc can be written from the perspective of "No one 
recommends this and it's a really bad idea, but here's what you can do 
if you're stuck with this technology like some of us" and still provide 
a useful informational HOWTO.  In fact, more than half of the document 
could be dedicated to eliminating PXE and preaching about LinuxBIOS as 
long as the rest of the document still provides actual PXE help.

Jason

Peter,

Again, comments below interspersed...

Peter Lister wrote:

> I really don't want to offend anyone, but if we are to write a document,
> I feel we have a duty to be accurate and fair. When I see incorrect
> information, I'm going to correct it (or wish to hear a very convincing
> argument). I appreciate that this poster hadn't read my previous
> comment, so please don't take it personally - but this is too important
> to ignore. This was partly the raison d'etre for my starting a howto in
> the first place.


Agreed.  I won't take it personally.  :-)   The outcome of the HOWTO is 
what's important.

>>>From my perspective, PXE is an alternative method of remote
>>>booting diskless workstations (the older and perhaps still
>>>more common method is etherboot
> 
> PXE is not an "alternative" to Etherboot. An odd feature of PXE is its
> need for a secondary loader such as Etherboot (or pxelinux, or whatever
> knows how to load Windows). Once one knows this, the choice between (a)
> running Etherboot "native" if at all possible or (b) running PXE to
> chain Etherboot (so taking several seconds longer to achieve the same
> effect) really isn't hard to make.


Absolutely right.  It's more like an "obstacle" to Etherboot.  :-) 
Sorry about the phrasing with the word "alternative".  Having been on 
the LTSP mailing list for a while, I've heard PXE tossed around so much 
that I've come to refer to it in a short-hand jargonish imprecise way. 
Sorry.

> Calling Etherboot "older" seems to imply that you consider it moribund.
> Far from it, as doubtless Markus or Ken will explain to visitors who
> drop by their Linux Expo booth (I'd love to visit, but I'm on the wrong
> side of the Atlantic). We at Sychron considered it worth writing the
> Etherboot PXE support precisely because we saw Etherboot as the best of
> the bunch in the near future.


Here I think you read to much into the word "older."  As with UNIX, 
older is better.  It means it's been around much longer and is therefore 
more solid, stable, tested, and widely used.  The word "old" does not in 
any way imply moribundity.  It simply means that its inception took 
place prior to that of PXE.

[Note:  I sense here a defensiveness on the behalf of the open, 
non-proprietary etherboot with which I can readily identify.  It feels 
just like when I get defensive about LTSP and Linux in general.  It's 
completely understandable.]

>>><http://etherboot.sourceforge.net/>).  But I've heard that
>>>PXE is quickly becoming a standard, at least for corporate
> 
> Aargh! PXE IS NOT A STANDARD.
> 
> Sorry to shout, but I have heard this stated before. Though usually the
> usage is turns out to be merely a figure of speech, as I am sure is the
> case here, it is wrong and misleading to newcomers. PXE is an Intel spec
> which refers to accepted RFC standards (DHCP and TFTP). I agree that PXE
> is ubiquitous in new hardware, and many sites add PXE to purchasing
> policies as an undeniably useful shorthand to ensure that new kit can be
> installed without surprises.


You caught me again...  Indeed, I was using the word "standard" to refer 
to the fact that it has started to appear in desktops systems labeled 
and intended for "corporate" use, and I did so at the word of someone on 
the LTSP list who I've never met and who quickly ran up against some 
fierce backlash on the list.

I suppose this use of the word is a sort of figure of speech, but it is 
used so casually in my circles that I didn't give it much thought. 
Sorry again.  I'm guilty of repeating rumors and misleading 
nomenclature!  Bad Jason!

By the way, please don't think that I especially encourage PXE usage. 
The best way to netboot that I've seen is to put Etherboot on an EEPROM 
on your NIC and roll.  But I've also seen people send messages to the 
LTSP discussion list asking how they can get their PXE cards to work 
with LTSP.  When the assumed goal is simply "getting LTSP to work" then 
working with the hardware they already have is the friendliest way of 
handling the situation.  As soon as we start telling LTSP newbies things 
like "Go get a *real* NIC!" or "Why didn't you buy a system with a 
LinuxBIOS?" they will turn away.  Okay, perhaps that's unfair.  What I 
mean is that comments with the message that PXE is bad, etc. are not 
helpful to people who are stuck with it.  So, I suppose in the interest 
of LTSP advocacy I've taken a soft line with regard to PXE and learned 
to accommodate it so long as it doesn't get in the way of reaping the 
benefits of LTSP and Linux on the desktop.

Now that you've rightly restored my perspective of PXE as an unwanted 
interloper in our etherboot-powered netbooting world, let's return to 
the readers of the proposed PXE HOWTO.  Hopefully this HOWTO is read by 
people doing research *before* they make a large purchase of PXE 
systems.  For those people, these comments about the weaknesses and, in 
fact, irrelevance of PXE to netbooting will be helpful.  For the others 
who find themselves with a PXE NIC and come seeking help, these comments 
  come slightly too late (unless they can get funds to alter their 
hardware situation).  So, perhaps the HOWTO's structure should reflect 
this by having reader-centric sections:

1. For Prospective Users/Buyers of PXE Hardware
2. For Current Owners of PXE Hardware

Or perhaps a section blatantly titled

"How to Avoid PXE"

As long as the next section is called

"If You're Stuck With It"

Jason

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

Just a short notice that debian (woody at least) includes a pair
of diskless packages (server and "client" side) that let one debootstrap
the dir to be used as NFS root. It does not save the trouble of using
something to boot the diskless nodes, but it surely eases maintenance on
the server.

I'll look up the exact reference and package name if needed.

-- 
Nicolas Chauvat

http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)

Keith Strachan wrote:

> Hi All,
[snip]


> I'm currently about a fifth of the way through writing this in DocBook.sgml
> book format, as article format didn't quite suit my needs, and apologies to
> the guys at LDP, but unless you guys can come up with a template for use
> that is a little more explanatory, and a little easier to use.... or someone
> write an application that can simplify doing documentation (there are a lot
> of people out there that would like to write doco, but the tools are
> extremely lacking). Sitting down writing code to write a document is not


HOWTO templates is partly my department and I wrote the first one.
If there is a problem or a deficiency I would really like to know
about it and have it fixed; it was specifically created to lower the
threshold for new authors. You are in the target audience which
makes your input valuable.

Regards,
    Stein Gjoen