Re: [Cooker] FHS 2.3 (fwd)
One reason the proposal came up for /srv is that the fhs is commonly asked by sysadmins for guidance as to where they should put data for services. On linux at least, /var/www and /home/www is common, though neither seem to fit into the definitions for those areas. Is it so hard to broaden the definition of /var then? The structure under /srv has been left undefined, with some suggestions as a non-normative rationale. Being that the structure under /srv is left undefined we still end up with the same mess. /srv/database/postgresql or /srv/postgresql or /src/disk1/postgresql This does not solve a problem: /srv will still be a mess from distro to distro. Or, even worse, some distros may ignore /srv sticking to the previous LSB/FHS (undefined) waiting for clarification or changes in future versions of the FHS. So we'll end up with both /var /home /srv depending on the flavor of linux. No, the rationale states that data of interest to a specific user should go in that user's home directory. Here is the full text of the rationale: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users home directory. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on these locations. This assumes data is arranged and stored in seprate places based off of services. rsync, cvs, ftp, and www can easily share the same target data. Yup, we don't have FHS police :-) Admins do make local changes. In this case its more about setting up defaults for applications/packages to place or access their data. Then please keep it out of / . If this is just to be a dumping ground for apps to leave their default junk we don't need to clutter up / with another dir do we? /var seems to have always been the ugly stepchild of unwanted crap... I'm fine with adding more to it... ;) The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly what they propose /media does. I can already visualize my inbox filling up for the mdk10 upgrade, /mnt/cdrom is GONE!!! please FIX At the moment on linux we have /mnt/cdrom, /cdrom and /media/cdrom used. The main objection to /mnt/cdrom has been the older unix tradition of using /mnt as a temporary mount kind of scratch area. Though I do wonder how much this really matters these days. Chris -- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 [EMAIL PROTECTED]
Re: [Cooker] FHS 2.3 (fwd)
Bryan, I think you managed to drop the cc, I don't think Chris is cc'ed. One reason the proposal came up for /srv is that the fhs is commonly asked by sysadmins for guidance as to where they should put data for services. On linux at least, /var/www and /home/www is common, though neither seem to fit into the definitions for those areas. Is it so hard to broaden the definition of /var then? IMHO the definition doesn't get any broader anyway. In the case where you have a large volume of data in /var/www, you most likely have a database supporting that data in /var/lib/mysql, and you would have planned ahead for this and created a large /var, or partitioned it better to allow quota use etc. There is a distinction between the types of data we have in /var though. We have data that could be used by multiple pieces of software (/var/www by any web server, /var/spool/mail by different MTAs), then we have data that is specific to the software (/var/spool/postfix, /var/spool/imap, /var/lib/urpmi, /var/lib/mysql etc etc). The structure under /srv has been left undefined, with some suggestions as a non-normative rationale. Being that the structure under /srv is left undefined we still end up with the same mess. /srv/database/postgresql or /srv/postgresql or /src/disk1/postgresql Yes, I see no advantage to just moving most of /var into /srv. This does not solve a problem: /srv will still be a mess from distro to distro. Or, even worse, some distros may ignore /srv sticking to the previous LSB/FHS (undefined) waiting for clarification or changes in future versions of the FHS. So we'll end up with both /var /home /srv depending on the flavor of linux. And symlink mess between them, some symlinks in /var pointing to /srv/X, some symlinks in /var/lib pointing to /srv/Y etc. No, the rationale states that data of interest to a specific user should go in that user's home directory. Here is the full text of the rationale: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. IMHO, scripts don't belong in /var (for samba we place supporting scripts in shell and perl in /usr/share/samba or /usr/share/samba3 which is IMHO a more sane location), but neither do they belong in some other location. We use /var/lib/samba for other non-user-specific data that should be available by default, so we have /var/lib/samba/printers for Windows printer drivers, /var/lib/samba/profiles for user profiles (which shouldn't really be in $HOME) and /var/lib/samba/netlogon for login scripts etc. I don't see the sense in placing this all in /srv. On existing servers, this will only mean more headaches for admins who must either symlink everything (and rpm doesn't deal well with changing a filesystem entry from a symlink to a directory and vice-versa so the admin has more headaches ahead with this method) or repartitioning (since / is likely too small to hold /srv too) or remounting /var/ (or some directory below it) under /src (which will likely require a reboot or at least dropping to single). And I don't see any benefit in this. Data that is only of interest to a specific user should go in that users home directory. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on these locations. This assumes data is arranged and stored in seprate places based off of services. rsync, cvs, ftp, and www can easily share the same target data. Yup, we don't have FHS police :-) Admins do make local changes. In this case its more about setting up defaults for applications/packages to place or access their data. Then please keep it out of / . If this is just to be a dumping ground for apps to leave their default junk we don't need to clutter up / with another dir do we? /var seems to have always been the ugly stepchild of unwanted crap... I'm fine with adding more to it... ;) My issue is that I really don't like typing extra keys unless really necessary. One of the nice things about linux used to be that you could hit two keys per directory level and get quite far. Now I am going to have to type: /sb[TAB]/ifco[TAB] instead of /s[TAB]/ifco[TAB]. Please don't pollute / any more (one of the reasons I hate Windows is polluted root directories due to lack of structure by most users ...). The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly
Re: [Cooker] FHS 2.3 (fwd)
[snip]
My issue is that I really don't like typing extra keys unless really
necessary. One of the nice things about linux used to be that you could
hit two keys per directory level and get quite far. Now I am going to have
to type:
/sb[TAB]/ifco[TAB] instead of /s[TAB]/ifco[TAB].
oh crap... I didn't even think of that till you mentioned it...
I know what you mean tho. I took over a solaris server and the previous
SA used /user for user data that jacked up my tab'n for /usr .
Please don't pollute / any more (one of the reasons I hate Windows is
polluted root directories due to lack of structure by most users ...).
Exactly. Var is already a mess, lets not turn / into a mess also...
Well, /mnt/cdrom is normally temporary, as is /mnt/floppy. And again, this
is increasing the tpying I have to do (even in a graphical file manager
like Konqueror typing is quite a bit faster to get to a directory you know
the location of) if /mnt is retained and /media added.
If someone really wants a scratch mount area, they can make /mnt/tmp or
similar (this is what I do, usually for loopback mounts).
However, /media is a lot more descriptive than /mnt, but then it looks
quite out of place in /, being the longest directory name now
It's a toss up, I don't care one way or another personally I create
a new directory for a temp mount then remove it when i'm done
everytime... With a team of SA's I don't want to mount over /mnt when
another had already has a mount there... and checking if a directory has
already been mounted gets old real fast... ;)
If /media is used instead of /mnt I'll just delete /mnt to keep /
cleaner
BTW, we mostly have non-system data in /home/{users,groups,projects,cvs},
but we are quite small ...
we keep our data in /export/{home[1,2,3...],proj[1,2,3]} then autofs
manages /home and /proj with real names via NIS. From the users
prospective all 130+ of our unix/linux boxes look the same in terms of
data location as the only look in /home or /proj...
--
Bryan Whitehead
SysAdmin - JPL - Interferometry and Large Optical Systems
Phone: 818 354 2903
[EMAIL PROTECTED]
[Cooker] FHS 2.3 (fwd)
OK folks. FHS 2.3 is currently stuggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. -- Stew Benedict -- MandrakeSoft -- Forwarded message -- Date: Wed, 5 Nov 2003 12:46:17 +1100 From: Christopher Yeoh [EMAIL PROTECTED] To: Stew Benedict [EMAIL PROTECTED] Subject: FHS 2.3 Hi Stew, A couple of proposed changes in FHS 2.3 are proving to be fairly controversial. Mainly Addition of /srv: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16 Addition of /media: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27 I'd like to know what MandrakeSoft's position is on these 2 changes. Something along the lines of: - Strongly oppose - Oppose - Don't care - Support - Strongly Support Thanks, Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia
Re: [Cooker] FHS 2.3 (fwd)
Le mer 05/11/2003 à 14:50, Stew Benedict a écrit : OK folks. FHS 2.3 is currently stuggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. Addition of /srv: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16 Addition of /media: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27 If only we could have an access to this ... unable to bugs.freestandards.org ... -- Broadcast message: fin du monde dans cinq minutes, repentez vous !
Re: [Cooker] FHS 2.3 (fwd)
Am Mittwoch, 5. November 2003, 09:50:21 Uhr MET, schrieb Stew Benedict: OK folks. FHS 2.3 is currently stuggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. I'd like to take a look at this proposals, but the URLs don't work. Can you put these documents somewhere I can access them? -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), Non-Violence in Peace and War
Re: [Cooker] FHS 2.3 (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stew Benedict wrote: OK folks. FHS 2.3 is currently stuggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. There seems to be a dns problem. I am seeing some issues with respect to other people resolving our DNS too (but I tested from klama and it seemd ok), so I don't know if it's more wide-spread and what the cause is ... [EMAIL PROTECTED] buchan]$ host bugs.freestandards.org ;; connection timed out; no servers could be reached [EMAIL PROTECTED] buchan]$ dig freestandards.org ns ; DiG 9.2.3rc2 freestandards.org ns ;; global options: printcmd ;; connection timed out; no servers could be reached [EMAIL PROTECTED] buchan]$ whois freestandards.org NOTICE: Access to .ORG WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the PIR registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and PIR does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations. All rights reserved. PIR reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. Domain ID:D26146162-LROR Domain Name:FREESTANDARDS.ORG Created On:02-May-2000 00:58:53 UTC Last Updated On:30-Sep-2003 16:00:20 UTC Expiration Date:02-May-2005 00:58:53 UTC Sponsoring Registrar:R34-LROR Status:OK Registrant ID:34-C Registrant Name:SEE SPONSORING REGISTRAR Registrant Street1:Whois Server:whois.dotster.com Registrant Street2:Referral URL:www.dotster.com/help/whois Registrant City:N/A Registrant Postal Code:N/A Registrant Country:CA Registrant Email:[EMAIL PROTECTED] Admin ID:34-C Admin Name:SEE SPONSORING REGISTRAR Admin Street1:Whois Server:whois.dotster.com Admin Street2:Referral URL:www.dotster.com/help/whois Admin City:N/A Admin Postal Code:N/A Admin Country:CA Admin Email:[EMAIL PROTECTED] Billing ID:34-C Billing Name:SEE SPONSORING REGISTRAR Billing Street1:Whois Server:whois.dotster.com Billing Street2:Referral URL:www.dotster.com/help/whois Billing City:N/A Billing Postal Code:N/A Billing Country:CA Billing Email:[EMAIL PROTECTED] Tech ID:34-C Tech Name:SEE SPONSORING REGISTRAR Tech Street1:Whois Server:whois.dotster.com Tech Street2:Referral URL:www.dotster.com/help/whois Tech City:N/A Tech Postal Code:N/A Tech Country:CA Tech Email:[EMAIL PROTECTED] Name Server:NS2.KERNEL.ORG Name Server:NS1.KERNEL.ORG Found referral to whois.dotster.com. The data contained in the WHOIS database, while believed by the company to be reliable, is provided as is, with no guarantee or warranties regarding its accuracy. This information is provided for the sole purpose of assisting you in obtaining information about domain name registration records. Any use of this data for any other purpose, including, but not limited to, allowing or making possible dissemination or collection of this data in part or in its entirety for any purpose, such as the transmission of unsolicited advertising and solicitations, is expressly forbidden without the prior written permission of this company. By submitting an inquiry, you agree to these terms of usage and limitations of warranty. Please limit your queries to 10 per minute and one connection. Registrant: Pathname Solutions 4390 Albany Drive San Jose, CA 95129 US Registrar: DOTSTER Domain Name: FREESTANDARDS.ORG Created on: 02-MAY-00 Expires on: 02-MAY-05 Last Updated on: 30-SEP-03 Administrative, Technical Contact: Quinlan, Daniel [EMAIL PROTECTED] Pathname Solutions 4390 Albany Drive San Jose, CA 95129 US (408) 919-3000 Domain servers in listed order: NS2.KERNEL.ORG NS1.KERNEL.ORG End of Whois Information [EMAIL PROTECTED] buchan]$ dig @ns2.kernel.org freestandards.org ns ; DiG 9.2.3rc2 @ns2.kernel.org freestandards.org ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4221 ;; flags: qr rd ra; QUERY: 1,
Re: [Cooker] FHS 2.3 (fwd)
I'd like to take a look at this proposals, but the URLs don't work. Can you put these documents somewhere I can access them? I can't reach the domain either. attachment: snapshot1.png
Re: [Cooker] FHS 2.3 (fwd)
On Wed, 5 Nov 2003 22:50, Stew Benedict wrote: FHS 2.3 is currently stuggling with a couple of controversial proposals. Addition of /srv: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16 Addition of /media: http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27 bugs.freestandards.org resolves to 207.235.77.149 which back-resolves to base3.freestandards.org but still won't allow me to connect on port 80. I tried https just for the fun of it and no go. Nmap shows FTP, SSH, SMTP, (TCP) DNS, IMAP[23] and SMux, whatever that is, on port 199. Cheers; Leon
Re: [Cooker] FHS 2.3 (fwd)
On Wed, 2003-11-05 at 17:56, Matthew D. Pitts wrote: I'd like to take a look at this proposals, but the URLs don't work. Can you put these documents somewhere I can access them? I can't reach the domain either. We didn't need the attachment. Please don't post binaries to this list, particularly something as big as a screenshot, unless it's ABSOLUTELY necessary. This being a geek list, there are people accessing it via modems and probably sometimes even odder and slower methods. -- adamw
Re: [Cooker] FHS 2.3 (fwd)
At 2003/11/6 07:12+0800 Leon Brooks writes: On Wed, 5 Nov 2003 22:50, Stew Benedict wrote: bugs.freestandards.org resolves to 207.235.77.149 which back-resolves to base3.freestandards.org but still won't allow me to connect on port 80. I tried https just for the fun of it and no go. Nmap shows FTP, SSH, SMTP, (TCP) DNS, IMAP[23] and SMux, whatever that is, on port 199. Apologies, freestandards.org had DNS problems last night and it now appears that the webserver on base3 is dead. Hopefully will be up soon. Meanwhile, the proposed /srv and /media specifications can be seen in the FHS 2.3 beta 3 document here: http://www.samba.org/~cyeoh/fhs-2.3-beta3.pdf Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia
Re: [Cooker] FHS 2.3 (fwd)
Stew Benedict wrote: OK folks. FHS 2.3 is currently struggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. Since you asked... My opinion is /srv is kinda lame idea to begin with. Where we put our data for services seems to be a personal preference. At JPL many use /export/home[1,2,3...] for nfs/samba home directories. Project space would get /export/proj[1,2,3...]. A database would get /export/data. Others use /data/ or /disk[1,2,3...] or whatever. In other words, this change looks like they want to enforce a certain way of locating / arranging data for various services. I say leave this out... this pulls us away from how other UNIX's deal with this problem: allow the SA to choose his own scheme. Also the description seems pretty stupid, /srv - data generated by users for the services the system offers. Can't this also mean data in /home? if the system offers samba as a service should the data now go in /srv ? What about nfs exported home directories do they belong in /srv now? The intention of unifying the location of where data is kept is a semi-good idea for those who need a decision made for them, but it will be largly ignored by shops who already have a scheme in place and don't want to have thier linux machines differ from their Solaris/AIX/IRIX machines. I don't see why keeping the default in /var is bad as many distro's do now. At least it doesn't clutter up my / with yet-another entry. The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly what they propose /media does. I can already visualize my inbox filling up for the mdk10 upgrade, /mnt/cdrom is GONE!!! please FIX -- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 [EMAIL PROTECTED]
Re: [Cooker] FHS 2.3 (fwd)
Just to recap. I think redhat is right on this one... / should not get more messy than it already is... my original reply is below that was sent to cooker (in case you don't subscribe). Bryan Whitehead wrote: Stew Benedict wrote: OK folks. FHS 2.3 is currently struggling with a couple of controversial proposals. They would like Mandrake's opinion, as part of what FHS tries to do is formalize current convention. United Linux based distros use these currently. My take is Red Hat is against them. I'm not sure how to reply with a formal Mandrake position, but perhaps posting here will give me more of a feel on how the community views these proposals. Since you asked... My opinion is /srv is kinda lame idea to begin with. Where we put our data for services seems to be a personal preference. At JPL many use /export/home[1,2,3...] for nfs/samba home directories. Project space would get /export/proj[1,2,3...]. A database would get /export/data. Others use /data/ or /disk[1,2,3...] or whatever. In other words, this change looks like they want to enforce a certain way of locating / arranging data for various services. I say leave this out... this pulls us away from how other UNIX's deal with this problem: allow the SA to choose his own scheme. Also the description seems pretty stupid, /srv - data generated by users for the services the system offers. Can't this also mean data in /home? if the system offers samba as a service should the data now go in /srv ? What about nfs exported home directories do they belong in /srv now? The intention of unifying the location of where data is kept is a semi-good idea for those who need a decision made for them, but it will be largly ignored by shops who already have a scheme in place and don't want to have thier linux machines differ from their Solaris/AIX/IRIX machines. I don't see why keeping the default in /var is bad as many distro's do now. At least it doesn't clutter up my / with yet-another entry. The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly what they propose /media does. I can already visualize my inbox filling up for the mdk10 upgrade, /mnt/cdrom is GONE!!! please FIX -- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 [EMAIL PROTECTED]
Re: [Cooker] FHS 2.3 (fwd)
At 2003/11/6 07:12+0800 Leon Brooks writes: bugs.freestandards.org resolves to 207.235.77.149 which back-resolves to base3.freestandards.org but still won't allow me to connect on port 80. I tried https just for the fun of it and no go. Nmap shows FTP, SSH, SMTP, (TCP) DNS, IMAP[23] and SMux, whatever that is, on port 199. The bugs database is up again. Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia
Re: [Cooker] FHS 2.3 (fwd)
I'm not subcribed to the list, so apologies for the broken threading... Bryan Whitehead wrote: My opinion is /srv is kinda lame idea to begin with. Where we put our data for services seems to be a personal preference. One reason the proposal came up for /srv is that the fhs is commonly asked by sysadmins for guidance as to where they should put data for services. On linux at least, /var/www and /home/www is common, though neither seem to fit into the definitions for those areas. In other words, this change looks like they want to enforce a certain way of locating / arranging data for various services. I say leave this out... this pulls us away from how other UNIX's deal with this problem: allow the SA to choose his own scheme. The structure under /srv has been left undefined, with some suggestions as a non-normative rationale. Also the description seems pretty stupid, /srv - data generated by users for the services the system offers. Can't this also mean data in /home? if the system offers samba as a service should the data now go in /srv ? What about nfs exported home directories do they belong in /srv now? No, the rationale states that data of interest to a specific user should go in that user's home directory. Here is the full text of the rationale: This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users home directory. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on these locations. The intention of unifying the location of where data is kept is a semi-good idea for those who need a decision made for them, but it will be largly ignored by shops who already have a scheme in place and don't want to have thier linux machines differ from their Solaris/AIX/IRIX machines. Yup, we don't have FHS police :-) Admins do make local changes. In this case its more about setting up defaults for applications/packages to place or access their data. The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly what they propose /media does. I can already visualize my inbox filling up for the mdk10 upgrade, /mnt/cdrom is GONE!!! please FIX At the moment on linux we have /mnt/cdrom, /cdrom and /media/cdrom used. The main objection to /mnt/cdrom has been the older unix tradition of using /mnt as a temporary mount kind of scratch area. Though I do wonder how much this really matters these days. Chris -- [EMAIL PROTECTED] IBM OzLabs Linux Development Group Canberra, Australia
