Where can I find info on filesystem layout?

Just go for ZFS root and accept the defaults. No more messing with slices!

Post by Anonymous
I want to set up a development machine with user desktop type stuff, email
client, newsreader, blah blah blah, possibly an intranet web server with
static pages like doc files (OMG 2 GIG of Solaris 10 doc in the tar.gz???)
and I don't know which additional filesystems I should create or what mount
points I should use for my addons. To make it worse it looks as the addon
packages in the companion CD and package sites all use different paths and I
don't see any pattern. Is this normal/acceptable on Solaris or how should
they be organized? Can anyone please point me to doc that describes how the
filesystem should be set up?

Packages from different sources have different paths to avoid clashes.

--
Ian Collins

Anonymous

2011-02-17 00:30:36 UTC

Post by Ian Collins
Just go for ZFS root and accept the defaults. No more messing with slices!

Yes, I got that part. What I want to know is what about adding filesystems
so I can organise my work. For example what if I have a bunch of doc and I
want to make it available to all the users. Where does it go? Do I create a
filesystem like /var/doc as I might do under BSD or Linux or do I use an
existing filesystem? Same question for stuff like virtualbox machines. I
don't want to keep them in my home directory. What about code I want to
share with other users?

What is /export/home btw?

Post by Ian Collins
Packages from different sources have different paths to avoid clashes.

I understand the purpose behind it but the naming conventions seem a little
wild compared to what I am used to.

Thank you.

Ian Collins

2011-02-17 00:37:01 UTC

Post by Anonymous

Post by Ian Collins
Just go for ZFS root and accept the defaults. No more messing with slices!

It's really up to you, there aren't any hard and fast rules. I tend to
keep all shared data in a variety of filesystems in one pool and all
machine specific files in rpool. With ZFS you can set your mountpoints
and share properties on each filesystem.

Post by Anonymous
Same question for stuff like virtualbox machines. I
don't want to keep them in my home directory. What about code I want to
share with other users?

Same again, I just create a vbox filesystem on each machine I run
VirtualBox.

Post by Anonymous
What is /export/home btw?

The filesystem the automounter mounts under /home.

--
Ian Collins

Thad Floryan

2011-02-17 02:47:19 UTC

Post by Anonymous

Post by Ian Collins
Just go for ZFS root and accept the defaults. No more messing with slices!

Post by Anonymous
Same question for stuff like virtualbox machines. I
don't want to keep them in my home directory. What about code I want to
share with other users?

Same again, I just create a vbox filesystem on each machine I run
VirtualBox.

The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

For decades I've been partial to a "/usr/local" hierarchy and I put it on
all systems under my control and/or purview. The hierarchy is a logical
arrangement regardless how many physical filesystems comprise it -- some
of the filesystems might be clear across the planet. I'm in Silicon Valley
and I used to nfs-mount filesystems located in Seattle WA and Reston VA for
access to client data.

Thus, I would have a /usr/local/doc to satisfy the OP. The beauty of a
/usr/local hierarchy is that all of a site's files are in it and are not
splattered all over the system and in what should be inviolate directories
such as /etc, /bin, /sbin, etc. as I've seen to be too often the case and
frequently a nightmare for the subsequent IT or system maintenance people.

With that written, there are two useful semi-official hierarchy guides:

1) Filesystem Hierarchy Standard for UNIX-like systems

<http://www.pathname.com/fhs/>
<http://www.pathname.com/fhs/pub/fhs-2.3.pdf>

2) Linux Filesystem Hierarchy from the Linux Documentation Project

<http://tldp.org/guides.html>
<http://tldp.org/LDP/Linux-Filesystem-Hierarchy/Linux-Filesystem-Hierarchy.pdf>

Ian Collins

2011-02-17 03:03:33 UTC

Post by Thad Floryan
The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

If that's the case, there's a decent guide at

http://www.cuddletech.com/blog/pivot/entry.php?id=562

although I disagree with the use of /user/local.

Post by Thad Floryan
For decades I've been partial to a "/usr/local" hierarchy and I put it on
all systems under my control and/or purview. The hierarchy is a logical
arrangement regardless how many physical filesystems comprise it -- some
of the filesystems might be clear across the planet. I'm in Silicon Valley
and I used to nfs-mount filesystems located in Seattle WA and Reston VA for
access to client data.

Use of /usr/local is more often than not discouraged on Solaris. I for
one prefer to keep non-system stuff well away from /usr.

Everything under /usr gets included in Live Upgrade BEs, which could be
a real pain with UFS but less so with ZFS. Symlinks used in /usr used
to bugger up LU big time! It's not unknown for /user to be mounted read
only.

I bung all my stuff under /opt/local (most Sun unbundled packages go in
/opt), which lives on another pool.

--
Ian Collins

Thad Floryan

2011-02-17 03:49:07 UTC

Post by Thad Floryan
The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

If that's the case, there's a decent guide at
http://www.cuddletech.com/blog/pivot/entry.php?id=562
although I disagree with the use of /user/local.
[...]

Well, I've been using /usr/local/* since before Sun even existed. I held
the first Sun machine in my hands at this meeting:

<http://thadlabs.com/FILES/HPCQ_SUN.pdf>

:-)

I still have a bunch of my early Sun boxes: 3/60, IPX, SS10, SS20, etc.
Several SS10/SS20 can be seen in the background in this pic from late
2010 atop a Lightwave ServerSwitch in my wooden "rack":

<Loading Image...

>

which is controlled by this (to the left of the monitor in above pic):

<Loading Image...

>

Lucky for me, my NEC LCD monitor handles both normal video and Sun video:

<Loading Image...

>

:-)

Ian Collins

2011-02-17 04:15:03 UTC

Post by Thad Floryan
The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

If that's the case, there's a decent guide at
http://www.cuddletech.com/blog/pivot/entry.php?id=562
although I disagree with the use of /user/local.
[...]

Well, I've been using /usr/local/* since before Sun even existed. I held
<http://thadlabs.com/FILES/HPCQ_SUN.pdf>

I was on the wrong side to the pond for that one..

Post by Thad Floryan
I still have a bunch of my early Sun boxes: 3/60, IPX, SS10, SS20, etc.
Several SS10/SS20 can be seen in the background in this pic from late
<http://thadlabs.com/PIX/Thad_desk.jpg>

Blimey, I though my desk was busy! Do you pump the heat from that room
to the rest of the building??

It was the combination of small drives and bloated BEs that moved me
away from /usr/local.

--
Ian Collins

Thad Floryan

2011-02-17 04:52:48 UTC

Blimey, I though my desk was busy! Do you pump the heat from that room
to the rest of the building??

I used to joke that my home office would keep the house warm during
the Winter. Way back when, that was almost true. Dumping CRTs for the
LCD made a big difference as did getting more-more systems with energy-
efficient PSUs and CPUs. For example, my Solaris 10 boxes are running
on AMD 4850e CPUs which are very efficient. I had to buy those chips
and replace the originals to gain that improvement as you can see:

<Loading Image...

>

Using PLUG computers has also dramatically reduced the energy load for
my 24/7/365 servers (DHCP, DNS, tftp, etc.) to about 4 to 5 Watts each
as measured with a Kill-A-Watt:

<Loading Image...

>
<Loading Image...

>

Kill-A-Watt info here in case you're not familiar with the devices:

<http://www.p3international.com/manuals/p4400_manual.pdf>
<http://www.p3international.com/manuals/p4460_manual.pdf>

Post by Ian Collins
It was the combination of small drives and bloated BEs that moved me
away from /usr/local.

Really? I had complete BEs on my Sun-3/60s and AT&T 3B1s that would
amaze you, especially the 3B1s (I still have 3) using a MC68010 CPU,
4 MB RAM max (yes, that's four megabytes) and an 80MB hard drive running
full AT&T SVR5 UNIX. I had a /usr/local hierarchy on all those
systems. One year I demonstrated one of my 3B1s at the West Coast
Computer Faire circa mid-1980s in San Francisco; I had it running gcc,
GNU emacs, and the asteroid game all simultaneously. FWIW, I also
ran the AT&T Silicon Valley UNIX Users Group for the entirety of its
existence (up to when AT&T abandoned UNIX). I'm now retired though
still available. :-)

Thad Floryan

2011-02-17 04:55:14 UTC

Post by Thad Floryan
[...]
the Winter. Way back when, that was almost true. Dumping CRTs for the
LCD made a big difference as did getting more-more systems with energy-
[...] ^^^^^^^^^

Whoops. "more-more" S/B "more-modern"

:-)

Ian Collins

2011-02-17 05:35:33 UTC

Post by Ian Collins
It was the combination of small drives and bloated BEs that moved me
away from /usr/local.

I didn't realise any of those could run Solaris, it was never an option
on 68K based systems.

The biggest problem with creating BEs on UFS wasn't the disk capacity is
was the time taken to copy the data into the new BE. That was why it
was a good plan to keep everything that wasn't part of the OS
distribution on a different slice.

--
Ian Collins

Thad Floryan

2011-02-17 07:00:28 UTC

Post by Ian Collins
It was the combination of small drives and bloated BEs that moved me
away from /usr/local.

I didn't realise any of those could run Solaris, it was never an option
on 68K based systems.

Perhaps I misunderstood? I assumed "BE" meant Build Environment for
building software packages.

Post by Ian Collins
The biggest problem with creating BEs on UFS wasn't the disk capacity is
was the time taken to copy the data into the new BE. That was why it
was a good plan to keep everything that wasn't part of the OS
distribution on a different slice.

Your last sentence (above) is something I wish more people/companies
would do and is/was one of the reasons I favored a "/usr/local"-like
approach. Whether it's /opt/local or whatever is irrelevant as long
as "local" additions aren't mixed with or replace the distribution files
unless one appreciates/understands the possible unforeseen consequences.

What used to really "bug" me were colleagues who'd build a more-recent
version of a package in their home directory then copy the executable
to a system directory without appropriate documentation or notification
meaning that later no one would have a clue as to the origin/nature of
some of the "new" system programs. This was a common problem back in
the days before mandated source control &tc, but I still see it occur
everywhere I visit. Sigh.

Whether it's /usr/local or /opt/local or /foo/local, there should be a
recognizable location for the sources, objects and executables of all
"home-grown" system changes. I've used "/usr/local" more out of habit
beginning back in the early 1970s after migrating from the PDP-10s and
SDS/XDS-940 systems of the 1960s and the CDC and IBM mainframes before
that. :-)

Ian Collins

2011-02-17 07:11:04 UTC

Post by Ian Collins
It was the combination of small drives and bloated BEs that moved me
away from /usr/local.

I didn't realise any of those could run Solaris, it was never an option
on 68K based systems.

Perhaps I misunderstood? I assumed "BE" meant Build Environment for
building software packages.

That explains a lot, I was referring to Live Upgrade Boot Environments
(see my response to your first post).

Yes, I agree.

Post by Thad Floryan
What used to really "bug" me were colleagues who'd build a more-recent
version of a package in their home directory then copy the executable
to a system directory without appropriate documentation or notification
meaning that later no one would have a clue as to the origin/nature of
some of the "new" system programs. This was a common problem back in
the days before mandated source control&tc, but I still see it occur
everywhere I visit. Sigh.

I agree. I always make sure everything built locally is under /opt/local.

--
Ian Collins

Andrew Gabriel

2011-02-17 09:35:17 UTC

Post by Thad Floryan
The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

If that's the case, there's a decent guide at
http://www.cuddletech.com/blog/pivot/entry.php?id=562
although I disagree with the use of /user/local.
[...]

Well, I've been using /usr/local/* since before Sun even existed. I held

The use of /usr/local became discouraged with Solaris 2, when the
filesystem layout changed to SVR4. In SVR4, /usr belongs exclusively
to the bundled OS. No third party or local changes should be made in
it, because a reinstall would lose everything under /usr, and you
generally didn't want to lose local and third party apps if you
reinstalled the base OS (or upgraded, which for SVR4 was a reinstall).

Whilst this change wasn't fully thought through at the time (it's
easy to spot warts on it), it was a big improvement on the situation
before.

I included some of this in the filesystem(5) manpage some years back.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

Nomen Nescio

2011-02-20 09:56:32 UTC

Post by Ian Collins
http://www.cuddletech.com/blog/pivot/entry.php?id=562

Thanks I'll have a look.

Post by Ian Collins
Use of /usr/local is more often than not discouraged on Solaris. I for
one prefer to keep non-system stuff well away from /usr.

Exactly.

Post by Ian Collins
Everything under /usr gets included in Live Upgrade BEs, which could be
a real pain with UFS but less so with ZFS. Symlinks used in /usr used
to bugger up LU big time! It's not unknown for /user to be mounted read
only.

This is the kind of info I need so I keep the system clean and working as
intended.

Post by Ian Collins
I bung all my stuff under /opt/local (most Sun unbundled packages go in
/opt), which lives on another pool.

Sigh, the opt option. Thanks Ian.

Fritz Wuehler

2011-02-22 14:51:29 UTC

Post by Thad Floryan
The OP's question hasn't been answered. I'm getting the impression the
the OP is really asking about a file system hierarchy. :-)

That's it!

Post by Thad Floryan
For decades I've been partial to a "/usr/local" hierarchy and I put it on
all systems under my control and/or purview. The hierarchy is a logical
arrangement regardless how many physical filesystems comprise it -- some
of the filesystems might be clear across the planet. I'm in Silicon
Valley and I used to nfs-mount filesystems located in Seattle WA and
Reston VA for access to client data.

I do similarly on Linux and BSD for my local apps and doc pertaining to what
I've installed, but I use various filesystems on /var for things that aren't
part of the OS or distro and are also not locally installed apps. There's a
tendency to think of usr as "user" but it really isn't, it's UNIX system
resources so I personally don't like to put non UNIX system resources like
doc, development code, media etc under /usr.

Post by Thad Floryan
Thus, I would have a /usr/local/doc to satisfy the OP. The beauty of a
/usr/local hierarchy is that all of a site's files are in it and are not
splattered all over the system and in what should be inviolate directories
such as /etc, /bin, /sbin, etc. as I've seen to be too often the case and
frequently a nightmare for the subsequent IT or system maintenance people.

Yeah this is the point I was asking about. I don't want to create a mess but
I don't know the rules of Solaris. You hit the nail on the head about what
the issue is.

Post by Thad Floryan
1) Filesystem Hierarchy Standard for UNIX-like systems
<http://www.pathname.com/fhs/>
<http://www.pathname.com/fhs/pub/fhs-2.3.pdf>

I'm not sure if I've see that one yet, I'll check. But all of the ones I've
seen that aren't Solaris specific (and I haven't seen a Solaris-specific one
yet) are all similar. I've tried to setup my BSD and Linux as I read them. I
wanted to ask the guys here about Solaris in case Solaris has a different
view. When in Rome etc.

Post by Thad Floryan
2) Linux Filesystem Hierarchy from the Linux Documentation Project
<http://tldp.org/guides.html>
<http://tldp.org/LDP/Linux-Filesystem-Hierarchy/Linux-Filesystem-Hierarchy.pdf>

Thanks for your post! I suppose I'll go with my normal /var strategy.

Cydrome Leader

2011-02-21 21:01:06 UTC