LINUX-BG Адрес : http://www.linux-bg.org |
BIND9 в многонодов режим на работа |
От: Beco Публикувана на: 26-04-2006 Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=381993892 |
BIND9 в многонодов режим на работаВерсия 1.0.2 (26 април 2006г.)Copyright ©2006 Веселин Колев, Софийски Университет "Св. Климент Охридски"Лиценз: CC Attribution-ShareAlike
1. Въведение.По подразбиране, инсталацията на BIND9 се извършва в рамките на една инстанция (от гледна точка на работна единица на услуга - един нод). Това означава, че в системата има само един майчин процес на демона named. В над 90% от случаите на инсталации на BIND9 върху UNIX и UNIX-подобни базирани системи, това е напълно достатъчно. В по-редки случаи може да се наложи в една система да има повече от един нода на named, които да работят паралелно. Причините за това може да са няколко. Погледнато реално, да се извършва виртуализация чрез Xen само за да се стартира един отделен сървър за имена, е нерантабилно от гледна точка на натоварването на системата и самата сложност на инсталация. Много по-лесният вариант е да се реализира още един сървър за имена в една и съща система, като още един нод на демона named. Такъв вариант е по-добър в многопроцесорни системи, ако е нужно всеки даден демон да използва отделен процесор. Ресурсите, които се използват от демона named могат да бъдат лесно регулирани, доколкото всеки нод (всеки отделен демон named) има ясна идентификация като име на процес и потребител, с чиито права функционира. Когато се говори за Red Hat Enterprise Linux обикновено става дума за сървърски системи с висока производителност и висока значимост от гледна точка на ресурсите, осигуряващи услугите, които се прдлагат на основа на тях. Това са консервативни системи, в които нещата не се променят значимо в рамките на жизнения цикъл на версията на дистрибуцията. Именно на тази и други особености трябва да е подчинена и идеологията на решението, което ще бъде описано тук. То не трябва да засяга или променя значимо системата и да не води до объркване тези, които я администрират. Следователно трябва да е максимално просто и лесно управляемо. Именно за това се използва стандартен за Red Hat Enterprise Linux инициализационен скрипт, максимално близък до този на услугата named. Решението трябва да може да бъде обновявано с минимален брой стъпки и при нужда да е лесно остранимо от системата, без да "замърсява" директорийната структура. Именно тези изисквания са заложени в реализацията му, която е описана по-долу. Разбира се, решението може да се реализира и върху други UNIX и UNIX-подобни дистрибуции. За целта обаче, ще трябва да се съобрази с локалната идеология за управление на услугите в системата, конкретното разположение на директории и файлове и т.н. Този документ е предназначен за системни администратори с опит в администрирането на сървъри за имена. От тази гледна точка описанието в него би било трудно разбираемо за начинаещи потребители. Решението е тествано и оптимизирано в рамките на повече от една година в условия на продукция, върху двата основни сървъра за имена в мрежата на Софийския Университет "Св. Климент Охридски". На базата на това решение са реализирани нодовете на сървърите за имена по проекта AS112 и тези на СУ (върху всяка машина има по два нода на named - един за нуждите на AS112 и друг за нуждите на СУ). Така решението е "чисто" и сървърите за имена на проекта AS112 не са обвързани по никакъв начин с тези на СУ, освен това, че процесите на named работят вурху една и съща машина. Всичко описано по-долу няма претенции да бъде единствено правилно и не бива да се разглежда като задължителен за следване шаблон по изграждане на подобни решения. Изложените тук техники и схеми са само едно възможно решение. Авторът не носи отговорност за евентуално възникнали проблеми или нанесени преки или косвени щети, причинени от прилагането на описаните техники и схеми в този документ.
2. Директорийна структура и съдържание на решението.Показаната по-долу директорийна структура е по-скоро примерна, а не задължителна. Реализиращият решението има пълната свобода да разположи файловете в системата на място, което е удобно за него. Файловият набор на решението се състои от два файла. Единият файл е инициализиращ скрипт, а втория е конфигурационен файл за инициализиращия скрипт. Инициализиращият скрипт се намира във файла /usr/local/miltinode-named/init.d/named-node_name, а конфигурацията на инициализиращия скрипт - във файла /usr/local/miltinode-named/sysconfig/named-node_name.
#!/bin/bash
# BIND named process options
3. Процедура по изграждане и управление на нодове.
От гледна точка на сигурността и по-точно сепарацията на привилегии в системата, е добре за всеки нод на демона named да има отделен непривилигирован потребител и групата, към която той принадлежи да съдържа само този потребител. С правата на непривилигерования потребител се изпълняват процесите на демона named за съответния нод. Едно примерно създаване на група за нод с име as112 би изглеждало по следния начин: # groupadd named-as112 След това създаването на потребителя може да протече по следния пример-шаблон: # useradd -g named-as112 -s /bin/false -d /dev/null -c "named user - node as112" named-as112 Подобно по своя характер създаване на група и потребител трябва да следва за всеки от наличните в системата нодове на named. Ако в системата се следва нумерационен план за GID и UID, в горните командни редове трябва да се укажат желаните числови стойности според нумерационния план.
# ln -s /usr/sbin/named /usr/sbin/named-as112 създава псевдоними за нодове с имена as112 и as5421. Ефектът от създаването на псевдонимите е такъв, че след стартиране, името на процеса съвпада с името на symlink връзката и така може да се намери неговия PID номер (макар демона named да се управлява само чрез rndc и това в базовия случай да отменя използването на PID номера на майчиния процес, то има случаи, в които се налага да този уникален номер да се знае). Подобен начин за създване на псевдоними е възможно най-рационалния. Причината е, че при актуализация на пакета bind (в състава на който е файла /usr/sbin/named), става дефакто актуализация и на всички псевдоними. Това например не би било така, ако вместо symlink връзки се използваше копиране на /usr/sbin/named във файлове с имена, свързани с нодовете.
# ln -s /usr/local/named-multinode/init.d/named-node_name /etc/rc.d/init.d/named-as112 По този начин в директорията с инициращите скриптове /etc/rc.d/init.d/, са привидно (symlink) създадени два нови скрипта, които дефинират две нови услуги, а именно named-as112 и named-as5421. Удобството от такова създаване на услуги е, че инициращия им скрипт много лесно може да се актуализира. Достатъчно е да се направят промени в скрипта-шаблон named-node_name, който се намира в директорията /usr/local/named-multinode/init.d/ и те веднага влизат в сила за всички инициращи скриптове, които сочат към шаблона. Тази схема създава добра функционалност и улеснява лесно актуализациите и повишава надежността и сигурността на услугите.
# cp /usr/local/named-multinode/sysconfig/named-node_name /etc/sysconfig/named-as112 Едни примерни указания във файла /etc/sysconfig/named-as112 могат да имат вида:
NODE_PROCESS_NAME=named-as112 Подобен пример би могъл да бъде даден и за /etc/sysconfig/named-as5421:
NODE_PROCESS_NAME=named-as5421
От гледна точка на сигурността на услугата, е добре да се използва опционалното заключване на демона named, налично като стартова за него опция. За целта трябва да се изгради chroot директория, в която да стане заключването на процеса. Във Fedora Core и Red Hat Enterprise Linux и дериватите му, създаването на chroot директорията и минималното й съдържание се извършва от пакета bind-chroot. Проверката за това дали пакетът bind-chroot е инсталиран в системата, може да се извърши чрез инструмента rpm по следния начин: # rpm -q bind-chroot Ако пакетът е наличен в системата, на нов ред ще бъде изведено името и версията му. Ако пакетът bind-chroot е наличен в системата е добре да бъде актуализиран (ако са налични актуализирани версии към момента, които не са локално инсталирани). Това може да стане чрез инструмента yum: # yum update bind-chroot Ако системата не е дериват, а е оригинален Red Hat Enterprise Linux и в нея няма допълнително инсталиран yum, то актуализацията може да се извърши и с инструмента up2date:up2date bind-chroot Ако пакетът bind-chroot не е истиналиран в системата, инсталацията му може да бъде извършена с инструмента yum: # yum install bind-chroot Ако се използва Red Hat Enterprise Linux, а не негов дериват и няма допълнително инсталиран инструмент yum, то инсталацията на пакета bind-chroot може да се извърши и чрез инструмента up2date:up2date -i bind-chroot Целта на инсталирането на този пакет, ако не е наличен вече в система, е да създаде шаблон за chroot средата, която ще се използва от нодовете. За всеки нод се създава отделна chroot среда, като се използва шаблона инсталиран от bind-chroot във /var/named/chroot.
За всеки нод се създава директория, в която ще се намира съответната за неговия демон named chroot среда. Добре е името на тази директория да бъде ясно свързано с името на нода. Това не е задължително, но е добра практика особено в системи, които се администрират от повече от един администратор:
# mkdir -p /home/chroot/named-as112
# cd /home/chroot Нарочно директориите, които ще бъдат синхронизирани се указват поименно, а не се синхронизира тоталното съдържание на /var/named/chroot. Причината е, че ако /var/named/chroot не е прясно инсталирана, а е използвана за някакъв период от време в ролята й на chroot директория на демона named, то в тази директория може да има монтиране на proc в поддиректория proc/ (може да има и наличие на други директории, които също не са част от прясно инсталирания пакет bind-chroot). Безмислено е тази директория и нейното съдържание да бъде копирано. Трябва да се отбележи синтаксиса на описание на директориите, които ще бъдат синхронизирани. Указването им става като след името на директорията няма знак за продължения на пътя "/". Причината е следната. Ако има знак за удължаване на пътя "/", то в директорията-цел на синхронизация (такива директории-цели в примера по-горе са /home/chroot/named-as112 и /home/chroot/named-as5421), няма да бъдат създадени поддиректории dev/, etc/ и var/, а съдържанието им ще бъде копирано в директорията-цел без създаването на поддиректориите dev/, etc/ и var/ Използването на rsync в този случай указва на добра практика. Ако след време излезе актуализация на пакета bind-chroot, директорията /var/named/chroot ще бъде използвана като шаблон за актуализация и на chroot директориите за отделните нодове, чрез използване именно на rsync. Разбира се, при това трябва чрез опция "--exclude" да се направи така, че да се избегне изтриването на дефинираните от администратора конфигурационни файлове и зонални файлове, а така също и от създадените от демона named зонални файлове и журнали. Ето примерен команден ред, който актуализира chroot директорията на нодовете от горния пример, спрямо шаблона /var/named/chroot, която засяга само поддиректория dev/:
# cd /home/chroot ВНИМАНИЕ!!! Всички файлове, които са специфично читаеми или писаеми от демона named-node_name за съотвения нод, трябва да бъдат с така установени права за собственост върху тях, че да се съблюдава факта, че всеки нод се стартира с правата на различен непривилигерован потребител. За горния пример нода на named за as112 се стартира с правата на непривилигерования потребител named-as112, а този за as5421 с правата на непривилигерования потребител named-as5421.
След като за всеки нод бъдат извършени описаните по-горе стъпки и бъдат поставени специфичните конфигурационни файлове, ключове и зонални файлове, е ред на описанието на процедурите по стартиране, презареждане, проверка на статуса и спиране на услугата. Доколкото дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите му) са SystemV базирани, то за управлението на услугите по нодове се използват отделни инициращи скриптове в директорията /etc/rc.d/init.d. Проверката на наличните чрез инициращия скрипт функционалности за управление може да се извърши така: # service named-node_name или пренесено за основния пример, а именно за имена на нодове as112 и as5421:
# service named-as112
# service named-as112
Стартирането на услугата при зареждането на системата може да се укаже чрез инструмента chkconfig. Първата стъпка е прибавянето на услугата за управление чрез инструмента chkconfig. То може да се извърши по следния модел:
# chkconfig --add named-as112 При това прибавяне chkconfig ще прочете заглавната част на инициращия скрипт за съответните нодове, ще провери в кои нива на стартиране на системата трябва да се стартират нодовете и ще изгради нужните за това symlink връзки в директорията на съответното ниво (по подразбиране сървърските инсталации без стартирана графична среда се зареждат в ниво номер 3 - initlevel 3). Ако след това се налага някой нод да бъде неактивен в дадено ниво на стартиране на системата, то дезактивирането може да се осъществи чрез chkconfig по начин, подобен на следния
# chkconfig --level 5 named-as112 off В този пример се извършва дезактивирането на нодове as112 и as5421 при стартиране на системата в ниво 5 (initlevel 5). Ако трябва да се направи активиране в дадено ниво, вместо "off" като аргумент се използва "on". Ако трява да се върне състоянието "по подразбиране" на услугата в дадено ниво (това, зададено в заглавната част на инициращия скрипт), се указва опцията "reset". Премахването на дадена услуга, свързана с нод, от обслужване в рамките на процеса на зареждане на услуги в различните стартови нива на системата, може да стане чрез използването на инструмента chkconfig, като се следва схемата: # chkconfig --del named-as112
4. Особености на използването на rndc при многонодов режим на работа на named.Rndc е инструмент за управление на демона named през TCP сокет. В дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите му), по подразбиране rndc чете настройките си от конфигурационния файл /etc/rndc.conf. В случаите на еднонодова инсталация (както е по подразбиране при инсталация на пакета bind), това не е проблем. Всички команди, които ще бъдат подадени чрез rndc към демона named следват простия синтаксис "rndc commnad", доколкото в /etc/rndc.conf е указано командите да отиват по подразбиране към rndc порта на даден IP адрес. В случаите на многонодова BIND9 инсталация, подаването на команди към даден нод чрез rndc е по-комплексно. Доколкото всеки нод на named е обвързан с конкретен IP адрес, то rndc трябва да знае към кой точно нод да изпрати командата и следователно трябва от някъде да взима информация за IP адреса му (и евентуално номера на порт, на който named приема rndc комуникация, ако този порт е различен от стандартния). При изпращането на команда към демона named на даден нод чрез rndc, се използва указване на IP адреса, до който тази команда се изпраща. За целта се използва наличната за това опция "-s" на rndc. Указването на IP адрес чрез опцията "-s" не решава напълно проблема. Нужно е да се укаже и ключ за използването му в алгоритъм HMAC-MD5, чрез който между rndc и named да тече електронно подписана комуникация. Добре е всеки нод да използва различен подписващ ключ. Има три варианта на указване на ключа, който rndc да използва за да подписва електронно комуникацията с даден нод: по име на файл, който го съдържа, по име на ключа или като асоциация на име на ключ към IP адрес на нод. Ако се използва директно указване на ключа като файл, който го съдържа, командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1 би изглеждал така: # rndc -s 192.175.48.1 -k /etc/su-as112.key status Ако се използва името на ключа, то този ключ трябва да е включен във файла /etc/rndc.conf чрез указването на пълния път до файла, който съдържа ключа с това име. Това указване става чрез декларацията "include" на отделен ред във файла /etc/rndc.conf, например: include "/etc/su-as112.key"; В един файл може да има повече от един ключ, но в рамките на включваните по този начин ключове в /etc/rndc.conf не трява да има два ключа с едно и също име. Ако се използва тази концепция, може да се даде следния пример на командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1: # rndc -s 192.175.48.1 -y su-as112 status Тази концепция важи и в случаите, когато се извиква файл (чрез опция "-k"), в който се намират повече от един ключа и трябва да се укаже кой точно от тях да се използва. По-лесният начин е във файла /etc/rndc.conf да се укаже асоциация на даден ключ към даден адрес на нод. По този начин на rndc се указва само IP адреса на нода и той сам намира ключа, чрез който да подписва електронно комуникацията. За да може да се реализира това ниво на автоматизация на избора на ключ, в /etc/rndc.conf се използват структури подобни на следната:
server 192.175.48.1 { В примера се предполага, че ключът с име su-as112 се намира във файла /etc/su-as112.key. Подобна структура се изгражда за всеки един нод, с който ще се води електронно подписана комуникация иницирана чрез инструмента rndc. За пример може да се покаже как в този случай би изглеждал командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1: # rndc -s 192.175.48.1 status |
Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук,
но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора,
както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.
All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
|