htmlize {Edrx's Dual Linux Page} {

[H2 1) Boots and chroots]

[P It is possible to have many bootable Linux partitions on the same
machine, and, even more, each one can be booted with many different
kernels (each one configured in a different way, say). This is very
well-known and I think that it is common practice to keep a small
bootable partition with only the basic tools inside to use as a
\"rescue parttion\" in case something goes wrong with the main
bootable partition\; this is much more convenient than using a rescue
floppy.]

[P But there's one variation on this trick that isn't as well-known as
it deserves: you can, in a certain sense, boot two partitions (with
the same kernel) [IT at the same time:] boot the first one, and put
the contents of the second on a directory (named, say, \"[TT
/sublinux]\"), maybe by just mounting the partition there\; then, by
mounting a second proc filesystem on [TT /sublinux/proc], chrooting to
[TT /sublinux] and doing a restricted initialization on the second
partition we get [IT almost] a second Linux system running in parallel
with the first (see my [AL /etc/inittab] for how to start consoles on
the second system). The \"almost\" is because this technique isn't
without its problems: for example, the two systems share PIDs, devices
and sockets, but not locks\; they both have the same IP number and
hostname, etc, etc, etc. In fact, I have had most success with this
technique when I was playing with boot disks, using the Debian
installation/rescue floppy (mounted on a loop device partition) to
install Debian on another (a third!) partition, and when I was using
[ES yard Yard]. I have used it a bit also a long time ago to run
Debian 1.3 on top of a small RedHat-based firewall server that I was
not allowed to change much or to turn off, and bits here and there to
test compiling things on a \"clean Debian 2.1 system\" while at the
same time keeping my full system running below.]

[P I would like to make the dual-Linux trick into standard practice,
and I'm working (slowly) on isolating the main programs which are not
chroot-clean and on preparing runlevels avoid problems with them.
Please, if you have some hints or links [ML edrx@inx.com.br mail them
to me]...]


[H2 2) Connecting to yourself from a (simulated) distant IP]

[P (On using expect (or pipes) to make a ppp link to yourself\;
advantages of this over a loopback connection -- ignoring performance,
of course. Security, firewalls...)]

[P All I have about it at this time is [ES {net
ppp_to_the_same_machine} this e-script], that does not work always\;
it contains a description of the problem and the beginnings of a
message asking for help...]

}