Archive for Февраль, 2010
Конфигурирование VLAN средствами RHEL/CentOS/Fedora Core
by admin on Фев.28, 2010, under *nix Administration
Во многих доках и HOWTO описывается, как поднять VLAN-ы в Linux вручную, при помощи последовательности команд, которые потом можно запихнуть в скрипт. Считаю, что это не совсем правильно. Подобные вещи лучше всего делать штатными средствами системы. В RedHat-based системах настройка VLAN-ов легко выполняется при помощи стандартного скрипта ifup. Ниже описана данная процедура.
Для начала необходимо описать базовый сетевой интерфейс, на котором мы будем поднимать VLAN.
host# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0 # здесь нужно указать реальное имя интерфейса
BOOTPROTO=static
HWADDR=00:07:E9:A7:13:48 # здесь нужно указать реальный MAC
ONBOOT=no
TYPE=Ethernet
IPADDR=0.0.0.0
NETMASK=255.255.255.0
Дла наших целей важны только два параметра: DEVICE и HWADDR. Остальное роли не играет. Можно даже заполнить «от балды».
Далее, создаем подинтерфейсы для VLAN. Именование подинтерфейсов может быть двух видов: «vlanX» и «eth0.X».
В первом случае, мы имеем описательное имя, которое не привязано к имени родительского интерфейса. Соответственно, перемещение VLAN на другой физический интерфейс не требует значительных изменений в конфигурацию системы (не нужно править правила пакетного фильтра и тд и тп).
С другой стороны, при использовании имен вида «eth0.X» мы имеем более удобное (по моему мнению) имя интерфейса, по которому видно на каком родительском интерфейсе поднят VLAN, чем немного упрощается администрирование системы. Плюс, поскольку имя подинтерфейса базируется на имени физического, то мы имеем различные пространства имен для VLAN-ов. Я имею ввиду ситуацию, когда на разных интерфейсах приходят VLAN-ы с одинаковыми номерами. Использование «vlanX» в данном случае будет несколько затруднительно. Минусом будет то, что некоторые утилиты некорректно работают с именами интерфейсов с точкой в имени (например sysctl).
Конфигурирование интерфейсов типа «vlanX»
host# cat /etc/sysconfig/network-scripts/ifcfg-vlan10
VLAN=yes
VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD
DEVICE=vlan10
PHYSDEV=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
IPADDR=10.10.10.2
NETMASK=255.255.255.252
Здесь:
PHYSDEV — физический интерфейс, на котором работает VLAN.
VLAN_NAME_TYPE — указываем тип наименование устройства. В данном случае номер VLAN будет браться с имени устройства. Возможные варианты:
VLAN_PLUS_VID —vlan0010
VLAN_PLUS_VID_NO_PAD — vlan10
DEV_PLUS_VID — eth0.0010
DEV_PLUS_VID_NO_PAD — eth0.10
Конфигурирование интерфейсов типа «eth0.X»
host# cat /etc/sysconfig/network-scripts/ifcfg-eth0.10
VLAN=yes
DEVICE=eth0.10
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
IPADDR=10.10.10.2
NETMASK=255.255.255.252
Все то же самое, но без PHYSDEV и VLAN_NAME_TYPE.
Хочеться добавить, что смешать в одной системе «vlanX» и «eth0.X» штатными средствами вряд ли получится, т.к. тип именования (VLAN_NAME_TYPE) при инициализации интерфейсов задается по первому поднимаемому интерфейсу.
Настраиваем репликацию MySQL в Fedora 10
by admin on Фев.28, 2010, under *nix Administration
В этой статье я покажу как настраивается реплакация баз в MySQL. MySQL репликация позволяет вам иметь точную копии базы, находящейся на главном сервере (master) на вторичном (slave) сервере. Все измениния в базе на мастере немедленно передаются на слейв. В общем случае репликация не предназначена для резервного копирования, так как операция удаления также реплицируется, но репликация может помочь в случае выхода из строя оборудования. В данном руководстве я буду использовать операционную систему Fedora 10 на обоих серверах.
Для настройки репликации существуют несколько различных путей, но я использую именно этот. В данном руководстве будут использованы следующие обозначения серверов:
* server1.example.com (IP 192.168.0.100): master
* server2.example.com (IP 192.168.0.101): slave
Я буду реплицировать базу exampledb с сервера server1.example.com (master) на сервер server2.example.com (slave).
Подразумевается, что MySQL уже установлен и работает на обоих серверах. База exampledb с таблицами и данными расположена на мастере, и ещё не существует на слейве.
Настраиваем Master
server1:
Для начала мы создадим директорию для лог файлов MySQL:
mkdir /var/log/mysqlchown mysql:mysql /var/log/mysql
Теперь мы отредактируем конфигурационный файл /etc/my.cnf; мы должны сообщить MySQL для какой базы необходимо писать логи ( эти данные будут использованы слейв сервером для того, чтобы видеть изменения на мастере), какой лог файл должен быть для этого использован, и мы должны указать что этот MySQL сервер является мастером.
vi /etc/my.cnf
[mysqld][...]log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=exampledb
server-id=1
[...]
Теперь перезапускаем MySQL:
/etc/init.d/mysqld restart
Далее залогинимся в MySQL под рутом и создадим пользователя с правами на репликацию:
mysql -u root -p
Enter password:
Находясь в MySQL шелле, введите следующие команды.
STOP SLAVE;GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';
FLUSH PRIVILEGES;
Далее там же введите:
USE exampledb;FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Последняя команда выдаст примерно такой результат, он нам понадобиться позднее:
mysql> SHOW MASTER STATUS;+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | exampledb | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)mysql>
Не выходите из шелла MySQL, иначе будет снята блокировка базы. Откройте ещё одно окно шелла, где мы создадим дамп Mysql базы и передадим его на server2 используя scp:
cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql root@192.168.0.101:/tmp
После этого, второе окно можно закрыть. А в первом разблокируйте базу и покиньте MySQL.
UNLOCK TABLES;quit;
Настраиваем Slave
server2:
Теперь нам необходиом сказать MySQL на слейве, что он слейв, что его мастер находится на 192.168.0.100, и что база данных, которую мы реплицируем - exampledb. Отредактируем /etc/my.cnf:
vi /etc/my.cnf
[mysqld][...]server-id=2
master-host=192.168.0.100
master-user=slave_user
master-password=slave_password
master-connect-retry=60
replicate-do-db=exampledb
[...]
Перезапускаем MySQL:
/etc/init.d/mysqld restart
Создадим пустую базу данных exampledb (убедитесь что вы запустили STOP SLAVE; для остановки всех слейв процессов, если они запущены):
mysql -u root -p
Введите пароль:
TOP SLAVE;CREATE DATABASE exampledb;
quit;
Теперь импортируем дамп SQL snapshot.sql:
cd /tmpmysql -u root -pyourrootsqlpassword exampledb < snapshot.sql
Потом опять подключаемся к MySQL …
mysql -u root -p
Вводим пароль:
… и запускаем следующую команду:
CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;
Наконец запускаем слейв:
START SLAVE;
Проверяем статус сервера:
SHOW SLAVE STATUSG
Обратите внимание на значение Slave_IO_Running и Slave_SQL_Running. Значение обоих параметров должно быть Yes, в противном случае что то пошло не так, и необходимо смотреть в /var/log/mysqld.log в поисках ошибок:
mysql> SHOW SLAVE STATUSG*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.100
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 98
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: exampledb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)mysql>
Выходим из MySQL на server2:
quit;
На этом все. После любых обновлений базы exampledb на мастере, все изменения немедленно будут реплицированы на слейв.
Как удаленно выключить Windows XP из под Linux
by admin on Фев.28, 2010, under *nix Administration
В этой статье рассматривается пример, как можно удаленно выключить компьютеры под управлением Windows XP из под Linux машины. Я не претендую на то что это лучшее решение, но тем не менее оно существует, и дабы про него не забыть, публикую у себя.
Необходимые требования к компьютеру WINDOWS XP для удаленного выключения:
1. Отключенный простой общий доступ к файлам. Снимите галочку с “Использовать простой общий доступ к файлам” через Мой компьютер > Сервис > Свойства папки > Вид.
2. Проверьте файервол Windows и убедитесь что ICMP и File and Printer Sharing включены.
3. После этого вы должны успешно пинговать Windows машину.
4. В локальной групповой политики группа администраторов должна иметь право на удаленное выключение компьютера. Для проверки запустите Group Policy Editor (gpedit.msc) . Выберите Конфигурацию компьютера > Конфигурация Windows > Параметры безопасности > Локальные политики > Назначение прав пользователя > Принудительное удаленное завершение и проверьте кто имеет права на данную процедуру.
Требования к Linux для удаленного выключения Windows XP:
1. Должна быть установлена и корректно работать Samba.
2. Для удаленного выключения используется следующая команда:
net rpc SHUTDOWN -C "enter a comment to display at shutdown" -f -I x.x.x.x -U username%password
В этом примере x.x.x.x это IP адрес компьютера с Windows XP, username - член группы локальных администраторов, и password это пароль пользователя, указанного в username.
3. Проверьте выполнение скрипта на тестовой машине.
4. Далее можно использовать эту команду в скрипте, который выключает все компьютеры в определенной подсети или с определенным IP адресами. Можно поместить данный скрипт в crontab для запланированного выключения в нужное вам время.