This is very helpful, thanks!
Dimitry Naldayev wrote:
You are missing /etc. It mast be part of / (root fs) becouse init
need some information from there
>>
Hm. I wonder if I could get by with just /etc/rc.d/rcsysinit.d on /
in order mount filesystems, one of which would be a "real" /etc in a
separate partition.
I need most of /etc to be outside of the / filesystem, because it's
not shareable - but that particular part should be common.
Let's consider what we need to put in /etc of root fs to be able mount
local file systems and full /etc particular
I was going to rebut, and in trying to prove my point, I proved yours
instead. :)
OK, I'm sold. I'll need a relatively full, default /etc on /. But...
If we will mount another /etc (from different partition) on top of root fs
/etc, we will have two sets of described above files --- one in read-only
root fs /etc and another in read-write mounted /etc and keeping these sets
in sync is not easy task.
... I'm not sold yet that I can't/shouldn't mount another /etc on top of
it. I need some of what's in /etc to load the new /etc, and much of the
rest of /etc in case I can't mount other filesystems, and trying to sort
out exactly what's needed and what's not seems not worth it - it's only
2MB or so straight from build, anyway.
_The motivations_ The main question is "why we want to keep the root fs
read-only?". The answer is probably "we want increase security". A cracker
need to remount root fs in read-write mode before he can do bad things with
oure computer. If his exploit do not do this, he out of luck. But if /etc
is mounted in read-write mode, he do not need to remount root fs to be able
modify something in /etc.
So there are no reasons to put /etc on different partition.
Well, the two are separable: the question of whether or not / is
read-only or read-write is different from that of putting /etc on
another partition.
Remember, in my case, I'm talking about running a large number of
virtual machines on a single piece of hardware. Duplicating all of the
static content in / between all of the VMs wastes space, but more
importantly, it's an administration hassle. As you point out above,
keeping all of them in sync would not be easy - much easier to have them
all reference the same disk and share the static content.
For this same reason, the argument about maintaining a separate /etc
being too much trouble doesn't hold up (in my case). I'm going to be
maintaining many different /etc partitions *anyway*, one for each VM.
It seems easier for me to maintain those separately (my plan is for each
VM to reference the one shared "static" disk with /, and each have their
own disk with partitions for swap, /etc, /var, /home, /svr, /opt and
other non-shareable content) rather than to maintain them as part of /.
In any event, I wouldn't be mounting the new /etc in read-write mode;
I'd be mounting that read-only as well. If I can move or redirect
variable content to /var or /svr (as with /etc/mtab->/proc/mounts), I
can do that. That seems to negate your argument about security.
I'm doing basically the same thing with root's home dir, putting a
small /home/root on / (ro), that gets mounted over by another /home
filesystem on a different partition (mounted rw).
The common technic is to put root's home dir in /root not in
/home/something
I agree that's common. FHS says that either is compliant, though. And
since I'll be mounting a separate /home anyway, moving root's homedir to
/home/root seems to make more sense.
(Although I suppose I could have the /etc/passwd on the / partition
reference /root, and the /etc/passwd that gets mounted over it reference
/home/root - but that seems like asking for administration confusion.
Otherwise, if / is read-only, I'd have to have a separate partition to
mount over /root, which seems a little silly.)
If convention dictates that /root exist, why not have that symlink to
/home/root?
There are software wich add entries to /etc/fstab when you hotplug some
hardware in you computer.
Luckily for me, I do not need to solve this problem. The virtual
machines will run in static virtual hardware, without even USB.
Thanks for your input; it's really helping me understand both the boot
process (I've been reading the woefully out of date Boot To Bash Prompt
for guidance as well) and arguments pro and con regarding security.
-jps
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
