Процесс настройки и управления VPN на Linux-сервере обычно занимает немало времени. И если настроить можно один раз и забыть, то управлять пользователями VPN периодически приходится и хорошо бы, чтобы это мог делать и рядовой сотрудник компании без прав доступа к серверу и SSH вообще. Часто используется сценарий, когда с помощью VPN организуется доступ во внутреннюю сеть облака для подключения виртуальных серверов к корпоративной сети компании. Даже для себя быстро поднять VPN бывает полезно.

В этой статье мы буквально за несколько минут настроим OpenVPN сервер с возможностью простого управления VPN–серверами, пользователями и организациями и запустим все это в InfoboxCloud. Это облако присутствует в регионах Москва и Амстердам, благодаря чему можно использовать VPN как для корпоративных целей, так и для того, чтобы представиться жителем Нидерландов в сети (например для использования сервисов, которые не доступны на территории вашей страны).

На сервере мы будем использовать проект Pritunl, который представляет собой панель управления, автоматизирующую управление конфигурациями OpenVPN. Исходные тексты pritunl открыты и доступны на гитхабе. Бесплатной версии более чем достаточно для использования. Платная позволяет отправлять данные для доступа по email или настраивать автоматическую отказоустойчивость сервиса (что для InfoboxCloud не очень важно, т.к. само облако работает в отказоустойчивом кластере) и управлять балансировкой нагрузки между несколькими серверами.

Предисловие

Добрый день.

На написание данной статьи меня сподвигло 2 вещи: малое количество или вовсе отсутствие современных рабочих примеров по «фишкам» Asterisk, а так же нежелание специалистов делиться этими самыми «фишками» с остальными. Это я сейчас про РУ-комьюнити. Всякие «Деды» на форумах скорее обольют тебя помоями и отправят читать книжки десятилетней давности, чем дадут мало мальски полезную информацию. Сами же темы форумов, созданные в 2005-2010 годах, сильно устарели и иногда что то уже выпилено из текущей версии астериска, а что то надо очень сильно переделать, чтобы заработало.

Развертываение kubernetes HA с containerd

Добрый день уважаемые читатели Хабра! 24.05.2018 г. в официальном блоге Kubernetes была опубликована статья под названием Kubernetes Containerd Integration Goes GA, в которой говорится, что интеграция containerd с Kubernetes готова к production. Также ребята из компании Флант в своем блоге разместили перевод статьи на русский язык, добавив немного уточнений от себя. Почитав документацию проекта на github, я решил попробовать containerd на "собственной шкуре".

У нас в компании есть несколько проектов в стадии "до продакшена еще очень далеко". Вот они и станут нашими подопытными; для них мы решили попробовать развернуть отказоустойчивый кластер Kubernetes с использованием containerd и посмотреть, есть ли жизнь без docker.

Если Вам интересно посмотреть, как мы это делали и что из этого получилось, — добро пожаловать под кат.

Сегодня мы поговорим о зеркалировании трафика на маршрутизаторах Juniper серии MX. После свичей производства Cisco, Huawei или Arista конфигурация SPAN и RSPAN на JunOS будет казаться очень сложной, но за сложной (на первый взгляд) конфигурацией скрываются огромные возможности платформы MX в области зеркалирования трафика. Подход Juniper хоть и на первый взгляд сложен, но становится прост и понятен, если не тупо копипастить конфиги с одной коробки на другую, а понимать, что и зачем делается. Идеология JunOS предполагает использовать filter based forwarding (FBF) в целях зеркалирования, что дает нам определенную гибкость в реализации сложных схем зеркалирования трафика.

Итак, начнем. Мы рассмотрим несколько примеров зеркалирования:

1. Локальное зеркалирование с порта на порт
2. Зеркалирование на два и более потребителя
3. Зеркалирование на удаленный хост
4. Избирательное зеркалирование на два и более потребителя
5. Локальное зеркалирование L2 трафика
6. Зеркалирование L2 трафика на удаленный сервер
7. Использование более двух mirroring инстансов на одном FPC

Итак, начнем по порядку.

В процессе эксплуатации того или иного умного устройства пользователи зачастую сталкиваются с рядом проблем, которые решить может только производитель. Решение, казалось бы, рядом: сообщаем по официальным каналам о найденном баге, производитель исправляет, выкладывает новую прошивку, дает инструкции по обновлению, обновляемся и все счастливы.

На практике же все не так сказочно и зачастую достучаться до производителя бывает сложно или совсем невозможно. А может банально закончиться срок поддержки данной модели устройства, тогда заниматься исправлением точно никто не будет.

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

Для нетерпеливых: в конце получился полноценный аппарат с актуальной версией загрузчика U-Boot, Debian Jessie и OpenMediaVault на борту.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

В прошлый раз мы говорили о работе с потоками ввода, вывода и ошибок в bash-скриптах, о дескрипторах файлов и о перенаправлении потоков. Сейчас вы знаете уже достаточно много для того, чтобы писать что-то своё. На данном этапе освоения bash у вас вполне могут возникнуть вопросы о том, как управлять работающими скриптами, как автоматизировать их запуск.

Многие пользуются функцией синхронизации с облаком от крупных компаний, таких как Apple или Google, кто-то предпочитает Yandex, mail.ru и тому подобное. Мне эти варианты не приглянулись, предпочитаю свои данные хранить самостоятельно. Потому, однажды, решил сделать себе простенькое «облако».


Задача: синхронизировать устройства и дать возможность получить отснятый материал через web-браузер, авторизировавшись по паролю. Пароль этот раздать родным и близким.

Командная строка Unix полна сюрпризов. Например, вы знали, что инструмент ls, который чаще всего используется для получения списка файлов в текущем каталоге, в версии OS X распознаёт не менее 38 разных флагов?

Я не знал, так что затвитил этот факт. И получил парочку ответов, один из которых заставил меня задуматься: действительно ли саму Unix нужно винить в этом?

Насколько я знаю, ни Linux, ни OS X не были спроектированы в строгом соответствии с философией Unix. Будет лицемерием основывать критику “Unix” только на этих производных от Unix, которые есть у нас сегодня.

Но я всё-таки попробую показать, как много проблем с интерфейсами командной строки в современных наследниках Unix восходят к корням самой Unix. В частности, я попытаюсь объяснить свой скепсис относительно идеи, что окружение командной строки Unix могло когда-либо поддерживать экосистему программ, каждая из которых хорошо выполняет одну функцию.

Но я немного опережаю события. Прежде чем я начну говорить об этом, давайте более пристально посмотрим на команду ls и попробуем выяснить, что конкретно она делает не так.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

В прошлый раз, в третьей части этой серии материалов по bash-скриптам, мы говорили о параметрах командной строки и ключах. Наша сегодняшняя тема — ввод, вывод, и всё, что с этим связано.

Давно хотел написать целостный туториал по поднятию Owncloud в условиях домашнего сервера или небольшой компании до 500 пользователей. Owncloud — это прекрасный open-source проект, который позволяет на собственной инфраструктуре поднять свой вариант сервера синхронизации. По возможностям очень похож на Dropbox, а в чем-то его и превосходит. Огромный плюс — отсутствие ограничений по объемам хранения, полный контроль над сервером. Минусы тоже очевидны: вам самим придется следить за всем этим безобразием и беспокоиться о надежности сервера, валяющегося на антресолях или в шкафу.

Совсем недавно мне подвернулась задача по развертыванию Owncloud в домашне-боевых условиях. Я честно отработал свои два литра кошерного русского имперского стаута и решил поделиться своим опытом, собрав все воедино. Итак, сегодня мы рассмотрим:

1. Развертывание актуального LEMP-stack
2. HTTPS. Let's Encrypt для Nginx с автоматическим обновлением сертификата
3. Конфигурирование Nginx для Owncloud
4. Кэширование php-apcu
5. Подключение внешнего основного хранилища по NFS

Вероятно, что трудно найти другую, настолько же полезную и плохо документированную программу, как Netstat, имеется в виду, опция показа статистики сетевого потока данных. Когда мы проводим инспекцию состояния сети на отдельно взятом Linux узле, всегда можно быть уверенным, что это утилита имеется в наличии. И вот мы хотим понять — справляется ли сетевой стэк с нагрузкой, или проблема на верхних этажах OSI, собственно там, где сосредоточенно крутятся колесики бизнес-логики нашего приложения.

(5:562)$ netstat -s |wc -l
124

Ура, у нас куча полезной информации, сейчас мы быстренько сообразим, что к чему. Вот только бы понять, что же это за зверь такой timeout in transit, явно что-то нехорошее.

Регулярно возникает задача подключения USB-устройства к удаленному ПК через локальную сеть. Под катом изложена история моих поисков в этом направлении, и путь к готовому решению на базе open-source проекта USB/IP с описанием заботливо установленных различными людьми на этом пути препятствий, а также способов их обхода.

Доброго времени суток хабражители.

Хотелось бы поделиться опытом развертывания голосовых деревьев (IVR), с помощью Asterisk.
Для этого нам понадобится:

• Машина с установленным Asterisk`ом
• Телефонный номер, заведенный в Asterisk посредством SIP/H.323 от провайдера ip-телефонии, либо посредством аналоговой линии/цифрового потока Е1 через платы Digium

Часто с началом нового проекта программист не в состоянии увидеть полную картину — он не знает с чего начать, где получить информацию, сколько ее получить, при этом есть шанс засесть за документацией надолго пока не пропадет желание что-либо делать. Я относительно часто делаю проекты «для души» в ранее незнакомых областях, например, программировал микроконтроллеры, делал свой segway, проектировал на ПЛИС свой микропроцессор, делал плагины под Counter-Strike, софт к купюроприемникам и другие проекты, в которых на старте был абсолютным нулем.

В работе Python приложения встала задача получать данные с сетевого оборудования и проводить его настройки удалённо, по SSH. Можно воспользоваться Paramiko, а можно не выдумывать велосипед и использовать основанную на нём библиотеку Exscript. Под катом — примеры кода для подключения и получения информации из команд. Ввиду отсутствия документации к Exscript этот материал может кому-нибудь здорово пригодиться.

Идея создать будильник на базе Asterisk была уже давно, т.к. от обычного будильника проснуться получалось не всегда в отличии от звонка. Идея следующая: на веб-сайте задаем свой номер телефона и время, когда нас надо разбудить (с учетом дней недели). Когда наступает час X и минута Y, то Asterisk звонит по указанному номеру и проигрывает ругательную запись о необходимости скорейшего подъема.

Команду «smartctl -d ata -a /dev/sdb» можно использовать для проверки жесткого диска и текущего состояния его соединения с системой. Но как с помощью команд smartctl проверить SAS или SCSI диски, спрятанные за RAID контроллером Adaptec в системах под управлением Linux ОС? Для этого необходимо использовать последовательные синтаксисы проверки SAS или SATA. Как правило — это логические диски для каждого массива физических накопителей в операционной системы. Команду /dev/sgX возможно использовать в качестве перехода через контроллеры ввода/вывода, которые обеспечиваюь прямой доступ к каждому физическому диску, подключенному к RAID контроллеру Adaptec.

Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй части будут рассмотрены:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Вам знакома такая архитектура? Хоровод демонов, пляшущих между web-server, cache и storage.



Какие минусы такой архитектуры можно отметить? Решая задачи в рамках такой архитектуры, мы сталкиваемся с кучей вопросов: какой язык(и?) взять, какой I/O framework выбрать, как синхронизировать cache и storage? Куча инфраструктурных вопросов. А зачем решать инфраструктурные вопросы, когда надо решить задачу? Безусловно, можно сказать, что нам нравятся некие технологии X и Y, и перевести эти минусы в рамки идеологических. Но нельзя отрицать тот факт, что данные располагаются на неком расстоянии от кода (картинка выше), что добавляет latency, что может уменьшить RPS.

Цель данной статьи — рассказать об альтернативе, которая построена на базе Nginx как web-server, bаlancer и Tarantool как App Server, Cache, Storage.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.