Вступление

Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.

Данная статья — это обобщение информации, накопленной за время использования гипервизора Qemu-KVM. Я хочу поделиться теми знаниями опытом, которыми обладаю на данный момент. Надеюсь, что моя статья пойдет на пользу тем, кто только собирается использовать гипервизор Qemu-KVM или уже использует. И еще: статья не для новичков linux (элементарные вещи здесь рассматриваться не будут).

Про данную систему виртуализации в сети написано много. Но когда действительно начинаешь с ней работать — сталкиваешься с нехваткой информации и практических примеров применения. Итак приступим.

Входящая задача. Был выделен компьютер как тестовая станция – для проверки работоспособности резервных копий баз данных, устанавливаемого программного обеспечения, сборки msi пакетов и прочих весьма разнообразных задач. Конфигурация компьютера:

• процессор Atlon X2 245
• оперативная память 4 гигабайта
• жесткий диск 500 гигабайт
• материнская плата ASUS M4N68T-M LE.

Более 3-х лет мы пытались настроить грамотную интеграцию 1С: Предприятия 8 и телефонной АТС на базе Asterisk для своего офиса. За какое бы решение мы не брались, всегда получались какие-то костыли. Это очень огорчало. Но на рынке действительно не было нормального решения для интеграции. Перепробовали разные продукты, бесплатные и платные, потратив не один 10-ток тысяч рублей, но счастья не наступало.

AMI — мощный и удобный программный интерфейс (API) Asterisk для управления системой из внешних программ. В дополнение к AMI, часто используется AGI — это интерфейс для запуска внешних приложений, управляющих каналом Астериска в рамках конкретного вызова. Благодаря AMI внешние программы могут осуществлять соединения с Астериском посредством TCP протокола, инициировать выполнение команд, считывать результат их выполнения, а так же получать уведомления о происходящих событиях в реальном времени. Этими механизмами можно пользоваться, например в следующих случаях:

• Необходимо узнать состояние системы
• Количество активных абонентов
• Выполнять команды CLI удаленно
• Улучшить хранение CDR
• … и многое другое

AMI часто используют для интеграции с бизнес-процессами и системами, программным обеспечением CRM (Customer Relationship Managment — управление взаимодействия с клиентами). Он также может применяться для разнообразных приложений, таких как программы автоматического набора номера и системы click-to-call (звонок-по-щелчку).

Управление Астериском часто осуществляется из консоли CLI, но при использовании AMI не требуется прямой доступ к серверу, на котором запущен Астериск. AMI — это наиболее простой инструмент, который в руках разработчика может оказаться очень мощным и гибким средством для интеграции с другими программными продуктами. Он дает возможность разработчикам использовать информацию, генерируемую Астериском, в реальном масштабе времени.

Стоит так же отметить, что Астериск начиная с версии 1.6 использует интерфейс менеджера версии 1.1. В основном изменения коснулись объединения множества однотипных команд и стандартизации ответов, выдаваемых различными модулями. Выяснить версию интерфейсам можно с помощью команды CoreSettings. Версия может меняться в дальнейшем, если интерфейс AMI будет терять полную совместимость с предыдущими версиями.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Как вы знаете, django очень мощный и гибкий фреймворк. Для него создано огромное количество приложений, как и каких-то личных так и публичных. Приложения могут быть как и достаточно монотонными, так и достаточно гибкими и даже встраиваемыми в другие приложения.

Привет!

Я много работаю с VoIP-сетями. С коммерческим оборудованием, конечно тоже, но и очень много с OpenSource (статья пишется в контексте использования Asterisk PBX).

В телефонии часто возникает простая задача, разделить маршруты на определённые направления. Ну например, направить вызовы на городские номера в сторону оператора 1, МГ — в сторону оператора 2, МН — в сторону оператора 3.
Задача, в общем-то тривиальная, и реализуется на Asterisk легко:

;Местная городская связь: 7 знаков (в разных регионах РФ от 3-х до 7-ми знаков), и номера экстренных служб.
exten => _0X,1,dial(SIP/itsp1/${EXTEN})
exten => _0XX,1,dial(SIP/itsp1/${EXTEN})
exten => _XXXXXXX,1,dial(SIP/itsp1/${EXTEN})
;Междугородняя и мобильная связь: код выхода на МГ связь (в РФ - "8") + 10 знаков.
exten => _8[348]XXXXXXXXX,1,dial(SIP/itsp2/${EXTEN})
exten => _89XXXXXXXXX,1,dial(SIP/itsp2/${EXTEN})
;Международная связь: код выхода на МН связь (в РФ - "810") + номер телефона в международном формате.
exten => _810X.,1,dial(SIP/itsp3/${EXTEN})

Однако иногда возникает необходимость предоставить абоненту доступ только к мобильным телефонам его области, и здесь простым "_89XXXXXXXXX" не отделаешься.