Cisco 7940: Файл диалплана dialplan.xml

Поскольку логику обработки вызовов проще организовать на ip-pbx, файл dialplan.xml является необязательным, но может внести некоторые полезные дополнительные функции, такие как автоматический набор и вторичный тоновый сигнал.

Файл dialplan.xml имеет следующую стркутуру:

где:

pattern может содержать: . (точка) для замены любого символа, * (звездочка) для замены одного или более символов, , (запятая) для генерации вторичного сигнала.
sec – время в секундах, после которого начинается набор.
type – может быть IP или Phone. Тэг, добавляемый к номеру, регистронезависим.
xxx – номер, который будет набираться вместо введенного пользователем при совпадении с pattern.
route – адрес прокси-сервера SIP, на который перенаправляется звонок, значение может быть default, emergency или имя прокси-сервера.
tone – если не задан, используется вторичный гудок по умолчанию, если стоит запятая и затем имя гудка, то проигрывает этот звук; без запятой гудок игнорируется.

Также можно указать решетку (#) и звездочку (*) как набираемые символы. По умолчанию # означает «набрать сейчас», не дожидаясь совпадения с шаблоном из номерного плана. * по умолчанию означает * или . в шаблоне (wildcard-символ).

В качестве вторичного гудка можно использовать следующие значения (после запятой): Bellcore-Alerting, Bellcore-dr5, Bellcore-Reorder, Bellcore-Busy, Bellcore-dr6, Bellcore-Stutter, Bellcore-BusyVerify, Bellcore-Hold, CallWaiting-2, Bellcore-CallWaiting, Bellcore-Inside, CallWaiting-3, Bellcore-Confirmation, Bellcore-None, CallWaiting-4, Bellcore-dr1, Bellcore-Outside (default), Cisco-BeepBonk, Bellcore-dr2, Bellcore-Permanent, Cisco-Zip, Bellcore-dr3, Bellcore-Reminder, Cisco-ZipZip, Bellcore-dr4.

К каждому правилу можно добавить <!— комментарий —> в конце каждой строки.

TIMEOUT=»0″ при совпадении паттерна, указывает сразу же отправить вызов на обработку — так реализуется вышеупомянутый автоматический набор.

<TEMPLATE MATCH=»1..» TIMEOUT=»0″ /> <!— Local Extensions —>

Например, набираем номер 110, подпадаем под первое правило и сразу идет вызов без дополнительных действий с нашей стороны, не нужно нажимать Dial или #.

Для звонков в другие страны будем использовать правило с паттерном 9,00* — пользователь поднимает трубку, слышит длинный гудок, набирает 9 — слышыт другой длинный  гудок (вторичный тоновый сигнал, это нам дает запятая в паттерне), затем номер, начинающийся с двух нулей (в Украине это код выхода на международную линию). Таймаут здесь уже не ставим 0, поскольку не указано точное колличество цифер, которые будут набраны.

<TEMPLATE MATCH=»9,00*» TIMEOUT=»10″ />

Номер в канал передается польностью — вместе в первой цифрой 9 — учитывайте это в диалплане на ip-pbx.

Cisco 7940: Обновление прошивки. Из SCCP в SIP

Особенности Cisco 7940

Питание: работает через POE. Если хотите отдельное питание на 220V, нужно докупить блок питания и шнур питания дополнительно.
Протокол: заточен под работу с Cisco Call Manager, дефолтная прошивка идет с SCCP протоколом, если нужен SIP — нужно заливать прошивку с SIP. Также есть прошивки с MGCP протоколом, если кто-то его использует.
Апгрейд и конфигурирование: производится через tftp — в корень tftp-сервера заливаем файл прошивки и конфигурационные файлы, а циске сообщаем адрес этого tftp-сервера

 

Получение файлов

Для начала файлы SIP-прошивки нужно получить. На сайте cisco.com они есть, но они залочены для обычного зарегистрированного пользователя, нужно либо иметь контракты на обслуживание компании, или связывать аккаунт с серийными номерами ваших цисковских продуктов, в общем нужно показать, что вы у циски что-либо приобрели и имеете право на поддержку.

 

Подготовка телефона

Обновление прошивки производится посредством TFTP-сервера. Сам циско-фон нужно сбросить, настроить сетевые параметры (ip/маска/шлюз) и указать адрес TFTP-сервера. Это можно сделать с помощью DHCP-сервера или прописать вручную через меню телефона.

 

Сброс и подготовительная настройка параметров телефона

Сначала разблокировать конфиг:

Settings — > Unlock config
пароль cisco (это пароль по умолчанию, но его могли поменять)

Сброс:

Settings -> Network Setup -> Erase Configuration:YES

уйдет в ребут.

После этого телефон пробует получить сетевые настройки и адрес TFTP от DHCP-сервера. Если DHCP-сервер не используется, настраиваем вручную.

 

Настройка DHCP-сервера

Пример настройки isc-dhcp на FreeBSD

/usr/local/etc/dhcpd.conf

# phones
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.101 192.168.1.149;
option routers 192.168.1.1;
option tftp-server-name «192.168.1.2»;
}

Значение опции tftp-server-name указываем в кавычках (потому что это строка), иначе вернет ошибку:

/usr/local/etc/dhcpd.conf line 29: expecting string.
option tftp-server-name 192.

 

Ручная настройка параметров телефона

Используем, если нет DHCP-сервера. Сначала снова разблокируем конфиг:

Settings — > Unlock config

Отключаем DHCP:

Settings — > Network Setup ->DHCP Enabled: NO

затем можно редактировать настройки ip/mask/gw и адрес tftp-сервера

 

Файлы прошивки и конфигурационные файлы на TFTP

В директории tftp должны оказаться следующие файлы:

  • OS79XX.TXT (необязательно с 8-й версии)
  • XMLDefault.cnf.xml (если есть SEP<mac>.cnf.xml, вроде как необязательно его создавать)
  • SEP<mac>.cnf.xml
  • P0S3-8-12-00.loads
  • P0S3-8-12-00.sb2
  • P003-8-12-00.bin
  • P003-8-12-00.sbn
  • SIPDefault.cnf
  • SIP<mac>.cnf
  • dialplan.xml (необязательно)
  • RINGLIST.DAT (необязательно)

 

OS79XX.TXT

это файл Dual-boot, в нем указывается, какую версию прошивки загрузить (имеется в виду не релиз, а выбор протокола — SCCP, SIP или MGCP). С 8-й версии прошивки он уже не нужен.

Имя файла OS79XX.TXT чувствительно к регистру и может содержать только имя загружаемого файла без расширения .bin. К примеру, при загрузке ПО SIP версии 2.3 в его имени должна присутствовать только строка P0S30203. Если нужно загрузить ПО версий 3.0 и позднее, имя файла должно находиться в формате P0S3-xx-y-zz. К примеру, при загрузке ПО SIP версии 7.4 в имени файла OS79XX.TXT должна присутствовать строка P0S3-07-4-00.
(c) cisco.com

 

XMLDefault.cnf.xml

файл для определения версии прошивки, которую нужно загрузить

 

SEP<mac>.cnf.xml

файл для определения версии прошивки, которую нужно загрузить. Если версия, указанная в этом файле отличается от версии на флеше телефона, телефон загружает новую прошивку.

 

SIPDefault.cnf

конфигурационный файл для SIP, в нем указываются общие настройки

 

SIP<mac>.cnf

конфигурационный файл для SIP, в котором указываются настройки, специфичные для конкретного телефона. Параметры, указанные здесь, перезаписывают параметры, указанные в SIPDefault.xml. Здесь можно указывать не только логин/екстеншен/пароль для подключения, а любые значения, которые присутствуют в SIPDefault.

 

dialplan.xml (необязательно)

файл диалплана.

 

RINGLIST.DAT (необязательно)

Листинг аудио-файлов, которые могут использоваться как мелодии звонков. Эти аудио-файлы также должны находиться на tftp

 

Ну и необходимые бинарники, без них «кина не будет»:

P0S3-8-12-00.loads
P0S3-8-12-00.sb2
P003-8-12-00.bin
P003-8-12-00.sbn

Скачать прошивку можно здесь, а примеры конфигурационных файлов здесь.

 

Полезные ссылки

http://www.voip-info.org/wiki/view/Asterisk+phone+cisco+79xx

Cisco 7940: Конфигурацианные файлы SIPDefault.cnf и SIPXXXXYYYYZZZZ.cnf

tftp-сервер нам жизненно необходим только при обновлении прошивки. Для конфигурирования телефонов tftp — удобная, но не обязательная вещь.

Т.е. можно единожды настроить телефон вручную или через tftp и убрать tftp (или убрать cnf-файлы с tftp, или закрыть доступ к tftp), и перенести телефон в сеть к пользователю, где tftp не будет.

Когда телефон включается, он сначала идет на tftp-сервер за конфигурационными файлами (если они есть), а если не находит, то загружает параметры, сохраненные локально в его флеш-памяти.

С tftp телефон загружает  следующие файлы:
сначала:
SIPDefault.cnf — дефолтный конфигурационный файл
затем:
SIPXXXXYYYYZZZZ.cnf — phone-specific конфигурационный файл — для конкретного телефона с MAC-адресом SIPXXXXYYYYZZZZ. MAC-адрес записывается в верхнем регистре, расширение .cnf — в нижнем.

 

Параметры, указанные в SIPXXXXYYYYZZZZ.cnf, перезаписывают параметры, указанные в SIPDefault.xml. В SIPXXXXYYYYZZZZ.cnf можно указывать не только логин/екстеншен/пароль для подключения, а любые значения, которые присутствуют в SIPDefault.cnf.

 

Правила записи переменных

Переменные в конфигурационных файлах имеют следующий формат:

variable-name : value ; optional comments

  • одна переменная — одно значение;
  • разделяем переменные и значения двоеточием;
  • на одну строку одна пара переменная:значение, пару не разрываем (не переносим «значение» в следующую строку);
  • можно ставить пробелы перед/после переменных и значений. Если нужен пробел в значении, заключаем значение в кавычки одинарные или двойные. Открывающие и закрывающие кавычки должны быть одинаковыми — либо одинарными, либо двойными;
  • для комментариев используются ; или #
  • строки могут быть пустыми, или с комментариями;
  • названия переменных — регистроНЕзависимые.

Примеры файлов конфигурации для настройки SIP-протокола на телефонах Cisco 7940 (взяты с сайта cisco):

SIPDefault.cnf — файл с общими параметрами SIP, применяемый ко всем телефонам (скачать)
SIPXXXXYYYYZZZZ.cnf — файл в настройками конкретного телефона (скачать)

 

SIPDefault.cnf


 

SIPXXXXYYYYZZZZ.cnf


 

 

Debian: Установка и настройка NET-SNMP

http://pro-voip.com.ua net-snmpЗдесь все манипуляции проводятся на Debian Wheezy.

Установка net-snmp

snmp — SNMP (Simple Network Management Protocol) applications
snmpd — SNMP (Simple Network Management Protocol) agents

snmpd.conf — конфигурационный файл для Net-SNMP SNMP агента.

Редактируем файл /etc/snmp/snmpd.conf:

Рестартуем демон snmpd:

Проверяем (например):

Контроль доступа к snmpd можно организовать двумя способами:

  • Traditional Access Control — традиционный контроль доступа
  • VACM Configuration — View-Based Access Control Model

 

SNMPv1 и SNMPv2c

 

Традиционный контроль доступа

Создание read-only и read-write community:

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, не ограничивая доступ к snmpd:

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, разрешив доступ к snmpd только localhost:

Создать read-only комьюнити public, разрешить доступ с localhost’а к ветке .1.3.6.1.2.1.1:

Если нам нужно объединить несколько разных веток дерева OID’ов для одного community, используем именованые «view»:

Если нужна более гибкое управление доступом к SNMP, следует использовать другую модель управления — VACM.

 

Контроль доступа VACM

Для того, чтобы настроить доступ к snmpd по модели VACM, необходимо определить 4 директивы:

  • com2sec
  • group
  • view
  • access

com2sec определяет некое имя (security name), к нему привязываются ip-адрес и комьюнити, с которыми можно получить доступ к snmpd:

com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

SECNAME — security name;
SOURCE — имя хоста, ip-адрес хоста, или подсеть в формате ip/mask, с которого разрешен доступ к snmpd;
COMMUNITY — строка community;
CONTEXT — используется в SNMPv3

group определяет группу, к которой привязываются ранее созданные secname:

group GROUP {v1|v2c|usm|tsm|ksm} SECNAME

view определяет ветки дерева MIB, к которым будем давать доступ:

view VNAME TYPE OID [MASK]

VNAME — произвольное имя вьюшки. Имена могут повторятся, таким образом создается вьюшка в набором «веток» дерева OID’ов;
TYPE — included или excluded — действие: включить или исключить ветку с view;
OID — определенный OID или ветка;

access даем ранее созданной группе права на доступ к просмотру/записи определенной вьюшки — связка group — view:

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY

GROUP — имя группы, определенное в шаге 2;
CONTEXT — default context —  «»

Пример:

«Пользователь» local — это пользователь локалхоста с комьюнити secret33, который входит в группу rwgroup. Пользователи группы rwgroup имеют read-write права на view с названием all. Вьюшке all соответствует дерево .1.

«Пользователь» rouser1 может получить доступ с сети 10.10.10.0/24, а «пользователь» rouser2 — с ip-адреса 11.11.11.11/32. Комьюнити — public. «Пользователи» rouser1 и rouser2 входят в группу rogroup. Группа rogroup имеет read-only права на view с названием systemview, в которую входят такие ветки дерева — 1.3.6.1.2.1.1, 1.3.6.1.2.1.2, 1.3.6.1.2.1.25:

 

SNMPv3

 

В SNMPv3 главным действующим «лицом» выступает не community, а user. Поэтому перед манипуляциями с контролем доступа, нужно сначала создать пользователя. При создании пользователя, мы также определяем уровень безопасности.

В SNMPv3 предусмотрено три уровня безопасности:

  • noAuthNoPriv — без аутентификации, без шифрования
  • authNoPriv — с аутентификацией (SHA|MD5), без шифрования
  • authPriv — с аутентификацией (SHA|MD5),с шифрованием (DES|AES)

Тип аутентификации — MD5 или SHA; Алгоритм шифрования — DES или AES;
SHA-аутентификация и DES/AES-шифрование используют OpenSSL — OpenSSL должен быть установлен, snmpd должен иметь поддержку OpenSSL.

Узнать, с какими опциями был собран net-snmp можно с помощью следующей команды:

Если —with-openssl в выводе есть, значит net-snmp собран с поддержкой openssl, если кто не догадался.

MD5 не использует OpenSSL.

 

Создание пользователя snmpv3

Для этого используется следующая команда:

net-snmp-config  —create-snmpv3-user [-ro] [-A authpass] [-X privpass] [-a MD5|SHA] [-x DES|AES] [username]

Минимальная длина authpass и privpass — 8 символов.

Сначала останавливаем демон snmpd:

Затем создаем пользователя, например, rouserv3:

При этом создается 2 записи в двух дефолтных конфигурационных файлах, о чем и пишет net-snmp-config в своем выводе. Если вы, не запуская snmpd, посмотрите на файл /var/lib/snmp/snmpd.conf, то в конце файла вы действительно увидите там строку «createUser rouserv3 MD5 «testtest» DES testtest». При запуске демона snmpd эта строка удаляется, появляется вместо нее ключ.

Запись «rouser rouserv3» в файле /usr/share/snmp/snmpd.conf — это настройка контроля доступа. Мало ведь создать пользователя, нужно дать ему какие-то права. Запись «rouser rouserv3» можно перенести в /etc/snmp/snmpd.conf (что я и делаю), а дальше использовать либо традиционный контроль доступа (оставив эту строку «rouser rouserv3»), либо VACM (по аналогии, как это настраивалось выше с SNMPv2c, только там были rocommunity и rwcommunity, а здесь rouser и rwuser).

 

Традиционный контроль доступа

Создание read-only и read-write-пользователя:

rouser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
rwuser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

noauth, auth, priv — помним про три уровня безопасности? было описано выше. Как по мне, так тут не хватает опции SOURCE, как в варианте в SNMP v1 и v2c с комьюнити. Для ограничения доступа с определенных ip-адресов нужно будет использовать фаервол. Ну и дальше примеры.

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, без аутентификации и без шифрования:

Проверка:

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией, но без шифрования:

Проверка:

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией и с шифрованием:

Проверка:

 

Контроль доступа VACM

В варианте с SNMP v1 и v2c для настройки VACM нужно было использовать 4 директивы: com2sec, group, view и access. В варианте с SNMP v3 — только три, com2sec использовать не нужно, у нас уже создан snmpv3-пользователь (он уже и есть «security name»), которого можно добавить в группу.

Отличие от настройки VACM в SNMP v1 и v2c — это указание securityModel — usm в директве group и указани sec.level в директиве access (sec.level может быть noauth, auth или priv)

 

Debian: Как узнать температуру процессора?

http://pro-voip.com.ua debianlm-sensors — набор утилит для считывания значений датчиков температуры, вольтажа и оборотов куллеров. С помощью этих утилит можно ответить себе на вопрос «Какая сейчас температура у моего процессора?» Итак, что мы делаем…

1.Устанавливаем lm-sensors:

apt-get install lm-sensors

2. Определяем наличие датчиков в системе:

sensors-detect

3. Догружаем недостающие драйвера:

modprobe <недостающие модули>

4. И все, смотрим значения датчиков:

sensors

 

Установка lm-sensors на Debian Wheezy

 

Определение датчиков в системе

Перед запуском команды sensors для считывания показаный с датчиков, нужно сначала определить, какие есть датчики в системе, и указать, показания каких из датчиков мы хотим увидеть в выводе команды sensors. С этим нам поможет утилита sensors-detect. Это интерактивная программа, запускаем ее на выполнение, читаем и отвечаем на вопросы. Рекомендуется оставить ответы по умолчанию (по умолчанию ответ Yes, просто нажимаем Enter)

Вывод дальнейший опущен, но, думаю, и так все понятно. Например, здесь был найден «Intel digital thermal sensor«, для которого необходимо будет догрузить драйвер coretemp.

В конце своей работы sensors-detect укажет, какие драйвера необходимы и предложит их добавить в /etc/modules, чтобы они автоматически подгружались при загрузке/перезагрузке системы. Соглашаемся. Но нужно проверить, есть ли у вас эти модули вообще.

Подгружаем недостающие модули

jc42 — не найден, скорее всего, нужно обновить ядро… jc42 нужен для считывания данных темературного сенсора ST STTS2002 DIMM. Обновиться я сейчас не могу, а какая температура памяти как-то не особо важно, поэтому просто уберу его с /etc/modules

Просмотр значений

Вывод всех значений:

Посмотреть значения датчиков в сыром неотформатированном виде:

 

Viel Spaß!

Freeswitch: Аутентификация по ip-адресу с использованием ACL

http://pro-voip.com.ua freeswitchДанный пост посвящен вопросам аутентификации пользователей c использованием acl при регистрации и совершении исходящих вызовов.

Хочу обратить внимание на 3 параметра в sip-профиле

<param name=»auth-calls» value=»true»/>
<param name=»apply-register-acl» value=»customers»/>
<param name=»apply-inbound-acl» value=»customers»/>

apply-register-acl — разрешать регистрацию пользователям, которые прошли проверку acl customers
apply-inbound-acl — разрешать совершать вызовы пользователям, которые прошли проверку acl customers
auth-calls — вкл/выкл аутентифицикацию c использованием acl

если auth-calls=true — apply-register-acl и apply-inbound-acl проверяются
если auth-calls=false — apply-register-acl и apply-inbound-acl игнорируются

Далее разные варианты настройки данных параметров и действия FS и клиента при разных комбинациях и исходах проверки acl

 

На что влияет auth-calls без apply-register-acl и apply-inbound-acl

auth-calls=true/false
apply-register-acl — не указан
apply-inbound-acl — не указан

Здесь аутенфицикация по логину-паролю действует! auth-calls на это никак не влияет.

Процесс регистрации пользователя (Client <-> FS):

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

… как и на входящие инвайты

Процесс совершения исходящего вызова (Client <-> FS):

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 407 Proxy Authentication Required
ACK ->
INVITE ->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10″,nonce=»8898………
<- SIP/2.0 100 Trying

 

На что влияет apply-register-acl

auth-calls=true
apply-register-acl — указан в sip-профиле
apply-inbound-acl — не указан

 

acl: allow

Если ip-пользователя проходит проверку acl (allow):

REGISTER ->
<- SIP/2.0 200 OK

логин-пароль не проверяются
пользователь попадает в тот домен, который укажет сам при подключении, и в соответствующий контекст.
Если у нас на профиле несколько доменов, пользователь при желании может попасть во все, не зная ни логинов, ни паролей!

acl: deny

Если ip-пользователя не проходит acl (deny):

REGISTER ->
<- SIP/2.0 403 Forbidden

в регистрации отказано

fs_cli

 

На что влияет apply-inbound-acl

auth-calls=true/false
apply-register-acl = не указан
apply-inbound-acl — указан в sip-профиле

 

apply-inbound-acl на регистрацию никак не влияет, пользователь проходит проверку логин-пароль, как положено:

REGISTER ->
<- SIP/2.0 401 Unauthorized
REGISTER ->
<- SIP/2.0 200 OK

 

А вот здесь с исходящими вызовами интересная история:

acl: allow

Если при совершении исходящего вызова ip пользователя проходит apply-inbound-acl(allow):
пользователь попадает в контекст public (указаный в sip-профиле)

INVITE ->
<- SIP/2.0 100 Trying
<- SIP/2.0 480 Temporarily Unavailable

acl: deny

Если при совершении исходящего вызова ip пользователя не проходит apply-inbound-acl (deny):
попадает в контекст company1 (указаный в домене)

INVITE ->
<- SIP/2.0 100 Trying
<- IP/2.0 407 Proxy Authentication Required
ACK ->

INVITE->
Proxy-Authorization: Digest username=»11″,realm=»10.10.10.10.»,nonce=»c52788bc………..
<- SIP/2.0 100 Trying

 

Что же за беда с этими контекстами? Пользователь проверку то прошел. Тут вопрос в «месте проведения» этой самой проверки. Поскольку проверка на айпи прошла успешно в sip-профиле! , то к пользователю применились все параметры sip-профиля! , а не домена, к которому подключается клиент.

Когда пользователь не прошел проверку по ip-адресу, FS запросил digest-аутентификацию, которая перекинула его в его домен и в его нужный контекст.

 

Выводы

Будьте аккуратны в использовании аутентификации по acl, особенно если у вас мультидоменная система. Если все же нуждаетесь в apply-register-acl и apply-inbound-acl, то лучше их ставить как можно ближе к клиенту (например, в настройке домена).

И еще… acl в FS не призван защищать, пользуйтесь для защиты фаерволом.

CentOS: Полезные заметки

http://pro-voip.com.ua centos

Man

# yum install man.i686 man-pages.noarch
man.i686: A set of documentation tools: man, apropos and whatis
man-pages.noarch: Man (manual) pages from the Linux Documentation Project

Пользователи

Добавление пользователя:
# useradd <login name>
Пользователь создается с параметрами, описанными в /etc/default/useradd. Для изменения дефолтных параметров можно использовать опции команды useradd. Есть еще команда adduser, но это всего-навсего символическая ссылка на useradd.

Установка пароля новосозданного пользователя:
# passwd <login name>

По умолчанию пользователь не может выполнять команды с правами root’a, используя команду sudo -s:

Править /etc/sudoers:
# visudo

В файле /etc/sudoers видим, что пользователи, которые входят в группу wheel, могут выполнять все команды:

Как вариант, можно добавить пользователя в группу wheel.

Добавить пользователя в дополнительную группу:
# usermod -a -G <group name> <login name>

-a — добавить пользователя в дополнительную группу (не меняя initial-группы пользователя), используется только совместно с опцией -G
-G — указывает, в какую именно группу (или группы) добавить пользователя. Группа должна быть создана ранее.

Добавить пользователя в группу wheel:
# usermod -a -G wheel user1

Проверка:

Добавить пользователя еще в несколько групп:
# usermod -a -G support,sales,management user1

 

Система

Посмотреть версию установленной OS Centos:

# cat /etc/centos-release
CentOS release 6.7 (Final)

lrwxrwxrwx. 1 root root 14 Nov 17 12:52 /etc/redhat-release -> centos-release
lrwxrwxrwx. 1 root root 14 Nov 17 12:52 /etc/system-release -> centos-release

/etc/redhat-release и /etc/system-release — это ссылки на centos-release

Посмотреть список возможных обновлений:
# yum list updates

Upgrage системы (например, с 6.0 до 6.7)
# yum update

 

Ядро и модули

Какие модули загружены:
# lsmod

Информация о модуле
# modinfo <module name>

Загрузить модуль на лету:
# modprobe <module name>

Выгрузить модуль на лету:
# modprobe -r <module name>

 

Автозагрузка модуля при старте системы

Для этого создаем скрипт и размещаем его в /etc/sysconfig/modules
Обязательные условия:
— имя скрипта должно иметь вид <some_words>.modules, например 8021q.modules
— скрипт, само собой, делаем исполняемым — chmod +x 8021q.modules
— сам скрипт запускает все тот же modprobe <имя модуля>

не забываем про первую строку #!/bin/sh и путь к modprobe лучше указать полностью

 

Добавление своего скрипта в автозагрузку

Скрипт должен быть исполняемым

# ls -al /etc/iptables/iptables-start.sh
-rwxr—r—. 1 root wheel 83 Nov 28  2013 /etc/iptables/iptables-start.sh

Добавляем его в /etc/rc.local

Скрипт выполняется после загрузки системы.

 

Сеть

DNS Настройка резолвера:

/etc/resolv.conf

seacrh provoip.in.ua
nameserver 8.8.8.8
nameserver 8.8.4.4

Настройка сетевых параметров:

/etc/sysconfig/network

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=srv.provoip.in.ua
GATEWAY=192.168.100.1

NETWORKING=yes (yes — сеть будет настраиваться автоматически из скриптов /etc/sysconfig/network-scripts, no — вручную)

 

Настройка сетевых интерфейсов:

/etc/sysconfig/network-scripts/ifcfg-*

В /etc/sysconfig/network-scripts есть файлы вида ifcfg-*, например ifcfg-eth0, ifcfg-eth1, ifcfg-lo — в них описываем необходимые настройки сетевых карт. Эти файлы передаются в качетсве аргумента в скрипты ifup, ifdown и т.п. Каждая сетевая карта имеет свой файл ifcfg-. Например, есть в системе сетевая карта, которая определяется как eth0. Для ее автонастройки после перезагрузки системы необходим соответствующий файл ifcfg-eth0.

 

Конфигурация сетевой карты (фиксированный ip-адрес):

DEVICE=eth0
BOOTPROTO=none
IPADDR=192.168.100.2
NETMASK=255.255.255.0
NETWORK=192.168.100.0
BROADCAST=192.168.100.255
ONBOOT=yes — включать интерфейс при загрузке или нет
NAME=eth0

Конфигурация сетевой карты (получение ip-адреса по dhcp):

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

BOOTPROTO=<protocol>, значения — none, dhcp, bootp — какой протокол использовать для получения настроек
BROADCAST=<address> — необязательно указывать, высчитывается автоматически
NETWORK=<address> — необязательно указывать, высчитывается автоматически
DEVICE=<name> — имя физического устройства

HWADDR=<MAC-address> — используется в серверах с несколькими сетевыми картами для того, чтобы убедиться интерфейсы получат свои правильные device-name. Т.е., например, настройки, прописанные для девайса eth0 всегда будут применяться к карте с вот таким вот HWADDR (Другими словами, сетевая карта с этим вот HWADDR всегда будет иметь имя eth0 и на при каких обстоятельствах не поменяет его на eth1). Директива не используется совместно с MACADDR.
MACADDR=<MAC-address> — можно перезаписать MAC-адрес физической сетевой карты (в форме AA:BB:CC:DD:EE:FF). Директива не используется совместно с HWADDR.

ETHTOOL_OPTS=<options> — указать опции утилиты ethtool, например, прибить жестко скорость и т.д
ETHTOOL_OPTS=»autoneg off speed 100 duplex full»

DNS1=<address>
DNS2=<address>
PEER_DNS=yes — изменять /etc/resolv.conf. При ONBOOT=dhcp PEER_DNS=yes — это дефолтное значение

SRCADDR=<address> — ip-адрес, котрый навешивается на исходящие пакеты (полезно если на интерфейсе прибито alias’ом несколько адресов)
USERCTL=<yes,no> — Не-root пользователи могут (или нет) управлять сетевой картой

 

Алиас на интерфейс:

Алиас — несколько ip-адресов на одном физическом интерфейсе

Файл для алиаса — ifcfg-<if-name>:<alias-value>

DEVICE=<ifname>:<alias-value>

!Алиас-интерфейсы не поддерживают DHCP

Пример

Физический интерфейс — файл ifcfg-eth0 (DEVICE=eth0)
Алиас на физический интерфейс — файл ifcfg-eth0:0 (DEVICE=eth0:0)
Еще один алиас на физический интерфейс — файл ifcfg-eth0:1 (DEVICE=eth0:2)
и т.д.

 

Файл-клон интерфейса:

Файл-клон используется для добавления каких-либо опций для одного и того же физического интерфейса.
Файл ifcfg-<if-name>-<clone-name>

Пример

Физический интерфейс — файл ifcfg-eth0 (DEVICE=eth0)
Клон физического интерфейса — файл ifcfg-eth0-custom (DEVICE=eth0)
Параметры, указанные в ifcfg-eth0 и ifcfg-eth0-custom комбинируются

 

802.1q в Centos

Должен быть загружен модуль 8021q
Проверяем:
# lsmod | grep 8021q

Если не загружен, загружаем:
# modprobe 8021q

Добавим автозагрузку модуля при старте системы (как это делается, смотрим выше)

! Для каждого влана создаем свой файл ifcfg-ethX.<vlan number> в /etc/sysconfig/network-scripts/. 

VLAN=yes
DEVICE=ethX.<vlan number>
IPADDR=192.168.100.2
NETMASK=255.255.255.0
ONBOOT=yes

Не лишним будет создать ifcfg- файл физического устройства перед этим.

Пример

Нужно создать vlan 222 на интерфейсе eth0. Создаем 2 файлав /etc/sysconfig/network-scripts/:

ifcfg-eth0

DEVICE=eth0
ONBOOT=yes

ifcfg-eth0.222

VLAN=yes
DEVICE=eth0.222
IPADDR=192.168.100.2
NETMASK=255.255.255.0
ONBOOT=yes

FreeBSD: Работа с коллекцией портов

http://pro-voip.com.ua freebsd

Скачать и распаковать коллекцию портов (утилита portsnap):

portsnap fetch extract

-данная команда выполняется один раз после установки свежей ОС, если в процессе установки вы не отметили галочкой установку портов сразу; либо если вы потерли каким-то образом свою коллекцию портов. В последующем же, чтобы установить порт, достаточно выполнить три действия:

1. Обновить коллекцию портов:

portsnap fetch update

2. Найти нужный порт:

cd /usr/ports
make search name=rkhunter

3. Установить нужный порт:

cd /usr/ports/security/rkhunter
make install clean

 

Вся коллекция портов находится в /usr/ports. Все приложения, описаные в коллекции портов, сгруппированы в категории (databases, deskutils, net-mgmt и т.д.).

 

Поиск

Поиск необходимого порта по имени (ищет совпадения в названии порта). Команда выполняется в директории /usr/ports:

make search name=rkhunter

Поиск порта по описанию (ищет совпадения и в названии и в описании порта, полезно, если не помнишь, как приложение называется, но помнишь хоть примерно, что оно должно делать или с чем оно связано). Команда выполняется в директории /usr/ports:

make search key=hunter

 

Описание порта

Пример, порт /usr/ports/security/rkhunter

Порт — директория с набором файлов, в которых находится достаточная информация для сборки и установки приложения. Самих исходных кодов порт не содержит, но знает, где их найти.

  • Makefile — содержит базовые команды и настройки для сборки порта. Здесь же и указывается (в переменной MASTER_SITES=), откуда скачивать исходники (src) приложения . Исходники приложения представляют собой сжатый архив с необходимыми src-файлами для сборки и установки.
  • distinfo — содержит контрольные суммы для файлов, которые скачиваются при сборке порта. Таким образом производится проверка на целосность.
  • files — директория содержит дополнительные патчи и исправления, которые в ходе сборки приложения накладываются на разархивированные исходники.
  • pkg-descr — описание приложения
  • pkg-message — содержит сообщения, адресованое от разработчиков администратору. В нем может указываться поздравление с установкой, необходмые дальнейшие шаги после установки, рекомендации и т.д. Файл pkg-message необязателен.
  • pkg-plist — перечень файлов, которые плодит устанавливает порт в системе.
  • В процессе сборки в директории порта создается рабочая директория work.

 

Описание процесса установки приложения с порта

  1. Конфигурирование опций порта
  2. Загрузка архива с исходными файлами приложения
  3. Проверка загруженых файлов на наличие ошибок
  4. Извлечение исходных файлов с архива в рабочую директорию
  5. Наложение патчей с директории files, если такое имеются и необходимы
  6. Проверка и установка зависимостей
  7. Запуск сценария configure, если такой есть в приложении
  8. Сборка приложения из исходных файлов
  9. Установка приложения (копирование скомпилированных бинарников, файлов конфигурации и т.п. в необходимые места в файловой системе — а что это за файлы и в какие необходимые места, описано в  pkg-plist)
  10. Регистрация приложения в /var/db/pkg — да, у нас получился обыкновенный пекедж.

 

Другие команды

Команды выполняются в директории порта. «make install clean» запускает поочередно цикл команд, которые проводят через все этапы установки приложения, описаные выше. При необходимости можете запускать эти команды вручную. Например, если вам нужно только собрать, но не устанавливать приложение, используем «make build«, который выполнит с 1 по 8-й пункты (см. описание процесса выше). Если нужно только скачать исходники, используем «make fetch«.

make config
— конфигурирование порта — если есть опциональные параметры, или дополнительные модули, здесь их можно включить/исключить.

make config-recursive
— конфигурирование порта и его зависимостей. Процесс сборки бывает длительным, и зависимостей бывает много. Для того чтобы перед установкой зависимостей каждый раз процесс не прерывался и не ждал от вас решения установить те или иные параметры для зависимостей, хорошо сразу все сконфигурить и оставить приложение собираться в одиночку.

make showconfig
— посмотреть, какие параметры выбраны.

make rmconfig
— удалить выставленные пользователем параметры, т.е. сбросить конфиг в дефолт — отмеченные изначально останутся отмечеными, отмеченные пользователем — удаляются.

make fetch
— загрузка архива с исходниками.

make fetch-recursive
— загрузка архивов с исходниками порта и зависимостей.

Откуда загрузка? — указано в Makefile в переменной MASTER_SITES=. Путей может быть несколько.
Куда загружаются исходники? — в /usr/ports/distfiles

make checksum
— проверка целосности скачаного архива с исходными файлами приложения

make extract
— извлечение скачаного архива — директории порта создается рабочий каталог work, куда и извлекаются исходники.

make patch
наложение или накладывание? Применение патчей с директории files.

make depends
— проверка зависимостей.

make configure
— если в приложении есть свой сценарий configure, он выполняется

make build
— компиляция кода.

make install
— установка приложения и регистрация его в /var/db/pkg.

make clean
— удаление рабочей директории work (архив с исходниками остается в /usr/ports/distfiles).

make distclean
— удалить архив с исходниками.

 

Источники информации

https://www.freebsd.org/doc/handbook/ports-using.html
http://freebsdguide.ru/_11/_6/

Freeswitch: Подключение к SIP-серверу провайдера

Подключение к оператору (провайдеру) связи производится через секцию <gateways> sip-профиля. Каждый gateway в секции <gateways> определяет одну регистрацию на сервере оператора. В дефолтном конфиге FS предлагает для таких вот внешних регистраций использовать sip-профиль external, описаный в файле external.xml. В дополнение к файлу external.xml подключается директория external, в котором в каждом xml-файле описан один gateway (вообще, такое деление на мелкие файлы мне лично кажется удобным для администрирования — удобно смотреть, редактировать, добавлять, удалять).

В этой статье я хочу описать несколько вариантов подключения FS к операторам/провайдерам связи. Это не все варианты — на страницах документации freeswitch.org можно найти больше примеров.

 

1. Регистрация Freeswitch по логину и паролю — один аккаунт у одного провайдера

В данном случае username, используемый для регистрации, является и нашим номером — 5555555, — на который мы будем принимать звонки, и номером, с которого мы будем звонить через этот gateway — поле From тоже будет 5555555. Регистрация будет происходить на сервере 192.168.100.100 — ip-адрес сервера прописан в gateway name.

 

2. Регистрация Freeswitch по логину и паролю — несколько аккаунтов у одного провайдера

Для того, чтобы зарегистрировать пару аккаунтов на одном и том же sip-сервере, нужно создать два отдельных gateway c разными названиями (name) —  при этом name не должен быть ip-адресом либо доменным именем, просто произвольное слово, например, gateway1 и gateway2, — а реальный ip-адрес сервера необходимо прописать в  параметре realm.

 

3. Регистрация Freeswitch по логину и паролю, один номер, username для регистрации отличается от номера

Параметр from-user используется для установки поля From при исходящих вызовах через данный gateway, параметр extension — для установки поля To при входящих вызовах с gateway. Если эти параметры явно не указать, по умолчанию применится значение username — user1 и, логично, вызовы с/на 5555555 проходить не будут.

 

4. Регистрация Freeswitch по логину и паролю, несколько номеров в одном аккаунте (построение транка с регистрацией)

Параметр caller-id-in-from позволяет каждому абоненту звонить со своим параметром From. Для этого в диалплане в extension, который описывает исходящий вызов через этот внешний gateway, нужно в переменную effective_caller_id_number подставить значение реального номера.

Например, есть абонент с внутренним номером 11, который при звонке «в город» должен звонить с номера 5555557. Прописываем в переменную абонента outbound_caller_id_number значение 5555557:

И прописываем в диалплане extension, в котором effective_caller_id_number подменяется значением переменной outbound_caller_id_number:

 

5. Подключение Freeswitch к провайдеру без регистрации

Просто ставим register=false и FS не будет отправлять запросы REGISTER к провайдеру. Обратите внимание, что username и password все равно должны присутствовать.

 

Зависимость значений некоторых параметров друг от друга в описании gateway

freeswitch gateway parameters

gateway name — обязательно нужно указывать. Параметр realm, если не указано другое, принимает значение gateway name. Параметр from-domain, если не указано другое, принимает значение realm и т.д.

Телефонный план нумерации Украины

Международный телефонный код Украины — 380.
Чтобы позвонить извне в Украину, набираем 380-yy-xxx-xx-xx

xxx-xx-xx — 7 цифр — звонки по фиксированной связи в пределах города
0-yy-xxx-xx-xx — 10 цифр — звонки в пределах Украины
00-код страны-код города-абонентский номер — звонки с Украины зарубеж

00 — выход на международные линии
0 — выход на междугородние линии или на мобильного оператора
yy — код мобильного оператора, или города, или области
xxx-xx-xx — 7-значный номер абонента

  • 010 — коды альтернативного выбора междугородней/международной фиксированной телефонной связи
  • 0100 — dial-up
  • 031, 032, 033, 034, 035, 036, 037, 038, 041, 043, 044, 045, 046, 047, 048, 051, 052, 053, 054, 055, 056, 057, 061, 062, 064, 065, 069 — список телефонных кодов областей Украины
  • 050, 063, 066, 067, 068, 073, 091, 092, 093, 094, 095, 096, 097, 098, 099 — список кодов мобильных операторов Украины
  • 0700 — код услуги персонального номера
  • 0800 — «бесплатные» горячие линии — платит получатель вызова
  • 089 — SIP-телефония Украины
  • 0900 — платные линии

 

Телефонные коды областей Украины
КодОбласть
31-xxx-xx-xxЗакарпатская область
32-xxx-xx-xxЛьвовская область
33-xxx-xx-xxВолынская область
34-xxx-xx-xxИвано-Франковская область
35-xxx-xx-xxТернопольская область
36-xxx-xx-xxРовенская область
37-xxx-xx-xxЧерновицкая область
38-xxx-xx-xxХмельницкая область
41-xxx-xx-xxЖитомирская область
43-xxx-xx-xxВинницкая область
44-xxx-xx-xxКиев город
45-xxx-xx-xxКиевская область
46-xxx-xx-xxЧерниговская область
47-xxx-xx-xxЧеркасская область
48-xxx-xx-xxОдесская область
51-xxx-xx-xxНиколаевская область
52-xxx-xx-xxКировоградская область
53-xxx-xx-xxПолтавская область
54-xxx-xx-xxСумская область
55-xxx-xx-xxХерсонская область
56-xxx-xx-xxДнепропетровская область
57-xxx-xx-xxХарьковская область
61-xxx-xx-xxЗапорожская область
62-xxx-xx-xxДонецкая область
64-xxx-xx-xxЛуганская область
65-xxx-xx-xxКрым АР - отключено 2015 г.
69-xxx-xx-xxСевастополь город - отключено 2015 г.

 

Телефонные коды мобильных операторов Украины
КодМобильный оператор
39-xxx-xx-xxGolden Telecom
50-xxx-xx-xxМТС Украина
63-xxx-xx-xxАстелит (он же Life:))
66-xxx-xx-xxМТС Украина
67-xxx-xx-xxКиевстар
68-xxx-xx-xxКиевстар (бывший Beeline)
73-xxx-xx-xxАстелит (он же Life:))
91-xxx-xx-xxТримоб (ТМ от Укртелеком)
92-xxx-xx-xxТЕЛЕСИСТЕМЫ УКРАИНЫ (они же PEOPLEnet)
93-xxx-xx-xxАстелит (он же Life:))
94-xxx-xx-xxИнтернациональные телекоммуникации (он же Интертелеком)
95-xxx-xx-xxМТС Украина
96-xxx-xx-xxКиевстар
97-xxx-xx-xxКиевстар
98-xxx-xx-xxКиевстар
99-xxx-xx-xxМТС Украина

 

SIP телефонные коды Украины
Код услугиНомерОператор
89SIP
89089-0xx-xx-xx--- не распределено
89189-1xx-xx-xxДатагруп
89289-2xx-xx-xxУкртелеком
89389-3xx-xx-xxТ.Р.Комьюникейшн
89489-4xx-xx-xxАтлантис Телеком
89589-5xx-xx-xxЛинком 3000
89689-6xx-xx-xx--- не распределено
89789-7xx-xx-xxКиевстар
89889-8xx-xx-xx--- не распределено
89989-9xx-xx-xxВелтон.Телеком

 

Другие телефонные коды Украины
Код услугиНомерОператор
10Коды альтернативного выбора сети междугородней фиксированной телефонной связи
10-23x-xx-xxДатагруп
10-93x-xx-xxАстелит (он же Life:))
10Коды альтернативного выбора сети международной фиксированной телефонной связи
10-23x-xx-xxДатагруп
10-33x-xx-xxФарлеп-Инвест
10-50x-xx-xxУкртелеком
10-93x-xx-xxАстелит (он же Life:))
100Код услуги выхода с сети ТФОП в сеть Интернет (dial-up)
100-50-xx-xxУкртелеком (dial-up)
700Код услуги персональных номеров
700-90-xx-xxИнтернациональные Телекоммуникации
800Бесплатные горячие линии.
Коды глобальной услуги "Вызов за счет абонента, который вызывают"
800-10-xx-xxВелтон.Телеком
800-20-xx-xxАстелит (он же Life:))
800-21-xx-xxДатагруп
800-30-xx-xxКиевстар
800-40-xx-xxМТС Украина
800-50-xx-xxУкртелеком
800-60-xx-xxФарлеп-Инвест
800-75-xx-xxИнтернациональные Телекоммуникации
800-80-xx-xxТ.Р.Комьюникейшн
900Платные линии. Коды глобальной услуги "С распределением прибыли"
900-23-xx-xxАудиотекс
900-25-xx-xxТ.Р. Комьюникейшн
900-26-xx-xxЕвроинформ
900-30-xx-xxУкртелеком
900-31-xx-xxДатагруп
900-32-xx-xxЕвро-Информ
900-33-xx-xxФарлеп-Инвест
900-90-xx-xxМикроком