Re: separate /bin and /usr/bin - is this just legacy?
- From: phil-news-nospam@xxxxxxxx
- Date: 14 Dec 2005 15:41:45 GMT
On 12 Dec 2005 11:53:27 -0800 Doug Freyburger <dfreybur@xxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx wrote:
|> There's plenty of space for a separate partition with a duplicate system.
|> And CDROMs can hold a complete rescue systems that surpass the capabilities
|> of an entire installed system of just a decade ago. I no longer use single
|> user mode for anything and so I can't see any need for structuring things
|> specifically to make single user mode workable.
|
| Ah, now there's where your bias comes in.
I won't say I'm not biased. But maybe you can describe what bias
you see. Is it that I use Linux?
|> Do we really need single
|> user mode for newer systems, as opposed to a complete, and totally separate,
|> maintenance system (either on another partition or separate media)?
|
| A small booting system exists. Whether it's only used for stuff like
| jumpstart/kickstart/ignite. It makes little sense for a separate
| system
| to be used when a pared-down version can be used. Of course, the
| only time that's needed in any strict sense is boot time.
My separate system is "complete" enough to be quite usable for doing
a lot of things. It is focused on doing administration. It does have
emacs, for example. But it doesn't have Solitaire to pass the time
while disks are reformatted :-) It is on a 248 MB partition while
the main system has 4 GB for /usr and some other stuff.
| There's more than "need", though. There can be other advantages. I
| like to side-step the actual history of the name of /usr and teach
| that it has newer meaning. USR for Unix System Reserved or even
| better Unix System Readonly. There is plenty of use to having the
| filesystem that contains the bulk of the installation to be read-only.
| Whether that means logically RO from strict permissions, virtually
| RO from being mounted RO except to do installs, or physically RO
| once installation is finished isn't as relevant as the idea that it can
| be treated as read-only.
Actually, I have been mounting /usr RO for years. It is interesting
that you bring this up, because I want to also have what's in /bin be
RO as well.
| Someday over the rainbow, viruses will attack UNIX. At that time
| the more systems that have the more layers of protection the better.
| Isolating the least changing parts of the installation, and the most
| crucial parts of the installation and making them RO is yet another
| layer of defense in depth. The stricter the level or RO-ness the
| less suseptible to attack.
That's why I want /bin, and /lib, and /sbin, to all be RO, in addition
to /usr and even /opt (where used).
| Whether there's a separate / and /usr isn't a big deal to me. Making
| /usr as locked down as feasible is. Try going to the extreme of
| making / and /usr together and to making it RO in hardware and
| see what happens - /etc is a problem. Files in /etc need to change
| with some frequency. Separate / and /usr works. Having /etc as a
| separate mount doesn't because of assumptions built into the
| system. How to find /etc/vfstab or /etc/filesystems>
What I'm experimenting with in Linux right now is making / be tmpfs
(e.g. lives in RAM but is swappable) and mounting everything else to
that. By using the "bind" option of mount, I can mount specific
directories of one filesystem as /bin, /lib, /sbin, and /usr. And
it is RO. So is / for that matter. So how did I deal with /etc?
And what about /dev? Those are similarly bind mounted along with
most of /var on another filesystem, which stays RW. Some other things
have their own tmpfs or filesystem. Here's what I have running with
Linux and derived from Slackware:
root@canopus:/root 1> df -a
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs[root] 1024 0 1024 0% /
/dev/hda1 248944 167280 81664 68% /admin
/dev/hda3:bin 4075456 3844784 230672 95% /bin
/dev/hda1:boot 248944 167280 81664 68% /boot
/dev/hda5:dev 128440 65192 63248 51% /dev
devpts 0 0 0 - /dev/pts
tmpfs[shm] 193032 0 193032 0% /dev/shm
/dev/hda5:etc 128440 65192 63248 51% /etc
/dev/hda4:home 113631392 96863892 16767500 86% /home
/dev/hda3:lib 4075456 3844784 230672 95% /lib
/dev/hda3:opt 4075456 3844784 230672 95% /opt
proc 0 0 0 - /proc
/dev/hda5:root 128440 65192 63248 51% /root
/dev/hda3:sbin 4075456 3844784 230672 95% /sbin
sysfs 0 0 0 - /sys
/dev/hda7:tmp 642536 37940 604596 6% /tmp
/dev/hda3:usr 4075456 3844784 230672 95% /usr
/dev/hda5:var 128440 65192 63248 51% /var
tmpfs[lock] 193032 0 193032 0% /var/lock
/dev/hda8:log 128440 47548 80892 38% /var/log
tmpfs[run] 193032 96 192936 1% /var/run
/dev/hda6:var/mail 128440 32840 95600 26% /var/mail
/dev/hda7:var/tmp 642536 37940 604596 6% /var/tmp
/dev/hda4:web 113631392 96863892 16767500 86% /web
root@canopus:/root 2>
These are RO: tmpfs[root], /dev/hda1, /dev/hda3.
And /dev/hda1 is that "complete" enough system I mentioned above. It is
also where the kernel image resides (a practice I started back when the
528 MB boundary on PC partitions was an issue for boot loading).
I certainly have /bin and /usr/bin on the same filesystem. This is part
of why I wonder why I can't just do away with the difference altogether.
I may well just have to try it and see what happens (although that won't
really tell me if it would break common situations that I just happen to
not have).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.
- Follow-Ups:
- Re: separate /bin and /usr/bin - is this just legacy?
- From: Doug Freyburger
- Re: separate /bin and /usr/bin - is this just legacy?
- References:
- separate /bin and /usr/bin - is this just legacy?
- From: phil-news-nospam
- Re: separate /bin and /usr/bin - is this just legacy?
- From: Doug Freyburger
- separate /bin and /usr/bin - is this just legacy?
- Prev by Date: Re: separate /bin and /usr/bin - is this just legacy?
- Next by Date: Re: Looking for HP-UX support engineer in TEXAS
- Previous by thread: Re: separate /bin and /usr/bin - is this just legacy?
- Next by thread: Re: separate /bin and /usr/bin - is this just legacy?
- Index(es):
Relevant Pages
|