view release on metacpan or  search on metacpan

bin/rs  view on Meta::CPAN

and create a new one with the same name will not influence any other
process that's still accessing the removed file in any way since they're
two different files.

So, you have to make sure that no other process is accessing a file when
when you overwrite it, which is impossible for C<make> itself, to say the
least, and any program C<make install> launched when you're overwriting it.
Or you have to remove it before C<make install> but you certainly cannot
remove C<make> since you need C<make> to do C<make install>. That's the
reason not to throw your toolchain away when you are done bootstrapping,
the toolchain resides in a different path and you don't have to worry about
it getting overwritten, and it provides a complete environment for building
so you could safely remove any package even glibc, while using this
environment to build a new one.

In summary, always remove a package before install a new version of it by
compiling from source, usually you don't want to overwrite files unless
you're absolutely sure no one is using them. And use the toolchain to
build the package if the package requires itself to do C<make install>.

=head2 INSTALLATION

=over 4

=item 1. No installation at all

With the advancing with various namespaces, this kind of installation
actually makes perfect sense, you could boot and live with your favorite
distribution while entering RSLinux in isolated namespaces for
exploration. Since VM images are used for release it's very easy to
do so by mounting the image directly.

=item 2. Live replace

You could do installation by simply swap directories under your current
root and the ones under your newly prepared system, what you need is
a third environment to do the actual swap, so that you are safe since
everything under the main system will be unavailable during moving.

The third environment doesn't need to be large, just C<bash> and C<coreutils>
could be enough for the swapping task, C<patch> a few more packages to help
you if you feel unsafe. Then you enter this container with the root directory
bind mounted somewhere under it, and start moving things around, also pray
that electricity won't be cut while you're doing it.

This method is the best option to install RSLinux on a system that's already
running Linux, and probably the only option to install it on a OpenVZ based VPS.

=item 3. Bootable media

If a system is not running Linux already, you cannot use the live replace
method to install RSLinux, you have to use a bootable media like USB disk
or CDROM.

A USB disk is handy to do installation locally while a CDROM image is
suitable to install remotely on a KVM based VPS. For both situations
the most important utilities to include are probably the ones to do
disk partition and filesystem formatting, for remote installation, it's
best to make the CDROM image as small as possible and transfer all the
packages to be installed via network at some later point since it's much easier
to re-upload the image if you forgot to C<patch> some vital packages into it,
so be sure to include something like C<socat> or C<rsync> or C<openssh>
for C<scp> depending on your mood or taste, and of course the C<iproute2>
package and necessary kernel modules to bring up the network.

=back

=head3 A faithful recording of live replace installation on a OpenVZ based VPS

I now have a complete RSLinux system inside a directory on my VPS, I have
already entered it several times and I'm confident that it's good, and the
next step is to swap it with the current distribution.

Since it's a VPS I must login remotely, so in addition to C<bash> and
C<coreutils> I will C<patch openssh> in the third sanctuary as well,
so that's the list of things I want directly. Now the dependencies,
well, definitely C<base> since it setups the directories that a sane
person will always want, and needless to say C<glibc>, since I always
compile C<bash> with curses so C<ncurses> as well, and C<openssl> since
that's what C<openssh> is built upon. So the complete list is
C<base glibc ncurses bash coreutils openssl openssh>. Now I'm going to try and see
how it works out.

Well, apparently C<openssh> needs C<zlib> as well, that's the only thing I
forgot, after C<patch zlib> I successfully entered this sanctuary with the
root directory bind mounted somewhere under it and launched C<sshd> on a
different port, confirmed that I could login through it. Then I did the
actual swap, moved everything under root to a backup directory, well,
except the usually mounted C</proc /sys /dev>, since it's meaningless to
C<umount> them and then C<mount> later, after that I moved all the directories
of the already prepared RSLinux into root, then I entered this fresh root,
played around a little bit, launched C<sshd> and ended the session with
the C<sshd> of the sanctuary.

Finally, I did a login through the C<sshd> of RSLinux I just launched, cleaned
up all the applications of the old system and sanctuary that're still running,
and mountpoints related to them. After that I did a C<rm -rf> on the backup
directory and the sanctuary to celebrate, the installation is done!

So yeah, the previously mentioned eight packages are guaranteed to do a
successful live replacing installation, and I'm sure you can reduce the
number even more if you want. It surely is an exicting, adventurous, and
fruitful journey for me, and it's not that hard, so don't hesitate to give
it a try.

=head3 A faithful recording of CDROM installation on a KVM based VPS

The first step is of course making a list of the packages that I need,
since this is a KVM based VPS I need to do disk partition, so C<fdisk>
from C<util-linux> is absolutely necessary, and needless to say the
C<mount> command from it, and in order to C<mount> I have to format it
first, so C<e2fsprogs> as well, and I like C<syslinux> as the bootloader
so include that too. The next thing to consider is how to transfer the
compiled packages, I never include them in the iso image since I don't
want to upload a big iso file again if I made a mistake, instead they're
transferred using network, this immediately implies that C<iproute2>
is required, while there may be some circumstances that you don't need a
encrypted connection, but I think I'll just stick to C<scp> of C<openssh>,
for good practice, and the additional benefit to login via C<ssh> if
the installation is complicated, so add C<openssh> to list.  Also, I
definitely want to pack things into a tarball, so put C<tar> on the list
so that I could unpack them later.  Finally, C<bash> and C<coreutils>
of course, they're essential for the commandline.

That's everything I need directly, but since it's expected to boot from
this environment, a init system, kernel modules, C<eudev>, C<kmod> are
also required, I always use my one-liner Perl script as the init system
so I will patch C<perl> as well.

Now the dependencies, C<openssl zlib> are required for C<openssh>,
C<ncurses> is required for C<bash>, and C<glibc> is required by
everybody, and C<base> for a sane person, so the final list is C<base
glibc ncurses bash coreutils util-linux e2fsprogs syslinux openssl zlib
openssh iproute2 perl eudev kmod tar>, now I'am going to C<patch> them into a
temporary directory and make a bootable iso out of it and see how things
are going.

So I C<patch>ed all the packages, copied the kernel and its modules, along with
relative C<isolinux> file and configuration, setup the script to boot, and
finally generated the iso using C<mkisofs>. After that I launched to C<qemu>
to test it, well, I forgot that C<agetty> will launch the C<login> program
which is from C<shadow-utils>, and the C<ip> command will link against
C<libmnl> if available, but that's fine, I C<patch>ed them and regenerated
the iso, did extensive testing on it and became pretty confident that it's solid.

And with all these preparations done the rest was really easy and smooth, I
uploaded the iso file and booted the VPS, did disk partition first, formatted
the filesystems after that, and then installed the bootloader, finally tranferred
the root filesystem tarball using C<scp> and extracted it. I rebooted the
VPS and saw a login prompt as a indication of success, the installation is done!

=head1 PERFORMANCE

B<rs> is actually pretty efficient, all the serializations routines are
written in C<C>, the first C<diff> operation will probably take some
noticeable time if you're not using a SSD since all the metadata is not
yet cached, that's just like the first C<git status> command inside a
repository, but the succesives ones take negligible time. Also note that
the C<diff> operation is only needed on the machine that does the actual
compilation, which will usually be the most powerful one you can get your
hands on, if you only install pre-compiled packages on a machine that's
really just like extracting a tarball, performance is not an issue there.

=head1 CONTRIBUTING

Try it! Download the VM image and play around with it, share your thoughts,
make suggestions or reporting bugs. Spread the word around if you find it
good or useful.

At some later point you may want to have a look at the guts of B<rs>, try
to add a new functionality or fix an existing problem, I'll always be
glad to see a new quality pull request.

You can also contribute by hiring me or help getting me hired,
if you find me appropriate for a job, a stable living for the author
is surely inevitable for a healthy project.

Support me during the TPF granting process, it will find me the necessary
time and resource to work on C<App::rs> and make it better.

=head1 VM image

A VM image to be used with C<qemu> in raw format is released on
L<github|https://github.com/057a3dd61f99517a3afea0051a49cb27994f94d/rslinux/releases>
as a demostration of RSLinux, it contains all the neccessary packages
to build itself, as well as some basic utilities.

You should first decompress the image using C<xz -d>, then launch it via:

    # qemu-system-x86_64 -machine accel=kvm -hda vm.img -m 512M -net nic -net user,hostfwd=::2222-:2222

A C<sshd> will be running in the guest and you could login through it using
C<ssh -p 2222 user@localhost>, the password for root is C<rslinux>, there's
also a non-privileged user C<somebody> with the same password in case you
do not like wandering around with root. You could also forget about C<ssh>
all together and use the GUI of C<qemu> if you happen to like it.

For simplicity, I used a Perl one liner as the init system, it's a poor
man's init but it does the job, it starts twelve virtual consoles from
C<tty1> to C<tty12> but it doesn't restart them, so don't be confused
if you logged out but a new login prompt is not displayed, just restart
the VT mannually using C<setsid /sbin/agetty ttyX>. Feel free to change the
init system to whatever you like, the whole point of RSLinux is to go
for it instead of doing meaningless arguing with others.

The B<rs> profile is already properly written under the home of C<root>, it's
highly recommended to login as C<root> first, and have a look at how all the