view release on metacpan or  search on metacpan

bin/rs  view on Meta::CPAN

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
configuration files are chained together, and play around a little bit to
get familiar with B<rs>. There're two source tarballs, one of C<emacs> and
another of C<vim>, try compile your favorite editor using C<rs compile tarball>
and see how a package is generated using B<rs>. The C<rs> directory is the
git repository of B<rs>, and the B<pkg> directory contains the compiled
packages and database for the VM image. Happy hacking, and remember C<man rs>
is your friend.

You could also mount the image directly using:

    # mount -o offset=$((2048*512)) vm.img mountpoint

And then enter the mountpoint and use it without C<qemu>, by entering
I mean all the methods from C<unshare> to a full fledged container utility
and to a plain C<chroot>, pick the one you like best.

=head1 BUILDING

Just follow the usual idiom to build a Perl module:

    # perl Makefile.PL
    # make
    # make install

That will install B<rs> to your system directory and it's recommended since
you do not have to mess around with the PATH or PERL5LIB environment. You could
also install to a custom directory by using:

    # perl Makefile.PL INSTALL_BASE=/path/to/prefix

The executable will reside in the C<bin> direcory under prefix and the Perl
modules will be in C<lib/perl5>. Adjust your
PATH and PERL5LIB accordingly.

Note that since C<App::rs> is used to bootstrap both RSLinux and CPAN, it's
explicitly designed to have no dependency other than the core Perl modules.

=head1 CPAN

I recently extended C<App::rs> to be the first reference counting CPAN client,
by adding a reference counting database to connect each package together.

By default, modules will be installed into the C<CPAN> directory under
your home, and C<.rs> directory will be used to store metadata about those
installed modules. Compilation will happen under the current directory,
the build directory of individual module will be removed automatically,
but the downloaded source tarballs will be preserved since they may be
useful for futher reference. You could use C<App::rs> without any configuration,
but of course all these settings could be customized, if
you want to do customization reading the full mannual is highly suggested,
it will be worth your while.

The only thing you have to do is setting your C<PERL5LIB> environment to include
C<< <HOME>/CPAN/lib/perl5 >>,