Linux-ის სარეზერვო ასლი Veeam-ისგან Elbrus OS-ზე. იმპორტის ჩანაცვლება ['?' | '.' | '!']

გაუმარჯოს ყველას.
ბოლო სტატიები ჰაბრეზე იმპორტის ჩანაცვლება პრაქტიკაში. ნაწილი 1. ვარიანტები и მუსიკა დიდხანს არ უკრავდა... ან როგორ Elbrus OS არასოდეს გახდა თავისუფალი გულგრილი არ დამტოვა. გადავწყვიტე შემესწავლა ეს საკითხი სარეზერვო ამოცანის კონტექსტში. უფრო მეტიც, ში ეს მუხლი Veeam Software-ის პროდუქტები ნახსენებია, რაც ნიშნავს, რომ საკითხი შეიძლება იყოს აქტუალური კონკრეტულად იმპორტის ჩანაცვლების კონტექსტში.

ორიგინალური გამოსახულების წყარო

უპირველეს ყოვლისა, გადავწყვიტე გადმოვწერო Elbrus OS, უფრო სწორად, მხოლოდ ხელმისაწვდომი დისტრიბუცია x86_64 არქიტექტურისთვის, ვნახოთ როგორ მუშაობს და ვეცადე მასზე დავაინსტალირო Veeam Agent for Linux. თუ გსურთ გაიგოთ, რა გამოვიდა აქედან, ნახეთ კატა.

ასე რომ, მცირე გადახვევა, თუ ვინმემ არ იცის. „ელბრუსი“ ასეთია პროცესორი საკმაოდ სპეციფიკური ბრძანების სისტემით. გარდა ამისა, არსებობს Elbrus OS პროგრამული უზრუნველყოფა. და - პოპულარული რწმენის საწინააღმდეგოდ - Elbrus OS-ის ფუნქციონირებისთვის, არ არის საჭირო ელბრუსის პროცესორზე დაფუძნებული ტექნიკის სისტემა. არსებობს "PDK "Elbrus" x86-ისთვის - ფაქტობრივად, ის საჯარო დომენში გამოჩნდა ინსტალაციის დისკის სახით. სხვათა შორის, არის სქოლიო "PDK - პლატფორმის განვითარების ნაკრები, დეველოპერის ნაკრები" - შესანიშნავი, ეს ნიშნავს, რომ იქ არის მინიმუმ შემდგენელი.

კიდევ ერთი მცირე იძულებითი უკანდახევა. ფაქტია, რომ ოდესღაც საქმე მქონდა შიდა პროგრამულ უზრუნველყოფასთან, როგორიცაა MSVS და Baguette RTOS. მე მქონდა შიდა კომპონენტებთან მუშაობის გამოცდილება, მათ შორის MCST-ის პროცესორი. ამიტომ, სრული პასუხისმგებლობით შემიძლია ვთქვა, რომ ამ სფეროში არის გარკვეული სპეციფიკა და ვეცდები სტატიაში არ შევეხო მას. როცა ძალიან მომინდება, დავდებ ტეგს [TBD]. ამიტომ ვეცდებით პირდაპირ ტროლინგისა და ბანალური წუწუნის გარეშე. საბოლოო ჯამში, რუსული თავდაცვის ინდუსტრია და სამთავრობო უწყებები უნდა გავიგოთ. დიდი ქვეყანა - მცირე ბიუჯეტი.. [TBD].

ნულოვანი ეტაპი - ჩამოტვირთვა. აღსანიშნავია, რომ ინფორმაცია იმის შესახებ, რომ Elbrus OS ხელმისაწვდომი გახდა, რეზონანსი გამოიწვია, იმდენად, რომ სადისტრიბუციო სერვერი დაიშალა. [TBD] მადლობა Yandex-ს და ინჟინერს, რომელმაც გადაწყვიტა მისი გადატანა იქ. ასე რომ, ჩამოტვირთვის სიჩქარე კარგია.

პირველ ეტაპზე - ინსტალაცია. მე დავაინსტალირე ის პირველ ჰიპერვიზორზე, რომელიც ხელმისაწვდომი იყო უფასო გამოყენებისთვის. ორი ბირთვი გამოვყავი, ორიოდე გიგა ოპერატიული მეხსიერება, 32 მბ ვიდეოსთვის (გრაფიკული ინტერფეისი იქნება მეგონა). დისკი ჩვეულებრივია - 32 GB.
დავიწყე ინსტალაცია. მე არ გამომიყენებია ინსტალაციის ინსტრუქციები, ამიტომ კომენტარს ვერ გავაკეთებ. TUI ინსტალაციის ინტერფეისი მკაცრად მინიმალისტურია.

კარგი, ჩვენ შეგვიძლია მაუსის გარეშე.

მე მოვახერხე შემდეგი ფანჯარა მეორე ცდაზე. რატომ არ აირჩიეთ ნაგულისხმევი მოწყობილობა sr0 [TBD] დისკიდან ინსტალაციისას?
აირჩიეთ CD-ROM წყარო და გადადით.

დროის ზონის არჩევისას, უცებ მივხვდი, რომ სისტემა იყენებს init boot პროცესს და მე ვმუშაობ TTY0-დან.

კარგი, მაშინ მოდით დავახარისხოთ "ელბრუსი", როგორც საზოგადოება ძველი მორწმუნეები[TBD]. პრინციპში, ეს კარგია: თქვენ არ გჭირდებათ წყაროს კოდის მოთხოვნა, რომ ნახოთ როგორ მუშაობს ჩამოტვირთვის პროცესი, რადგან ყველაფერი დაწერილია.

დანარჩენი თითქმის არ არის მნიშვნელოვანი: ჩვენ ყველაფერს ვდებთ და ვეთანხმებით. გზაში აღმოვაჩენთ, რომ ბირთვი გამოიყენება 3.14.79-13.84. ჰმ, Debian 7-ს ჰქონდა 3.2 [TBD].

შემდეგი, აირჩიეთ დისკის ნაგულისხმევი დანაყოფი და... ჩვენ ვხედავთ გაფრთხილებას:

ჰმ, რატომღაც ავტომატური დანაყოფი კარგად ვერ უმკლავდება 32 გიგა დისკს. მე არ შევცვალე დისკი, დავასრულე დისკის ხელით დაყოფა „all-in-one“ სტილში. მომიწია ext3-ის დაყენება, რადგან /boot არ შეიძლებოდა ყოფილიყო ext4-ში.
სისტემა ამოქმედდა ინციდენტის გარეშე.

მეორე ეტაპი - მოძებნეთ ალტერნატივები.
მეორე დისკის შიგთავსის დათვალიერების შემდეგ მივხვდი, რომ ეს არის დამატებითი საცავი. პაკეტებში. და შევხედე /etc/apt/sources.list, მივხვდი, რომ ის უნდა დამონტაჟდეს /mnt/cdrom-ში. მაგრამ მე ვერ ვიპოვე /etc/os-release. მაგრამ არსებობს /etc/mcst-ვერსია შიგთავსით 3.0-rc36. 3.0 არის ალბათ ვერსია - როგორც ჩანს ჯდება, მაგრამ rc36? ზოგადად, მესამე მხარის პროგრამული უზრუნველყოფა, სავარაუდოდ, ვერ შეძლებს ამ განაწილების ამოცნობას კლასიკური გზით.

root დანაყოფში, /mcst დირექტორია იპყრობს ჩემს თვალს და იქ, ჩაძირული გულით, აღმოვაჩინე /mcst/backup. ანუ, არის სარეზერვო ინსტრუმენტი და ის ჩაშენებულია სისტემაში! "მშვენიერია," გავიფიქრე მე, "ვნახოთ, როგორ მუშაობს ეს!"

აღმოჩნდა, რომ არსებობს 4Kb bash სკრიპტი /mcst/bin/backup, რომელიც უზრუნველყოფს ფაილის კოპირებას. ნაგულისხმევად - /mcst/სარეზერვო დირექტორიაში. წყაროს კოდში ველოდი, რომ დავინახე rsync ბრძანება, მაგრამ ის არ არის ნაგულისხმევ კონფიგურაციაში. სკრიპტი უბრალოდ აკოპირებს ფაილებს. ბრძანება ასე გამოიყურება:

cp -rpdx <file backup> <file>

მთელი ფაილი /mcst/bin/backup არის აქმაშინვე გაფრთხილებ, რომ მხოლოდ ეს სკრიპტი არ არის საკმარისი ბოლომდე გასაგებად. ის ამოიღებს ფუნქციებს /mcst/bin/source-დან, რაც არის ფუნქციების ბიბლიოთეკის მსგავსი. მე არ ჩავურთე (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

თუმცა, იქნებ რაღაც ვერ გავიგე? იქნებ ვინმემ ახსნას კომენტარებში: როგორ უზრუნველყოფს ეს სკრიპტი მონაცემთა უსაფრთხო და საიმედო სარეზერვო ასლს? [TBD]

rsync, სხვათა შორის, შედის დანამატში. საცავები. ვერსია 3.1.3. ვფიქრობ, rsync-ის გამოყენება მაინც უკეთესი ალტერნატივაა /mcst/bin/backup აპლიკაციისთვის.

შემდეგ გადავწყვიტე ახალი დამეყენებინა Veeam აგენტი Linux-ისთვის. ვიღაც იკითხავს: "რა შუაშია Veeam და იმპორტის ჩანაცვლება?" დიახ, ის არ არის რეესტრში, მაგრამ ის დამოწმებულია FSTEC-ის მიერ, რაც ნიშნავს, რომ ალტერნატივის არარსებობის შემთხვევაში მისი გამოყენება შესაძლებელია. თხუთმეტი წუთის დახარჯვა ალტერნატივებზე რეესტრი, მე შევძელი 3 ბმული ვიპოვო სიტყვა „სარეზერვო“-სთვის (არცერთი არ არის დაკავშირებული ჩემს შეკითხვასთან სიტყვა „რეზერვთან“). მე არ გამიკეთებია ამ პროგრამების ღრმა ანალიზი, ამიტომ არ შევეცდები ვიმსჯელო, რამდენად შესაფერისია ისინი Linux-ზე მომუშავე მანქანების სარეზერვო ასლისთვის. ვისაც ეს სჭირდება, დასკვნას თავად გამოიტანს და კომენტარებში გააზიარებს.

მესამე ეტაპი - Veeam Agent-ის ინსტალაცია Linux-ისთვის.
ასე რომ, Veeam Agent for Linux შედგება ორი პაკეტისგან: veeamsnap ბირთვის მოდული (სხვათა შორის, წყარო აქ) და საკუთრებაში არსებული მომხმარებლის სივრცის კოდი veeam პაკეტის სახით.

იყო ერთი პატარა პრობლემა ბირთვის მოდულის დაყენებისას - დაკარგული dkms პაკეტი. ეს არის სერვისი, რომელიც საშუალებას გაძლევთ შექმნათ ბირთვის მოდულები წყაროდან. როგორც წესი, ის ხელმისაწვდომია ყველა deb დისტრიბუციაზე. მე მომიწია მისი ჩამოტვირთვა მესამე მხარის დებ საცავიდან. ერთი რამ, რაც გამახარა, არის ის, რომ პაკეტი არ არის დამოკიდებული არქიტექტურაზე, ამიტომ ის ჯდება როგორც მშობლიური. რატომ არ იყო ის ხელმისაწვდომი პაკეტების სიაში, უფრო სწორად, არ იყო განვითარებული [TBD]? შესაძლოა, ვივარაუდოთ, რომ არავინ უნდა ააშენოს და გაუშვას MCST ბირთვის მოდული. აქ ნამდვილად არის შეუსაბამობა - რადგან არის ლინუქსის სათაურები. ანუ, მოდული, სურვილის შემთხვევაში, შეიძლება ხელით შეიკრიბოს და სკრიპტით გაშვება, როდესაც მანქანა მუშაობს. ვფიქრობ, არ უნდა ელოდოთ ხშირ განახლებებს MCST [TBD]-ისგან.

„კარგი, მოდული დაინსტალირებულია - ურთულესი ნაწილი დასრულდა“, გავიფიქრე... deb საცავისთვის veeam პაკეტი არის amd64 პლატფორმისთვის, ხოლო Elbrus OS-ს აქვს x86_64 [TBD] პლატფორმა. განსხვავება, რა თქმა უნდა, მხოლოდ სახელშია, მაგრამ ეს განსხვავება მესამე მხარის დებ საცავებიდან თითქმის ყველა პაკეტს შეუთავსებელს ხდის Elbrus OS-თან. ეს შემაშფოთებელი გაუგებრობა შეიძლება აღმოიფხვრას უბრალოდ: უბრალოდ დაშალეთ პაკეტი, შეასწორეთ ინფორმაცია არქიტექტურის შესახებ და დააბრუნეთ იგი. Როგორ გავაკეთო ეს დაგუგლდა მყისიერად.

mkdir tmp
dpkg-deb -R original.deb tmp
# edit DEBIAN/postinst
dpkg-deb -b tmp fixed.deb

კიდევ ერთი პრობლემა არის დამოკიდებულებები. როგორც ჩანს, საჭირო ფაილები არსებობს, მაგრამ პაკეტები არ არის. ისეთი შთაბეჭდილება იყო, რომ პაკეტების სახელები განსხვავდებოდა მათი „იმპორტირებული ანალოგებისგან“. შესაძლოა, ბიბლიოთეკები სხვაგვარადაა შეფუთული. მე არ ჩავუღრმავდი ზედმეტ დეტალებს, მოვხსენი თითქმის ყველა დამოკიდებულება და ინსტალაცია გაგრძელდა.

შემდეგ პრობლემები გაჩნდა სერვისის დაწყების კოდთან დაკავშირებით. სკრიპტი /lib/init/vars.sh აკლდა. რატომღაც, ელბრუსი ახერხებს მის გარეშე, ამიტომ ჩვენ მასაც ამოვიღებთ. შემდეგი, ჩვენ უნდა შევცვალოთ შეტყობინების გამომავალი ფუნქცია: log_daemon_msg და log_end_msg ფუნქციები არ იყო დაკარგული. /lib/lsb/init-functions ფაილში დათვალიერების შემდეგ ვიპოვე log_success_msg ფუნქცია - ეს კარგი იქნება ჩვენთვის ექსპერიმენტებისთვის. სხვათა შორის, /lib/lsb/init-functions ფაილში ხაზი „# Source SuSE`s rc functions“ არის [TBD] ფაილის დასაწყისში.

პაკეტის ფაილით ასეთი უხეში დამუშავების შემდეგ, NFS წილზე მთელი მანქანური სარეზერვო ასლი წარმატებით დაიწყო. სარეზერვო სამონტაჟო ასევე წარმატებული იყო. ასე რომ, მე მჯერა, რომ Elbrus PDK-ით ჩამოტვირთული აპარატის სარეზერვო ასლისთვის, რომელიც გადმოწერილია „ასევე“ ყოველგვარი ვალდებულებების გარეშე, Veeam Agent Linux-ისთვის ნამდვილად შესაფერისია. ფაილის ყველა ცვლილების შემდეგაც კი.

რა თქმა უნდა, Elbrus OS დისტრიბუციის ნაკრები ოფიციალურად არ არის მხარდაჭერილი, რადგან ის არ შედის მხარდაჭერილთა სიაში. გარდა ამისა, Linux-ისთვის Veeam აგენტი არ იყო ტესტირება მასზე QA დეპარტამენტის მიერ, ამიტომ ისინი. არ არსებობს მხარდაჭერა (ყოველ შემთხვევაში, სტატიის გამოქვეყნების დროს).

იმედი მაქვს, სტატია გამოადგება მათ, ვინც ცდილობს 334 წლის 29.06.2017 ივნისის NoXNUMX ბრძანების შესრულებას. ჩემი შენთვის... [TBD].

წყარო: www.habr.com