Hello.
Recent articles on habré
First of all, I decided to download the Elbrus OS, or rather, only the available distribution kit for the x86_64 architecture, see how it works, and try to install Veeam Agent for Linux on it. Those who want to know what came of it, please under cat.
So, a small digression, otherwise suddenly someone does not know. "Elbrus" is
Another small forced retreat. The fact is that I once dealt with domestic software, such as "MSVS" and RTOS "Baguette". There was experience in working with the domestic element base, including the processor from the MCST. Therefore, with all responsibility I can say that there is a certain specificity in this area, and I will try not to touch on it in the article. When I really really want to, I will put the [TBD] tag. So we will try to do without outright trolling and banal moans. In the end, the Russian defense industry and government agencies need to be understood. Big country, small budget. [TBD].
Zero stage - download. It is noteworthy that the news that the Elbrus OS became available caused a resonance, so much so that the distribution server lay down. [TBD] Thanks to Yandex and the engineer who thought of moving it there. So the download speed pleases.
The first stage - installation. I put on the first hypervisor that came free for free use. I allocated two cores, a couple of gigs of RAM, 32 MB for video (there will be a graphical interface, I thought). Disochek as usual - 32 GB.
Started the installation. I did not use the installation instructions, so I can not comment on it. The TUI installation interface is severely minimalistic.
Well, great, without a mouse, then we can do it.
With the next window, I coped with the second attempt. Why not choose sr0 [TBD] as the default device when installing from disk?
Select the CD-ROM source and move on.
When choosing a time zone, I suddenly realized that the system was using the init boot process and I was working from TTY0.
OK, then we will attribute Elbrus to the community
The rest is almost unimportant: we put everything and agree. Along the way, we learn that the kernel is used 3.14.79-13.84. Hmm, Debian 7 had 3.2 [TBD].
Next, select the default partitioning of the disk and ... We see a warning:
Hmm, somehow the automatic partitioning coped with a 32 gig disk poorly. I did not change the disk, I passed the quest with manual disk marking in the all-in-one style. I had to install ext3, since /boot could not be in ext4.
The system got up without incident.
The second stage - search for alternatives.
Having rummaged with the contents of the second disk, I realized that this is a repository with additional. packages. And looking at /etc/apt/sources.list, I realized that it needs to be mounted in /mnt/cdrom. But I did not find /etc/os-release. But there is /etc/mcst-version with contents 3.0-rc36. 3.0 is probably the version - it seems to converge, but rc36? In general, third-party software most likely will not be able to recognize this distribution in the classical way.
In the root section, the /mcst directory catches the eye, and there, with bated breath, I discovered /mcst/backup. That is, there is a backup tool, and it is built into the system! “Great,” I thought, “Let’s see how it works!”
It turned out that there is a 4Kb bash script /mcst/bin/backup that provides file copying. By default, to the /mcst/backup directory. In the source, I expected to see the rsync command, but in the default configuration it is not. The script simply copies the files. The command looks something like this:
cp -rpdx <file backup> <file>
The entire /mcst/bin/backup file is hereI immediately warn you that this script alone is not enough for a complete understanding. It pulls functions from /mcst/bin/source which is some kind of function library. I did not bring it (44KB).
#!/bin/bash
unalias -a
set +vx
source $(dirname $0)/source
[[ $? != 0 ]] && exit 1
OPTIONS="hvcdrRil:L:"
usage()
{
echo "Usage: $PROG_NAME [-$OPTIONS] [backup]"
echo " h - this help"
echo " v vv vvv - verbose, very verbose, extremly verbose"
echo " c - create backup"
echo " d - diffs backup and system"
echo " r - recovery system"
echo " R - remove backup"
echo " i - prompt before backup removing"
echo " l list - additional backup files list"
echo " L list - global backup files list"
echo " backup - backup directory, default /mcst/backup/backup"
}
init_prog()
{
typeset flg=0
while getopts $OPTIONS opt
do
case $opt in
h ) usage; exit 0;;
v ) (( verbose = verbose + 1 )); set_verbose;;
c ) flg=1; c_flg=1;;
d ) flg=1; d_flg=1;;
r ) flg=1; r_flg=1;;
R ) flg=1; R_flg=1;;
i ) i_flg=1;;
l ) l_flg=1; list_arg="$list_arg $OPTARG";;
L ) L_flg=1; LIST_arg="$LIST_arg $OPTARG";;
* ) usage "Invalid option"; exit 1;;
esac
done
set_verbose
check_su
init_variables
shift $((OPTIND-1))
if (( $# > 1 ))
then
echo_fatal "invalid arguments number, exp 0|1, act $#"
exit 1
fi
[[ $# = 1 ]] && BACKUP=$1
echo "Backup directory is $BACKUP"
if [[ $L_flg = 1 ]]
then
backup_list="$LIST_arg"
elif [[ $c_flg != 1 && $R_flg != 1 ]]
then
get_output_cmd "cat $BACKUP/$BACKUP_LIST_NAME"
backup_list="$output_cmd"
else
get_output_cmd "get_backup_list"
backup_list="$output_cmd"
fi
if [[ $l_flg = 1 ]]
then
backup_list="$backup_list $list_arg"
fi
if [[ $flg = 0 ]]
then
if [[ -d $BACKUP ]]
then
ls -laR $BACKUP
else
echo_info "Cannot access $BACKUP"
fi
echo "backup_list=$backup_list"
exit 0
fi
### echo "Backup list: $backup_list"
}
create_file()
{
typeset f=$1 fr=$2
typeset fb
[[ -z $fr ]] && fr=$f
fb=${f#/}
fb=$BACKUP/$fb
xcmd="rm -rf $fb"
set_cmd "$xcmd"
run_cmd
xcmd="mkdir -p $fb"
set_cmd "$xcmd"
run_cmd
if [[ -a $fr ]]
then
xcmd="cp -rpdx $fr $fb/file"
set_cmd "$xcmd"
run_cmd
xcmd="touch $fb/create"
set_cmd "$xcmd"
run_cmd
else
xcmd="touch $fb/delete"
set_cmd "$xcmd"
run_cmd
fi
}
diff_file()
{
typeset f=$1
typeset fb
fb=${f#/}
fb=$BACKUP/$fb
if [[ -f $fb/delete ]]
then
echo_info "$f absent"
elif [[ -f $fb/create ]]
then
# echo "state: create $f"
if [[ ! -a $f ]]
then
echo_info "cannot access $f"
else
xcmd="diff -r $f $fb/file"
echo "$xcmd"
set_cmd "$xcmd" "" "0 1 2"
run_cmd
fi
else
echo_fatal "wrong $f backup"
exit 1
fi
}
recovery_file()
{
typeset f=$1
typeset fb
fb=${f#/}
fb=$BACKUP/$fb
if [[ ! -a $fb ]]
then
echo_fatal "cannot access $fb"
exit 1
fi
xcmd="rm -rf $f"
set_cmd "$xcmd"
run_cmd
if [[ -f $fb/delete ]]
then
:
elif [[ -f $fb/create ]]
then
xcmd="cp -rpdx $fb/file $f"
set_cmd "$xcmd"
run_cmd
else
echo_fatal "wrong $fb backup"
exit 1
fi
}
remove_backup()
{
echo "Remove backup"
if [[ ! -d $BACKUP ]]
then
echo_info "Cannot access $BACKUP"
return
fi
if [[ ! -f $BACKUP/$BACKUP_LIST_NAME ]]
then
echo_fatal "$BACKUP_LIST_NAME absent, remove backup manually"
exit 0
fi
answer=
if [[ $i_flg = 1 ]]
then
echo -n "Remove $BACKUP directory (yes/...)?"
read answer
else
answer=yes
fi
if [[ $answer = yes ]]
then
xcmd="rm -rf $BACKUP"
set_cmd "$xcmd"
run_cmd
fi
}
recovery_backup()
{
echo "Recovery system from $BACKUP"
for f in $backup_list
do
get_output_cmd "get_mount_point $f"
mnt=$output_cmd
get_output_cmd "is_ro_mounted $mnt"
mnt=$output_cmd
if [[ ! -z $mnt ]]
then
remount_rw_fs $mnt
fi
recovery_file $f
if [[ ! -z $mnt ]]
then
remount_ro_fs $mnt
fi
done
echo "The system is ready, reboot the system manually"
}
create_backup()
{
echo "Create backup"
xcmd="mkdir -pm0777 $BACKUP"
set_cmd "$xcmd"
run_cmd
for v in $backup_list
do
f=${v%%:*}
backup_list2="$backup_list2 $f"
fr=${v#*:}
create_file $f $fr
done
echo "$backup_list2" >$BACKUP/$BACKUP_LIST_NAME
}
diff_backup()
{
echo "Diffs system and backup"
if [[ ! -d $BACKUP ]]
then
echo_fatal "cannot access $BACKUP"
exit 1
fi
for f in $backup_list
do
diff_file $f
done
}
main()
{
typeset f mnt mnt_list answer
if [[ $R_flg = 1 ]]
then
remove_backup
fi
if [[ $r_flg = 1 ]]
then
recovery_backup
fi
if [[ $c_flg = 1 ]]
then
create_backup
fi
if [[ $d_flg = 1 ]]
then
diff_backup
fi
}
init_prog "$@"
main
exit 0
But maybe I don't understand something? Maybe someone in the comments can explain: how does this script provide safe and reliable data backup? [TBD]
rsync, by the way, is in add. repositories. Version 3.1.3. I think using rsync is still the best alternative to the /mcst/bin/backup application.
Next, I decided to put a fresh Veeam Agent for Linux. Someone will ask: “What does Veeam and import substitution have to do with it?” Yes, it is not in the registry, but it is certified by the FSTEC, which means that if there are no alternatives, it can be used. After spending fifteen minutes on alternatives from
Stage three - installation of Veeam Agent for Linux.
So, Veeam Agent for Linux consists of two packages: the veeamsnap kernel module (by the way,
There was one small problem with installing the kernel module - the lack of a dkms package. This is a service that allows you to build kernel modules from source. As a rule, it is on all deb distributions. I had to download it from a third-party deb repository. One pleased - the package does not depend on the architecture, so I got up like a native. Why was it not included in the list of available packages, or rather, [TBD] was not developed? Perhaps it is intended that no one should build and run any non-MCST kernel modules. There really is a hitch here - since there are linux-headers. That is, the module, if desired, can be assembled by hand and run at the start of the machine with a script. I don't think you should expect frequent updates from MCST [TBD].
“OK, the module is up – the hardest part is over,” I thought… The veeam package for the deb repository is available for the amd64 platform, while the Elbrus OS has the x86_64 [TBD] platform. The difference, of course, is only in the name, but this difference makes almost all packages from third-party deb repositories incompatible with the Elbrus OS. This unfortunate misunderstanding is eliminated in an elementary way: it is enough to disassemble the package, correct the information about the architecture and assemble it back. How to do it
mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb
Another problem is dependencies. The necessary files seem to be there, but there are no packages. I got the impression that the names of the packages are different from "import analogues". Perhaps the libraries are packaged differently. I did not go into details, removed almost all dependencies, and the installation went.
Next, problems with the service start code surfaced. The /lib/init/vars.sh script was missing. For some reason, Elbrus does without it, so we will also remove it. Next, I had to replace the message output function: there were no log_daemon_msg and log_end_msg functions. Digging through the /lib/lsb/init-functions file, I found the log_success_msg function - it will do for us for experiments. By the way, in the /lib/lsb/init-functions file, the line "# Source SuSE`s rc functions" at the beginning of the [TBD] file.
After such a rough processing of the package with a file, the entire-machine backup on the NFS-share successfully started. Mount backup was also successful. So, I believe, for backing up a machine with the Elbrus PDK, downloaded for "just like that" without any obligations, Veeam Agent for Linux will definitely fit. Even after all the file modifications.
Of course, the Elbrus OS distribution kit is not formally supported, since it is not included in the list of supported ones. In addition, Veeam Agent for Linux on it was not tested by the QA department, so those. there is no support (at least at the time of publication of the article).
I hope the article will be useful to those who are trying to implement order No. 334 of 29.06.2017/XNUMX/XNUMX. Mine to you… [TBD].
Source: habr.com