Кратко подытожим проделанную работу.
Мы импортировали содержимое установочного диска, в результате чего мы получили два distro и два профиля (для обычных и для виртуальных машин).
Кроме этого, мы создали несколько репозиториев, в том числе репозиторий с обновлениями и репозиторий с «установочным деревом».
Также мы рассмотрели шаблоны кикстарт-файлов и кратко ознакомились с возможностями по приданию им необходимой гибкости.
Теперь мы имеем все необходимое для того чтобы создавать собственные варианты установки. Чем и займемся. :)
Нет ничего лучше, чем реальные примеры из жизни! Мое знакомство с cobbler'ом началось на почве установки клиентам моего продукта ОфисМастер. Мне нужно было иметь возможность быстро устанавливать нужную версию, используя одну из поддерживаемых платформ. Изначально было две базовые системы, на которые устанавливался ОфисМастер — Fedora Core 6 и CentOS. Позднее к ним добавился еще и Scientific Linux и НауЛинукс.
Причем, cobbler обеспечил абсолютно безболезненную работу со всеми этими дистрибутивами. Также нужно иметь ввиду, что ОфисМастер может устанавливаться как на платформу i386, так и на x86_64, а это означает удваивание количества сборок, которые нужно делать, чтобы внедрять решение на платформе заказчика. Ручная работа в таком случае просто превращается в ад.
Поскольку на сцену вышел ОфисМастер, то я должен добавить к уже обозначенным репозиториям (updates и установочный) еще и репозиторий ОфисМастера.
Меньше слов, больше дела...
Смотрим кикстарт-файл:
keyboard ru
lang ru_RU
poweroff
rootpw --iscrypted password_was_here
selinux --disabled
skipx
timezone --utc Asia/Novosibirsk
install
zerombr
url --url=$tree$yum_repo_stanzaSNIPPET::OM_partitioning$kickstart_start
%packages SNIPPET::OM_packages
%post /sbin/chkconfig --level 345 bluetooth off /sbin/chkconfig --level 345 cpuspeed off /sbin/chkconfig --level 345 hidd off /sbin/chkconfig --level 345 ip6tables off /sbin/chkconfig --level 345 netfs off /sbin/chkconfig --level 345 nfslock off /sbin/chkconfig --level 345 pcscd off /sbin/chkconfig --level 345 portmap off /sbin/chkconfig --level 345 rpcgssd off /sbin/chkconfig --level 345 rpcidmapd off
$yum_config_stanza SNIPPET::OM_rescue_boot $kickstart_done
До первой пустой строки используются обычные опции раздела команд, пояснять которые я не буду, они и так понятны.
В опции url мы видим переменную tree, которую укажем в профиле cobbler'а. Его будем создавать чуть позже.
Далее мы видим уже обсуждавшиеся stanza и snippet'ы, которые рассмотрим подробнее.
Буквально мимоходом отмечу, что набор команд chkconfig просто отключает все ненужные службы.
Итак, наши snippet'ы.
[root@cobbler snippets]# cat /var/lib/cobbler/snippets/OM_partitionin
%include /tmp/partinfo %pre # Determine how many drives we have set \$(list-harddrives)
let numd=\$#/2 d1=\$1 d2=\$3
cat << EOF > /tmp/partinfo
part /boot --size=100 --fstype ext3 --ondisk=\$d1 part pv.1 --size=0 --grow --ondisk=\$d1 volgroup VG01 --pesize=32768 pv.1 logvol swap --fstype swap --name=SWAP --vgname=VG01 --size=512 logvol /opt --fstype ext3 --name=OPT --vgname=VG01 --size=128 logvol / --fstype ext3 --name=ROOT --vgname=VG01 --size=1024 --grow --maxsize=2048 logvol /rescue --fstype ext3 --name=RESCUE --vgname=VG01 --size=1024 --grow --maxsize=2048 logvol /home --fstype ext3 --name=HOME --vgname=VG01 --size=256 --grow --maxsize=1024 logvol /var --fstype ext3 --name=VAR --vgname=VG01 --size=1024 --grow
Здесь мы наблюдаем весьма стандартное разбиение. Отклонение можно заметить лишь в том, что создается раздел /rescue. Сюда мы установим еще одну(!) систему.
Для чего? это будет система, загрузившись в которую мы сможет выполнить необходимые манипуляции с основной системой. Такие, например, как изменение размера разделов (включая /root. что не получится выполнить из основной системы «на горячую»), исправление конфигурации и т.д.
[root@cobbler snippets]# cat /var/lib/cobbler/snippets/OM_packages
@russian-support @system-tools cryptsetup-luks mc bind dhcp openldap-servers postgresql-server postgresql-pl postgresql-libs postgresqlphp-ldap php-pdo php-mbstring php-pear php-pgsql php-cli php-gd samba sendmail-cf dovecot squirrelmail mod_ssl mod_authz_ldap cracklib-dicts officemaster-release OfficeMaster OfficeMaster-doc
Здесь мы указываем инсталлятору, какие приложения (и группы приложени; они указаны с использованием @) необходимо установить на нашей системе. Вполне очевидно, что в дистрибутиве CentOS некоторых из этих пакетов нет, поэтому впрофиле мы должны указать репозитории, которые эти пакеты содержат, а также те репозитории, которые содержат пакеты, которые необходимо установить для удовлетворения зависимостей.
Это мы также сделаем при создании профиля установки.
[root@cobbler snippets]# cat /var/lib/cobbler/snippets/OM_rescue_boot
yum --installroot=/rescue -y --disablerepo=\* --enablerepo=centos-5\* groupinstall "System Tools"
grubby --info=DEFAULT|sed -e 's/ROOT/RESCUE/; s/\/boot//'>/tmp/grubby
. /tmp/grubby
grubby --add-kernel="12345678\$kernel" --title="Rescue system" --initrd="12345678\$initrd" --args="\$args root=\$root 1" --boot-filesystem="\$boot"
mkdir -p /rescue/mnt/system mkdir -p /rescue/mnt/system/home mkdir -p /rescue/mnt/system/var mkdir -p /rescue/mnt/system/opt
cat << _EOF >/rescue/etc/fstab
/dev/VG01/RESCUE / ext3 defaults 1 1 /dev/VG01/ROOT /mnt/system ext3 defaults 1 2 /dev/VG01/HOME /mnt/system/home ext3 defaults 1 2 /dev/VG01/VAR /mnt/system/var ext3 defaults 1 2 /dev/VG01/OPT /mnt/system/opt ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VG01/SWAP swap swap defaults 0 0
_EOF
Безусловно, скрипты секции %post кикстарт-файлов представляют наибольший интерес, поскольку здесь мы уже имеем установленную систему и уже начинаем ее «обживать».
Приведенный скрипт выполняет установку еще одной системы, корнем для которой является раздел примонтированных к /rescue, на что указывает параметр —installroot yum'а.
Необходимо учитывать, что на данной фазе установке мы уже имеем весьма «богатую» среду — у нас есть сеть (возможно, без службы имен, если мы описывали статическую конфигурацию сети), мы имеем все необходимые приложения и т.д. В том числе мы имеем конфигурацию репозиториев yum'а, а некоторые из стандартно устанавливаемых репозиториев указывают на внешние ресрусы. В данный момент он нам не нужны, использование их приведет к значительному увеличению времени установки, да и все необходимое у нас имеется в нашей сети. Именно поэтому опции «--disablerepo=\* --enablerepo=centos-5\*» отключают все репозитории и включают только необходимые (так «совпало», что все нужные репозитории начинаются одинаково ;) ). Все необходмое для нас находится в группе пакетов «System Tools», поэтому мы ее и устанавливаем.
Одной командой, таким образом, мы получили еще одну систему.
Теперь нам нужно включить ее в конфигурацию загрузчика.
Здесь нам помогает утилита grubby, которая специально создана для манипуляции с записями о вариантах загрузки в grub.conf.
Нужна нам конфигурация отличается от существующей только корнем файловой системы, который должен быть использован при загрузке. Поэтому мы получаем текущую конфигурацию и делаем замену имени корневого раздела с помощью sed'а. Также мы «обрезаем» строку /boot в путях к файлам ядра и initrd, потому что grub все пути рассматривает относительно корня загрузочного раздела, который у нас примонтирован в /boot.
Эта конфигурация, пропущенная через наш фильтр синтаксически представляет из себя корректный shell-скрипт, поэтому мы просто импортируем его в текущее окружение, создавая тем самым нужные нам переменные.
Этипеременные мы используем в следущем вызове grubby, который и создает еще одну запись загрузки.
Далее мы создаем точки монтирования, куда будут примонтированы рабочие разделы, когда мы загрузимся в нашу спасательную систему.
А для того, чтобы это монтирование состоялось мы формируем соответствующий фйл /etc/fstab.
На этом рассмотрение кикстарт-файла мы закончили.
Все, что нам осталось сделать для быстрой интсалляции новой системы, это создать профиль cobbler'а, в котором определить переменную tree и указать необходимые нам репозитории.
Это делается одной командой, но в моем случае создается сразу два профиля для разных архитектур, поэтому я сделал небольшой скрипт:
[root@cobbler cobbler]# cat ./om-profile
#!/bin/bash
op="add" #op="edit"
for arch in i386 x86_64 ; do
cobbler profile $op \
--name=OfficeMaster-1.3-$arch \
--distro=CentOS5.2-$arch \
--kickstart=/etc/cobbler/officemaster.ks \
--ksmeta="tree=http://192.168.90.249/cob --repos="centos-5-$arch-base centos-5-$arch-om centos-5-$arch-updates" done
Как несложно заметить, каждому профилю мы «даем» дополнительно к инсталляционному дереву еще три репозитория. Причем, в данном случае репозиторий centos-5-$arch-base ссылается на установочное дерево нашей установки! Это позволяет, я уже говорил об этом, (при yum_post_install_mirror=1 в /etc/cobbler/settings) на установленной системе получить настройку на данный ресурс, что избавит нас от дополнительной ручной работы с репозиторями.
Указание в профиле репозитория centos-5-$arch-updates позволяет сразу же во время установки системы использовать самые последние версии пакетов. Разве это не здорово? ;)
После создания профилей мы можем их увидеть:
# cobbler profile report
profile : OfficeMaster-1.3-i386 distro : CentOS5.2-i386 dhcp tag : default kernel options : {} post kernel options : {} kickstart : /etc/cobbler/officemaster.ks ks metadata : {'tree': 'http://192.168.90.249/cobbler/ks_mirror/Cowners : ['admin'] repos : ['centos-5-i386-base', 'centos-5-i386-om', 'centos-5-i386-updates'] server : <<inherit>> virt bridge : xenbr0 virt cpus : 1 virt file size : 5 virt path : virt ram : 512 virt type : xenpv
profile : OfficeMaster-1.3-x86_64 distro : CentOS5.2-x86_64 dhcp tag : default kernel options : {} post kernel options : {} kickstart : /etc/cobbler/officemaster.ks ks metadata : {'tree': 'http://192.168.90.249/cobbler/ks_mirror/Cowners : ['admin'] repos : ['centos-5-x86_64-base', 'centos-5-x86_64-om', 'centos-5-x86_64-updates'] server : <<inherit>> virt bridge : xenbr0 virt cpus : 1 virt file size : 5 virt path : virt ram : 512 virt type : xenpv
Теперь, при загрузке из сети по PXE мы получим примерно следующее меню:
(Да, я проделываю такие «фокусы» и с Fedora! ;) )
Понятно, что описанный кикстарт-файл является всего лишь примером возможных действий.
Вы можете создавать самые замысловатые сценарии, которые будут, например, устанавливать графическую рабочую станцию, к которой домашние каталоги пользователей будут примонтироваться с NFS сервера и авторизация будет настроена на общий сетевой LDAP-сервер (или иной центр аутентификации, например AD).
Возможные варианты ограничиваются лишь вашей фантазией!
Отмечу лишь, что наличие вариантов установки (и продуманная организация сетевой инфраструктуры) позволяет не только быстро разворачивать системы, но и столь же быстро их переустанавливать. Например, вы можете очень быстро подготовить компьютерный класс к занятиям, установив систему, на которой имеются только необходимые приложения.
Безусловно специфика Fedora в разговоре заметно присутствовала, но, полагаю, она не помешала бы и любителям других дистрибутивов.
Поучаствовать в занятиях определенно стоило!
И пусть ничего принципиально нового на них не прозвучало, тем не менее такие мероприятия я нахожу крайне полезными.
Такое общение со специалистами, под руководством наиболее посвященного в тему, всегда способствует упорядочению давно уже накопленных знаний и дает почву для рождения новых идей.
В эти ночи (эх! часовые пояса лежат между нами... и не дают спать!) прозвучали очень интересные темы, как для новичков, так и для уже опытных пользователей и админов.
Clint Savage рассказал об основах SELinux, Jon Stanley сделал полезное введение в использовании Багзиллы.
Paul W. Frields, заменивший Макса Спивака (Max Spevak) на посту лидера проекта Fedora рассказал о том, как принять участие в работе сообщества Fedora.
Ignacio Vazquez-Abrams рассказал о принципах, лежащих в основе пакетов приложений.
Kevin Fenzi сделал введение в устройство механизма фильтрации IP-пакетов в Линукс.
Безусловно, самыми интересными были два доклада от Jeroen van Meeuwen в которых он рассказал от том, как легко и просто собрать свой собственный дистрибутив или LiveCD Fedora и о том как с помощью Puppet управлять Линукс-системами.
Я подозреваю, что после его вдохновенных рассказов народ побежал "клепать" собственные диски с дистрибутивами.
А что? Я тоже сделаю несколько! У меня есть свои идеи на этот счет. Да и все необходимое у меня имеется.... ;)
Более подробную информацию об этом "обучении вместо сна" можно найти здесь. Там же есть ссылки на все материалы, которые были показаны во время занятий, а также записи бесед.
Эта статья является частью этой стаьи и продолжением этой.
Как только в вашей сети появляется две или более машин с одной и той же операционной системой, которые вы стремитесь аккуратно обновлять, избавляясь от проблем с безопасностью и ошибками, и обретая новые возможности, появляющиеся в новых версиях программ, вы начинаете задумываться о своем собственном репозитории, из которого бы обновлялись все установленные системы.
Эта задача становится легкой и приятной с помощью cobbler'а!
Более того, вы избавитесь от необходимости устанавливать старую систему, а затем при первой загрузки сразу же заниматься длительным обновлением, накопившимися к этому времени пакетами. Cobbler дает вам возможность устанавливать сразу же обновленные системы, избавляя вас даже от мыслей о том, как это происходит.
Что ж, сделаем сказку былью! Это очень просто.
Начинаем с того, что определяемся, какие репозитории нам нужны.
Я у себя поддерживаю следующий набор репозиториев: updates, extra, epel (плюс собственный репозиторий для ОфисМастера), как для архитектуры i386, так и для x86_64.
Конфигурация первых двух уже имеется в составе CentOS, а информацию о EPEL берем на сайте проекта. Для примера я рассмотрю настройку лишь одного из них, потому как различий в настройке этих репозиториев практически нет.
Выполняем следующую команду (ее удобно оформить в виде скрипта):
cobbler repo add \
--name=centos-5-i386-updates \
--mirror=http://mirror.centos.org/centos/5/u
--keep-updated=Y \
--arch=i386
Этой командой мы указали cobbler'у с каким источником должно синхронизироваться наше зеркало. Далее, команда
# cobbler reposync
загружает все пакеты с удаленного репозитория и делает другие необходимые операции для того, чтобы данным репозиториям можно было пользоваться внутри нашей сети.
Для поддержания актуальности нашего зеркала нужно выполнять последнюю команду с помощью cron'а с некоторым интервалом, например, раз в сутки.
Указанная команда обновляет все сконфигурированные репозитории, однако некоторые из них, возможно, не требуют обновления. Для таких репозиториев нужно использовать параметр --keep-updated=N.
Как вы еще вероятно помните, в самом начале мы выполнили импорт установочного DVD. Интересным следствием этой процедуры является то, что мы в результате создали «установочное дерево» (installation tree), но не получили репозитория. Это буквально означает, что те пакеты, которые имеются в установочном дереве доступны нам лишь во время установки, а если нам потребуется установить еще какие-либо пакеты из этого комплекта, то нам нужно будет выполнять некоторую ручную работу, что разумеется совершенно неприемлемо для людей занимающихся автоматизацией. :)
При этом, cobbler предоставляет нам возможность не только использовать дополнительные репозитории во время интсталляции, но и создает конфигурацию этих репозиториев на целевой системе, так что и после установки можно легко устанавливать пакеты из этих дополнительных репозиториев (если мы установили yum_post_install_mirror=1).
Драма заключается в том, что установочное дерево не является репозиторием! А если бы являлось, то мы бы получили автоматическую настройку на этот источник и легко бы пользовались им и после установки.
К счастью проблема решается и решение ее просто.
Все, что нам нужно для этого сделать, это создать еще один репозиторий:
cobbler repo add \
--name=centos-5-i386-base \
--mirror=http://192.168.90.249/cobbler/k
--keep-updated=N \
--mirror-locally=0 \
--arch=i386
Данная команда ссылается на наше установочное дерево и отличается от использованной ранее только двумя параметрами. Мы отключаем обновление этого репозитория (содержимое DVD не обновляется, для этого есть отдельный репозиторий) и также отключаем синхронизацию файлов (нам незачем их копировать, они уже у нас). Такие настройки превращают наш новый репозиторий просто в конфигурацию, которая ссылается на установочное дерево.
Теперь, если при создании профиля мы указываем --repos="centos-5-i386-base centos-5-i386-updates", то при инсталляции anaconda, используя все предоставленные ей репозитории будет устанавливать самые новые пакеты, а если параметр yum_post_install_mirror установлен в значение 1, то и после установки на этой системе все наши репозитории будут доступы безо всякой ручной работы, в том числе и установочное дерево.
Сбываются мечты! ;)
Данный файл является ключевым элементом всего процесса автоматизации установки операционной системы, поэтому необходимо уделить ему должное внимание.
Структура кикстарт-файла
Кикстарт-файл имеет определенную структуру, которую необходимо соблюдать при его создании. Он состоит из секций, которые должны следовать в следующем порядке:
секция команд, в которой есть как обязательные опции, так и необязательные, в случае отсутствия обязательных опций инсталлятор прерывает процесс и «выясняет» необходимую информацию интерактивно;
секция %packages описывает устанавливаемые пакеты;
секции %pre и %post, описывают дополнительные действия; эти секции не являются обязательными и могут следовать в любом порядке.
Я рекомендую использовать все секции для более наглядного вида.
Порядок обработки кикстарт-файла следующий:
после загрузки файла инсталлятор выполняет его парсинг, т.е. выполняется замена используемых макросов, разделение на секции и проверка синтаксиса;
исполняется секция %pre кикстарт-файла. Данная секция исполняется в контексте инсталлятора, т.е. корнем файловой системы является ram-диск, дисковые разделы на этом этапе либо не примонтированы, либо не существуют вообще, есть доступ к сети, но символические имена использовать не получится, ибо name service не действует;
исполняется секция команд. т.е. опции, описанные в ней, используются на соответствующих этапах работы инсталлятора;
далее исполняется секция %packages и устанавливаются указанные в ней пакеты;
далее исполняется секция %post, в которой можно выполнить необходимые дейстия в условиях практически готовой системы. На этом этапе исполнение секции осуществляется в chroot-окружении, есть доступ к сети, а разрешение символических имен работает, если использовалась статическая конфигурация сети. При использовании параметров сети от DHCP на этом этапе файл /etc/resolv.conf (внутри chroot-среды) не сформирован, поэтому разрешение имен не работает. Подробнее о исполнении этой секции смотрите здесь.
Cobbler вносит дополнительную гибкость в файлы кикстарта обрабатывая их с помощью обработчика шаблонов Cheetah, что позволяет включать в них весьма сложный код для создания необходимых сценариев установки.
Образцы таких файлов есть в комплекте cobbler'а, поэтому рассмотрим один из них. Вот файл sample.ks, из которого я удалил комментарии и пустые строки:auth --useshadow --enablemd5
bootloader --location=mbr
clearpart --all --initlabel
text
firewall --enabled
firstboot --disable
keyboard us
lang en_US
url --url=$tree
$yum_repo_stanza
network --bootproto=dhcp --device=eth0 --onboot=on
reboot
rootpw 123456
selinux --disabled
skipx
timezone America/New_York
install
zerombr
SNIPPET::partition_select
$kickstart_start
%packages
%post
$yum_config_stanza
$kickstart_done
Как можно видеть, это довольно простой файл, описывающий установку системы в текстовом режиме (на это указывает директива text). Далее я буду кратко описывать стандартные директивы и немного подробнее остановлюсь на специфичных для cobbler'а моментах, имеющихся в этом файле.
Описание директив кикстарт-файлов вы можете найти тут или в руководстве по установке вашего дистрибутива.
Итак, данный файл описывает сценарий установки системы, при котором:
система аутентификации настраивается на использование shadow-механизма хранения паролей, которые шифруются с применением алгоритма md5 (опция auth);
загрузчик устанавливается в MBR (bootloader);
на жестком диске удаляются все разделы и инициализируются метки при использовании ранее не размеченного диска (clearpart);
используется текстовый режим для всего процесса установки (text);
пакетный фильтр настраивается на работу со значениями по умолчанию (firewall);
отключается скрипт настройки для первой загрузки (firstboot);
клавиатура использует раскладку us (keyboard, меняем ее на русскую, указав ru);
язык системы по умолчанию en_US (lang, меняем на русский, указав ru_RU)
источник установки находится в сети и доступен по ссылке, которая берется из переменной метаданных tree (url, обсудим это при создании профилей);
$yum_repo_stanza будет заменен cobbler'ом на описания дополнительных репозиториев, если они будут указаны в параметре --repos для профиля, иначе это выражение будет заменено пустой строкой;
сетевой интерфейс eth0 будет активирован при запуске и будет получать адрес от dhcp сервера (network);
после окончания установки система будет перезагружена (reboot, для отключения poweroff);
пароль root - это строка 123456 (rootpw, разумеется его нужно будет заменить);
механизм защиты selinux отключен (selinux);
настройка системы X Window при установке производиться не будет (skipx);
используется часовая зона America/New_York (timezone, меняем на нужную, например Europe/Moscow);
выполняется установка системы (install. для обновления используем upgrade);
инициализируются все поврежденные таблицы разделов на диске (zerombr);
выполняются необходимые действия по созданию разделов на диске. Описание этого процесса находится в файле partition_select и будет включено cobbler'ом в кикстарт-файл при выполнении команды cobbler sync. О механизме snippet будет сказано ниже.
выполняются действия, которые определены для инструкции $kickstart_start (об этом далее);
устанавливаются необходимые пакеты (%packages). Пакеты, входящие в группу base устанавливаются вне зависимости от их упоминания в кикстарт-файле;
выполняются завершающие сценарии установки, которые подставляются из stanza - $yum_config_stanza и $kickstart_done (об этом также далее).
Механизмы snippet и stanza появились в cobbler'е в разное время, snippets появились позднее и предоставляют большую гибкость и больше возможности при разработке шаблонов кикстарт-файлов, включая выполнение кода, написанного в виде команд Cheetah, включая ветвление, циклы и пр. Рассмотрим их подробнее.
Snippet
Механизм скриптов snippet позволяет включать в кикстарт-файлы целые наборы директив, которые могут быть использованы в разных шаблонах кикстарт-файлов, если это необходимо. Наиболее часто этот механизм используется для описания вариантов разбиения жестких дисков, создания RAID-массивов и пр.
Эти скрипты хранятся в каталоге, на который указывает параметр snippetsdir в файле /etc/cobbler/settings и по умолчанию это /var/lib/cobbler/snippets.
Весьма удобно использовать этот механизм для создания универсальных, повторно используемых блоков, например для «специализированных» наборов приложений (пакетов), которые необходимо устанавливать на рабочие станции в зависимости от специфики, для выполнения стандартных (рпегламентных) процедур подготовки машин к работе и т.д.
Вы можете создавать произвольное количество snippet'ов и использовать их как угодно.
Stanza
Stanza используются для вставок предопределенных в cobbler'е конструкций в кикстарт файлы.
$kickstart_start заменяется вызовом wget, который запросом к серверу вызывает срабатывание специальных триггеров, предотвращает PXE-зацикливание (о нем расскажу отдельно) и позволяет отслеживать статус процесса установки.
$kickstart_done также с помощью wget вызывает срабатывание определенных триггеров на стороне сервера, что также позволяет серверу определить результат установки системы.
Действия, вызываемые описанными директивами могут изменятся от версии к версии.
$yum_config_stanza создает на устанавливаемой системе конфигурацию репозиториев, которые использовались при выполнении установки, чтобы их можно было использовать и после установки на этой системе. Эта работа выполняется только в том случае, если в файле /etc/cobbler/settings параметр yum_post_install_mirror имеет значение 1.
PXE-зацикливание
Порядок загрузки компьютера определяется установками BIOS'а. Если вы интенсивно используете PXE при работе с компьютерами в вашей сети, то вполне логичным будет установить загрузку по сети, как наиболее приоритетный источник загрузки компьютера.
Однако, такой выбор может привести к интересному эффекту, который мы и называем PXE-зацикливание.
Суть его в том, что если согласно вашему кикстар-файлу, установленная система должна перезагрузиться а не выключится, то после перезагрузки на этой машине сценарий установки может запуститься повторно, поскольку мы по-прежнему загружаемся из сети, а не с локального диска! Совершенно понятно, что такой цикл может длиться сколь угодно долго и вряд ли является тем, что нам нужно.
Чтобы избежать такого сценария, cobbler выполняет несколько специальных действий. Суть их в том, что после того, как система успешно установлена на целевую машину, cobbler автоматически создает у себя запись system для этой машины и эта машина после установки по PXE получает не процесс установки, а указание на загрузку с локального носителя.
Таким образом предовращается PXE-зацикливание.
Эта статья является частьи этой статьи и продолжением этой.
Теперь, когда все необходимые службы работают и мы определились с терминами, приступаем к созданию дистрибутива, который будет "раздаваться" cobbler'ом.
Т.е. нам нужно все содержимое установочного DVD передать в управление cobbler'у.
Для этого cobbler предоставляет возможность импорта дистрибутивов.
Допустим, наш DVD с CentOS 5.2 i386 смонтирован в каталоге /mnt/dvd, тогда команда импорта будет выглядеть так:
# cobbler import --name=CentOS-5.2-i386 --path=/mnt/dvd --arch=x86 --breed=redhat
Единственными, требующими пояснения опциями являются --arch и --breed. Опция --arch указывает на целевую аппаратную платформу дистрибутива (варианты - x86, x86_64, ia64), а опция --breed указывает на "породу" дистрибутива. В настоящее время это либо redhat, либо debian, либо suse.
Последний параметр является необязательным и cobbler при импорте будет пытаться определить разновидность дистрибутива самостоятельно.
Команда import выполняет сразу несколько действий. В результате ее работы создается как distro, так и профиль. При импорте дистрибутива cobbler пытается автоматически найти подходящий кикстарт-файл, однако удобнее всего указать шаблон кикстарт-файла опцией --kickstart.
# cobbler import --name=CentOS-5.2-i386 --path=/mnt/dvd --kickstart=/etc/cobbler/my_ks.cfg --arch=x86
Если шаблон кикстарта не указан, то cobbler формирует стандартный кикстарт в котором предполагается полная очистка жесткого диска, настройка одного сетевого интерфейса, eth0, по параметрам, получаемым от dhcp, а в качестве пароля root используется "cobbler". Скорее всего, вам нужны будут более полезные варианты установки, поэтому перед выполнением импорта подготовьте файл кикстарта. Шаблон кикстарта вы можете указать в созданном при импорте профиле позднее, используя команду редактирования профиля (cobbler profile edit).
Будьте осторожны! При импорте дистрибутивов Scientific Linux и НауЛинукс вы можете столкнуться с проблемой зацикливания cobbler'а, которое является следствием использования на дисках с указанными дистрибутивами циклических ссылок. Не импортируйте эти дистрибутивы с DVD. Скопируйте содержимое DVD на жесткий диск вручную, удалите цикличесие ссылки (они находятся в каталоге с примерами создания "сайтов") и после этого производите импорт прямо из того каталога, куда вы сохранили дистрибутив.
Поскольку в результате работы команды import создаются и distro и профили, то после выполнения импорта мы уже может пробовать установить какую-либо систему через сеть.
Прежде чем отправится перезагружать целевую машину, выполняем команду cobbler sync, которая актуализирует конфигурационные файлы.
Теперь идем на машину, куда нужно установить систему и грузим ее из сети. Должны наблюдать примерно следующее (рассказы без картинок скучны, не так ли? ;) ):
Данная статья является частью этой статьи и продолжением этой.
Чтобы продолжать рассказ дальше нам нужно договориться об используемых терминах и сделать предварительный набросок того решения, которое мы создаем.
Далее мы будем много говорить о "дистрибутивах", "профилях", "системах", "репозиториях" и "метаданных". На этих пяти терминах список не кончается, но мы сейчас уделим особое внимание только этим ключевым терминам, оставив остальные за рамками данной статьи, поскольку разобраться с ними не составит труда.
Дистрибутив (distro)
Cobbler имеет довольно специфичный взгляд на "дистрибутив". В то время, как российские (и не только) пользователи различных систем привыкли подразумевать под дистрибутивом некий комплект файлов, которые необходимы для разворачивания некой системы, то cobbler ограничивает рамки этого понятия буквально парой файлов - ядро и initrd, и набором так называемых метаданных, т.е. параметров ядра и дополнительных, определяемых пользователем, переменных. Все это и есть "дистрибутив". Чтобы не вносить лишнюю путаницу и в то же время сохранить терминологию, я далее по тексту буду использовать слово "дистрибутив" в обычном нашем его понимании, а для cobbler'овского значения буду использовать непереведенное сокращение distro. Именно в таком виде эта сущность используется во всех командах cobbler'а, так что это не должно вызвать ни затруднений, ни двусмысленности.
Профиль (profile)
С понятием профиля все гораздо лучше. Под профилем мы будем понимать (и нас будет "понимать" cobbler) набор параметров, определяющих некий вариант установки. Все создаваемые нами профили будут отображаться в меню при загрузке через PXE и выбором того или иного профиля мы, таким образом, будем выбирать тот или иной вариант установки. В число параметров, охватываемых профилем входят distro, параметры ядра, имя файла кикстарта, метаданные, дополнительные репозитории, параметры виртуальной машины (для разворачивания образов виртуальных машин) и некоторые другие.
Основная задача профиля - связать distro с файлом кикстарта для получения установочного комплекта.
Репозиторий (repo)
Репозиторий - это обычное хранилище пакетов, которое используется менеджером пакетов YUM.
Репозитории являются необязательной компонентой при использовании cobbler'а, но как показывает практика использование их существенно упрощает работу при обслуживании даже небольшой офисной сети, не говоря уже о сетях большего размера.
Система (system)
Понятием "система" в cobbler'е некоторый ранее определенный профиль связывается с определенным MAC-адресом (а также IP-адресом и/или именем хоста) что позволяет создать "целевой" комплект для установки на конкретную машину.
Описав систему мы снимаем с себя задачу выбора варианта установки и система сразу же приступает к исполнению сценария, согласно кикстарт-файла, соответствующего данной системе профиля.
Метаданные
Такие вышеперечисленные сущности, как distro, профили и системы могут сопровождаться необходимыми метаданными. Под метеданными в данном случае понимаются некие переменные и их значения. Синтаксис метаданных иллюстрирует следующий пример:
# cobbler profile add --name=F9 --ksmeta="foo=bla bar=8" ...
Определенные таким образом метаданные замещаются при генерации файлов кикстарта (и других) при выполнении команды cobbler sync.
То есть, если в файле кикстарта интерпретатор найдет выражение $foo или $bar, то они их заменит на bla и 8 соответственно. Если вам необходимо в шаблоне использовать знак доллара в явном виде, экранируйте его обратным слешем, например \$foo.
Поскольку метаданные можно определять для всех основных понятий, используемых cobbler'ом (distro, profile, system), то действуют правила переопределения. В соответствии с этими правилами переменные, определенные для системы переопределяют переменные (с тем же именем) профиля, а переменные профиля переопределяют переменные distro.
То есть при определении метаданных с одинаковыми именами в генерации файлов будут использованы наиболее "конкретные" значения переменных.
Кроме определяемх пользователем переменных, cobbler располагает некоторым количеством "системных" переменных, которые могут быть переопределены, используюя описанные выше правила.
Список системных переменных можно просмотреть, выполнив команду
# cobbler system dumpvars —name=system
Для получения списка переменных, определенных для какой-либо сущности, используйте следующий синтаксис:
# cobbler {distro|profile|system|repo} dumpvars —name=<entity_name>
где entity_name — имя соответствующей сущности.
Архитектура
Теперь, когда мы стали понимать с чем имеем дело, опишем взаимодействие всех компонент решения.
Создав distro (командой cobbler distro add ...) мы тем самым обозначили используемые при загрузке ядро и initrd. Сами по себе они не дают нам никакой практической пользы, но являются важной основой для создания профиля.
Профиль связывает наш distro с неким файлом кикстарта, в том числе пустым, и создает пункт в меню загрузки, которое мы будем видеть, загрузившись по PXE. Это уже позволяет устанавливать операционные системы на любой компьютер в нашей сети (в ручном режиме, если мы при создании профиля не указали. кикстарт-файл).
Автоматизация процесса установки операционной системы обеспечивается созданием надлежащего файла кикстарта (в нашем случае с применением cobbler'а, это шаблон) и указанием его при создании профиля (cobbler также позволяет и редактировать профили, чтобы добавить нужный параметр, в том числе и файл кикстарта). Как уже отмечалось, cobbler интерпретирует шаблон файла кикстарта с помощью движка Cheetah. Интерпретация выполняется по команде cobbler sync.
В том случае, если нам нужно описать сценарий для установки какой-либо конкретной машины в сети, то мы для этого создаем "систему", в описании которой указываем ее MAC-адрес. Это, например, удобно для быстрого разворачивания серверов, либо виртуальных машин. При загрузке по PXE компьютера, для которого создано такое описание системы, меню не появляется и вся установка проходит полностью по тому сценарию, который описан в кикстарт-файле.
Источник пакетов для описанных выше вариантов установки указывается в кикстарт-файле. Это единственный способ указать инсталлятору где брать пакеты. Путь к репозиторию пакетов cobbler берет из значения переменной $tree, поэтому ее нужно определить в метаданных.
Если нам необходимо при установке операционной системы установить какие-либо приложения, которые не входят в основной репозиторий (взятый, например, с установочного DVD) , то при создании профиля можно указать дополнительные репозитории, в которых находятся требуемые пакеты.
Если эти репозитории находятся под управлением cobbler'а, то достаточно просто указать их имена в параметре --repos="repo1 repo2 ..." в команде cobbler profile add (edit).
Если необходимо использовать какие-либо "внешние" (для cobbler'а) репозитории, то необходимо добавить команду repo ... непосредственно в шаблон кикстарт-файла (синтакис кикстарт файлов описан, например, здесь, и кратко мы его рассмотрим чуть позже).
Данная статья является частью этой статьи и продолжением этой.
Теперь нам нужно все настроить. Это несложно! Команда
# cobbler check
проверит готовность нашего сервера к работе и скажет, что нужно сделать, если в этом есть необходимость.
Но, кроме этой проверки необходимо провести тщательную проверку содержимого каталога /etc/cobbler.
Главное внимание в этом каталоге нужно уделить файлу settings, поскольку в нем находятся основные параметры cobbler'а.
Cobbler способен управлять службами DNS и DHCP для чего он использует специальные шаблоны конфигурации для dhcpd, named или dnsmasq, в зависимости от того, какую из этих программ вы используете в своей системе.
В данном случае я использую ISC DHCP, а BIND не использую, потому что DNS'ом занимается другая машина в моей сети.
Эта ситуация требует от меня использования следующих параметров в файле settings (если вы используете named, установите 1 в параметре manage_dns):
manage_dhcp: 1
manage_dns: 0
Поскольку я использую dhcpd от ISC, то я использую возможность omapi для управления этим сервером:
omapi_enabled: 1
Для того, чтобы получить возможность устанавливать дистрибутивы через сеть по PXE мне, кроме dhcpd, нужен еще boot-сервер (tftp), адрес которого также нужно указать в файле settings, в нашем случае это адрес нашего сервера, поскольку у нас все на одной машине:
next_server: 192.168.90.249
server: 192.168.90.249
Второй параметр (server) используется для генерации ссылок на репозитории и прочие ссылки в кикстарт-файлах. Важно использовать в значениях этих параметров имена адреса, а не символические имена, потому как генерируемые ссылки могут использоваться на этапах инсталляции, когда разрешение имен в адреса недоступно.
Остальные параметры файла settings можно оставить в начальных значениях, они вполне подходящи для многих случаев.
Хочу отдельно отметить один из нерассмотренных параметров - yum_post_install_mirror.
Что он дает?
Cobbler может включать в кикстарт-файлы директивы, указывающие на дополнительные репозитории, доступность которых обеспечивается только во время установки. Если после установки на новой системе есть необходимость пользоваться этими репозиториями, то установите указанный параметр в значение 1 и cobbler сконфигурирует на новой системе специальный конфигурационный файл, который обеспечит доступность этих репозиториев и после окончания установки. Это может быть очень удобно, если вы устанавливаете операционные системы в локальной сети и эти системы имеют доступ по сети к серверу, на котором установлен cobbler. Таким образом вы не только устанавливаете систему через сеть, избегая использования DVD, но и можете легко доустановить необходимые пакеты позднее, не прибегая к возне с дисками и настройке репозиториев.
Более того, можно указать в кикстарте репозитории с обновлениями, тогда при установке инсталлятор сразу будет ставить новые пакеты, вместо тех, что находятся в исходном дистрибутиве. Это позволит сразу же устанавливать обновленные системы, а параметр yum_post_install_mirror со значением 1, создаст все необходимое, чтобы система обновлялась и дальше. Я нахожу эту возможность весьма привлекательной и удобной.
Если описанный случай вам не подходит, оставьте этот параметр со значением 0.
Закончив с файлом settings, проверим файл modules.conf.
Если для DNS и DHCP используются named и dhcpd от ISC, то оставляем все как есть, а если этими службами будет заниматься dnsmasq, то делаем соответствующие правки (заменяем на module = manage_dnsmasq в разделах [dns] и [dhcp]).
Далее осматриваем другие файлы.
Файлы с расширением .template являются шаблонами конфигурационных файлов соответствующих служб, поэтому необходимо их просмотреть и при необходимости поправить, указав требуемые параметры.
Например, в файле dhcp.template нужно проверить адреса на принадлежность вашей сети, адрес шлюза и диапазон распределяемых адресов.
Также вы можете дополнять шаблоны необходимыми параметрами.
На основе этих шаблонов cobbler создает конфигурационные файлы служб при выполнении команды "cobbler sync".
В шаблоне pxedefault.template поправлять практически ничего не нужно, но можно заменить строку заголовка меню так, чтобы она отражала нужную информацию. Это меню будет отображаться на машинах, загружающихся по PXE с вашей машины, поэтому будет полезно знать откуда оно появилось.
Остальные файлы шаблонов вполне пригодны в том виде, в каком они есть, но их осмотр в любом случае лишним не будет.
На этом этап конфигурирования нашей системы можно считать законченым.
Убеждаемся в этом, для чего выполняем:
#cobbler sync <- она сгенерирует необходимые конфигурационные файлы для управляемых служб
#cobbler check <- покажет, на что нужно обратить внимание в настройке cobbler'а
Внимательно читаем рекомендации и делаем необходимые действия, после чего повторяем эти команды до тех пор, пока не исчезнут сообщения об ошибках и предупреждения.
Вообще говоря, добиться полного отсутствия предупреждений команды "cobbler check" у вас, скорее всего, не получится.
Если все настроено правильно, то могут остаться два предупреждения: о том, чтобы вы не забыли открыть нужные порты в сетевом фильтре и об использовании пароля "cobbler" в качестве пароля для root'а в стандартных кикстарт-файлах, даже если строки с этими паролями закомментированы.
От последнего можно избавиться, заменив пароли на свои.
Для первого убеждаемся, что в настройке межсетевого фильтра на данной машине доступны такие сервисы, как dhcp, tftp, http, а также сам cobbler, использующий порты 25151/tcp и 25150/udp. Последние порты используются cobbler'ом для веб-интерфейса и для syslog-протоколирования установки.
Если настройки и проверки cobbler' а благополучно завершены, запускаем все необходимые службы:
# for serv in httpd xinetd dhcpd cobblerd ; do service $serv start ; done
Если какой либо сервис не запускается, то устраняем эту проблему и запускаем его. Возможно вы пропустили какой-либо параметр в шаблоне конфигурации службы, либо допустили синтаксическую ошибку при редактировании.
Эта статья является частью этой.
Все описываемые ниже действия я выполнял на CentOS.
Поскольку я описываю центр управления поцессом внедрения, то скорее всего в вашем случае это будет персональная машина самого внедряющего админа. Для внедренцев весьма удобным вариантом оказывается ноутбук, однако весьма логично всю описанную систему развернуть на сервере, обслуживающим вашу локальную сеть.
Далее я буду называть систему, на которой развернут cobbler, сервером.
В качестве основы для нашего сервера идеально подходит Fedora или CentOS, хотя нет никаких причин не использовать RedHat Enterprise Linux или Scientific Linux (в том числе и НауЛинукс).
Свежесть дистрибутива будет плюсом. Cobbler - это бурно развивающийся перспективный проект, поэтому его возможности порой весьма существенно отличаются от версии к версии. Нареканий на его надежность и корректность работы не наблюдалось (я весьма интенсивно использую его с конца 2007 года), но по мере развития в него добалвяются новые интересные возможности. Именно поэтому использовать самую последнюю версию cobbler'а всегда полезно, но как известно между репозиториями для Fedora и RHEL/CentOS/SL/Nau всегда есть определенный лаг, поэтому имейте ввиду, что если вам нужны самые последние возможности cobbler'а, то удобнее всего описываемую систему внедрения разворачивать на основе Fedora.
Все повестование предполагает наличие у вас прав админа, трезвой головы и понимания происходящего, ибо первое при отсутствии второго и третьего может стоить вам потери данных, нервов и т.д. и т.п.
Также на нашем сервере необходимо наличие достаточного объема свободного места на диске.
Конкретно, нас интересует каталог /var/www, потому как именно туда будут сохраняться дистрибутивы и репозитории. Безусловно, есть алтьтернативные спсобы хранения дистрибутива (например, на соседней машине, откуда он доступен по http или nfs и т.д), но в данном тексте, для простоты, я буду рассматривать ситуацию с минимальным объемом действий, поэтому сконцентрируемся на /var/www, который используется cobbler'ом по умолчанию.
Места на диске нам потребуется достаточно много. Его должно хватать для размещения копии дистрибутивов и репозиториев, т.е. порядка 4,5 Гигабайт только для дистрибутива, плюс объем, необходимый для размещения нужных нам репозиториев.
Разумеется, это не должны быть последние байты на диске.
Если свободное место есть, двигаемся дальше.
На нашем сервер, помимо всего прочего, необходимо наличие следующих пакетов: httpd, xinetd, tftp-server, dhcp. Их назначение достаточно понятно и я не буду на нем останавливаться.
Если они не установлены, устанавливаем:
# yum install httpd xinetd tftp-server dhcp
Этих служб уже достаточно, чтобы начать работу с кикстарт-файлами, но настоящую мощь этому придает cobbler.
Взять его можно прямо на сайте разработчиков, для вышеуказанных дистрибутивов он может быть найден как в основных (fedora или updates для Fedora), так и в дополнительных (EPEL для RHEL/CentOS/SL/НауЛинукс) репозиториях.
Устанавливаем cobbler с помощью yum:
# yum install cobbler
В свете массовой линуксификации российского образования и намечающегося усугубления данного процесса, хочу поделится рецептом, который, как я надеюсь, сохранит нервную систему, время и оптимизм любого внедренца.
Разговор пойдет о RedHat-based дистрибутивах, потому как с другими я не работаю по ряду причин и ситуация в ближайшее время вряд ли изменится, хотя описанные ниже способы применимы и для других дистрибутивов (Debian, SUSE).
RedHat Enterprise Linux и другие дистрибутивы на его основе, имеет крайне полезную для нашей ситуации штуку. Это "кикстарт"!
Сам по себе механизм автоматического развертывания дистрибутивов извествен давно, однако недавно на этой сцене появился новый игрок - cobbler.
Сила этого явления воистину велика, а осознание ее может существенно повлиять на ваше мировоззрение. ;)
Для чего это может быть полезно? Вариантов применения немало. Приведем краткий список некоторых из них:
Установка дистрибутива на несколько машин.
Установка подготовленных поставщиком решений на машинах заказчика.
Поддержание репозиториев пакетов для установки и обновления компьютерных классов, интернет-кафе и т.п.
Предоставление вспомогательных, загружаемых через сеть (PXE) систем для восстановления, резервного копирования и вывода из эксплуатации машин.
Автоматическое развертывание виртуальных систем.
и т.д. и т.п.
Внедрение достаточно непростой процесс, который зависит от специфики заказчика, поэтому чтобы описать полную картину этого процесса, нужно уделить этому занятию достаточный объем времени.
Чтобы упростить и упорядочить эту задачу я разобью весь свой рассказ на части. Это позволит мне совершенствовать их со временем и не использовать слишком много букв, которые могут оказаться не по силам для некоторых. ;)
Итак, весь рассказ будет состоять из следующих частей:
Развертывание систем по PXE.
Развертывание систем на изолированных машинах.
Системы или целевая установка.
Создание восстановительной системы, загружаемой по сети.
Развертывание виртуальных машин.
Эти части я буду публиковать по мере их готовности, поэтому, если какой-либо из них вы не обнаружили сейчас, вернитесь на эту страницу позже.
Точно не помню когда она появилась, возможно до анекдота о "вступим в НАТО по самые Нидерланды", а может и вместе.
Вообще говоря, мысль эта не показалась мне глупой тогда, несмотря на ее литобработку, а сейчас вообще представляется весьма разумной и верной.
Особенно эта мысль во мне утвердилась после увиденного интервью Далай-Ламы по Евроньюс.
Во всяком случае, тот факт, что не мне одному одному эта мысль попала в голову уже радует.
В любом случае, политика ответных контрмер не имеет никаких шансов на успех.
В этом я убежден стопроцентно.
Способность уступать не есть признак слабости, но есть признак мудрости.
Возможность прийти к согласию может быть только в соучастии, но никогда в подавлении.
Есть только одно лекарство от сепаратизма - добрососедство и взаимное уважение.
Любого политика, пытающегося отстаивать национальные интересы любого народа, нужно лишать языка, ибо мир слишком тесен, чтобы проводить границы между нациями.
На правах имхо.
История знает тому немало примеров и мы видм это и в наши дни.
Как один из микровариантов этого явления - создание хозяйствующих субъектов, всевозможных ООО, ОАО и т.д., которые нацелены на ведение самостоятельной деятельности для достижение определенных благ как для их организаторов, так и для тех людей, которые участвуют в этой организации, т.е. для работников.
Каждое государство поощряет такое явление, ибо образование таких хозяйствующих субъектов создает не только блага "внутренние" по отношению к хозяйствующему субъекту, но и "внешние", как в виде налогов и рабочих мест, так и иных. которые вполне очевидны.
Является ли уход работника из одной организации и создание им собственной организации преступным деянием по отношению к своей бывшей компании? Можно ли это назвать "сепаратизмом"?
Ответ на первый вопрос, по-моему, выглядит как нет, если такой уход находится в рамках действующего законодательства, которое допускает как образование догвоорных отношений между работником и работодателем, так и их прекращение.
На второй вопрос можно ответить как "да", ибо это есть отделение, а ведь именно таков смысл слова "сепаратизм".
Давайте увеличим масштаб явлений.
Допустим, группа людей, проживающих на определенной территории посчитала целесообразным образование хозяйствующего субъекта , который при данном масштабе вполне может выглядеть и как автономная область, и как автономная республика и как отдельное государство. Данная возможность на этом уровне обеспечивается правом на самоопределение (http://ru.wikipedia.org/wiki/%D0%9F%D
Хорошо это или плохо?
Что произойдет, если какая-то группа людей решит жить таким образом, "отделив" определенную территорию от территории государства, с которым они ранее были единым целым?
Как относиться тем, кто остались "снаружи" к тем, кто оказались "внутри" и наоборот?
Не будут ли нарушены гражданские права и социальная защищенность людей по обе стороны новообразованной границы?
Мое личное мнение заключается в том, что такие "территоиальные новообразование" не влекут никаких отрицательных последствий, если обе стороны договариваются о ведении справедливых (т.е. рыночных, саморегулируемых) отношений.
Совершенно ясно, что ни одна страна сегодня не может жить в изоляции,что эффективное взаимодействие жизненноважно для каждой из взаимодействующих сторон.
Такие взаимодействия, что очевидно, включают в себя, в частности, и товарные отношения и туризм. Примеры таких отношений мы видим, например, в объединенной Европе.
Всегда, когда образовывается новое государство на него следует смотреть как на потенциально выгодного партнера в экономическом сотрудничестве. Если группа людей решила, что она может работать эффекивно и доказывает это, это, прежде всего означает, что эта хорошее место для размещения своих инвестиций, выгодный партнер в получении дохода от любого вида деятельности.
Безусловно, такие отношения не просты и главный гарант их органичного развития - добрая воля народов и их лидеров, что на сегодняшний день не такое уж и частое явление.
Преступно, в ответ на желание реализовать свое право на самоопределение разрушать сложившиеся ранее механизмы взаимодействия, лишь в угоду неким политическим соображениям, типа "а попробуйте-ка без нас выжить"!
Возможно, образование отдельных государств не всегда может являться правильным решением, однако для любого политика (а он, безусловно, должен быть грамотным и чутким хозяйственником) это должно быть сигналом к тому, что если в государстве появляются мысли о сепаратизме, то самое время заняться оптимизацией экономической и социальной жизни в стране, что он как политик и управленей не удовлетворяет своими методами управления жителей своей страны.
Не должно быть причин, по которым силовое решение может быть вариантом решения проблемы, поскольку количество проблем в этом случае всегда только увеличивается. (Безусловно, есть определенные "товарищи", которые получают от этого доход, но это не уменьшает количество жертв силового решения, а стало быть, преступно по определению.)
Полагаю, что на сепаратизм можно глядеть еще и как на вариант децентрализации управления экономикой, что может быть средством для существенного повышения эффективности такого управления.
Никогда при этом не следует забывать и о возможности обратного процесса. Если взаимодействующие страны находят, что им выгоднее существовать в рамках единого государства или любой формы союза, то нет ничего мешающего им соединиться вновь.
И уж абсолютно нет никаких оснований для мыслей, типа "Мы великое государство с многовековой историей и культурой, которому никакое новоявленное государство не указ!".
Мы живем в одном мире и любой локальный конфликт легко может перерасти в глобальный.
Оно нам надо?
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
neverho0d- neverho0d
- ООО АББРИС, ОфисМастер
Syndicate
