Re: bin, sbin, etc as seperate LVM volumes

On Tuesday 21 March 2006 21:55, Floyd L. Davidson stood up and spoke the
following words to the masses in /comp.os.linux.misc...:/

Aragorn <stryder@xxxxxxxxxxxxxxx> wrote:

On Tuesday 21 March 2006 19:48, Floyd L. Davidson stood up and spoke
the following words to the masses in /comp.os.linux.misc...:/

Those are *not* "mount points". With the exception of mnt, they
*must* all be on the same filesystem.

Putting */mnt* on a _different_ filesystem would be really awkward.
;-)

True, but it doesn't *have* to be on the root filesystem. It's just
a lot easier to type /mnt/floppy than it is to type
/elsewhere/mnt/floppy, and serves no purpose whatever; but no real
harm comes from putting it elsewhere.

Well, I wouldn't even have thought so far. One could technically also
easily make */mnt* a separate filesystem - that was actually my point -
but it makes no sense. ;-)

On the other hand, */root* _can_ be placed on a different filesystem.

That is a *really bad* idea!

I don't see why it would be. The only thing that directory contains are
the personal /.bashrc,/ /.bash_logout/ and /.profile/ files of the root
user, and those can be easily copied to the directory */root* on the
root filesystem _before_ the separate */root* filesystem is mounted to
the mountpoint.

During normal operation, */root* would be the separate filesystem - and
the /bash/ history would be stored there - and when booting up in
single-user mode with only the root filesystem mounted, */root* would
be available still as a directory, eventually with the root user's own
shell configuration files.

The only real potential problem would be if one were to make */root* a
symbolic link to e.g. */home/root.* In the above scenario of a
single-user mode boot, */root* would be a broken link.

But even then still, I think the default /bash/ configuration in most
distros is to fall back to using the actual root directory as the root
user's home - just as in the old Unix tradition.

That shouldn't be a problem as long as the mountpoint exists, i.e. it
must _not_ be a symbolic link to e.g. */home/root.*

It *must* be on the root filesystem.

I don't see why it should be - see above section...

The whole point is to have it available if *anything* actually boots.
Very similar to the requirement for /bin and /sbin, for example.

No, there is nothing in */root* that requires being present at boot-up,
not even in single-user mode. */root* is the root user's home
directory. It should only contain data, and none of those should be
needed upon boot.

*/bin,* */sbin,* */etc* and */dev,* yes, they need to be on the root
filesystem, eventhough */dev* only needs to contain */dev/console* and
*/dev/null.* /udev/ users run their */dev* off of a /ramfs/ - or a
/devfs/ for /devfs/ users of course.

As for */tmp,* if the OP so desires and has enough RAM, he could make
that a /tmpfs./ That way, he would be sure that */tmp* is empty
again upon each boot, regardless of whether he installed /tmpwatch/
or of the presence or absence of...

rm -rf /tmp/*

... in his /init/ scripts.

Which of course is exceedingly easy to do..., hence I see no
particular purpose in tmpfs.

I don't have my */tmp* on a /tmpfs/ but there are people who prefer it
that way. A /tmpfs/ mounted on */dev/shm* is needed for POSIX
compliance, by the way. Gentoo uses it, for one. On my older Mandrake
system, it's empty but it's mounted.

Also, I would recommend that /usr/local be a separate filesystem.

I also have that one as a separate filesystem, but it's not really
recommended in most distributions unless the user is going to install
lots of packages from sources. Most distributions just put
everything under */usr* and */opt.* ;-)

That is exactly what should be *avoided*.

Keep in mind that "most distributions" are not necessarily set
for the *best* configuration, so much as one that will work at
the lowest common denominator. This discussion is about where
to go from that point if you want to have a *better* configuration.

But then by your standards, the OP would also need to start moving all
that stuff - which his distribution installed in */usr* - to
*/usr/local,* and that would be pointless and cumbersome.

Unless the OP wants to build his entire distribution from scratch - as
in "LFS-style" - he'll probably end up with most software installed in
*/usr* and part of it in */opt.*

I already mentioned I use an older Mandrake on this machine - it will be
replaced with Gentoo as soon as my new hard disks are installed - and
this is what my */usr* and */usr/local* look like, sizewise...

/dev/sda3 xfs 7.1G 4.7G 2.4G 67% /usr
/dev/sda5 xfs 2.0G 25M 2.0G 2% /usr/local

Kind of a spacewaster, huh? ;-)

Make them manageable by someone who knows what they are doing.

That would most certainly _exclude_ Windows Admins, considering that
Microsoft has a tendency to rewrite the definitions of certain
concepts and globally acknowledged standards... ;-þ

Well, I wouldn't exclude someone knowing what they are doing
with Linux just because they do happen to also know Windows.

I was being sarcastic, based upon my experiences with the knowledge of
Windows sysadmins... ;-) Those guys typically know everything there is
to know about Windows, but they don't know anything whatsoever about
other operating systems and they're stuck to Microsoft logic.

The point was that knowing Windows is useless; somebody who knows
*Linux* is necessary.

Absolutely! ;-)

If he wants "everything on God's green earth", fooling around with
people who are guessing isn't productive, no matter how good they are
at something else.

Oh yeah... We've had an administrator like that once... He had one
common solution for every small little problem we ran into, whether it
was a stuck process or a failing daemon...:

shutdown -r now

;-þ

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user #223157)
.

Relevant Pages

  • Re: bin, sbin, etc as seperate LVM volumes
    ... be available still as a directory, eventually with the root user's own ... recommended in most distributions unless the user is going to install ... with Linux just because they do happen to also know Windows. ...
    (comp.os.linux.misc)
  • Re: Of mice and men
    ... >> This is no different to many environments OS - even windows. ... With their own account, and guest accounts set ... > root password, but they cannot "run as root" without it. ... > it will tell you that you do not have disk access. ...
    (comp.lang.cobol)
  • Re:Deploring *nix Philosophy
    ... > our different understanding of 'Desktop Installation'. ... > accounts for different family members and root account is managed by the ... initially invest in a fedora bible of sorts. ... bring the complexity or power of the OS down to the level of a windows ...
    (Fedora)
  • Re: New To Linux
    ... A file can be user root and group root, but when yo uhave a look you will ... The concept behind Linux IS confusing for someone accustomed to windows, ... execute, delete). ... In windows you are always an Administrator unless you use explicitely the ...
    (alt.os.linux.suse)
  • Re: Does Scandisk MSG indicate Hardware, Application, or OS Issue? - R
    ... Windows 2000 SP4, ... I had a problem that I am trying to determine the root cause of a problem. ... A disk check has been scheduled. ... After this restore it complained ...
    (microsoft.public.windows.file_system)