l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 20: Web Application Hacking: How to Make and Break Security on the Web
Next Installfest:
TBD
Latest News:
Oct. 10: LUGOD Installfests coming again soon
Page last updated:
2005 Apr 18 17:14

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] A philosophical question about partitioning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] A philosophical question about partitioning



Bryan Richter said:
> ME wrote:
>> Richard Crawford said:
>> [store music in]
>> > /home/music
>> [where should I store it on a new system]
>>
>> For shared variable data some place under /var. Perhaps make a
>> dir/var/share and in there, make a dir called music
>> /var/share/music
>> (for example)
>
> I think the problem with that is that music is not 'variable'.

For a shared space on a system, there is a lot of turnover in music files.

Space is finite, you download a song, play it, and download other songs.
Eventually, you delete songs you no longer want to make space for other
songs.

>> /var is for variable data.. things like logs, web server roots, file
>> shares that are shared by many users.
>>
>> If you music is shared by many, then a /var sub directory is one of the
>> better choices.
>
> var != shared.

Though the default webroot in many Linux distros is /var/www which would
seem to violate this convention.

When /var/www is a web root, and a web server is running, and user use
that web server, then many users are sharing files in /var space.

Also, web reports generated from log files are also often stored and
shared from /var as are log files to customers as needed.

> In fact, the FHS doesn't specify a /var/share. /var is
> designed for
> variable data files and "transient and temporary" files --- none of which
> applies
> to music.

temporary depends on timing and what is considered temporary enough to be
variable but not good for /tmp.

For me, 1 month temporary-- about how log I keep songs rotated in when new
songs cause old ones go away.

This is longer than some mbox in /var/spool/mail go without being emptied.

Giving users access to fill up /usr space runs the risk of system or
manual source upgrades failing.

Allowing use of /usr/local/* by user is better than /usr, but is still a
poor choice for source builds, as the admin may need to manage user files
in order to complete an application install.

Use of /var space has also been a convention in many Linux distros for
default web roots, web reports, and as well as a store for mail.

Use of /var space is a convention that has been used for years for things
like those mentioned above.

>> /home should really just be user accounts. Pollution of /home with other
>> dirs that are not usernames can lead to problems when you start adding
>> many users. (As a result, is not a good convention.)
>>
>> Looking at others, and you will see they are not good choices:
>> /tmp (no.)
>> /proc (heh heh. no!)
>> /usr (no. /usr, /usr/share, /usr/src, /usr/local (and other /usr should
>> be
>> used for source an applications and libs-- things that the system uses.)
>
> Well.. except for /usr/local. The system doesn't touch that.
>
> And then,
> from the
> FHS, "The /usr/share hierarchy is for all read-only architecture
> independent
> data files" (note how this conflicts with /var). Put those two together
> and you
> get my choice, /usr/local/share/music.

But music directory is not read only. It will continue to grow as users
add more to it.

However, the /var directory may have music files added over time and
deleted over time (much like what you see with maildir for mail storage--
which is located where, when not in the user's home directory space?)

/usr/local/share and /usr/local/share/music still risks problems for
instalation of new software in /usr/local space-- unless there are plans
to creat more partitions.

/
/home
/usr
/usr/local
/usr/local/share
/usr/local/share/music
/var
/tmp
swap
/boot

Not counting a multi-boot system, the above shows the potential for many
partitions for a home user to consider, and exceeding 8 on one drive can
leads to issues of complexity.

> p.s. Actually, /usr/local/share/music is just a symlink on my computer to
> /mnt/nonsys/music. /mnt/nonsys is a big partition with respective
> directories
> for the symlinks /usr/local, /home, /tmp, and some random stuff. That
> seemed
> like a good solution to some of the frustrations I was having with
> partitioning.

This is another alternative, as is the other laternative mentioned to
create a new space in /.

As an admin, I don't think users should be able to write to anything in
the /usr space.
As an admin, I know users have had mbox files stored in /var/spool/mail/
and other files in /var as well (crontab, and other info) and as a result,
they can control addition of content to /var
Allowing users to write to /usr space in addition to /var adds more risk
to administration.

If /var is not liked, then use of another directory in /, or a symlink as
above seem reasonable enough to me.

To me, the function of a directory of music is much closer to how a
maildir directory of mail functions... lots of read only files, added as
needed and deleted as needed.

_______________________________________________
vox mailing list
vox@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.