[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thread: Webdirectory standard



The keyboard of bsa@kf8nh.apk.net emitted at some point in time:
> 
> In <[🔎] 32752959.5B00C0CC@megabaud.fi>, on 10/28/96 at 11:44 PM,
>    Fabrizio Polacco <fpolacco@megabaud.fi> said:
> +-----
> | Does this discussion belong to FHS ?
> | Is it worth?
> +--->8
> 
> cgi-bin location is a local issue, modified by security concerns; it has no
> place in FHS.
> 
> I'm not convinced the Web root has a place here, either; a lot of it depends
> on what you are using it for (local/intranet, single site, ISP w/user account
> sites, commercial multiple-site web hosting service, etc.).

The question is almost "where do we put byte aggregates into the file
hierarchy", although not quite so general. The answer must therefore
clearly be: "below /".

This is quite correct, but does not really help. So:

   o  Operating System User Guides in Html Format
      - /usr/doc/component-name/...
      - /opt/application-name/doc  (/opt/doc/application-name ?)
      - /usr/local/doc/application-name/

   o  Operating System man Pages in Html Format
      - /usr/share/man/html?/.....  (cf man page hierarchy discussion)

   o  Administered and Approved Personal Home Pages
      - ~home-page-approval-pseudo-user/user/

   o  Non-Administered and Approved Personal Home Pages
      - ~user/the-user-will-know-where-to-put-them

   o  Other Information Published on the Machine
      This is an administration issue, people may want to create a
      pseudo user (such as ftp for anonymous ftp), but who is FHS to
      tell people what to do with their machines ?

   o  User Callable Browsers
      - /usr/bin
      - /usr/local/bin
      - /opt/bin
      - /opt/browser-name/bin

   o  Browser Callable Support Executeables
      - /usr/libexec/browser-name/bin  (useable only by one browser)
      - /usr/libexec/www/bin           (meant to be used by all browsers)
      - /usr/local/libexec/browser-name/bin
      - /opt/browser-name/bin

   o  Demand Acquired Executeables from the Web
      - ~user/bin, ~user/bin/www (~user/bin/cgibin ?)
      Basically, Executebles Acquired from the net MUST not be placed
      into directories where they are visible systemwide without
      administrator intervention (basic principle of virus protection)

Most of this is straight from application of the principles of the FHS. The
things that may be controversial here are:

   o  www directory in .../libexec claimed as support for all browsers
   o  /usr{,/local}/doc will also be used for other formats (such as .txt)
   o  /opt/doc
   o  The idea that system administrators want to approve personal home 
      pages. This is certainly not an issue for owner-user-administrators,
      and where it is an issue, those who enforce approval will not
      listen to counter-arguments from fhs-discuss.

There is also the information protection and security issue. 1For example,
application providers may not want the user guides served world-wide
via an http daemon, even though they are quite happy that users able
to log in to a machine that has bought their software can read it.

The basic principle must be that operating system supplied stuff in html
form should go into /usr, application supplied stuff into /opt, /usr,
or /usr/local, and the stuff that the user wants to run the machine for
into /home or some other name. If the operating system changes the stuff
automatically in its usual operation it goes into /var (for example an
html page displaying the current information that the who or w commands
would display, or demand expanded and retained man pages).


                                 Thomas

*   email: cmaae47 @ imperial.ac.uk
*   voice: +44 171 594 6904 (day), +44 171 385 6540
*   fax:   +44 171 594 6958
*   snail: Thomas Sippel - Dau
*          Application Support Group
*          The Center for Computing Services
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: