монтирование лиска в LikeWise
http://blog.cyphermox.net/2008/10/automatic-mounting-of-samba-shares.html?showComment=1224536280000
Lotus Notes 8.5
http://otrs.org/demo/ - система тикетов
флопи диск gfloppy
принт сервер на линуксе
http://www.lissyara.su/?id=1873
настройка openvpn:
http://ylsoftware.com/news/393
понедельник, 30 марта 2009 г.
суббота, 28 марта 2009 г.
10+ фактов для вашего босса, почему выгоден переход на Linux
1. Стоимость
Начальники очень хорошо знают как считать деньги, так что это первое, что вы должны сказать, почему вы должны перейти на Linux. Общая стоимость владения (TCO) Linux ниже, чем Windows и это доказано. Подробнее см. здесь “Microsoft, Linux и TCO“
2. Безопасность
Это практически аксиома или постулат, если хотите, современного ИТ мира. Для полной картины прочтите также статью “Microsoft ворует данные“.
3. Производительность
Linux - это высокопроизводительная ОС. Благодаря своей модульной природе все части операционной системы Linux могут быть легко добавлены или удалены, операционная система Linux может быть легко настроена для конкретной цели. Нужен веб-сервер? Вы можете установить только компоненты веб-сервера, без графического интерфейса, который вам не нужен. Нужен почтовый сервер? Вы можете запустить выделенный, специализированные почтовый сервис без проблем.
4. Устойчивость
Тоже, как ни странно, это аксиома.
5. Открытые стандарты
Linux свободен от привязки к конкретному продавцу, т.н. “vendor-lock-in“.
6. Интероперабельность
В Linux очень легко общаться по сети с почти любым ПК на любой компьютерной платформе с использованием различных протоколов. Linux с Samba может выступать в качестве файл-сервера Windows и члена домена Active Directory. Linux также имеет очень хороший свободный офис - Open Office, который читает файлы Windows Office.
7. Гибкость
Когда вам нужно что-то в плане программного обеспечения, то не нужно делать абсолютно новые программные разработки. В Linux существует большая вероятность того, что это уже есть и можно просто взять существующий проект и адаптировать его к вашим потребностям. Это происходит все время, и является одним из великих преимуществ СПО, FOSS.
8. Free software - cвободное программное обеспечение
Linux - это не только ОС. При использовании Linux вы не только получаете полноценную операционную систему.
Вы также получаете невероятное количество свободного и открытого исходного программного кода, который делает практически всё, что вам когда-нибудь понадобится.
Это то, про что часто забывают.
Если сравниваете Linux и Windows TCO, то вы смотрите только затраты на операционные системы. Но если вам нужно на чём-то работать в Windows, то это также будет стоить денег. Есть проекты с открытым исходным кодом для Windows, но далеко не столько, как для Linux.
9. Виртуализация
Linux имеет передовые решения для виртуализации, давая вам возможность запуска виртуальных серверов с очень низким уровнем накладных расходов. Вот еще одна возможность подчеркнуть экономию средств. Бесплатная виртуализация доступна на Linux!
10. Стабильное будущее
Linux не исчезнет, он показал очень стабильный рост и поддерживается некоторыми очень крупными компаниями.
Если только одна единственная компания, владеющая и поддерживающая проприетарную операционную систему и ПО исчезнет, например, в результате кризиса или банкротства, то у вас будут очень большие проблемы.
Но, если все крупные компании, поддерживающие Linux исчезнут, что почти нереально, то код по-прежнему будет доступен всем и любой новый игрок на рынке может просто взять его и продолжить поддержку.
11. Счастливый сисадмин
Linux делает системных администраторов счастливыми.
Linux намного проще и приятнее поддерживать, потому что он сделан для пользователей и за счет пользователей.
Ничто не может конкурировать с Linux, когда дело доходит до администрирования. Linux очень прозрачен и имеет все средства, какие только можно себе представить, в свободном доступе.
Начальники очень хорошо знают как считать деньги, так что это первое, что вы должны сказать, почему вы должны перейти на Linux. Общая стоимость владения (TCO) Linux ниже, чем Windows и это доказано. Подробнее см. здесь “Microsoft, Linux и TCO“
2. Безопасность
Это практически аксиома или постулат, если хотите, современного ИТ мира. Для полной картины прочтите также статью “Microsoft ворует данные“.
3. Производительность
Linux - это высокопроизводительная ОС. Благодаря своей модульной природе все части операционной системы Linux могут быть легко добавлены или удалены, операционная система Linux может быть легко настроена для конкретной цели. Нужен веб-сервер? Вы можете установить только компоненты веб-сервера, без графического интерфейса, который вам не нужен. Нужен почтовый сервер? Вы можете запустить выделенный, специализированные почтовый сервис без проблем.
4. Устойчивость
Тоже, как ни странно, это аксиома.
5. Открытые стандарты
Linux свободен от привязки к конкретному продавцу, т.н. “vendor-lock-in“.
6. Интероперабельность
В Linux очень легко общаться по сети с почти любым ПК на любой компьютерной платформе с использованием различных протоколов. Linux с Samba может выступать в качестве файл-сервера Windows и члена домена Active Directory. Linux также имеет очень хороший свободный офис - Open Office, который читает файлы Windows Office.
7. Гибкость
Когда вам нужно что-то в плане программного обеспечения, то не нужно делать абсолютно новые программные разработки. В Linux существует большая вероятность того, что это уже есть и можно просто взять существующий проект и адаптировать его к вашим потребностям. Это происходит все время, и является одним из великих преимуществ СПО, FOSS.
8. Free software - cвободное программное обеспечение
Linux - это не только ОС. При использовании Linux вы не только получаете полноценную операционную систему.
Вы также получаете невероятное количество свободного и открытого исходного программного кода, который делает практически всё, что вам когда-нибудь понадобится.
Это то, про что часто забывают.
Если сравниваете Linux и Windows TCO, то вы смотрите только затраты на операционные системы. Но если вам нужно на чём-то работать в Windows, то это также будет стоить денег. Есть проекты с открытым исходным кодом для Windows, но далеко не столько, как для Linux.
9. Виртуализация
Linux имеет передовые решения для виртуализации, давая вам возможность запуска виртуальных серверов с очень низким уровнем накладных расходов. Вот еще одна возможность подчеркнуть экономию средств. Бесплатная виртуализация доступна на Linux!
10. Стабильное будущее
Linux не исчезнет, он показал очень стабильный рост и поддерживается некоторыми очень крупными компаниями.
Если только одна единственная компания, владеющая и поддерживающая проприетарную операционную систему и ПО исчезнет, например, в результате кризиса или банкротства, то у вас будут очень большие проблемы.
Но, если все крупные компании, поддерживающие Linux исчезнут, что почти нереально, то код по-прежнему будет доступен всем и любой новый игрок на рынке может просто взять его и продолжить поддержку.
11. Счастливый сисадмин
Linux делает системных администраторов счастливыми.
Linux намного проще и приятнее поддерживать, потому что он сделан для пользователей и за счет пользователей.
Ничто не может конкурировать с Linux, когда дело доходит до администрирования. Linux очень прозрачен и имеет все средства, какие только можно себе представить, в свободном доступе.
вторник, 24 марта 2009 г.
Используем 2+ провайдера (вторая часть)
Продолжим настройку нашего шлюза, про который я говорил в предыдущей статье. Напомню, там мы настроили правила маршрутизации, теперь нам надо заняться iptables. Сейчас мы настроим сеть состоящую из шлюза и сервера. На шлюзе будет работать SSH и DNS, а сервер у нас будет виндовый на нем у нас RDP и SMTP. Сеть будет настроена таким образом, что через любой из внешних айпишников мы сможем подключаться к любому из серверов, а SMTP сервер будет выходить наружу через основного провайдера.
Ну и конечно, же начнем с переменных, причем вынесем следующие настройки в отдельный файл, это нам сильно пригодиться в будущем:
#!/bin/bash
export GLOBAL_ETH_PRIM=eth1
export GLOBAL_ETH_SEC=eth2
export GLOBAL_IP_PRIM=10.10.10.10
export GLOBAL_IP_SEC=20.20.20.20
export MARK_PRIM=10
export MARK_SEC=20
Назовем этот файл ipt_p1.conf. А содержит он данные о том, какой из интерфейсов является главным, а какой запасным (PRIM и SEC соответственно) и значения для маркировки пакетов.
Перейдем к основному файлу конфигурации iptables, назовем его ipt.conf. Запишем переменные ;-)
#!/bin/bash
IPTABLES=/sbin/iptables
MODPROBE=/sbin/modprobe
Это для того, чтобы меньше зависеть от дистрибутива - пути к исполняемым файлам.
LOCAL_ETH=eth0
GLOBAL_ETH_P1=eth1
GLOBAL_ETH_P2=eth2
LOCAL_IP=192.168.0.1
LOCAL_NET=192.168.0.0/24
GLOBAL_IP_P1=10.10.10.10
GLOBAL_IP_P2=20.20.20.20
Тут мы описали конфигурацию нашей сети, по порядку: локальный интерфейс, интерфейсы, которые смотрят к провайдерам, локальный айпишник и подсеть, айпишники, которые выданы провайдерами.
SRV11=192.168.0.11
SRV12=192.168.0.12
А это наш сервер, для которого мы настраивали маршрутизацию на основе политик, используя метки. Как я уже говорил этот сервер на своем сетевом интерфейсе имеет два айпишника, чуть ниже я расскажу для чего это нам пригодиться.
. $1
Зацепили внешние настройки, в данном случае это будет наш файл ipt_p1.conf.
Хватит о скучном, приступим к настройке, причем попытаемся все сделать красиво:
echo "[+] Flushing existing iptables rules..."
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t raw
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
Очищаем все правила iptables, в первой строке говорим, что делаем, почему по английски, а чтобы не было проблем с кодировками. Последние три строчки устанавливают правила по умолчанию - все пакеты не подходящие под список правил будут просто отброшены.
$MODPROBE ip_conntrack
$MODPROBE iptable_nat
Загрузили модули ядра, которые будем использовать.
Теперь пройдемся по цепочкам iptables и заполним их необходимыми правилами:
echo "[+] Setting up INPUT chain..."
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Используя возможности модуля state мы отбрасываем некорректные пакеты и принимаем пакеты относящиеся к уже установленным соединениям либо ко вторичными соединениям (таким как передача данных в ftp).
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
Принимаем подключения по SSH отовсюду.
$IPTABLES -A INPUT -i $LOCAL_ETH -s $LOCAL_NET -j ACCEPT
Локальный трафик будет ходить без ограничений, хотя это не всегда правильно.
$IPTABLES -A INPUT -i lo -j ACCEPT
Тоже на localhost.
Продолжаем с цепочкой OUTPUT:
echo "[+] Setting up OUTPUT chain..."
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Эти правила аналогичны правилам в цепочке INPUT.
$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p udp --dport 53 -j ACCEPT
Мы разрешили работать нашему DNS серверу через основного провайдера
$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
А также разрешили выходить наружу по SSH.
$IPTABLES -A OUTPUT -o $LOCAL_ETH -d $LOCAL_NET -m state --state NEW -j ACCEPT
Опять же на исходящий локальный трафик ограничений нет.
Переходим к обработке трафика из локальной сети:
echo "[+] Setting up FORWARD chain..."
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Все те же два удобных правила.
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT
Так у нас получается, что пакеты приходящие на первого провайдера пропускаются только на первый айпишник сервера, второго - на второй.
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV11 -j ACCEPT
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV12 -j ACCEPT
Разрашаем весь исходящий трафик с нашего сервера, опять же это не совсем правильно.
Далее идут правила NAT:
$IPTABLES -t nat -A POSTROUTING -s $SRV11 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM
$IPTABLES -t nat -A POSTROUTING -s $SRV12 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM
Все, что наш сервер попытается отправить по SMTP пойдет через основного провайдера.
И опять самое интересное нам осталось на последок. Переходим к PREROUTING, здесь то мы и воспользуемся возможностью маркировать пакеты, которая нам понадобится для маршрутизации вот в этих двух строчках:
ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2
Итак, наши правила:
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM
Все пакеты уходящие с нашего внутреннего сервера на 25 порт мы маркируем значением $MARK_PRIM. Давайте проследим, что это нам дает: исходящий пакет маркируется значением 10, значит маршрутизироваться он будет по таблице T1, а соответствуя этой таблице пакет должен уйти через первого провайдера, в цепочке FORWARD есть разрешающее правило, поэтому пакет безпрепятственно проходит - все правильно это нам и требовалось.
Теперь нам надо разобраться с соединениями идущими к нам. Сначала, конечно же, должен отработать DNAT:
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 25 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 3389 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 25 -j DNAT --to-destination $SRV12
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 3389 -j DNAT --to-destination $SRV12
Вроде бы все правильно, проверяем: пакет приходит на внешний интерфейс шлюза, в зависимости от принадлежности интерфейса провайдеру, он перенаправляется на первый или второй айпишник внутреннего сервера, сервер отвечает с того же(!) айпишника, пакет на шлюзе маршрутизируется по основной таблице, проходит через FORWARD и отправляется через основного провайдера, а вот это уже не правильно, ведь пакет мог прийти и через запасного провайдера. Исправляем, добавляя правила:
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --sport 25 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --sport 3389 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --sport 25 -j MARK --set-mark $MARK_SEC
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --sport 3389 -j MARK --set-mark $MARK_SEC
Теперь на обратном пути мы маркируем пакеты в соответствии с адресом, с которого они отправляются. Далее в дело вступают таблицы маршрутизации T1 и T2, поэтому решение через какой интерфейс отправлять пакеты принимается правильное.
Все! Готово. Для применения правил выполняем команду "./ipt.conf ipt_p1.conf". Теперь наши сервера доступны, пока хотя бы один из провайдеров дает нам доступ в интернет.
Еще хотел рассказать, как можно переключаться между провайдерами и сделать парочку замечаний, но объем статьи и так уже слишком большой, видимо будет третья часть.
Скачать скрипты из первой и второй части.
Ну и конечно, же начнем с переменных, причем вынесем следующие настройки в отдельный файл, это нам сильно пригодиться в будущем:
#!/bin/bash
export GLOBAL_ETH_PRIM=eth1
export GLOBAL_ETH_SEC=eth2
export GLOBAL_IP_PRIM=10.10.10.10
export GLOBAL_IP_SEC=20.20.20.20
export MARK_PRIM=10
export MARK_SEC=20
Назовем этот файл ipt_p1.conf. А содержит он данные о том, какой из интерфейсов является главным, а какой запасным (PRIM и SEC соответственно) и значения для маркировки пакетов.
Перейдем к основному файлу конфигурации iptables, назовем его ipt.conf. Запишем переменные ;-)
#!/bin/bash
IPTABLES=/sbin/iptables
MODPROBE=/sbin/modprobe
Это для того, чтобы меньше зависеть от дистрибутива - пути к исполняемым файлам.
LOCAL_ETH=eth0
GLOBAL_ETH_P1=eth1
GLOBAL_ETH_P2=eth2
LOCAL_IP=192.168.0.1
LOCAL_NET=192.168.0.0/24
GLOBAL_IP_P1=10.10.10.10
GLOBAL_IP_P2=20.20.20.20
Тут мы описали конфигурацию нашей сети, по порядку: локальный интерфейс, интерфейсы, которые смотрят к провайдерам, локальный айпишник и подсеть, айпишники, которые выданы провайдерами.
SRV11=192.168.0.11
SRV12=192.168.0.12
А это наш сервер, для которого мы настраивали маршрутизацию на основе политик, используя метки. Как я уже говорил этот сервер на своем сетевом интерфейсе имеет два айпишника, чуть ниже я расскажу для чего это нам пригодиться.
. $1
Зацепили внешние настройки, в данном случае это будет наш файл ipt_p1.conf.
Хватит о скучном, приступим к настройке, причем попытаемся все сделать красиво:
echo "[+] Flushing existing iptables rules..."
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t raw
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
Очищаем все правила iptables, в первой строке говорим, что делаем, почему по английски, а чтобы не было проблем с кодировками. Последние три строчки устанавливают правила по умолчанию - все пакеты не подходящие под список правил будут просто отброшены.
$MODPROBE ip_conntrack
$MODPROBE iptable_nat
Загрузили модули ядра, которые будем использовать.
Теперь пройдемся по цепочкам iptables и заполним их необходимыми правилами:
echo "[+] Setting up INPUT chain..."
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Используя возможности модуля state мы отбрасываем некорректные пакеты и принимаем пакеты относящиеся к уже установленным соединениям либо ко вторичными соединениям (таким как передача данных в ftp).
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
Принимаем подключения по SSH отовсюду.
$IPTABLES -A INPUT -i $LOCAL_ETH -s $LOCAL_NET -j ACCEPT
Локальный трафик будет ходить без ограничений, хотя это не всегда правильно.
$IPTABLES -A INPUT -i lo -j ACCEPT
Тоже на localhost.
Продолжаем с цепочкой OUTPUT:
echo "[+] Setting up OUTPUT chain..."
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Эти правила аналогичны правилам в цепочке INPUT.
$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p udp --dport 53 -j ACCEPT
Мы разрешили работать нашему DNS серверу через основного провайдера
$IPTABLES -A OUTPUT -o $GLOBAL_ETH_PRIM -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
А также разрешили выходить наружу по SSH.
$IPTABLES -A OUTPUT -o $LOCAL_ETH -d $LOCAL_NET -m state --state NEW -j ACCEPT
Опять же на исходящий локальный трафик ограничений нет.
Переходим к обработке трафика из локальной сети:
echo "[+] Setting up FORWARD chain..."
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Все те же два удобных правила.
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 25 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P1 -d $SRV11 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $GLOBAL_ETH_P2 -d $SRV12 -p tcp --dport 3389 --syn -m state --state NEW -j ACCEPT
Так у нас получается, что пакеты приходящие на первого провайдера пропускаются только на первый айпишник сервера, второго - на второй.
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV11 -j ACCEPT
$IPTABLES -A FORWARD -i $LOCAL_ETH -s $SRV12 -j ACCEPT
Разрашаем весь исходящий трафик с нашего сервера, опять же это не совсем правильно.
Далее идут правила NAT:
$IPTABLES -t nat -A POSTROUTING -s $SRV11 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM
$IPTABLES -t nat -A POSTROUTING -s $SRV12 -p tcp --dport 25 -j SNAT --to-source $GLOBAL_IP_PRIM
Все, что наш сервер попытается отправить по SMTP пойдет через основного провайдера.
И опять самое интересное нам осталось на последок. Переходим к PREROUTING, здесь то мы и воспользуемся возможностью маркировать пакеты, которая нам понадобится для маршрутизации вот в этих двух строчках:
ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2
Итак, наши правила:
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --dport 25 -j MARK --set-mark $MARK_PRIM
Все пакеты уходящие с нашего внутреннего сервера на 25 порт мы маркируем значением $MARK_PRIM. Давайте проследим, что это нам дает: исходящий пакет маркируется значением 10, значит маршрутизироваться он будет по таблице T1, а соответствуя этой таблице пакет должен уйти через первого провайдера, в цепочке FORWARD есть разрешающее правило, поэтому пакет безпрепятственно проходит - все правильно это нам и требовалось.
Теперь нам надо разобраться с соединениями идущими к нам. Сначала, конечно же, должен отработать DNAT:
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 25 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P1 -d $GLOBAL_IP_P1 -p tcp --dport 3389 -j DNAT --to-destination $SRV11
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 25 -j DNAT --to-destination $SRV12
$IPTABLES -t nat -A PREROUTING -i $GLOBAL_ETH_P2 -d $GLOBAL_IP_P2 -p tcp --dport 3389 -j DNAT --to-destination $SRV12
Вроде бы все правильно, проверяем: пакет приходит на внешний интерфейс шлюза, в зависимости от принадлежности интерфейса провайдеру, он перенаправляется на первый или второй айпишник внутреннего сервера, сервер отвечает с того же(!) айпишника, пакет на шлюзе маршрутизируется по основной таблице, проходит через FORWARD и отправляется через основного провайдера, а вот это уже не правильно, ведь пакет мог прийти и через запасного провайдера. Исправляем, добавляя правила:
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --sport 25 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV11 -p tcp --sport 3389 -j MARK --set-mark $MARK_PRIM
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --sport 25 -j MARK --set-mark $MARK_SEC
$IPTABLES -t mangle -A PREROUTING -i $LOCAL_ETH -s $SRV12 -p tcp --sport 3389 -j MARK --set-mark $MARK_SEC
Теперь на обратном пути мы маркируем пакеты в соответствии с адресом, с которого они отправляются. Далее в дело вступают таблицы маршрутизации T1 и T2, поэтому решение через какой интерфейс отправлять пакеты принимается правильное.
Все! Готово. Для применения правил выполняем команду "./ipt.conf ipt_p1.conf". Теперь наши сервера доступны, пока хотя бы один из провайдеров дает нам доступ в интернет.
Еще хотел рассказать, как можно переключаться между провайдерами и сделать парочку замечаний, но объем статьи и так уже слишком большой, видимо будет третья часть.
Скачать скрипты из первой и второй части.
Дублируем весь трафик, проходящий через цепочку FORWARD на адрес сервера съема 172.16.1.2:
#iptables -t mangle -A FORWARD -j ROUTE --tee --gw 172.20.1.2
пятница, 20 марта 2009 г.
использование двух каналов инет
Есть у меня своя домашняя сеть, с linux сервером, и подключена она к интернет с помощью беспроводного соединения — на крыше антена и роутер, к серверу подключено витой парой. Все вобщем то неплохо, канал с гарантированой полосой в обоих направлениях, постоянный IP адрес, довольно надежный — падает редко. Но вот есть у него один минус — цена кусается.
Ценовая политика провайдера построена так, что для того, чтоб увеличить скорость в два раза — платить тоже надо в два раза больше. А скорости хочется больше! И надежности тоже — как то во время сильных заморозков роутеру стало «холодно» и интернета вечером и ночью небыло.
Поэтому задумал я провести домой второй интернет-канал, выбар пал на одного известного на Украине провайдера, предоставляющего доступ по ADSL. У него и тарифы недорогие и модем ADSL стоит недорого. Так я и сделал, подключился, воткнул ADLS модем в свич — все работает. Но от старого доброго беспроводного канала отказываться мне нехотелось, поэтому задумал я сделать так, чтоб интернет трафик шел сразу по обеим каналам, так, чтоб я мог воспользоваться суммарной пропускной способностью. Да еще и чтоб при падении одного канала всю нагрузку на себя брал другой.
После поиска в интернете я выснил, что есть как минимум два решения:
— на уровне файрвола раскидывать TCP сессии по разным интерфейсам. Недостатки — сайты, которые имею привязку сессий к IP адресу перестанут работать, так как последовательные запросы от одного пользователя могут приходить по разным каналам и с разных IP.
— на уровне маршрутизации раскидывать маршруты через разные интерфейсы. Проблем перового решения небудет, так как маршруты кешируются и последующие обращения к одному адресу будут идти через один и тот же интерфейс. Но балансировка будет не такая точная, и качая с одного сервера даже в несколько потоков не удастся достигнуть суммарной скорости двух каналов.
Я выбрал для себя балансировку с помощью маршрутизации, так как мне была очень важна стабильная работа всех сайтов, ну и эта функциональность уже была в моем ядре, а файрвол пришлось бы патчить.
Итак, приступим!
Для начала определим переменные:
$ cat /etc/balance/vars
1. #!/bin/bash
2.
3. # LAN interface
4. IF0="eth1"
5.
6. # WAN interface 1
7. IF1="eth0"
8.
9. # WAN interface 2
10. IF2="ppp0"
11.
12. IP1="194.9.xx.xx"
13. IP2="`ip addr show $IF2 | grep inet | awk '{print $2}'`"
14.
15. # gateway 1
16. P1="194.9.xx.xx"
17. # gateway 2
18. P2="195.5.xx.xx"
19.
20. # LAN netmask
21. P0_NET="192.168.0.0/24"
22. # WAN1 netmask
23. P1_NET="194.9.xx.xx/xx"
24. # WAN2 netmask
25. P2_NET="195.5.xx.xx/xx"
26.
27.
28. TBL1="provider1"
29. TBL2="provider2"
30.
31. # Realtive weight of channels bandwidth
32. W1="2"
33. W2="1"
Добавим в файл /etc/iproute2/rt_tables две дополнительные таблицы маршрутизации:
echo "1 provider1" >> /etc/iproute2/rt_tables
echo "2 provider2" >> /etc/iproute2/rt_tables
Теперь напишем скрипт, который будет прописывать все необходимые маршруты и правила файрвола:
cat /etc/balance/routing.sh
1. #!/bin/bash
2.
3. . /etc/balance/vars
4.
5. echo "1" > /proc/sys/net/ipv4/ip_forward
6.
7.
8. ip route add $P1_NET dev $IF1 src $IP1 table $TBL1 > /dev/null 2>&1
9. ip route add default via $P1 table $TBL1 > /dev/null 2>&1
10. ip route add $P2_NET dev $IF2 src $IP2 table $TBL2 > /dev/null 2>&1
11. ip route add default via $P2 table $TBL2 > /dev/null 2>&1
12.
13. ip route add $P1_NET dev $IF1 src $IP1 > /dev/null 2>&1
14. ip route add $P2_NET dev $IF2 src $IP2
15.
16. ip route add default via $P1 > /dev/null 2>&1
17.
18. ip rule add from $IP1 table $TBL1 > /dev/null 2>&1
19. ip rule add from $IP2 table $TBL2 > /dev/null 2>&1
20.
21.
22. ip route add $P0_NET dev $IF0 table $TBL1 > /dev/null 2>&1
23. ip route add $P2_NET dev $IF2 table $TBL1 > /dev/null 2>&1
24. ip route add 127.0.0.0/8 dev lo table $TBL1 > /dev/null 2>&1
25. ip route add $P0_NET dev $IF0 table $TBL2 > /dev/null 2>&1
26. ip route add $P1_NET dev $IF1 table $TBL2 > /dev/null 2>&1
27. ip route add 127.0.0.0/8 dev lo table $TBL2 > /dev/null 2>&1
28.
29. iptables -t nat -F POSTROUTING
30. iptables -t nat -A POSTROUTING -s $P0_NET -o $IF1 -j MASQUERADE
31. iptables -t nat -A POSTROUTING -s $P0_NET -o $IF2 -j MASQUERADE
Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос, а так же маскарадинг а обоих интерфейсах.
Теперь напишем скрипт, который будет определять, работатет ли тот или иной канал и соответственно менять записи шлюза по умолчанию.
$ cat /etc/balance/check.sh
1. #!/bin/bash
2.
3. . /etc/balance/vars
4.
5. OLDIF1=0
6. OLDIF2=0
7.
8. . /etc/balance/routing.sh
9. while true; do
10.
11.
12. ping -c 3 -s 100 $P1 -I $IF1 > /dev/null
13. if [ $? -ne 0 ]; then
14. echo "Failed IF1!"
15. NEWIF1=0
16. else
17. NEWIF1=1
18. fi
19.
20. ping -c 3 -s 100 $P2 -I $IF2 > /dev/null
21. if [ $? -ne 0 ]; then
22. echo "Failed IF2!"
23. NEWIF2=0
24. else
25. NEWIF2=1
26. fi
27.
28. if (( ($NEWIF1!=$OLDIF1) || ($NEWIF2!=$OLDIF2) )); then
29. echo "Changing routes"
30.
31. if (( ($NEWIF1==1) && ($NEWIF2==1) )); then
32. echo "Both channels"
33. ip route delete default
34. ip route add default scope global nexthop via $P1 dev $IF1 weight $W1 \
35. nexthop via $P2 dev $IF2 weight $W2
36. elif (( ($NEWIF1==1) && ($NEWIF2==0) )); then
37. echo "First channel"
38. ip route delete default
39. ip route add default via $P1 dev $IF1
40. elif (( ($NEWIF1==0) && ($NEWIF2==1) )); then
41. echo "Second channel"
42. ip route delete default
43. ip route add default via $P2 dev $IF2
44. fi
45.
46. else
47. echo "Not changed"
48. fi
49.
50. OLDIF1=$NEWIF1
51. OLDIF2=$NEWIF2
52. sleep 3
53. done
Работу канала проверяем пингуя шлюз, и если нет ответа на 3 пинга подряд — мы считаем, что канал упал, и соответственно исключаем его из таблицы маршрутизации.
Таким образом, если работают оба канала:
$ ip route
195.5.xx.xx dev ppp0 proto kernel scope link src 95.133.xx.xx
194.9.xx.xx/xx dev eth0 proto kernel scope link src 194.9.xx.xx
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.75
default
nexthop via 194.9.xx.xx dev eth0 weight 2
nexthop via 195.5.xx.xx dev ppp0 weight 1
Итого имеем два default gw, первый с весом 2 и второй с весом 1. Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.
Для того, чтобы кастомизировать эти скрипты под ваши нужды необходимо настроить значения в файле vars, остальные скрипты практически не требуют настройки.
Здесь я хочу рассказать о настройке шлюза на Linux'e, для использования 2-х (и более) провайдеров интернета.
Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе "policy routing" (т.е. маршрутизация на основе политик), а не "destination routing" (маршрутизация на основе адреса получателя).
Итак, приступим. Для начала определимся с переменными:
#!/bin/bash
IF1=eth1
IF2=eth2
IF - это сетевые интерфейсы, которые смотрят в интернет, через наших провайдеров
IP1=10.10.10.10
IP2=20.20.20.20
IP - это наши внешние IP-адреса, которые нам выдали провайдеры
P1=10.10.10.1
P2=20.20.20.1
P - это шлюзы по умолчанию у наших провайдеров
Policy routing позволяет выполнять маршрутизацию на основе адреса источника поэтому перечислим сервера которые будут учавствовать:
SRV11=192.168.0.11
SRV12=192.168.0.12
Здесь SRV11 и SRV12 - это два айпишника одного и тогоже сервера (это важно!), это позволяет одному серверу обрабатывать входящие соединения с двух провайдеров. Конечно же, существуют и другие варианты реализовать эту возможность, но я буду использовать именно айпишники, мне кажется для начала так будет проше.
Ну а теперь самое интересное - пишем правило для маршрутизации.
Первое что мы должны сделать это добавить свои таблицы маршрутизации, для этого необходимо отредактировать файл /etc/iproute2/rt_tables, например так:
#echo "101 T1" >> /etc/iproute2/rt_tables
#echo "102 T2" >> /etc/iproute2/rt_tables
Заполняем первую таблицу:
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
Тоесть мы добавляем маршруты, в которых указываем что попасть в подсеть первого провайдера можно через первый интерфейс. Во второй строчке мы добавляем шлюз по умолчанию.
Тоже самое и во второй:
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
Затем разберемся с основной таблицей, которая называется "main". Ее мы видим, когда набираем ip route:
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip route add default via $P1 metric 10
Первые две строчки аналогичны предыдущим записям, только опущено "table main". В третьей строчке задается маршрут по умолчанию с указанием метрики.
На этом с маршрутизацией разобрались, чтобы посмотреть что у нас находится в таблице маршрутизации можно выполнить команду "ip route show table <имя таблицы>". Теперь приступим к правилам. Как раз по правилам и будет приниматься решения какой пакет по какой таблице будет маршрутизироваться.
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
Здесь мы указали, что если адрес источника равен первому внешнему адресу, тогда маршрутизация выполняется по таблице T1. Аналогично вторая запись.
И наконец самое интересное:
ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2
Используя iptables мы можем маркировать интересующие нас пакеты и маршрутизировать их на основе этих меток. Собственно здесь мы добавили два правила: для пакетов, имеющих метку 10, использовать таблицу T1, для пакетов с меткой 20 - T2. Сейчас возможно не очень понятно для чего это может потребоваться, но из правил iptables все станет ясно. Для просмотра правил выполняем "ip rule", при маршрутизации они проверяются по порядку.
Ну вот половина работы сделана осталось написать правила для iptables, об этом мы поговорим во второй части.
Ценовая политика провайдера построена так, что для того, чтоб увеличить скорость в два раза — платить тоже надо в два раза больше. А скорости хочется больше! И надежности тоже — как то во время сильных заморозков роутеру стало «холодно» и интернета вечером и ночью небыло.
Поэтому задумал я провести домой второй интернет-канал, выбар пал на одного известного на Украине провайдера, предоставляющего доступ по ADSL. У него и тарифы недорогие и модем ADSL стоит недорого. Так я и сделал, подключился, воткнул ADLS модем в свич — все работает. Но от старого доброго беспроводного канала отказываться мне нехотелось, поэтому задумал я сделать так, чтоб интернет трафик шел сразу по обеим каналам, так, чтоб я мог воспользоваться суммарной пропускной способностью. Да еще и чтоб при падении одного канала всю нагрузку на себя брал другой.
После поиска в интернете я выснил, что есть как минимум два решения:
— на уровне файрвола раскидывать TCP сессии по разным интерфейсам. Недостатки — сайты, которые имею привязку сессий к IP адресу перестанут работать, так как последовательные запросы от одного пользователя могут приходить по разным каналам и с разных IP.
— на уровне маршрутизации раскидывать маршруты через разные интерфейсы. Проблем перового решения небудет, так как маршруты кешируются и последующие обращения к одному адресу будут идти через один и тот же интерфейс. Но балансировка будет не такая точная, и качая с одного сервера даже в несколько потоков не удастся достигнуть суммарной скорости двух каналов.
Я выбрал для себя балансировку с помощью маршрутизации, так как мне была очень важна стабильная работа всех сайтов, ну и эта функциональность уже была в моем ядре, а файрвол пришлось бы патчить.
Итак, приступим!
Для начала определим переменные:
$ cat /etc/balance/vars
1. #!/bin/bash
2.
3. # LAN interface
4. IF0="eth1"
5.
6. # WAN interface 1
7. IF1="eth0"
8.
9. # WAN interface 2
10. IF2="ppp0"
11.
12. IP1="194.9.xx.xx"
13. IP2="`ip addr show $IF2 | grep inet | awk '{print $2}'`"
14.
15. # gateway 1
16. P1="194.9.xx.xx"
17. # gateway 2
18. P2="195.5.xx.xx"
19.
20. # LAN netmask
21. P0_NET="192.168.0.0/24"
22. # WAN1 netmask
23. P1_NET="194.9.xx.xx/xx"
24. # WAN2 netmask
25. P2_NET="195.5.xx.xx/xx"
26.
27.
28. TBL1="provider1"
29. TBL2="provider2"
30.
31. # Realtive weight of channels bandwidth
32. W1="2"
33. W2="1"
Добавим в файл /etc/iproute2/rt_tables две дополнительные таблицы маршрутизации:
echo "1 provider1" >> /etc/iproute2/rt_tables
echo "2 provider2" >> /etc/iproute2/rt_tables
Теперь напишем скрипт, который будет прописывать все необходимые маршруты и правила файрвола:
cat /etc/balance/routing.sh
1. #!/bin/bash
2.
3. . /etc/balance/vars
4.
5. echo "1" > /proc/sys/net/ipv4/ip_forward
6.
7.
8. ip route add $P1_NET dev $IF1 src $IP1 table $TBL1 > /dev/null 2>&1
9. ip route add default via $P1 table $TBL1 > /dev/null 2>&1
10. ip route add $P2_NET dev $IF2 src $IP2 table $TBL2 > /dev/null 2>&1
11. ip route add default via $P2 table $TBL2 > /dev/null 2>&1
12.
13. ip route add $P1_NET dev $IF1 src $IP1 > /dev/null 2>&1
14. ip route add $P2_NET dev $IF2 src $IP2
15.
16. ip route add default via $P1 > /dev/null 2>&1
17.
18. ip rule add from $IP1 table $TBL1 > /dev/null 2>&1
19. ip rule add from $IP2 table $TBL2 > /dev/null 2>&1
20.
21.
22. ip route add $P0_NET dev $IF0 table $TBL1 > /dev/null 2>&1
23. ip route add $P2_NET dev $IF2 table $TBL1 > /dev/null 2>&1
24. ip route add 127.0.0.0/8 dev lo table $TBL1 > /dev/null 2>&1
25. ip route add $P0_NET dev $IF0 table $TBL2 > /dev/null 2>&1
26. ip route add $P1_NET dev $IF1 table $TBL2 > /dev/null 2>&1
27. ip route add 127.0.0.0/8 dev lo table $TBL2 > /dev/null 2>&1
28.
29. iptables -t nat -F POSTROUTING
30. iptables -t nat -A POSTROUTING -s $P0_NET -o $IF1 -j MASQUERADE
31. iptables -t nat -A POSTROUTING -s $P0_NET -o $IF2 -j MASQUERADE
Этот набор команд обеспечивает маршрутизацию ответов через интерфейс, на котором был получен запрос, а так же маскарадинг а обоих интерфейсах.
Теперь напишем скрипт, который будет определять, работатет ли тот или иной канал и соответственно менять записи шлюза по умолчанию.
$ cat /etc/balance/check.sh
1. #!/bin/bash
2.
3. . /etc/balance/vars
4.
5. OLDIF1=0
6. OLDIF2=0
7.
8. . /etc/balance/routing.sh
9. while true; do
10.
11.
12. ping -c 3 -s 100 $P1 -I $IF1 > /dev/null
13. if [ $? -ne 0 ]; then
14. echo "Failed IF1!"
15. NEWIF1=0
16. else
17. NEWIF1=1
18. fi
19.
20. ping -c 3 -s 100 $P2 -I $IF2 > /dev/null
21. if [ $? -ne 0 ]; then
22. echo "Failed IF2!"
23. NEWIF2=0
24. else
25. NEWIF2=1
26. fi
27.
28. if (( ($NEWIF1!=$OLDIF1) || ($NEWIF2!=$OLDIF2) )); then
29. echo "Changing routes"
30.
31. if (( ($NEWIF1==1) && ($NEWIF2==1) )); then
32. echo "Both channels"
33. ip route delete default
34. ip route add default scope global nexthop via $P1 dev $IF1 weight $W1 \
35. nexthop via $P2 dev $IF2 weight $W2
36. elif (( ($NEWIF1==1) && ($NEWIF2==0) )); then
37. echo "First channel"
38. ip route delete default
39. ip route add default via $P1 dev $IF1
40. elif (( ($NEWIF1==0) && ($NEWIF2==1) )); then
41. echo "Second channel"
42. ip route delete default
43. ip route add default via $P2 dev $IF2
44. fi
45.
46. else
47. echo "Not changed"
48. fi
49.
50. OLDIF1=$NEWIF1
51. OLDIF2=$NEWIF2
52. sleep 3
53. done
Работу канала проверяем пингуя шлюз, и если нет ответа на 3 пинга подряд — мы считаем, что канал упал, и соответственно исключаем его из таблицы маршрутизации.
Таким образом, если работают оба канала:
$ ip route
195.5.xx.xx dev ppp0 proto kernel scope link src 95.133.xx.xx
194.9.xx.xx/xx dev eth0 proto kernel scope link src 194.9.xx.xx
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.75
default
nexthop via 194.9.xx.xx dev eth0 weight 2
nexthop via 195.5.xx.xx dev ppp0 weight 1
Итого имеем два default gw, первый с весом 2 и второй с весом 1. Тоесть через первый канал пойдет в два раза больше трафика, чем через второй.
Для того, чтобы кастомизировать эти скрипты под ваши нужды необходимо настроить значения в файле vars, остальные скрипты практически не требуют настройки.
Здесь я хочу рассказать о настройке шлюза на Linux'e, для использования 2-х (и более) провайдеров интернета.
Для настройки мы будем использовать возможности iptables и утилиты ip из пакета, который как правило называется iproute2. А для решения поставленной задачи пакеты мы будем маршрутизировать на основе "policy routing" (т.е. маршрутизация на основе политик), а не "destination routing" (маршрутизация на основе адреса получателя).
Итак, приступим. Для начала определимся с переменными:
#!/bin/bash
IF1=eth1
IF2=eth2
IF - это сетевые интерфейсы, которые смотрят в интернет, через наших провайдеров
IP1=10.10.10.10
IP2=20.20.20.20
IP - это наши внешние IP-адреса, которые нам выдали провайдеры
P1=10.10.10.1
P2=20.20.20.1
P - это шлюзы по умолчанию у наших провайдеров
Policy routing позволяет выполнять маршрутизацию на основе адреса источника поэтому перечислим сервера которые будут учавствовать:
SRV11=192.168.0.11
SRV12=192.168.0.12
Здесь SRV11 и SRV12 - это два айпишника одного и тогоже сервера (это важно!), это позволяет одному серверу обрабатывать входящие соединения с двух провайдеров. Конечно же, существуют и другие варианты реализовать эту возможность, но я буду использовать именно айпишники, мне кажется для начала так будет проше.
Ну а теперь самое интересное - пишем правило для маршрутизации.
Первое что мы должны сделать это добавить свои таблицы маршрутизации, для этого необходимо отредактировать файл /etc/iproute2/rt_tables, например так:
#echo "101 T1" >> /etc/iproute2/rt_tables
#echo "102 T2" >> /etc/iproute2/rt_tables
Заполняем первую таблицу:
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
Тоесть мы добавляем маршруты, в которых указываем что попасть в подсеть первого провайдера можно через первый интерфейс. Во второй строчке мы добавляем шлюз по умолчанию.
Тоже самое и во второй:
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
Затем разберемся с основной таблицей, которая называется "main". Ее мы видим, когда набираем ip route:
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip route add default via $P1 metric 10
Первые две строчки аналогичны предыдущим записям, только опущено "table main". В третьей строчке задается маршрут по умолчанию с указанием метрики.
На этом с маршрутизацией разобрались, чтобы посмотреть что у нас находится в таблице маршрутизации можно выполнить команду "ip route show table <имя таблицы>". Теперь приступим к правилам. Как раз по правилам и будет приниматься решения какой пакет по какой таблице будет маршрутизироваться.
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
Здесь мы указали, что если адрес источника равен первому внешнему адресу, тогда маршрутизация выполняется по таблице T1. Аналогично вторая запись.
И наконец самое интересное:
ip rule add from $SRV11 fwmark 10 table T1
ip rule add from $SRV12 fwmark 20 table T2
Используя iptables мы можем маркировать интересующие нас пакеты и маршрутизировать их на основе этих меток. Собственно здесь мы добавили два правила: для пакетов, имеющих метку 10, использовать таблицу T1, для пакетов с меткой 20 - T2. Сейчас возможно не очень понятно для чего это может потребоваться, но из правил iptables все станет ясно. Для просмотра правил выполняем "ip rule", при маршрутизации они проверяются по порядку.
Ну вот половина работы сделана осталось написать правила для iptables, об этом мы поговорим во второй части.
четверг, 12 марта 2009 г.
squid - AD
http://www.flatmtn.com/article/setting-squid-ntlm-auth
http://www.papercut.com/kb/Main/ConfiguringSquidProxyToAuthenticateWithActiveDirectAd
http://www.papercut.com/kb/Main/ConfiguringSquidProxyToAuthenticateWithActiveDirectAd
Рассылка дисков - и как это всё происходит на самом деле
http://mydebianblog.blogspot.com/2009/03/blog-post_09.html
Как-то у меня коллега Garfeild спросил, как лучше упаковывать диски при отправке. Думаю, эта информация будет полезна тем, кто решил / решает заняться этим хлопотным, но полезным делом. Накопленные ошибки и наступленные грабли выложены ниже
Предисловие
Время от времени при рассчётах за оплату дисков для отправки приходится сталкиваться с откровенно хамскими личностями. Они начинают высчитывать до копейки стоимость отправлений, придираются к непрезентабельной упаковке, требуют десятки дисков за себестоимость носителей и начинают сокрушаться о "погибели опенсорс-духа" вообще и в моём лице в особенности. Таким гражданам я по возможности вежливо отказываю и / или посылаю в линуксцентр. Там им называют совсем другие цены, и желающие купить по почте 20 дистрибутивов за 200 рублей в графе "Итого" наблюдают астрономические цифры.
Так вот, ежели кто сомневается в духе опенсорс - отвечаю словами Ричарда Столмена: "free market from any kind", то бишь "свободный рынок чего угодно". Есть я, есть местные аксакалы и есть Линуксцентр/Nixp.ru. Выбирайте.
Технология отправки дисков почтой
Очень надеюсь, что это не прочтут работники почтовых отделений,
в которых я отправляю письма :-)
Этап 0. Формулировка заказа
Добиться точной формулировки заказа и точного адреса. Это бывает нелегко: постоянные жители Интернета в ряде случаев не помнят свой точный адрес, а некоторые не подозревают о существовании почтовых индексов. Заказ должен формулироваться точно, никаких разночтений. Способы оплаты - минимум геморроя, минимум экзотики. Лучше всего сбербанком, на мобильник или электронными деньгами. Переводить лучше в систему электронных денег, которая позволяет быстро отслеживать приход и выводить деньги в наличность / счёт в российском банке. У меня это яндекс.деньги.
Короче:
* точный (документальный) заказ
* точный (полный) адрес
* способ оплаты
Этап 1. Подготовка
Диски лучше всего покупать на шпинделе, и сразу штук 100 - дешевле и удобнее. Никаких no-name / Мань-Лянь и прочей безродной китайщины - только честную китайщину типа Verbatim и TDK.
Далее, на почте закупаемся конвертами за 1р30коп (они формата 23х16 см). Именно таких - в них помещается с запасом для упаковки диск по высоте. И по ширине можно запихнуть два в ряд, если очень постараться. В такой конверт без скрипа влезает 8-9 дисков. И ещё парочку покупаем полноформатных конвертов А4, за 4 рубля. Туда насовать дисков можно до одури.
Кроме того, пойти на рынок и купить простой китайский клей-карандаш, фломастер для дисков, шариковую ручку и скотч, а так же где-нибудь найти пупырчатый упаковочный материал (можно купить или, идя по улице, смотреть по сторонам и не упускать момент) и картонные коробки - например, от купленного оборудования.
Кроме того, заводим таблицу (или базу данных) - для отслеживания заказов и их состояния (если планируются масштабные отправки дисков).
Сразу отвечаю на вопрос: почему я отправляю только письмами и никогда - посылками. Очень просто: заказное письмо - самый дешёвый и технологичный вид отправлений. Легко и просто наклепать десяток заказных писем и не мучаться с посылками, заполняя на почте описи и платя за всё это весьма ощутимые деньги.
Короче, потребуется:
* конверты 23x16 см и 21х29см
* клей-карандаш
* шариковая ручка
* фломастер для дисков
* скотч
* упаковка (картон и пупырчатый полиэтилен)
Этап 2. Пропаливание
Оплата получена - можно палить диски. Лучше это поставить на скрипты - тыкать по цветастым кнопкам быстро надоест. Лично у меня каждый диск проходит проверку на совпадение контрольных md5-сумм после прожига. Это удлиняет время обработки заказа, но даёт гарантию, что диск читается.
Поначалу я иногда отправлял диски с упреждением - то есть ещё до оплаты. В честности некоторых линуксоидов пришлось разочароваться: от троих деньги так и не пришли. Так что после этого я жёстко следую формуле "утром деньги - вечером стулья", отступая от неё лишь в крайних случаях (вопрос жизни и смерти / прокуратура стучит сапогами у дверей по поводу ворованного софта / угроза выхода из строя стратегических объектов жизнеобеспечения).
Скрипты пропаливания и проверки есть у меня в блоге. Готовые диски подписываются, и сразу складываются на уже заполненный конверт - чтобы потом не забыть, что и кому отправляется.
Короче:
* пропаливаем диск
* проверяем md5-суммы
* подписываем диск
Этап 3. Упаковка
Здесь начинается всё самое весёлое. Упаковка! То, о чём так часто забывают скрупулёзные и скуповатые рыцари духа Опенсорс. Если вы просто накидаете дисков в конверт и отправите - к месту назначения придёт кучка сверкающих обломков.
Методом проб и ошибок найдены несколько технологий упаковки, которые дают хороший результат: диски приходят в нормальном состоянии и всё читается. Читаются даже те, что приходят с возвратом! Итак:
3.1 Картон + пупырчатый полиэтилен + бумага
Берём картонку, вдвое превышающую по формату конверт, сгибаем пополам, вкладываем туда отрезанный под размер пупырчатый полиэтилен (это очень эротичное занятие, поверьте мне). Теперь накладываем туда диски, стараясь класть их в "шахматном" порядке. Разделяем старой бумагой / газетой. В итоге получился бутерброд из дисков, картона и пупырышков. Теперь - важный момент! - несильно сжимаем этот бутерброд и перетягиваем его скотчем.
Скотчем клеем не только по вертикали, но и по горизонтали, стягивая друг к другу края "бутерброда" из дисков.
Если этого не сделать, диски в процессе транспортировки будут болтаться по конверту и поцарапаются!
Это если дисков мало (до 8 штук), а если много (больше 10) - такой способ не пройдёт. Тут нам пригодятся крупные конверты и старые глянцевые (или не очень) журналы, а так же красочные буклеты от купленного когда-то железа.
3.2 Картон + буклет
Берём журнал / буклет и набиваем его дисками, помещая между страницами. Шахматный порядок дисков тут тоже важен. Потом подкладываем под одну сторону картонку (для жёсткости), на первую и последнюю станицу вкладываем пупырчатую упаковку и всё это перетягиваем скотчем. Получится тоже бутерброд, только больше :-)
Ешё более простой и демократичный способ:
3.3. Части книги
Можно использовать ненужные книжки или методические пособия. Разрываем их на нужное количество половинок и вкладываем диски в шахматном порядке между страниц. Первую и последнюю страницу, содержащие диски, лучше всего склеивать скотчем, чтобы диски не болтались при транспортировке. Доходит превосходно, как и в предыдущих случаях.
Теперь осталось это всунуть в конверт - море положительных эмоций гарантировано. В деле запихивания упакованных дисков в конверт могут пригодиться навыки игры в тетрис, ножницы и линейка.
Даже если вам удастся всё это засунуть в конверт, его ещё надо заклеить. Про клей-карандаш было сказано совсем не зря: если вы думаете, что за рупь-тридцать вам густо намажут полоску конверта клеем - время в этом разочароваться.
Намазываем густо клей-карандашом тыльную сторону конверта и, в разумных пределах прикладывая грубую физическую силу, пытаемся две половинки конверта свести. Яростно трём клеевую полоску конверта, чтобы оно-таки схватилось с бумагой.
Внимание! Не вздумайте заклеивать конверт скотчем вместо клея! Это вправе делать только сами почтовики на пересылочных пунктах, о чём на конверте ставится печать: "Поступило в Н-ск МСЦ закленное клейкой лентой". Мне в своё время за это на почте надавали по шее. Только клеем, причём так, чтобы у работников почты не возникло и мысли о лёгком вскрытии конверта. При сомнениях о содержимом письма и плохой проклеенности они могут полезть внутрь.. и увидев там диски, с чувством выполненного долга разводят вас на ценное ускоренное письмо или того хуже посылку. Но об этом позже.
Теперь осматриваем этот здоровенный и пухлый конвертище - и если видим, что он начинает расходиться по швам, берём клей-карандаш снова и проходимся по швам.
Ну и что мы после этого говорим тем, кто жадничает нам двадцатник? :-)
Этап 4. Отправка.
Такое письмо (не менее 50 грамм) в почтовый ящик у почтамта опускать не стоит, ибо это уже не простое письмо, а как минимум заказное, что стоит больших денег. Так что начинается психология, партизанщина и дипломатия: вам предстоит завалить босса уровняобщение с сотрудниками почты.
Значит, так: посылать диски заказными письмами нельзя. Это считается "товарным вложением" и если сотрудник почты прознается, то завернёт вас на ценное ускоренное письмо / посылку. Это влетит в 80-100 рублей и больше, в зависимости от веса и дальности. Заказное письмо стоит 20-25 рублей, максимум - 30.
Насчёт "товарных вложений" - тут ваша совесть должна быть кристально чиста: вы пересылаете лицензионное опенсорсное ПО, способствуя распространению никс-систем и вытеснению подлой проприетарщины.
На самом деле, почтовикам просто не нужна дополнительная ответственность за пересылку хрупкого предмета в конверте - ведь в случае чего, чек останется у вас и вы можете крупно попортить нервы почте (дураков хватает и прецеденты были). Но если диски упакованы по технологиям, описанным выше - всё отлично доходит, дёшево и быстро, и все счастливы.
Стало быть, ваша задача - чтобы сотрудник почты об этом не догадался либо получил от вас бодрый энергичный ответ, который его успокоит. Поэтому при вопросах "что в письме" и "почему такое пухлое" бодро отвечаем, что это книжка / буклет - и никаких придумок на ходу.
Если письмо заклеено не плотно - сотрудник почты может его вскрыть. Мало ли, что вы собрались посылать - может, оно тикает и вибрирует? :-)
Именно поэтому у Линуксцентра так дорого, а у меня дешевле: они - компания, и распорядок Почты для них закон. Поэтому они отправляют посылками и с солидной задержкой (никто специально ради вас на почту не ломанётся). Для частных лиц устав почты носит, скажем так, рекомендательный характер :-)
Так вот, с чувством собственной правоты, которое "достигается упражнением", убеждаем почтаря в том, что вы посылаете книжку или буклетик. Отвечаем чётко и убедительно, с ясным взглядом выдерживая этот допрос с пристрастием.
Когда сотруднику почты надоест это дело, скорее всего, конверты отправят и чек отдадут (сохраняйте его обязательно!). Но если вы будете этим промышлять регулярно, ваша физиономия быстро примелькается, и допросы с пристрастем могут быть более длительными и коварными - здесь всё зависит от сотрудника почты. Многим наплевать, что вы посылаете, но есть и сугубо принципиальные товарищи. Тут главное ни в коем случае не хамить и быть предельно вежливым - почтовых отделений поблизости мало даже в Москве, и плевать в колодец совершенно не стоит.
Это к слову о партизанщине: разузнайте, где ещё в пределах вашей досягаемости есть почтовые отделения. Отправлять письма можно откуда угодно - не обязательно с почты по месту жительства. Если вы занимаетесь отправкой таких писем часто, есть смысл наведываться в разные почтовые отделения.
Этап 5. После отправки.
Известите того, кому посылаете диски, что они отправлены. Лучше приложить отсканированный чек с почты - так можно отследить на сайте почты, что диски на самом деле отправлены.
Со сроками дохода всё сложнее: обычно - неделя или полторы. От дальности зависит слабо: в Петропавловск-Камчатский одно письмо долетело за четыре дня, а в Вологду тащилось месяц.
Резюме
Здесь я постарался описать технологию пересылки дисков - может быть, кто-то захочет заниматься отправкой дисков. И чтобы получатель не рассматривал красивые обломки вместо долгожданного диска с дистрибутивом, я поделился своим скромным (более сотни почтовых отправлений) опытом по этой части.
Эпилог
- "Виренс, ну и зачем тебе всё это надо!?" - спросит, может быть, любопытствующий читатель. Отвечаю:
1. Время, потраченное вместо флейма на ЛОРе, можно использовать лучше. Например, помогая распространению *никс-систем.
2. Помогать другим людям вообще приятно. Особенно получая письма, что диски пришли :-)
3. Рассылка дисков не приносит огромных прибылей, но на оплату интернета, мобильника и коммунальных платежей вполне хватет.
4. И, наконец, философское: когда солнце моих дней зайдёт окончательно, и меня, может быть, спросят "так что ты сделал, чтобы тот мир стал немного лучше?" - и мне будет, что ответить :-)
В общем, рассылка дисков - дело интересное, хлопотное, увлекательное, забавное, поучительное и до некоторой степени прибыльное.
Как-то у меня коллега Garfeild спросил, как лучше упаковывать диски при отправке. Думаю, эта информация будет полезна тем, кто решил / решает заняться этим хлопотным, но полезным делом. Накопленные ошибки и наступленные грабли выложены ниже
Предисловие
Время от времени при рассчётах за оплату дисков для отправки приходится сталкиваться с откровенно хамскими личностями. Они начинают высчитывать до копейки стоимость отправлений, придираются к непрезентабельной упаковке, требуют десятки дисков за себестоимость носителей и начинают сокрушаться о "погибели опенсорс-духа" вообще и в моём лице в особенности. Таким гражданам я по возможности вежливо отказываю и / или посылаю в линуксцентр. Там им называют совсем другие цены, и желающие купить по почте 20 дистрибутивов за 200 рублей в графе "Итого" наблюдают астрономические цифры.
Так вот, ежели кто сомневается в духе опенсорс - отвечаю словами Ричарда Столмена: "free market from any kind", то бишь "свободный рынок чего угодно". Есть я, есть местные аксакалы и есть Линуксцентр/Nixp.ru. Выбирайте.
Технология отправки дисков почтой
Очень надеюсь, что это не прочтут работники почтовых отделений,
в которых я отправляю письма :-)
Этап 0. Формулировка заказа
Добиться точной формулировки заказа и точного адреса. Это бывает нелегко: постоянные жители Интернета в ряде случаев не помнят свой точный адрес, а некоторые не подозревают о существовании почтовых индексов. Заказ должен формулироваться точно, никаких разночтений. Способы оплаты - минимум геморроя, минимум экзотики. Лучше всего сбербанком, на мобильник или электронными деньгами. Переводить лучше в систему электронных денег, которая позволяет быстро отслеживать приход и выводить деньги в наличность / счёт в российском банке. У меня это яндекс.деньги.
Короче:
* точный (документальный) заказ
* точный (полный) адрес
* способ оплаты
Этап 1. Подготовка
Диски лучше всего покупать на шпинделе, и сразу штук 100 - дешевле и удобнее. Никаких no-name / Мань-Лянь и прочей безродной китайщины - только честную китайщину типа Verbatim и TDK.
Далее, на почте закупаемся конвертами за 1р30коп (они формата 23х16 см). Именно таких - в них помещается с запасом для упаковки диск по высоте. И по ширине можно запихнуть два в ряд, если очень постараться. В такой конверт без скрипа влезает 8-9 дисков. И ещё парочку покупаем полноформатных конвертов А4, за 4 рубля. Туда насовать дисков можно до одури.
Кроме того, пойти на рынок и купить простой китайский клей-карандаш, фломастер для дисков, шариковую ручку и скотч, а так же где-нибудь найти пупырчатый упаковочный материал (можно купить или, идя по улице, смотреть по сторонам и не упускать момент) и картонные коробки - например, от купленного оборудования.
Кроме того, заводим таблицу (или базу данных) - для отслеживания заказов и их состояния (если планируются масштабные отправки дисков).
Сразу отвечаю на вопрос: почему я отправляю только письмами и никогда - посылками. Очень просто: заказное письмо - самый дешёвый и технологичный вид отправлений. Легко и просто наклепать десяток заказных писем и не мучаться с посылками, заполняя на почте описи и платя за всё это весьма ощутимые деньги.
Короче, потребуется:
* конверты 23x16 см и 21х29см
* клей-карандаш
* шариковая ручка
* фломастер для дисков
* скотч
* упаковка (картон и пупырчатый полиэтилен)
Этап 2. Пропаливание
Оплата получена - можно палить диски. Лучше это поставить на скрипты - тыкать по цветастым кнопкам быстро надоест. Лично у меня каждый диск проходит проверку на совпадение контрольных md5-сумм после прожига. Это удлиняет время обработки заказа, но даёт гарантию, что диск читается.
Поначалу я иногда отправлял диски с упреждением - то есть ещё до оплаты. В честности некоторых линуксоидов пришлось разочароваться: от троих деньги так и не пришли. Так что после этого я жёстко следую формуле "утром деньги - вечером стулья", отступая от неё лишь в крайних случаях (вопрос жизни и смерти / прокуратура стучит сапогами у дверей по поводу ворованного софта / угроза выхода из строя стратегических объектов жизнеобеспечения).
Скрипты пропаливания и проверки есть у меня в блоге. Готовые диски подписываются, и сразу складываются на уже заполненный конверт - чтобы потом не забыть, что и кому отправляется.
Короче:
* пропаливаем диск
* проверяем md5-суммы
* подписываем диск
Этап 3. Упаковка
Здесь начинается всё самое весёлое. Упаковка! То, о чём так часто забывают скрупулёзные и скуповатые рыцари духа Опенсорс. Если вы просто накидаете дисков в конверт и отправите - к месту назначения придёт кучка сверкающих обломков.
Методом проб и ошибок найдены несколько технологий упаковки, которые дают хороший результат: диски приходят в нормальном состоянии и всё читается. Читаются даже те, что приходят с возвратом! Итак:
3.1 Картон + пупырчатый полиэтилен + бумага
Берём картонку, вдвое превышающую по формату конверт, сгибаем пополам, вкладываем туда отрезанный под размер пупырчатый полиэтилен (это очень эротичное занятие, поверьте мне). Теперь накладываем туда диски, стараясь класть их в "шахматном" порядке. Разделяем старой бумагой / газетой. В итоге получился бутерброд из дисков, картона и пупырышков. Теперь - важный момент! - несильно сжимаем этот бутерброд и перетягиваем его скотчем.
Скотчем клеем не только по вертикали, но и по горизонтали, стягивая друг к другу края "бутерброда" из дисков.
Если этого не сделать, диски в процессе транспортировки будут болтаться по конверту и поцарапаются!
Это если дисков мало (до 8 штук), а если много (больше 10) - такой способ не пройдёт. Тут нам пригодятся крупные конверты и старые глянцевые (или не очень) журналы, а так же красочные буклеты от купленного когда-то железа.
3.2 Картон + буклет
Берём журнал / буклет и набиваем его дисками, помещая между страницами. Шахматный порядок дисков тут тоже важен. Потом подкладываем под одну сторону картонку (для жёсткости), на первую и последнюю станицу вкладываем пупырчатую упаковку и всё это перетягиваем скотчем. Получится тоже бутерброд, только больше :-)
Ешё более простой и демократичный способ:
3.3. Части книги
Можно использовать ненужные книжки или методические пособия. Разрываем их на нужное количество половинок и вкладываем диски в шахматном порядке между страниц. Первую и последнюю страницу, содержащие диски, лучше всего склеивать скотчем, чтобы диски не болтались при транспортировке. Доходит превосходно, как и в предыдущих случаях.
Теперь осталось это всунуть в конверт - море положительных эмоций гарантировано. В деле запихивания упакованных дисков в конверт могут пригодиться навыки игры в тетрис, ножницы и линейка.
Даже если вам удастся всё это засунуть в конверт, его ещё надо заклеить. Про клей-карандаш было сказано совсем не зря: если вы думаете, что за рупь-тридцать вам густо намажут полоску конверта клеем - время в этом разочароваться.
Намазываем густо клей-карандашом тыльную сторону конверта и, в разумных пределах прикладывая грубую физическую силу, пытаемся две половинки конверта свести. Яростно трём клеевую полоску конверта, чтобы оно-таки схватилось с бумагой.
Внимание! Не вздумайте заклеивать конверт скотчем вместо клея! Это вправе делать только сами почтовики на пересылочных пунктах, о чём на конверте ставится печать: "Поступило в Н-ск МСЦ закленное клейкой лентой". Мне в своё время за это на почте надавали по шее. Только клеем, причём так, чтобы у работников почты не возникло и мысли о лёгком вскрытии конверта. При сомнениях о содержимом письма и плохой проклеенности они могут полезть внутрь.. и увидев там диски, с чувством выполненного долга разводят вас на ценное ускоренное письмо или того хуже посылку. Но об этом позже.
Теперь осматриваем этот здоровенный и пухлый конвертище - и если видим, что он начинает расходиться по швам, берём клей-карандаш снова и проходимся по швам.
Ну и что мы после этого говорим тем, кто жадничает нам двадцатник? :-)
Этап 4. Отправка.
Такое письмо (не менее 50 грамм) в почтовый ящик у почтамта опускать не стоит, ибо это уже не простое письмо, а как минимум заказное, что стоит больших денег. Так что начинается психология, партизанщина и дипломатия: вам предстоит завалить босса уровняобщение с сотрудниками почты.
Значит, так: посылать диски заказными письмами нельзя. Это считается "товарным вложением" и если сотрудник почты прознается, то завернёт вас на ценное ускоренное письмо / посылку. Это влетит в 80-100 рублей и больше, в зависимости от веса и дальности. Заказное письмо стоит 20-25 рублей, максимум - 30.
Насчёт "товарных вложений" - тут ваша совесть должна быть кристально чиста: вы пересылаете лицензионное опенсорсное ПО, способствуя распространению никс-систем и вытеснению подлой проприетарщины.
На самом деле, почтовикам просто не нужна дополнительная ответственность за пересылку хрупкого предмета в конверте - ведь в случае чего, чек останется у вас и вы можете крупно попортить нервы почте (дураков хватает и прецеденты были). Но если диски упакованы по технологиям, описанным выше - всё отлично доходит, дёшево и быстро, и все счастливы.
Стало быть, ваша задача - чтобы сотрудник почты об этом не догадался либо получил от вас бодрый энергичный ответ, который его успокоит. Поэтому при вопросах "что в письме" и "почему такое пухлое" бодро отвечаем, что это книжка / буклет - и никаких придумок на ходу.
Если письмо заклеено не плотно - сотрудник почты может его вскрыть. Мало ли, что вы собрались посылать - может, оно тикает и вибрирует? :-)
Именно поэтому у Линуксцентра так дорого, а у меня дешевле: они - компания, и распорядок Почты для них закон. Поэтому они отправляют посылками и с солидной задержкой (никто специально ради вас на почту не ломанётся). Для частных лиц устав почты носит, скажем так, рекомендательный характер :-)
Так вот, с чувством собственной правоты, которое "достигается упражнением", убеждаем почтаря в том, что вы посылаете книжку или буклетик. Отвечаем чётко и убедительно, с ясным взглядом выдерживая этот допрос с пристрастием.
Когда сотруднику почты надоест это дело, скорее всего, конверты отправят и чек отдадут (сохраняйте его обязательно!). Но если вы будете этим промышлять регулярно, ваша физиономия быстро примелькается, и допросы с пристрастем могут быть более длительными и коварными - здесь всё зависит от сотрудника почты. Многим наплевать, что вы посылаете, но есть и сугубо принципиальные товарищи. Тут главное ни в коем случае не хамить и быть предельно вежливым - почтовых отделений поблизости мало даже в Москве, и плевать в колодец совершенно не стоит.
Это к слову о партизанщине: разузнайте, где ещё в пределах вашей досягаемости есть почтовые отделения. Отправлять письма можно откуда угодно - не обязательно с почты по месту жительства. Если вы занимаетесь отправкой таких писем часто, есть смысл наведываться в разные почтовые отделения.
Этап 5. После отправки.
Известите того, кому посылаете диски, что они отправлены. Лучше приложить отсканированный чек с почты - так можно отследить на сайте почты, что диски на самом деле отправлены.
Со сроками дохода всё сложнее: обычно - неделя или полторы. От дальности зависит слабо: в Петропавловск-Камчатский одно письмо долетело за четыре дня, а в Вологду тащилось месяц.
Резюме
Здесь я постарался описать технологию пересылки дисков - может быть, кто-то захочет заниматься отправкой дисков. И чтобы получатель не рассматривал красивые обломки вместо долгожданного диска с дистрибутивом, я поделился своим скромным (более сотни почтовых отправлений) опытом по этой части.
Эпилог
- "Виренс, ну и зачем тебе всё это надо!?" - спросит, может быть, любопытствующий читатель. Отвечаю:
1. Время, потраченное вместо флейма на ЛОРе, можно использовать лучше. Например, помогая распространению *никс-систем.
2. Помогать другим людям вообще приятно. Особенно получая письма, что диски пришли :-)
3. Рассылка дисков не приносит огромных прибылей, но на оплату интернета, мобильника и коммунальных платежей вполне хватет.
4. И, наконец, философское: когда солнце моих дней зайдёт окончательно, и меня, может быть, спросят "так что ты сделал, чтобы тот мир стал немного лучше?" - и мне будет, что ответить :-)
В общем, рассылка дисков - дело интересное, хлопотное, увлекательное, забавное, поучительное и до некоторой степени прибыльное.
Создание сервера видеоконференций на базе OpenMCU и GnuGK (voip gatekeeper openmcu linux)
http://www.opennet.ru/base/net/openmcu_gnugk.txt.html
Введение
Эта статья призвана немного восполнить пробел практически полного отсутствия
информации о проекте OpenMCU на русском языке. Пару раз эта тема проскакивала здесь
на opennet.ru и на форуме ixbt.com и, собственно, из этих источников я и узнал
о существовании OpenMCU :) А вот, как его все-таки использовать,
информации было крайне мало и она была неполная. На английском языке ее,
по-моему, также не густо, лучшее, что я нашел, было в зарубежных списках
рассылки, опубликованных на http://osdir.com/ml/telephony.openh323.general/ ,
небольшом мануале на openmcu (man openmcu) и сайте, посвященном GnuGK http://www.gnugk.org/,
который, в отличие от OpenMCU, куда лучше документирован.
Буду очень благодарен за любые замечания и улучшения.
Дистрибутив:
Я использовал Linux OpenSUSE 10.3, версия ядра 2.6.22.5-31
Версии пакетов:
openmcu-2.2.0-104 (сервер видеоконференций, использующий протокол H323)
gnugk-2.2.5-65 (H323 Gatekeeper)
Используемые библиотеки:
openh323-1.19.0.1-106
pwlib-1.10.7-61
Процесс установки описывать не буду, никаких трудностей в нем нет, положим,
все необходимое уже установлено.
По поводу того, что такое протокол H323, привратник, MCU и т.д.
можно почитать, например, Здесь
и Здесь
Как все это работает?
Клиент регистрируется у привратника (GnuGK) под именем, скажем, nm1. Затем набирает
код выхода на openmcu, например, "02" и привратник соединяет его с сервером видеоконференций (OpenMCU),
где nm1 ждет остальных участников. Все остальные попадают на конференцию точно так же.
Для всех собравшихся используется default room - комната видеоконференции по умолчанию.
Привратник не является обязательным компонентом, но дает удобную возможность использовать
короткие символьные имена вместо ip-адресов. Так, все зарегестрировшиеся у привратника могут
также вызывать друг друга по имени, например, клиент зарегестрировавшийся, как nm2 может вызвать nm1
по его имени и организовать с ним видеообщение на 2 участников (point-to-point).
Тогда openmcu не используется.
Конфигурация GnuGK:
/etc/gnugk.ini
[Gatekeeper::Main]
FourtyTwo=42
Name=GNU_Gk
;EndpointSuffix=_gnugk
Home=127.0.0.1
StatusTraceLevel=2
UseBroadcastListener=0
TimestampFormat=ISO8601
EndpointSignalPort=1721
EncryptAllPasswords=0
UseMulticastListener=0
StatusPort=7000 #Порт мониторинга
SignalCallId=1
[GkStatus::Auth] #Здесь задаются правила доступа к
#мониторингу GnuGK
rule=explicit #Доступ осуществляется на основе ip
192.168.2.106=allow #Хост с которого можно мониторить GnuGK
Shutdown=allow #Разрешено отключать gnugk в мониторинге
#Самое важное:
#Описываем постоянные точки подключения, то есть те, которые будут
#постоянно храниться в регистрационной таблице привратника
[RasSrv::PermanentEndpoints]
127.0.0.1:1720=mcu;02 #наш mcu
[RasSrv::GWPrefixes]
mcu=02 #префикс выхода на него
#Остальное можно не трогать
[RasSrv::RRQFeatures]
AcceptEndpointIdentifier=1
AcceptGatewayPrefixes=1
OverwriteEPOnSameAddress=1
IRQPollCount=0
[RasSrv::ARQFeatures]
CallUnregisteredEndpoints=0
ArjReasonRouteCallToGatekeeper=0
[RoutedMode]
GKRouted=1
H245Routed=1
CallSignalPort=1721
AcceptNeighborCalls=1
AcceptUnregisteredCalls=1
RemoveH245AddressOnTunneling=0
RemoveCallOnDRQ=1
DropCallsByReleaseComplete=1
SendReleaseCompleteOnDRQ=1
SupportNATedEndpoints=1
TranslateFacility=1
[Proxy]
Enable=1
ProxyForNAT=1
RTPPortRange=1024-65535
[RoutingPolicy]
00=explicit,internal
02=internal,explicit
Default=explicit,internal,numberanalysis
[CallTable]
GenerateNBCDR=0
GenerateUCCDR=1
[Gatekeeper::Auth]
FileIPAuth=optional;RRQ
SQLPasswordAuth=required;RRQ
SQLAuth=required;ARQ,Setup
[Gatekeeper::Acct]
SQLAcct=required;start,update,stop
Подробное описание каждого из параметров можно найти на http://www.gnugk.org/gnugk-manual.html
Работу GnuGK можно мониторить подключившись к серверу на 7000 порт.
Например, мой сервер - 192.168.3.2
telnet 192.168.3.2 7000
Version:
Gatekeeper(GNU) Version(2.2.5) Ext(pthreads=1,radius=1,mysql=0,pgsql=0,firebird=0,large_fd
set=0,crypto/ssl=1) Build(Sep 25 2007, 22:47:36) Sys(Linux i686 2.6.22.5-31-default)
GkStatus: Version(2.0) Ext()
Toolkit: Version(1.0) Ext(basic)
Startup: Thu, 26 Feb 2009 14:09:41 +0600 Running: 0 days 23:41:38;
Конфигурация OpenMCU
OpenMCU по умолчанию хранит свой конфиг в
~/.pwlib_config/openmcu.ini
Поначалу конфига нет в этой директории, чтобы он появился, можно
подключиться к openmcu через веб-интерфейс (про это - ниже), заполнить
необходимые поля, нажать Accept и конфиг будет создан.
[Parameters]
Username=mcu
Password=******* #Пароль здесь указывать не надо, это
#можно сделать через веб-интерфейс, а здесь хранится только хэш
Log Level=4
HTTP Certificate=server.pem
HTTP Port=1420
Gatekeeper Mode=No gatekeeper #Не использовать регистрацию у
#привратника
#Далее идут различные параметры, связанные с обслуживанием
#видеоконференции,
#можно все оставить, как есть, все нормально работает с дефолтовыми
#параметрами
Interface Array Size=0
Enable video=True
Video frame rate=10
Video quality=10
Default room=room101
Room time limit=0
Connecting WAV File=/usr/sbin/connecting.wav
Entering WAV File=/usr/sbin/entering.wav
Leaving WAV File=/usr/sbin/leaving.wav
Call log filename=/var/log/openmcu/opemcu.log
Force split screen video=False
Для описания этих параметров читайте man на openmcu.
Как уже говорилось, настраивать openmcu можно также через web-интерфейс.
Для этого нужно набрать в браузере https://your-MCU-ip:1420/
Доступны следующие опции:
* Parameters
* MCU Status
* Invite user to conference
С помощью Parametrs можно производить настройку сервера
В MCU status можно мониторить его текущее состояние. Очень полезная вещь!
Invite user to conference - отправить пользователю приглашение на конференцию
(не понял, как это должно работать:))
Для отладки сервисов можно использовать команды
gnugk -c имя_конфига -ttt (trace - расширенный вывод данных)
openmcu -i имя_конфига -cx (запускать как обычную программу с выводом данных на экран)
Чтобы сервисы автоматически запускались при старте, надо создать их стартовые скрипты и
положить их (в зависимости от дистрибутива) в /etc/rc.d/ или /etc/init.d/
Сами скрипты тоже могут отличаться в зависимости от используемого дистрибутива.
Вообще-то эти скрипты обычно идут вместе с пакетом (или архивом с исходниками)
программы, но для openmcu он отсутствовал, а для gnugk я немного
изменил строчку запуска
startproc $OPENGK_BIN -c /etc/gnugk.ini -o /var/log/gnugk/gnugk.log -t
Скрипт для запуска openMCU я на скорую руку слепил из шаблона для стартовых
скриптов /etc/init.d/skeleton
#!/bin/sh
#
#
# /etc/init.d/openmcu
#
### BEGIN INIT INFO
# Provides: openMCU
# Required-Start: $network $syslog $remote_fs
# Should-Start: $time ypbind smtp
# Required-Stop: $syslog $remote_fs
# Should-Stop: $time ypbind smtp
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: OpenMCU
# Description: Start openMCU
### END INIT INFO
#
FOO_BIN="/usr/sbin/openmcu -d"
MCU_BIN="/usr/sbin/openmcu"
test -x $MCU_BIN || { echo "$MCU_BIN not installed";
if [ "$1" = "stop" ]; then exit 0;
else exit 5; fi; }
. /etc/rc.status
# Reset status of this service
rc_reset
case "$1" in
start)
echo -n "Starting OpenMCU "
## Start daemon with startproc(8). If this fails
## the return value is set appropriately by startproc.
/sbin/startproc $FOO_BIN
# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down OpenMCU"
## Stop daemon with killproc(8) and if this fails
## killproc sets the return value according to LSB.
/sbin/killproc -TERM $MCU_BIN
# Remember status and be verbose
rc_status -v
;;
try-restart|condrestart)
## Do a restart only if the service was active before.
## Note: try-restart is now part of LSB (as of 1.9).
## RH has a similar command named condrestart.
if test "$1" = "condrestart"; then
echo "${attn} Use try-restart ${done}(LSB)${attn} rather than condrestart ${warn}(RH)${norm}"
fi
$0 status
if test $? = 0; then
$0 restart
else
rc_reset # Not running is not a failure.
fi
# Remember status and be quiet
rc_status
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start
# Remember status and be quiet
rc_status
;;
force-reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
## If it does not support it, restart the service if it
## is running.
echo -n "Reload service OpenMCU "
## if it supports it:
/sbin/killproc -HUP $FOO_BIN
rc_status -v
## Otherwise:
#$0 try-restart
#rc_status
;;
reload)
## Like force-reload, but if daemon does not support
## signaling, do nothing (!)
# If it supports signaling:
echo -n "Reload service OpenMCU "
/sbin/killproc -HUP $FOO_BIN
rc_status -v
## Otherwise if it does not support reload:
#rc_failed 3
#rc_status -v
;;
status)
echo -n "Checking for service OpenMCU "
# NOTE: checkproc returns LSB compliant status values.
/sbin/checkproc $MCU_BIN
# NOTE: rc_status knows that we called this init script with
# "status" option and adapts its messages accordingly.
rc_status -v
;;
probe)
esac
rc_exit
Не забудьте назначить скриптам права на выполнение.
Собственно, теперь надо положить соответсвующие ссылки на скрипты в rcN.d,
то есть для соответствующих уровней запуска.
Я предпочитаю делать это программой chkconfig
chkconfig openmcu on
chkconfig gnugk on
Теперь все готово для запуска сервисов.
service gnugk start
service openmcu start
В настройках NetMeeting надо выставить Сервис-Параметры - Расширенный вызов-
Использовать привратника для вызовов и Регистрация моей учетной записи
(имя учетной записи).
После активации параметров в правом нижнем углу у него должен появиться значок
"Есть регистрация у привратника". Теперь набираем наш префикс выхода (02) и
попадаем на сервер OpenMCU, на экране будет виден соответствующий логотип.
Все остальные участники, также регистрируясь у привратника и набирая 02, будут
попадать на нашу конференцию.
Но тут возникает один интересный вопрос. Получается, что наш сервер будет
обслуживать одновременно только одну видеоконференцию, ту, что в default room.
А как сделать так, чтобы на одном сервере MCU одновременно проводить несколько
параллельных конференций?
Именно для этого и используется разделение конференций по комнатам.
К сожалению, NetMeeting не умеет указывать при вызове желаемую комнату для
конференции и может попадать только на default room, если она задана.
Поэтому организовывать различные комнаты мы будем, используя различные префиксы
выхода на MCU в gnugk.
Например, так:
/etc/gnugk.ini
[RasSrv::GWPrefixes]
#Комната 00
mcu=00
#Комната 11
mcu=11
#Комната 22
mcu=22
Таким образом, при наборе соответствующих префиксов, клиент будет попадать в
различные комнаты. Например, при наборе 00, openmcu создаст комнату 00, в
которую и попадет клиент. Остальным участникам конференции также можно выбирать
нужную комнату, набирая нужный префикс.
Другим способом выбора комнаты является явное указание ее в запросе следующим
образом:
"room_name@server_name"
NetMeeting эту возможность не поддерживает, поэтому можно использовать другого
h323 клиента, например, несколько хороших клиентов перечислены здесь:
http://www.gnugk.org/h323-endpoint.html
В этом случае, можно не использовать регистрацию у привратника, а сразу набирать
выход на openmcu в адресной строке, например, набираем example@192.168.3.2
и попадаем на наш openmcu. Аналогично другие клиенты могут указывать свои
комнаты, отличные от example и участвовать в отдельной конференции.
Заключение
Число комнат, по идее, ограничено только аппаратными ресурсами вашего сервера.
Что касается того, сколько максимально участников может одновременно участвовать
в одной видеоконференции, то я использовал конференции лишь до 4-х
участников включительно и могу сказать только, что это работает. Что
касается большего числа участников, то единственную информацию, которую мне
удалось найти на этот счет была на http://www.e-bizone.com/e_chinabo_03.htm
(но,к сожалению, не было возможности проверить, так что за что купил,
за то и продаю)
You hear the audio from the other users, but only see the video from the
four users actively talking.
Введение
Эта статья призвана немного восполнить пробел практически полного отсутствия
информации о проекте OpenMCU на русском языке. Пару раз эта тема проскакивала здесь
на opennet.ru и на форуме ixbt.com и, собственно, из этих источников я и узнал
о существовании OpenMCU :) А вот, как его все-таки использовать,
информации было крайне мало и она была неполная. На английском языке ее,
по-моему, также не густо, лучшее, что я нашел, было в зарубежных списках
рассылки, опубликованных на http://osdir.com/ml/telephony.openh323.general/ ,
небольшом мануале на openmcu (man openmcu) и сайте, посвященном GnuGK http://www.gnugk.org/,
который, в отличие от OpenMCU, куда лучше документирован.
Буду очень благодарен за любые замечания и улучшения.
Дистрибутив:
Я использовал Linux OpenSUSE 10.3, версия ядра 2.6.22.5-31
Версии пакетов:
openmcu-2.2.0-104 (сервер видеоконференций, использующий протокол H323)
gnugk-2.2.5-65 (H323 Gatekeeper)
Используемые библиотеки:
openh323-1.19.0.1-106
pwlib-1.10.7-61
Процесс установки описывать не буду, никаких трудностей в нем нет, положим,
все необходимое уже установлено.
По поводу того, что такое протокол H323, привратник, MCU и т.д.
можно почитать, например, Здесь
и Здесь
Как все это работает?
Клиент регистрируется у привратника (GnuGK) под именем, скажем, nm1. Затем набирает
код выхода на openmcu, например, "02" и привратник соединяет его с сервером видеоконференций (OpenMCU),
где nm1 ждет остальных участников. Все остальные попадают на конференцию точно так же.
Для всех собравшихся используется default room - комната видеоконференции по умолчанию.
Привратник не является обязательным компонентом, но дает удобную возможность использовать
короткие символьные имена вместо ip-адресов. Так, все зарегестрировшиеся у привратника могут
также вызывать друг друга по имени, например, клиент зарегестрировавшийся, как nm2 может вызвать nm1
по его имени и организовать с ним видеообщение на 2 участников (point-to-point).
Тогда openmcu не используется.
Конфигурация GnuGK:
/etc/gnugk.ini
[Gatekeeper::Main]
FourtyTwo=42
Name=GNU_Gk
;EndpointSuffix=_gnugk
Home=127.0.0.1
StatusTraceLevel=2
UseBroadcastListener=0
TimestampFormat=ISO8601
EndpointSignalPort=1721
EncryptAllPasswords=0
UseMulticastListener=0
StatusPort=7000 #Порт мониторинга
SignalCallId=1
[GkStatus::Auth] #Здесь задаются правила доступа к
#мониторингу GnuGK
rule=explicit #Доступ осуществляется на основе ip
192.168.2.106=allow #Хост с которого можно мониторить GnuGK
Shutdown=allow #Разрешено отключать gnugk в мониторинге
#Самое важное:
#Описываем постоянные точки подключения, то есть те, которые будут
#постоянно храниться в регистрационной таблице привратника
[RasSrv::PermanentEndpoints]
127.0.0.1:1720=mcu;02 #наш mcu
[RasSrv::GWPrefixes]
mcu=02 #префикс выхода на него
#Остальное можно не трогать
[RasSrv::RRQFeatures]
AcceptEndpointIdentifier=1
AcceptGatewayPrefixes=1
OverwriteEPOnSameAddress=1
IRQPollCount=0
[RasSrv::ARQFeatures]
CallUnregisteredEndpoints=0
ArjReasonRouteCallToGatekeeper=0
[RoutedMode]
GKRouted=1
H245Routed=1
CallSignalPort=1721
AcceptNeighborCalls=1
AcceptUnregisteredCalls=1
RemoveH245AddressOnTunneling=0
RemoveCallOnDRQ=1
DropCallsByReleaseComplete=1
SendReleaseCompleteOnDRQ=1
SupportNATedEndpoints=1
TranslateFacility=1
[Proxy]
Enable=1
ProxyForNAT=1
RTPPortRange=1024-65535
[RoutingPolicy]
00=explicit,internal
02=internal,explicit
Default=explicit,internal,numberanalysis
[CallTable]
GenerateNBCDR=0
GenerateUCCDR=1
[Gatekeeper::Auth]
FileIPAuth=optional;RRQ
SQLPasswordAuth=required;RRQ
SQLAuth=required;ARQ,Setup
[Gatekeeper::Acct]
SQLAcct=required;start,update,stop
Подробное описание каждого из параметров можно найти на http://www.gnugk.org/gnugk-manual.html
Работу GnuGK можно мониторить подключившись к серверу на 7000 порт.
Например, мой сервер - 192.168.3.2
telnet 192.168.3.2 7000
Version:
Gatekeeper(GNU) Version(2.2.5) Ext(pthreads=1,radius=1,mysql=0,pgsql=0,firebird=0,large_fd
set=0,crypto/ssl=1) Build(Sep 25 2007, 22:47:36) Sys(Linux i686 2.6.22.5-31-default)
GkStatus: Version(2.0) Ext()
Toolkit: Version(1.0) Ext(basic)
Startup: Thu, 26 Feb 2009 14:09:41 +0600 Running: 0 days 23:41:38;
Конфигурация OpenMCU
OpenMCU по умолчанию хранит свой конфиг в
~/.pwlib_config/openmcu.ini
Поначалу конфига нет в этой директории, чтобы он появился, можно
подключиться к openmcu через веб-интерфейс (про это - ниже), заполнить
необходимые поля, нажать Accept и конфиг будет создан.
[Parameters]
Username=mcu
Password=******* #Пароль здесь указывать не надо, это
#можно сделать через веб-интерфейс, а здесь хранится только хэш
Log Level=4
HTTP Certificate=server.pem
HTTP Port=1420
Gatekeeper Mode=No gatekeeper #Не использовать регистрацию у
#привратника
#Далее идут различные параметры, связанные с обслуживанием
#видеоконференции,
#можно все оставить, как есть, все нормально работает с дефолтовыми
#параметрами
Interface Array Size=0
Enable video=True
Video frame rate=10
Video quality=10
Default room=room101
Room time limit=0
Connecting WAV File=/usr/sbin/connecting.wav
Entering WAV File=/usr/sbin/entering.wav
Leaving WAV File=/usr/sbin/leaving.wav
Call log filename=/var/log/openmcu/opemcu.log
Force split screen video=False
Для описания этих параметров читайте man на openmcu.
Как уже говорилось, настраивать openmcu можно также через web-интерфейс.
Для этого нужно набрать в браузере https://your-MCU-ip:1420/
Доступны следующие опции:
* Parameters
* MCU Status
* Invite user to conference
С помощью Parametrs можно производить настройку сервера
В MCU status можно мониторить его текущее состояние. Очень полезная вещь!
Invite user to conference - отправить пользователю приглашение на конференцию
(не понял, как это должно работать:))
Для отладки сервисов можно использовать команды
gnugk -c имя_конфига -ttt (trace - расширенный вывод данных)
openmcu -i имя_конфига -cx (запускать как обычную программу с выводом данных на экран)
Чтобы сервисы автоматически запускались при старте, надо создать их стартовые скрипты и
положить их (в зависимости от дистрибутива) в /etc/rc.d/ или /etc/init.d/
Сами скрипты тоже могут отличаться в зависимости от используемого дистрибутива.
Вообще-то эти скрипты обычно идут вместе с пакетом (или архивом с исходниками)
программы, но для openmcu он отсутствовал, а для gnugk я немного
изменил строчку запуска
startproc $OPENGK_BIN -c /etc/gnugk.ini -o /var/log/gnugk/gnugk.log -t
Скрипт для запуска openMCU я на скорую руку слепил из шаблона для стартовых
скриптов /etc/init.d/skeleton
#!/bin/sh
#
#
# /etc/init.d/openmcu
#
### BEGIN INIT INFO
# Provides: openMCU
# Required-Start: $network $syslog $remote_fs
# Should-Start: $time ypbind smtp
# Required-Stop: $syslog $remote_fs
# Should-Stop: $time ypbind smtp
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: OpenMCU
# Description: Start openMCU
### END INIT INFO
#
FOO_BIN="/usr/sbin/openmcu -d"
MCU_BIN="/usr/sbin/openmcu"
test -x $MCU_BIN || { echo "$MCU_BIN not installed";
if [ "$1" = "stop" ]; then exit 0;
else exit 5; fi; }
. /etc/rc.status
# Reset status of this service
rc_reset
case "$1" in
start)
echo -n "Starting OpenMCU "
## Start daemon with startproc(8). If this fails
## the return value is set appropriately by startproc.
/sbin/startproc $FOO_BIN
# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down OpenMCU"
## Stop daemon with killproc(8) and if this fails
## killproc sets the return value according to LSB.
/sbin/killproc -TERM $MCU_BIN
# Remember status and be verbose
rc_status -v
;;
try-restart|condrestart)
## Do a restart only if the service was active before.
## Note: try-restart is now part of LSB (as of 1.9).
## RH has a similar command named condrestart.
if test "$1" = "condrestart"; then
echo "${attn} Use try-restart ${done}(LSB)${attn} rather than condrestart ${warn}(RH)${norm}"
fi
$0 status
if test $? = 0; then
$0 restart
else
rc_reset # Not running is not a failure.
fi
# Remember status and be quiet
rc_status
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start
# Remember status and be quiet
rc_status
;;
force-reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
## If it does not support it, restart the service if it
## is running.
echo -n "Reload service OpenMCU "
## if it supports it:
/sbin/killproc -HUP $FOO_BIN
rc_status -v
## Otherwise:
#$0 try-restart
#rc_status
;;
reload)
## Like force-reload, but if daemon does not support
## signaling, do nothing (!)
# If it supports signaling:
echo -n "Reload service OpenMCU "
/sbin/killproc -HUP $FOO_BIN
rc_status -v
## Otherwise if it does not support reload:
#rc_failed 3
#rc_status -v
;;
status)
echo -n "Checking for service OpenMCU "
# NOTE: checkproc returns LSB compliant status values.
/sbin/checkproc $MCU_BIN
# NOTE: rc_status knows that we called this init script with
# "status" option and adapts its messages accordingly.
rc_status -v
;;
probe)
esac
rc_exit
Не забудьте назначить скриптам права на выполнение.
Собственно, теперь надо положить соответсвующие ссылки на скрипты в rcN.d,
то есть для соответствующих уровней запуска.
Я предпочитаю делать это программой chkconfig
chkconfig openmcu on
chkconfig gnugk on
Теперь все готово для запуска сервисов.
service gnugk start
service openmcu start
В настройках NetMeeting надо выставить Сервис-Параметры - Расширенный вызов-
Использовать привратника для вызовов и Регистрация моей учетной записи
(имя учетной записи).
После активации параметров в правом нижнем углу у него должен появиться значок
"Есть регистрация у привратника". Теперь набираем наш префикс выхода (02) и
попадаем на сервер OpenMCU, на экране будет виден соответствующий логотип.
Все остальные участники, также регистрируясь у привратника и набирая 02, будут
попадать на нашу конференцию.
Но тут возникает один интересный вопрос. Получается, что наш сервер будет
обслуживать одновременно только одну видеоконференцию, ту, что в default room.
А как сделать так, чтобы на одном сервере MCU одновременно проводить несколько
параллельных конференций?
Именно для этого и используется разделение конференций по комнатам.
К сожалению, NetMeeting не умеет указывать при вызове желаемую комнату для
конференции и может попадать только на default room, если она задана.
Поэтому организовывать различные комнаты мы будем, используя различные префиксы
выхода на MCU в gnugk.
Например, так:
/etc/gnugk.ini
[RasSrv::GWPrefixes]
#Комната 00
mcu=00
#Комната 11
mcu=11
#Комната 22
mcu=22
Таким образом, при наборе соответствующих префиксов, клиент будет попадать в
различные комнаты. Например, при наборе 00, openmcu создаст комнату 00, в
которую и попадет клиент. Остальным участникам конференции также можно выбирать
нужную комнату, набирая нужный префикс.
Другим способом выбора комнаты является явное указание ее в запросе следующим
образом:
"room_name@server_name"
NetMeeting эту возможность не поддерживает, поэтому можно использовать другого
h323 клиента, например, несколько хороших клиентов перечислены здесь:
http://www.gnugk.org/h323-endpoint.html
В этом случае, можно не использовать регистрацию у привратника, а сразу набирать
выход на openmcu в адресной строке, например, набираем example@192.168.3.2
и попадаем на наш openmcu. Аналогично другие клиенты могут указывать свои
комнаты, отличные от example и участвовать в отдельной конференции.
Заключение
Число комнат, по идее, ограничено только аппаратными ресурсами вашего сервера.
Что касается того, сколько максимально участников может одновременно участвовать
в одной видеоконференции, то я использовал конференции лишь до 4-х
участников включительно и могу сказать только, что это работает. Что
касается большего числа участников, то единственную информацию, которую мне
удалось найти на этот счет была на http://www.e-bizone.com/e_chinabo_03.htm
(но,к сожалению, не было возможности проверить, так что за что купил,
за то и продаю)
You hear the audio from the other users, but only see the video from the
four users actively talking.
Как сбросить пароль в Linux
* В окне загрузчика GRUB выделите строку с нужной версией линукса, для которого вам нужно сбросить pароль
* Нажмите 'e' для редактирования. Выберите строку ядра. Добавьте 'single' в конец строки. Нажмите 'b' для загрузки. Если система продолжает запрашивать пароль рута, добавьте в конец строки init=/bin/bash Снова нажмите 'b' для загрузки
* Нажмите 'e' для редактирования. Выберите строку ядра. Добавьте 'single' в конец строки. Нажмите 'b' для загрузки. Если система продолжает запрашивать пароль рута, добавьте в конец строки init=/bin/bash Снова нажмите 'b' для загрузки
вторник, 10 марта 2009 г.
Настройка репликации дисков на трех узлах в Debian GNU/Linux при помощи DRBD
http://www.howtoforge.com/drbd-8.3-third-node-replication-with-debian-etch
пятница, 6 марта 2009 г.
Перед тем, как освободить диск, давайте узнаем, какой процесс его использует:
# fuser /media/cdrom
# screen -S foo
Затем говорите Дэвиду: «Запусти-ка на своем терминале следующую команду»: # screen -x foo."
Поиск открытых файлов и сетевых соединений
lsof — список открытых файлов
В дополнение к списку открытых файлов lsof может такде оторбражать открытые сокеты (сетевые соединения), если вы запустите его в ключом -i:
Вывод netstat можно сделать подобным выводу lsof, добавив -A inet и -program, которые указывают netstat печатать только нелокальные соединения, включая процессы, чьей собственностью они являются:
# fuser /media/cdrom
# screen -S foo
Затем говорите Дэвиду: «Запусти-ка на своем терминале следующую команду»: # screen -x foo."
Поиск открытых файлов и сетевых соединений
lsof — список открытых файлов
В дополнение к списку открытых файлов lsof может такде оторбражать открытые сокеты (сетевые соединения), если вы запустите его в ключом -i:
Вывод netstat можно сделать подобным выводу lsof, добавив -A inet и -program, которые указывают netstat печатать только нелокальные соединения, включая процессы, чьей собственностью они являются:
четверг, 5 марта 2009 г.
Как восстановить файлы, недавно удаленные с USB-флешки? Легко! Понадобится связка из fls и icat.
Эти программы входят в пакет sleuthkit.
Mandriva:
urpmi sleuthkit
Gentoo:
emerge sleuthkit
Программа fls покажет нам список удаленных файлов:
#fls -rd /dev/sdb1
r/r * 117: dsc0005.jpg
r/r * 119: dsc0006.jpg
r/r * 122: dsc0007.jpg
r/r * 125: dsc0008.jpg
r/r * 128: dsc0009.jpg
Команда icat восстанавливает удаленные файлы:
#icat -rf fat /dev/sdb1 117 > /home/yuri/dsc0005.jpg
Поскольку у меня была задача восстановить только фотографии, а значит имя файла было не важно, то родился следующий однострочник:
#for i in $(fls -rd /dev/sdb1|awk {'print $3'}|tr -d [:]); do icat -r -f fat /dev/sdb1 $i > /home/yuri/photo/$i.jpg;done
Как указано в документации, Sleuthkit работает не только с FAT и NTFS, но и с ext2/3, iso9660, ufs, raw, swap.
Mandriva:
urpmi sleuthkit
Gentoo:
emerge sleuthkit
Программа fls покажет нам список удаленных файлов:
#fls -rd /dev/sdb1
r/r * 117: dsc0005.jpg
r/r * 119: dsc0006.jpg
r/r * 122: dsc0007.jpg
r/r * 125: dsc0008.jpg
r/r * 128: dsc0009.jpg
Команда icat восстанавливает удаленные файлы:
#icat -rf fat /dev/sdb1 117 > /home/yuri/dsc0005.jpg
Поскольку у меня была задача восстановить только фотографии, а значит имя файла было не важно, то родился следующий однострочник:
#for i in $(fls -rd /dev/sdb1|awk {'print $3'}|tr -d [:]); do icat -r -f fat /dev/sdb1 $i > /home/yuri/photo/$i.jpg;done
Как указано в документации, Sleuthkit работает не только с FAT и NTFS, но и с ext2/3, iso9660, ufs, raw, swap.
Команда setfacl устанавливает расширенные права доступа (access control list или ACL).
Основные параметры команды setfacl:
-m — установить ACL,
-x — удалить ACL,
-b — удалить все установленные параметры ACL.
Например, команда
setfacl -m user:B:rwx
добавляет доступ на чтение, запись и выполнение для пользователя «В».
Подробней смотри man setfacl. Также смотри man acl и man getfacl.
Основные параметры команды setfacl:
-m — установить ACL,
-x — удалить ACL,
-b — удалить все установленные параметры ACL.
Например, команда
setfacl -m user:B:rwx
добавляет доступ на чтение, запись и выполнение для пользователя «В».
Подробней смотри man setfacl. Также смотри man acl и man getfacl.
Поиск открытых файлов и сетевых соединений
Одной из многих выгод использования операционной системы Linux является то, что есть возможность получить обширую информацию о процессах, работающих в данный момент, и ресурсах, которые они потребляют. Эта статья описывает две очень полезные команды: lsof и netstat, которые покажут вам список всех открытых файлов или сетевых соединений на системе наряду с соответствующими им процессами.
Их еще одно очевидное преимущество — безопасность. Например, если бы spyware или какая-либо другая malware-программа отправляли бы информацию с вашего компьютера в Интернет или в файл на вашем жестком диске, это можно было увидеть в выводе этих команд.
lsof — список открытых файлов
Эта простая команда часто запускается без аргументов и делает только то, что ей сказано: отображать список из каждых открытых файлов каждой программы, запущенной в данной момент.
Обычно вывод lsof выглядит так:
kain@slickbox:~> lsof
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root cwd unknown /proc/1/cwd
init 1 root rtd unknown /proc/1/root
init 1 root txt unknown /proc/1/exe
init 1 root mem REG 8,22 509596 60081 /sbin/init
init 1 root mem REG 0,0 0 [heap]
init 1 root NOFD /proc/1/fd
kthreadd 2 root cwd unknown /proc/2/cwd
kthreadd 2 root rtd unknown /proc/2/root
kthreadd 2 root txt unknown /proc/2/exe
....
Информация в колонках обычно является прямой.
Обычно lsof выводит слишком много информации, чтобы она могла поместиться в буфер прокрутки консоли. Таким образом у вас может возникнуть желание сбросить эту информацию на диск (через lsof > lsof-output.txt) или отфильтровать ее, используя различные pipe-команды.
Например, если хотите увидеть, открыт ли специальный файл /dev/dsp (звуковая карта) каким-нибудь процессом, запустите следующую команду:
kain@slickbox:~> lsof|grep dsp
game 3835 kain mem CHR 195,0 13940 /dev/dsp
Теперь мы можем убить процесс, если хотим освободить звуковую карту:
kain@slickbox:~> kill -9 3835
kain@slickbox:~> killall -9 game # это также сработает
В дополнение к списку открытых файлов lsof может такде оторбражать открытые сокеты (сетевые соединения), если вы запустите его в ключом -i:
kain@slickbox:~> lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
kded 4140 kain 15u IPv4 15400 TCP localhost:37435 (LISTEN)
kded 4140 kain 19u IPv6 15483 TCP *:5800 (LISTEN)
kded 4140 kain 20u IPv6 15488 TCP *:5900 (LISTEN)
pidgin 4530 kain 14u IPv4 17075 TCP 192.168.1.104:54623->205.188.9.158:aol (ESTABLISHED)
pidgin 4530 kain 15u IPv4 17072 TCP 192.168.1.104:56693->205.188.5.214:aol (ESTABLISHED)
pidgin 4530 kain 16u IPv4 49002 TCP 192.168.1.104:37275->64.12.30.80:aol (ESTABLISHED)
pidgin 4530 kain 17u IPv4 17092 TCP 192.168.1.104:57145->oam-d09b.blue.aol.com:aol (ESTABLISHED)
pidgin 4530 kain 18u IPv4 50809 TCP 192.168.1.104:42839->64.12.30.92:aol (ESTABLISHED)
pidgin 4530 kain 23u IPv4 17107 TCP 192.168.1.104:43997->oam-d23c.blue.aol.com:aol (ESTABLISHED)
firefox-b 9464 kain 10u IPv4 55549 TCP 192.168.1.104:37274->mu-in-f91.google.com:http (ESTABLISHED)
firefox-b 9464 kain 44u IPv4 54630 TCP 192.168.1.104:43427->132.235.194.70:http (ESTABLISHED)
firefox-b 9464 kain 45u IPv4 54631 TCP 192.168.1.104:43428->132.235.194.70:http (ESTABLISHED)
firefox-b 9464 kain 46u IPv4 54635 TCP 192.168.1.104:49242->132.235.194.69:http
Можно заметить, что когда я запустил эту команду, у меня уже были запущены pidgin и firefox. В колонке содержится адрес соединения, его номер порта или имя сервиса, и действительно ли сокет LISTEN или ESTABLISHED. Прослушиваемые сокеты соответствуют процессам сервера, запущенным на вашей машине, которые ожидают соединений от других частей. Любые подозрительные слушающие процессы должны быть проверены на предметбезопасности. Если номер порта будет в списке известных сервисов на системе, то он отображается как именованный сервис (например, http или aol в листинге выше). Вы можете поискать файл /etc/services, чтобы узнать, что это такое:
kain@slickbox:~> cat /etc/services|grep aol
aol 5190/tcp # America-Online
Чтобы быть уверенным, что вы получаете полный вывод lsof, вы должны быть пользователем root.
netstat — инструмент сетевой статистики
В то время, как lsof -i удобный способ отображения списка сетевых соединений, netstat обеспечивает альтернативный и более подробный способ получаения информации о вашей сети.
Вывод netstat обычно более длинный, чем lsof -i:
kain@slickbox:~> netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.104:56693 205.188.5.214:aol ESTABLISHED
tcp 0 0 192.168.1.104:55219 64.12.30.80:aol ESTABLISHED
tcp 0 0 192.168.1.104:43997 oam-d23c.blue.aol.c:aol ESTABLISHED
tcp 0 0 192.168.1.104:54623 205.188.9.158:aol ESTABLISHED
tcp 0 0 192.168.1.104:57145 oam-d09b.blue.aol.c:aol ESTABLISHED
tcp 0 0 192.168.1.104:44775 64.12.30.92:aol ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ] DGRAM 15294 /var/run/NetworkManager/wpa_ctrl_3020-1
unix 2 [ ] DGRAM 15215 /var/run/wpa_supplicant-global
unix 3 [ ] DGRAM 15292 /var/run/wpa_supplicant/eth1
unix 2 [ ] DGRAM 3300 @/org/kernel/udev/udevd
unix 2 [ ] DGRAM 8419 /var/lib/dhcp/dev/log
....
Заметьте, что netstat указывает также локальный адрес для каждого соединения, а также размер отправленной и полученной очереди, что помогает контролировать активность каждого соединения. В дополнение к этому, она отображает соединения, созданные поверх сокетов Unix, другой механизм для соединений между процессами в Linux.
Вывод netstat можно сделать подобным выводу lsof, добавив -A inet и -program, которые указывают netstat печатать только нелокальные соединения, включая процессы, чьей собственностью они являются:
slickbox:/home/kain # netstat -A inet --program
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.104:56693 205.188.5.214:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:55219 64.12.30.80:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:43997 oam-d23c.blue.aol.c:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:54623 205.188.9.158:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:57145 oam-d09b.blue.aol.c:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:44775 64.12.30.92:aol ESTABLISHED 4530/pidgin
Вот и все, что можно сказать по этому поводу. Обе эти команды имеют гораздо больше возможностей, которые вы можете узнать, прочитав соответствующие man-страницы — man lsof и man netstat.
Их еще одно очевидное преимущество — безопасность. Например, если бы spyware или какая-либо другая malware-программа отправляли бы информацию с вашего компьютера в Интернет или в файл на вашем жестком диске, это можно было увидеть в выводе этих команд.
lsof — список открытых файлов
Эта простая команда часто запускается без аргументов и делает только то, что ей сказано: отображать список из каждых открытых файлов каждой программы, запущенной в данной момент.
Обычно вывод lsof выглядит так:
kain@slickbox:~> lsof
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
init 1 root cwd unknown /proc/1/cwd
init 1 root rtd unknown /proc/1/root
init 1 root txt unknown /proc/1/exe
init 1 root mem REG 8,22 509596 60081 /sbin/init
init 1 root mem REG 0,0 0 [heap]
init 1 root NOFD /proc/1/fd
kthreadd 2 root cwd unknown /proc/2/cwd
kthreadd 2 root rtd unknown /proc/2/root
kthreadd 2 root txt unknown /proc/2/exe
....
Информация в колонках обычно является прямой.
Обычно lsof выводит слишком много информации, чтобы она могла поместиться в буфер прокрутки консоли. Таким образом у вас может возникнуть желание сбросить эту информацию на диск (через lsof > lsof-output.txt) или отфильтровать ее, используя различные pipe-команды.
Например, если хотите увидеть, открыт ли специальный файл /dev/dsp (звуковая карта) каким-нибудь процессом, запустите следующую команду:
kain@slickbox:~> lsof|grep dsp
game 3835 kain mem CHR 195,0 13940 /dev/dsp
Теперь мы можем убить процесс, если хотим освободить звуковую карту:
kain@slickbox:~> kill -9 3835
kain@slickbox:~> killall -9 game # это также сработает
В дополнение к списку открытых файлов lsof может такде оторбражать открытые сокеты (сетевые соединения), если вы запустите его в ключом -i:
kain@slickbox:~> lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
kded 4140 kain 15u IPv4 15400 TCP localhost:37435 (LISTEN)
kded 4140 kain 19u IPv6 15483 TCP *:5800 (LISTEN)
kded 4140 kain 20u IPv6 15488 TCP *:5900 (LISTEN)
pidgin 4530 kain 14u IPv4 17075 TCP 192.168.1.104:54623->205.188.9.158:aol (ESTABLISHED)
pidgin 4530 kain 15u IPv4 17072 TCP 192.168.1.104:56693->205.188.5.214:aol (ESTABLISHED)
pidgin 4530 kain 16u IPv4 49002 TCP 192.168.1.104:37275->64.12.30.80:aol (ESTABLISHED)
pidgin 4530 kain 17u IPv4 17092 TCP 192.168.1.104:57145->oam-d09b.blue.aol.com:aol (ESTABLISHED)
pidgin 4530 kain 18u IPv4 50809 TCP 192.168.1.104:42839->64.12.30.92:aol (ESTABLISHED)
pidgin 4530 kain 23u IPv4 17107 TCP 192.168.1.104:43997->oam-d23c.blue.aol.com:aol (ESTABLISHED)
firefox-b 9464 kain 10u IPv4 55549 TCP 192.168.1.104:37274->mu-in-f91.google.com:http (ESTABLISHED)
firefox-b 9464 kain 44u IPv4 54630 TCP 192.168.1.104:43427->132.235.194.70:http (ESTABLISHED)
firefox-b 9464 kain 45u IPv4 54631 TCP 192.168.1.104:43428->132.235.194.70:http (ESTABLISHED)
firefox-b 9464 kain 46u IPv4 54635 TCP 192.168.1.104:49242->132.235.194.69:http
Можно заметить, что когда я запустил эту команду, у меня уже были запущены pidgin и firefox. В колонке содержится адрес соединения, его номер порта или имя сервиса, и действительно ли сокет LISTEN или ESTABLISHED. Прослушиваемые сокеты соответствуют процессам сервера, запущенным на вашей машине, которые ожидают соединений от других частей. Любые подозрительные слушающие процессы должны быть проверены на предметбезопасности. Если номер порта будет в списке известных сервисов на системе, то он отображается как именованный сервис (например, http или aol в листинге выше). Вы можете поискать файл /etc/services, чтобы узнать, что это такое:
kain@slickbox:~> cat /etc/services|grep aol
aol 5190/tcp # America-Online
Чтобы быть уверенным, что вы получаете полный вывод lsof, вы должны быть пользователем root.
netstat — инструмент сетевой статистики
В то время, как lsof -i удобный способ отображения списка сетевых соединений, netstat обеспечивает альтернативный и более подробный способ получаения информации о вашей сети.
Вывод netstat обычно более длинный, чем lsof -i:
kain@slickbox:~> netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.104:56693 205.188.5.214:aol ESTABLISHED
tcp 0 0 192.168.1.104:55219 64.12.30.80:aol ESTABLISHED
tcp 0 0 192.168.1.104:43997 oam-d23c.blue.aol.c:aol ESTABLISHED
tcp 0 0 192.168.1.104:54623 205.188.9.158:aol ESTABLISHED
tcp 0 0 192.168.1.104:57145 oam-d09b.blue.aol.c:aol ESTABLISHED
tcp 0 0 192.168.1.104:44775 64.12.30.92:aol ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ] DGRAM 15294 /var/run/NetworkManager/wpa_ctrl_3020-1
unix 2 [ ] DGRAM 15215 /var/run/wpa_supplicant-global
unix 3 [ ] DGRAM 15292 /var/run/wpa_supplicant/eth1
unix 2 [ ] DGRAM 3300 @/org/kernel/udev/udevd
unix 2 [ ] DGRAM 8419 /var/lib/dhcp/dev/log
....
Заметьте, что netstat указывает также локальный адрес для каждого соединения, а также размер отправленной и полученной очереди, что помогает контролировать активность каждого соединения. В дополнение к этому, она отображает соединения, созданные поверх сокетов Unix, другой механизм для соединений между процессами в Linux.
Вывод netstat можно сделать подобным выводу lsof, добавив -A inet и -program, которые указывают netstat печатать только нелокальные соединения, включая процессы, чьей собственностью они являются:
slickbox:/home/kain # netstat -A inet --program
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.104:56693 205.188.5.214:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:55219 64.12.30.80:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:43997 oam-d23c.blue.aol.c:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:54623 205.188.9.158:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:57145 oam-d09b.blue.aol.c:aol ESTABLISHED 4530/pidgin
tcp 0 0 192.168.1.104:44775 64.12.30.92:aol ESTABLISHED 4530/pidgin
Вот и все, что можно сказать по этому поводу. Обе эти команды имеют гораздо больше возможностей, которые вы можете узнать, прочитав соответствующие man-страницы — man lsof и man netstat.
Удаленное управление сервером имён BIND9
Управление сервером имён BIND9 производится с помощью команды rndc. С его помощью можно удаленно обновить (или принудительно перезагрузить) зоны, сбросить кеш сервера или заморозить обновление динамических зон.
Сперва настраиваем BIND9
* Сгенерируем ключ «/etc/namedb/rndc.key»
# rndc-confgen -u bind -a -b 256
* Создадим конфигурационный файл «/etc/namedb/rndc.conf»
1. include "/etc/namedb/rndc.key";
2.
3. options {
4. default-key "rndc-key";
5. default-server 127.0.0.1;
6. default-port 953;
7. };
* Отредактируем файл «/etc/namedb/named.conf» и добавим
1. include "/etc/namedb/rndc.key";
2. controls {
3. inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
4. inet 192.168.0.xxx port 953 allow { 192.168.0.yyy; } keys { "rndc-key"; };
5. };
где «192.168.0.xxx» – ip-адрес сервера в сети, а «192.168.0.yyy» – ip-адрес компьютера администратора.
* Перезагружаем сервер имён
# /etc/rc.d/named restart
* Проверяем
# rndc reload
server reload successful
Теперь настроим на стороне администратора
* Копируем с сервера файлы для rndc
$ sudo scp -p admin@192.168.0.xxx:/etc/namedb/rndc.'*' /etc/namedb/
* Отредактируем файл «/etc/namedb/rndc.conf»
1. include "/etc/namedb/rndc.key";
2.
3. options {
4. default-key "rndc-key";
5. # default-server 127.0.0.1;
6. default-server 192.168.0.xxx;
7. default-port 953;
8. };
* Проверяем
# rndc reload
server reload successful
Если у вас несколько серверов, то они настраиваются похожим образом.
* На стороне администратора сохраняем ключи с именами вроде «/etc/namedb/server-name.key» и редактируем
1. key "rndc-server-name-key" {
2. algorithm hmac-md5;
3. secret "super-secret-password-hash=";
4. };
* В файл «/etc/namedb/rndc.conf» добавим строки для каждого сервера
1. include "/etc/namedb/server-name.key";
2. server "server-name" {
3. key "rndc-server-name-key";
4. };
«server-name» может быть именем сервера или его ip-адресом.
* Проверяем
# rndc -s server-name reload
server reload successful
Если опустить параметр «-s» то будем «рулить» сервером, заданным по умолчанию в секции «options»
Сперва настраиваем BIND9
* Сгенерируем ключ «/etc/namedb/rndc.key»
# rndc-confgen -u bind -a -b 256
* Создадим конфигурационный файл «/etc/namedb/rndc.conf»
1. include "/etc/namedb/rndc.key";
2.
3. options {
4. default-key "rndc-key";
5. default-server 127.0.0.1;
6. default-port 953;
7. };
* Отредактируем файл «/etc/namedb/named.conf» и добавим
1. include "/etc/namedb/rndc.key";
2. controls {
3. inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
4. inet 192.168.0.xxx port 953 allow { 192.168.0.yyy; } keys { "rndc-key"; };
5. };
где «192.168.0.xxx» – ip-адрес сервера в сети, а «192.168.0.yyy» – ip-адрес компьютера администратора.
* Перезагружаем сервер имён
# /etc/rc.d/named restart
* Проверяем
# rndc reload
server reload successful
Теперь настроим на стороне администратора
* Копируем с сервера файлы для rndc
$ sudo scp -p admin@192.168.0.xxx:/etc/namedb/rndc.'*' /etc/namedb/
* Отредактируем файл «/etc/namedb/rndc.conf»
1. include "/etc/namedb/rndc.key";
2.
3. options {
4. default-key "rndc-key";
5. # default-server 127.0.0.1;
6. default-server 192.168.0.xxx;
7. default-port 953;
8. };
* Проверяем
# rndc reload
server reload successful
Если у вас несколько серверов, то они настраиваются похожим образом.
* На стороне администратора сохраняем ключи с именами вроде «/etc/namedb/server-name.key» и редактируем
1. key "rndc-server-name-key" {
2. algorithm hmac-md5;
3. secret "super-secret-password-hash=";
4. };
* В файл «/etc/namedb/rndc.conf» добавим строки для каждого сервера
1. include "/etc/namedb/server-name.key";
2. server "server-name" {
3. key "rndc-server-name-key";
4. };
«server-name» может быть именем сервера или его ip-адресом.
* Проверяем
# rndc -s server-name reload
server reload successful
Если опустить параметр «-s» то будем «рулить» сервером, заданным по умолчанию в секции «options»
Подписаться на:
Сообщения (Atom)