etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: [Etherboot-users] Booting a non-supported OS.

[Marty C. <md...@th...>]

On 9/6/2001 11:03 AM Anders Pettersson and...@md... wrote:
>Now I want to move on and wants to boot up the PC104 board with a micro
>kernel. The format of the kernel image can be either a binary image or a
>S-record file. So I want to be able to modify the etherboot code to
>accept these formats.

This isn't my area of specialty with Etherboot, but I'll do what I can.  
Ken should be back in a few days, and may be able to give a more informed 
statement.

>I have looked into to the source and think that the modification is
>possible, but as I not fully understand the code yet I might be wrong.
>I'm also aware of that I probably have to modify mknbi source as well to
>get a tagged image.

I suspect you'll mostly need to modify mknbi to accept the format of your 
object code, and convert it into NBI (network bootable image) format.  If 
you download the mknbi package from, say:

   http://prdownloads.sourceforge.net/etherboot/mknbi-1.2.tar.gz

You will find a file called "spec.txt", which has describes NBI format. 
Etherboot is also capable of loading ELF format, though I'm not sure how 
much help that will be to you.

>Now to the question, is there anyone out there who can give some
>pointers or advice in how this can be accomplished? Or can tell if this
>project cannot be done? Or have it already been done by someone else?

I'm almost certain that what you want can be done.  I suspect that most 
of the work is in modifying mknbi, but wait a few days and Ken or another 
developer may have a another answer.  I notice there is a directory in 
the contrib subdir of Etherboot for loading QNX.

I hope this is of some help.  Let us know how it goes.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[Marty C. <md...@th...>]

On 9/5/2001 2:30 PM Eric W. Biederman ebi...@ln... wrote:
>> My gut reaction is not to make this common, and just to insert helper
>> functions calls.  The reason is that pci devices while they tend to
>> be fairly standard, they are not always so.  Leaving this logic to the 
>> device driver sounds a little more reasonable to me.  I don't
>> think etherboot supports any unreasonable hardware at the moment.
>And I forgot to say.  If you code it I really don't care how it is dealt
>with, unless I'm the project maintainer.  If I code it I'll write it my 
>way :)

I am of two minds on this.  One one hand, since PCI bus initialization is 
generally done outside the drivers anyway, I suspect his won't make much 
difference, since most of the code I've looked at seems to be doing the 
same thing for all the cards that need it.

The sticky part is that we're trying to deal with (possibly) buggy 
drivers that have failed to properly locate and initialize a card.  Since 
this seems like a BIOS interface issue and not a driver issue, I'd prefer 
that the etherboot core deal with it, and let the driver deal with making 
the card ready to send and receive packets.

I'll be interested in hearing what Ken's take on this is when he gets 
back.  The other way to look at it is that if we put the logic in the 
Etherboot core, it might break more things, rather than just the drivers 
we add the code to.  I don't think this is the case though, since, 
basically, it's code very similar to what the etherboot core does (or 
should do) now.

Anyway, interesting to think about.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[<ebi...@ln...>]

ebi...@ln... (Eric W. Biederman) writes:

> Marty Connor <md...@th...> writes:
> 
> > On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote:
> > >Given that we need this for both linuxBIOS and some of the more different 
> > >BIOS's I suspect we should create some helper functions like 
> > >pci_enable_device and pci_set_master (examples from the linux kernel api) 
> > >and use these in all of the pci networking drivers. 
> > >Marty, Ken what do you think?
> > 
> > I think this would be a good idea.  There is inconsistency in how drivers 
> > handle PCI initialization, and I think it should probably be done before 
> > the call to eth_reset, so that the driver doesn't have to deal with it.  
> > This shouldn't increase code size, and would likely fix some BIOS 
> > incompatibility bugs.
> 
> Hmm.  Code size is an issue...  
> 
> My gut reaction is not to make this common, and just to insert helper
> functions calls.  The reason is that pci devices while they tend to
> be fairly standard, they are not always so.  Leaving this logic to the 
> device driver sounds a little more reasonable to me.  I don't
> think etherboot supports any unreasonable hardware at the moment.

And I forgot to say.  If you code it I really don't care how it is dealt
with, unless I'm the project maintainer.  If I code it I'll write it my way :)

Eric

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[<ebi...@ln...>]

Marty Connor <md...@th...> writes:

> On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote:
> >Given that we need this for both linuxBIOS and some of the more different 
> >BIOS's I suspect we should create some helper functions like 
> >pci_enable_device and pci_set_master (examples from the linux kernel api) 
> >and use these in all of the pci networking drivers. 
> >Marty, Ken what do you think?
> 
> I think this would be a good idea.  There is inconsistency in how drivers 
> handle PCI initialization, and I think it should probably be done before 
> the call to eth_reset, so that the driver doesn't have to deal with it.  
> This shouldn't increase code size, and would likely fix some BIOS 
> incompatibility bugs.

Hmm.  Code size is an issue...  

My gut reaction is not to make this common, and just to insert helper
functions calls.  The reason is that pci devices while they tend to
be fairly standard, they are not always so.  Leaving this logic to the 
device driver sounds a little more reasonable to me.  I don't
think etherboot supports any unreasonable hardware at the moment.

Eric

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[Marty C. <md...@th...>]

On 9/4/2001 4:59 PM Eric W. Biederman ebi...@ln... wrote:
>Given that we need this for both linuxBIOS and some of the more different 
>BIOS's I suspect we should create some helper functions like 
>pci_enable_device and pci_set_master (examples from the linux kernel api) 
>and use these in all of the pci networking drivers. 
>Marty, Ken what do you think?

I think this would be a good idea.  There is inconsistency in how drivers 
handle PCI initialization, and I think it should probably be done before 
the call to eth_reset, so that the driver doesn't have to deal with it.  
This shouldn't increase code size, and would likely fix some BIOS 
incompatibility bugs.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] rtl8139 TX timeout solved (for me)

[<ebi...@ln...>]

Bernd Wiebelt <wi...@dr...> writes:

> Thanks to the suggestion from Eric W. Biederman, I was able to get my
> RTL8139 card to behave. I verbatimely copy'n'pasted code to activate
> busmastering from 3c90x.c to rtl8139.c and things magically began to work.
> 
> It seems my BIOS is buggy (i.e. not initializing PCI cards correctly)?

Possibly.  I haven't seen a spec on what BIOS's are supposed to initialize
before calling the rom on a card.

Given that we need this for both linuxBIOS and some of the more different BIOS's
I suspect we should create some helper functions like pci_enable_device and
pci_set_master (examples from the linux kernel api) and use these in
all of the pci networking drivers. 

Marty, Ken what do you think?

Eric

[Etherboot-developers] rtl8139 TX timeout solved (for me)

[Bernd W. <wi...@dr...>]

Thanks to the suggestion from Eric W. Biederman, I was able to get my
RTL8139 card to behave. I verbatimely copy'n'pasted code to activate
busmastering from 3c90x.c to rtl8139.c and things magically began to work.

It seems my BIOS is buggy (i.e. not initializing PCI cards correctly)?

Re: [Etherboot-developers] bootrom for Dlink DE530CT+

[Marty C. <md...@th...>]

On 9/1/2001 7:24 AM Christian Schoebel e99...@st... wrote:
>what I've also realised is that the dc21041 boot rom
>(dc21041.lzrom) only needs about 500 bytes more than a
>16 KB boot rom.
>my question:
>what are the possibilities I have for reducing the dc21041.lzrom
>size in order to be able to put it into an 16 KB rom?
>reducing the tulip driver? does anyone have experience with that?
>or saving space in any other part?
>please give me some ideas!

Note that:

  /* Size of transmit and receive buffers */
  #define BUFLEN 1536

and there are 4 of them currently:

  #define RX_RING_SIZE    4

If you set RX_RING_SIZE to 3 you might save 1.5K.

There are also a lot of debugging printfs that could be taken out.  And 
there is code that is only run for particular kinds of cards which could 
be #ifdef'ed.

Let us know if that helps.

Marty

P.S. There is a media-selection bug that could probably be fixed by 
putting this call:

      init_media(nic);

just before

    /* enable transmit and receive */
    outl(tp->csr6 | 0x00002002, ioaddr + CSR6);

at the end of the "tulip_reset" function.

The media selection bug seems mostly to affect old Cisco 5000 series 
switches, which are problematic with a number of NICs.  If someone could 
test this, I'd be grateful...



---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] bootrom for Dlink DE530CT+

[Christian S. <e99...@st...>]

I am trying to etherboot a

Dlink DE530CT+, a pci network controller.

it uses an dc21041, therefore I'm using the
tulip driver. The vendor id and pci id are correct.


the problem is that this network controller mentioned
above can only cope with 16 KB boot roms, but the dc21041
boot rom is 32 KB.

what I've also realised is that the dc21041 boot rom
(dc21041.lzrom) only needs about 500 bytes more than a
16 KB boot rom.

my question:
what are the possibilities I have for reducing the dc21041.lzrom
size in order to be able to put it into an 16 KB rom?

reducing the tulip driver? does anyone have experience with that?

or saving space in any other part?

please give me some ideas!
thanks!
christian.

[Etherboot-developers] LinuxWorld WebCam up!!

[Marty C. <md...@th...>]

See Ken, Markus, and Marty at the booth! :-)

     http://thinguin.org/linuxworldsf2001/webcam/

Tell your friends ;)


---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] rom-o-matic.net status

[Marty C. <md...@th...>]

rom-o-matic.net is back up after sustaining a security breach a few days 
ago.

After a careful security audit, we are confident that the crackers who 
broke in were trying to hide the intrusion so that they could use the 
machine to attack other machines.  The rom-o-matic.net website was not 
affected by intrusion, other than being slowed down by unauthorized 
processes running on the machine.

The machine has been rebuilt from scratch, and all recommended updates 
are installed.

Etherboot 5.0.3 is now available on rom-o-matic.net.  

Because we are running Red Hat 7.1 on this machine, I have installed two 
versions of Etherboot for 5.0.3. 

The only difference is that one version compiles Etherboot ROMs with gcc 
2.96 and the other compiles using kgcc 2.91.

If you find that making a ROM image with gcc doesn't work, try making one 
with kgcc and see if that works.  I have applied all the recommended gcc 
updates to RH 7.1.

Please let me know of any problems.  Now it's back to LinuxWorld 
preparations! I'll have a message about that a bit later.

Marty

P.S. We're still looking for folks who are willing to help us out at 
LinuxWorld Expo in San Francisco.  Please reply if you can come and 
assist us in the booth, even for a little while.  We'll arrange a free 
pass for you, and it will be a fun time.

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] rom-o-matic.net offline temporarily

[Marty C. <md...@th...>]

rom-o-matic.net will be offline for a day or two for a rebuild.  I 
apologize for any inconvenience.

Someone exploited a recently published stack overflow bug in xinetd to 
gain access.  They then installed a root kit, and attempted to go into 
stealth mode on the machine.  If you're using xinetd on a publicly 
accessible machine, I'd recommend you check securityfocus or your Linux 
vendor to get a patch/upddate.

The intrusion here was detected very quickly, and the machine is intact, 
including the root kit.  The rom-o-matic.net web site was unaffected. 

I was somewhat surprised by the complexity of the tools used.  Basically, 
they installed two kernel modules that attempted to hide files and 
network connections at the kernel level.  So if you did an "ls" or 
"netstat" you would simply not see files or unusual network connections.  
There are also tools that communicate with the modules and hidden 
processes to hide files with a particular owner, and certain ports on the 
machine.  They hacked rc.sysinit so that the modules would be reinstalled 
upon system reboot.  They installed an sshd running on particular port 
number as a back door.  They also changed the root password, and replaced 
some files in /usr/bin.

They then proceeded to attempt to use the server to do massive port 
scans, and ran tools to attempt to compromise other machines, using tools 
to scan large chunks of IP address space.  The names of machines that 
were found were logged in a hidden directory.

If you've never had a server cracked in this fashion, it's quite an 
educational experience.  I have the source of the tools that they used, 
and a .bash_history file of them port scanning and breaking into other 
machines, and using IRC to report successes, rather like a logging 
mechanism.  

What's annoys me about this is that some of the time I would spend 
preparing for LinuxWorld Expo and running my business now has to be used 
to rebuild this machine.  But I'm sure I was just part of some other 
massive port scan that indicated that I was running a vulnerable xinetd, 
and from there it was just a matter of stack-smashing and root-kitting, 
nothing personal.

Anyway, thanks a LOT to all the people who are contributing such 
excellent code and techniques to Etherboot.  I've been listening, even 
though lately I've been too busy to add much to the discussion.  You make 
it totally worthwhile to put up with the occasional bad moments.  It's 
just deeply satisfying and rewarding to be helping people all over the 
world build networks of network booting workstations using Free Software.

rom-o-matic.net will be back soon, and it's my pleasure to provide the 
service.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] Moving ltsroot out of /tftpboot

[<ebi...@ln...>]

Jim McQuillan <ja...@mc...> writes:

> Hello all,
> 
> I sent this posting to several lists, because I think this
> is important, and I want to get comments from as many people
> as possible.
> 
> I want to move the location of the ltsroot directory.
> I've been talking on and off about this for many months now,
> and it's finally time to do it, before the next release of ltsp.
> 
> Currently, it exists in /tftpboot/lts, and I just really think
> that is not the correct place for it.
> 
> I thought it would be a simple matter of sending mail to the
> FHS (File Hierarchy Standards) guys, and ask them where it should
> reside, but they don't have a place for it.
> 
> 
> As part of this directory renaming task, I'm also going to
> begin planning for other (non intel) architectures.
> 
> That is, PowerPC, StrongArm and whatever other CPUs are being
> used in workstations.
> 
> I've had suggestions of many locations, but nobody could really
> put their finger on one perfect location.
> 
> Here are some of the suggestions:
> 
>   /var/lts
>   /var/opt/lts
>   /var/local/lts
>   /var/lib
>   /var/lib/lts
>   /usr/lib
>   /usr/lib/lts
>   /data
>   /export
>   /public
>   /srv
>   /sys
> 
> A few people on the FHS mailing list told me that there was work
> towards putting things like the files that Apache serves into
> "/srv/www" or "/srv/http".

This kind of scheme only works if you can swap out the server/project
on the data.  So you would need to make images that are non-ltsp specific.

> I think that would also be a reasonable place for the ltsp files to 
> reside.
> 
> So, I'm strongly considering putting the root directories into
> "/srv/ltsp".

No please.  
> 
> The basic structure would be:
> 
>     /srv/ltsp/root_i386     standard x86 based workstations
>     /srv/ltsp/root_i686     workstations with PII, PIII and Celerons
>     /srv/ltsp/root_ppc      workstations with PowerPC cpus
>     /srv/ltsp/root_arm      workstations with StrongArm cpus
> 
> 
> Initially, I'll have the root_i386, which would be useable by all
> of the X86 compatible workstations. Then, we'll add root_i686, which
> would
> include the binaries and libraries optimized for the better processors.
> 
> Also, with help from some of you, we'll have packages for ppc, strongarm
> and
> other alternative cpus.

It is a reasonable idea.  If we could find a naming scheme that would
allow multiple nfs roots per architecture that would be nice.  Say something
like:
/srv/nfsroot/i386-ltsp-linux

Currently at Linux NetworX we have been setting things up as:
/opt/lnxi/var/system-images/``name''/

And unless you can find something that will work for all systems export
filesystems nfs-root don't go in /srv.  I wouldn't mind having a
standard but I don't want to rush into it.  

If you can't think of a good solution for the general case, please
just do:
/opt/ltsp/i386/....

> Also, in the plans are support for the --relocate option to RPM.  this
> way, people can put the root directories anywhere they want.
> I'm hoping there is a similar option for .deb packages.

That sounds reasonable.

> So, any comments?

See above.

Eric

[Etherboot-developers] help

[karthikeyan n. <kar...@ya...>]

dear experts,
                  my name is karthi, how to compile
the kernel please sent the detail steps, please help
me

karthikeyan.N

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: [Etherboot-developers] Moving ltsroot out of /tftpboot

[<ke...@us...>]

I'm all for this. I've always thought it ugly that /tftpboot should
contain stuff that have nothing to do with TFTP. It's the defaults in the
kernel source that need to be changed though, uses of /tftpboot in
Etherboot are for TFTP.

>So, I'm strongly considering putting the root directories into
>"/srv/ltsp".

The other option is /opt/ltsp, it's available for extra packages in many
systems, not just Linux. There's a tradition for using /opt for
third-party packages.

Anyway if you make it relocatable, it should not matter much whether
it's /srv or /opt

I'm against using /var or /usr or /usr/local for LTSP. The /usr
filesystem may itself be imported (remember that the LTSP server doesn't
necessarily have to be the /usr server), /usr/local is often used for
site wide exports. LTSP isn't really something that belongs in /var,
/var tends to be associated with temporary state, or admin files.

>    /srv/ltsp/root_i386     standard x86 based workstations
>    /srv/ltsp/root_i686     workstations with PII, PIII and Celerons
>    /srv/ltsp/root_ppc      workstations with PowerPC cpus
>    /srv/ltsp/root_arm      workstations with StrongArm cpus

Instead of prepending root_ to everything, just use the official
architecture name, e.g. /srv/ltsp/i386. Legions of people in future who
have to type the pathname will thank you. There may also be a place for
a noarch directory for architecture independent files that can be shared
by mounting or by hardlinking.

Re: [K12ltsp-list] Re: [Etherboot-developers] Moving ltsroot out of/tftpboot

[Eric H. <eha...@ma...>]

On Fri, 10 Aug 2001, Jim McQuillan wrote:

>Eric,
>
>Maybe I don't understand your comment about mounting ltsroot 'ro'.
>
>It is exported Read-only.

>> I also would like to see ~ltsroot to be easily ro mounted.  Since NFS
>> delegates both authentication and authorization to the client, a prudent
>> security policy would dictate that the export partition be mounted read
>> only.

Oh, I see my mistake... this should have read "a prudent security policy
would dictate that the EXPORTED partition be mounted read only".

The theory is that although the client decides who is "root", that has
minimal impact if there is NO write access to the files on the server.

It's Friday 9:00pm PST, I think I'll go do something other than think
about esoteric security stuff ;-)

-Eric

Re: [K12ltsp-list] Re: [Etherboot-developers] Moving ltsroot out of/tftpboot

[Eric H. <eha...@ma...>]

On Fri, 10 Aug 2001, Jim McQuillan wrote:

>Eric,
>
>Maybe I don't understand your comment about mounting ltsroot 'ro'.
>
>It is exported Read-only.
>
>Here's the line from the /etc/exports file, as it is setup
>by the lts-core package:
>
>   /tftpboot/lts/ltsroot  192.168.100.0/255.255.255.0(ro,no_root_squash)
>

Healthy paranoia. Redundant security mechanisms are a good thing, especially
when the authentication/authorization is delegated to the client and the
vast majority of your clients happen to be high school students.

Redundant security mechanisms are especially nice if they are easy to
implement, such as if ltsroot was put somewhere where it would be easy
to mount the partition read only.

This falls under "it would be nice" rather than "this is a must" ;-)

-Eric

[Etherboot-developers] Re: K12LTSP: Moving ltsroot out of /tftpboot

[Eric H. <eha...@ma...>]

On Fri, 10 Aug 2001, Jim McQuillan wrote:

>I want to move the location of the ltsroot directory.
>I've been talking on and off about this for many months now,
>and it's finally time to do it, before the next release of ltsp.
>
>Currently, it exists in /tftpboot/lts, and I just really think
>that is not the correct place for it.

/tftpboot/ is the traditional place for all things booting via TFP.
On the other hand, anyone using a system so old or obscure that it
is difficult to change that should have no problems moving the LTSP ;-)

>Here are some of the suggestions:
>
>  /var/lts

Falls in line with Red Hat's /var/www & /var/ftp, for better or worse.

>  /var/opt/lts
>  /var/local/lts
>  /var/lib
>  /var/lib/lts

/var seems like an odd place for something as static as the LTSP.

>  /usr/lib
>  /usr/lib/lts

LTSP is not a library as well.

>  /data
>  /export
>  /public
>  /srv
>  /sys

adding directories off of the root feels odd as well.

Perhaps /usr/share/...  would be more natural?

>A few people on the FHS mailing list told me that there was work
>towards putting things like the files that Apache serves into
>"/srv/www" or "/srv/http".

<grumble, grumble> I guess I could live with that as long as other
such services were moved there and everyone promised to never move
the apache or ftp root again ;-)  <yes I'm lazy!>

>So, any comments?
>
>If so, please send them to me pronto.  I'd like to put a 2.09pre2
>package together really soon, so people can test the directory move,
>and other new features like:
>
>     Kernels with NFS swap built-in
>     2.4 kernels
      ^^^^^^^^^^^

In my experience, "legacy free" terminals work much, much better with a
2.4 kernel.

>     devfs
>     XFree86-4
      ^^^^^^^^^

Has anyone tried playing hardware-accelerated games on a terminal? This
seems like an interesting possiblity ;-)

I can verify that Tux Racer and Chromium do no play well on an unaccelerated
terminal.

>     Better support for Local apps
>
>I'd like to get the 2.09-final out before Linux World at the end of
>this month.

See you at LW, the first round of beers will be on me Jim. Thanks again for
all of your great work!

-Eric

Re: [K12ltsp-list] Re: [Etherboot-developers] Moving ltsroot out of/tftpboot

[Jim M. <ja...@mc...>]

Eric,

Maybe I don't understand your comment about mounting ltsroot 'ro'.

It is exported Read-only.

Here's the line from the /etc/exports file, as it is setup
by the lts-core package:

   /tftpboot/lts/ltsroot  192.168.100.0/255.255.255.0(ro,no_root_squash)


Jim McQuillan
ja...@lt...


Eric Harrison wrote:
> 
> Currently the LTSP exports /tftpboot/lts/ltsroot with the "no_root_squash"
> parameter. NFS exports make me nervous, especially with no_root_squash.
> I also would like to see ~ltsroot to be easily ro mounted.  Since NFS
> delegates both authentication and authorization to the client, a prudent
> security policy would dictate that the export partition be mounted read
> only.

Re: [K12ltsp-list] Re: [Etherboot-developers] Moving ltsroot out of /tftpboot

[Eric H. <eha...@ma...>]

On Fri, 10 Aug 2001, Markus Gutschke wrote:

>If all of the files are read-only (it should be possible to mount "/usr"
>read-only, although most distribution don't quite achieve that goal),
>then I think they should go into "/usr/lib/ltsp" or possibly
>"/usr/share/diskless" (if the files make sense for projects other than
>just LTSP or for multiple versions that are supported in parallel).

Currently the LTSP exports /tftpboot/lts/ltsroot with the "no_root_squash"
parameter. NFS exports make me nervous, especially with no_root_squash.
I also would like to see ~ltsroot to be easily ro mounted.  Since NFS
delegates both authentication and authorization to the client, a prudent
security policy would dictate that the export partition be mounted read
only.

>Executables should go into "/usr/bin" (or "/usr/sbin" if there is no
>conceivable reason why normal users would call the program), but they
>might just be links or small wrappers referencing files in
>"/usr/lib/ltsp". All configuration files should go into "/etc/ltsp"
>(although it is OK to have symbolic links from other places that
>reference these files, if that is necessary for technical reasons).

Symbolic links are relative to the system's root. Root on the server is /.
Currently root on the clients is the server's /tftpboot/lts/ltsroot/
directory. Thus a link to the server's /usr/bin placed somewhere in
/tftpboot/lts/ltsroot/ would be a broken link to the client who had mounted
/tftpboot/lts/ltsroot/ as its root. Hopefully that makes sense ;-)

You could hard link specific executables, but that seems like a dangerous
thing to do on a no_root_squash exported directory. Such a hard link
config would also be difficult to package.

>All files that can be written to during the normal course of operation
>and that are not just configuration files, should go into
>"/var/lib/ltsp" or possibly "/var/diskless" (the precedence would be web
>servers putting the entire site into "/var/www").

See above.

>If the project is also made available in a form that does not integrate
>with the system's package management system (e.g. as a tar ball instead
>of an RPM or DEB package), then it should default to "/usr/local/lib" in
>preference over "/usr/lib".

Two opinions on this one:

1) /usr/local does not seem to make sense, since the files in question
   are not local to the server - they are local to the client.

2) consistency is nice. I'd like to see the .tgz, .deb, & .rpm all have
   the same root.

-Eric

Re: [Etherboot-developers] Moving ltsroot out of /tftpboot

[Markus G. <ma...@gu...>]

Jim McQuillan wrote:
> Currently, it exists in /tftpboot/lts, and I just really think
> that is not the correct place for it.
> 
> I thought it would be a simple matter of sending mail to the
> FHS (File Hierarchy Standards) guys, and ask them where it should
> reside, but they don't have a place for it.

I don't really like the proliferation of additional entries in the root 
directory. So, baring overwhelming precedence, I would discourage 
putting any files into "/srv" (as it is, I don't even like the fact that 
there is "/opt").

If all of the files are read-only (it should be possible to mount "/usr" 
read-only, although most distribution don't quite achieve that goal), 
then I think they should go into "/usr/lib/ltsp" or possibly 
"/usr/share/diskless" (if the files make sense for projects other than 
just LTSP or for multiple versions that are supported in parallel). 
Executables should go into "/usr/bin" (or "/usr/sbin" if there is no 
conceivable reason why normal users would call the program), but they 
might just be links or small wrappers referencing files in 
"/usr/lib/ltsp". All configuration files should go into "/etc/ltsp" 
(although it is OK to have symbolic links from other places that 
reference these files, if that is neccessary for technical reasons).

All files that can be written to during the normal course of operation 
and that are not just configuration files, should go into 
"/var/lib/ltsp" or possibly "/var/diskless" (the precedence would be web 
servers putting the entire site into "/var/www").

If the project is also made available in a form that does not integrate 
with the system's package management system (e.g. as a tar ball instead 
of an RPM or DEB package), then it should default to "/usr/local/lib" in 
preference over "/usr/lib".

All of the above is closely modeled after the defaults used by the 
Debian distribution. It has been my experience that Debian typically 
adheres to the FHS as closely as possible.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

[Etherboot-developers] Moving ltsroot out of /tftpboot

[Jim M. <ja...@mc...>]

Hello all,

I sent this posting to several lists, because I think this
is important, and I want to get comments from as many people
as possible.

I want to move the location of the ltsroot directory.
I've been talking on and off about this for many months now,
and it's finally time to do it, before the next release of ltsp.

Currently, it exists in /tftpboot/lts, and I just really think
that is not the correct place for it.

I thought it would be a simple matter of sending mail to the
FHS (File Hierarchy Standards) guys, and ask them where it should
reside, but they don't have a place for it.


As part of this directory renaming task, I'm also going to
begin planning for other (non intel) architectures.

That is, PowerPC, StrongArm and whatever other CPUs are being
used in workstations.

I've had suggestions of many locations, but nobody could really
put their finger on one perfect location.

Here are some of the suggestions:

  /var/lts
  /var/opt/lts
  /var/local/lts
  /var/lib
  /var/lib/lts
  /usr/lib
  /usr/lib/lts
  /data
  /export
  /public
  /srv
  /sys

A few people on the FHS mailing list told me that there was work
towards putting things like the files that Apache serves into
"/srv/www" or "/srv/http".

I think that would also be a reasonable place for the ltsp files to 
reside.

So, I'm strongly considering putting the root directories into
"/srv/ltsp".

The basic structure would be:

    /srv/ltsp/root_i386     standard x86 based workstations
    /srv/ltsp/root_i686     workstations with PII, PIII and Celerons
    /srv/ltsp/root_ppc      workstations with PowerPC cpus
    /srv/ltsp/root_arm      workstations with StrongArm cpus


Initially, I'll have the root_i386, which would be useable by all
of the X86 compatible workstations. Then, we'll add root_i686, which
would
include the binaries and libraries optimized for the better processors.

Also, with help from some of you, we'll have packages for ppc, strongarm
and
other alternative cpus.

Also, in the plans are support for the --relocate option to RPM.  this
way, people can put the root directories anywhere they want.
I'm hoping there is a similar option for .deb packages.


So, any comments?

If so, please send them to me pronto.  I'd like to put a 2.09pre2
package together really soon, so people can test the directory move,
and other new features like:

     Kernels with NFS swap built-in
     2.4 kernels
     devfs
     XFree86-4
     Better support for Local apps

I'd like to get the 2.09-final out before Linux World at the end of
this month.

Thanks,

Jim McQuillan
ja...@Lt...

[Etherboot-developers] patches to 5.0.3

[<ke...@us...>]

Klaus Espenlaub sent me more patches for UDP checksumming on transmit,
NFS fixes and other small tweaks. I have released the patches under
Patch Manager at the web site, instead of waiting for the next version,
so that people can put them to use right away. Here are the changes in
the LOG. Have fun!

+ New version of contrib/Diskless-From-NT/furtmayer.html. I mangled the
previous version by forgetting to extract with metamail so it was still
quotable-printable encoded.

+ Renamed do_printf to vsprintf because that's the standard function it
has the same signature as.

+ More patches from Klaus Espenlaub. In his own words:

The patch to add UDP checksums for transmitted packets is attached.
Just don't be surprised if some packet sniffer tells you that the
checksum for the NFS_LOOKUP packets are wrong and that the filename is
truncated.  It's a bug in the sniffer, not in Etherboot.

Oh, and the small change in udpchksum() almost makes up for the
increased code size.

I also rewrote the NFS code to use pointers instead of array accesses.
This reduced the code size by 124 bytes.  Patch attached.

The last patch in this mail fixes misc things: a typo in misc.c
(DOT_PROGRESS instead of BAR_PROGRESS), and twiddle() is only called if
the packet type is IP.  This makes the output nicer - the dots are also
printed in some non-approriate places for ARP reply packets.  The
important packets are IP anyway.

RE: [Etherboot-developers] TX Timeout

[Hamish G. \(M. Lists\) <ha...@dp...>]

Ken,

I have been having some really weird things going on with one of my
development systems - this was even before I started incorporating the timer
code in 5.0.3, I thought I would just build a standard tulip.lzfd0 and test
it on one of my machines - the configuration was such that it should use the
BIOS timer - It never managed to receive a DHCP packet - also, the timer
appeared to be running extremely slowly. I then used the TSC version of the
code and it was better, I received an IP and it requested the kernel from
the tftp server but then bombed. This is with a Linksys card on a PIII
600MHz machine.

As an experiment, I then moved the NIC to a 233MHz PII box and it works
perfectly.

I will try some more combinations, but there is something strange going on.

As a result, of this nonsense, I have lost the rest of the day for coding,
so will not be sending the timer stuff today - I will see if I am barred
from working tomorrow by the boss!!! (read wife)



Regards

Hamish

-----Original Message-----
From: eth...@li...
[mailto:eth...@li...]On Behalf Of
Ken Yap
Sent: Saturday, August 04, 2001 2:50 PM
To: Etherboot developers list
Cc: ha...@dp...
Subject: Re: [Etherboot-developers] TX Timeout


>I have just downloaded 5.0.3 and I will incorporate it in that - there are
a
>few changes I will make - like reducing the size of the IDT and then also
>putting in the PIC and PIT init code.
>
>I will try to get it to you this afternoon if possible

No hurry, it'll go into the next release, although I will check it into
CVS and also release a patch under Patch Manager.

_______________________________________________
Etherboot-developers mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] TX Timeout

[<ke...@us...>]

>I have just downloaded 5.0.3 and I will incorporate it in that - there are a
>few changes I will make - like reducing the size of the IDT and then also
>putting in the PIC and PIT init code.
>
>I will try to get it to you this afternoon if possible

No hurry, it'll go into the next release, although I will check it into
CVS and also release a patch under Patch Manager.