Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.

В 2019 году была написана потрясающая статья Parse, don’t validate. Я крайне рекомендую изучить её всем программистам (а также недавнее дополнение к ней Names are not type safety). Её основная идея заключается в том, что существует два способа проверки валидности входящих данных функции:

• Валидатор проверяет входящие данные на правильность и в случае их неправильности выдаёт ошибку. Он ничего не возвращает. Например, он может проверять, не пуст ли список.
• Парсер делает то же самое, что и валидатор, но возвращает более конкретное представление входящих данных, обеспечивающее соответствие требуемого свойства. Например, он проверяет, не пуст ли список, и возвращает тип NonEmptyList.

Главное утверждение, сделанное в этой статье — что парсеры предпочтительнее, чем валидаторы. Её основной посыл — нужно сделать недопустимые состояния непредставимыми (unrepresentable). В статье это реализовано с помощью использования системы типов. Я полностью согласен с такой философией, но хотел бы выделить и более подробно обсудить один из ироничных аспектов аргументации:

Инструмент контроля типов является хрестоматийным примером валидатора!

Ведь в конечном итоге инструмент контроля типов получает на входе уже подвергнутое парсингу представление программы и «бракует» его, если не удаётся выполнить контроль типов. Он не возвращает более конкретного представления программы. (Не стоит путать это с выводом типа, который возвращает больше информации, но только касательно типов).

Какой же может быть альтернатива инструменту контроля типов в виде парсера для языка программирования?

Иногда YouTube или Twitch не подходят как стриминговая платформа — скажем, если вы пилите портал с вебинарами или контентом 18+, нарушаете авторские права или хотите максимально отгородить свою трансляцию от остального интернета. У них есть много альтернатив как в виде сервисов (те же минусы, недостаток контроля и непредсказуемая политика), так и в виде self-hosted решений. Проблема опенсорсных стриминговых проектов в том, что все они начинаются с крохотной связки из пары технологий, а затем отчаянно пытаются вырасти в сервис, добавляя сложные веб-интерфейсы, чаты, библиотеки стримов и в конечном счёте отдаляясь от исходной цели: дать миру инструмент, который по понятному мануалу позволит запустить свой сервер трансляций. Что с ним будет дальше, в какие системы будет встроена эта картинка — это только ваше личное дело, а самописный аналог твича с лагающими и отваливающимися сервисами и периодически валящимся билдом не нужен никому, кроме его разработчиков. Поэтому в этой статье мы разберём минимальную цепочку действий для запуска своего RTMP-сервера с плеером.

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

Знакомьтесь: Ceph

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



При выходе любого диска, узла или группы узлов из строя Ceph не только обеспечит сохранность данных, но и сам восстановит утраченные копии на других узлах до тех пор, пока вышедшие из строя узлы или диски не заменят на рабочие. При этом ребилд происходит без секунды простоя и прозрачно для клиентов.

В сети есть разные варианты интеграции IP-АТС Asterisk и CRM Битрикс24, но мы, все таки, решили написать свою.

По функционалу все стандартно:

• Кликом на ссылку с номером телефона клиента в Битрикс24, Asterisk соединяет внутренний номер пользователя, от имени которого это клик совершен, с номером телефона клиента. 
В Битрикс24 фиксируется запись о звонке и по окончании вызова подтягивается запись разговора.
• На Asterisk поступает звонок извне — в интерфейсе Битрикс24 показываем карточку клиента тому сотруднику, на номер которого этот звонок прилетел.
  Если такого клиента нет, откроем карточку создания нового лида.
  Как только звонок завершен, отражаем это в карточке и подтягиваем запись разговора.

Под катом расскажу как все настроить у себя и дам линк на github — да-да, забирайте и пользуйтесь!

Олег Царёв ( zabivator )

Есть мастер, мастер неожиданно упал, но система продолжает работать. Клиенты мигрируют на вторую базу. Нужно делать резервные копии базы. Если делать резервные копии на основной базе, мы можем получить какие-то проблемы производительности, увеличение времени отклика. Это плохо. Поэтому достаточно распространенный пример асинхронной репликации — это снятие резервной копии со слэйва. Другой пример — это миграция тяжелых запросов с мастера на слэйв, с основной базы на вторую. Например, построение отчетов.

Иногда бывает необходимо, чтобы приложение могло получать все обновления из базы и желательно в режиме реального времени. Этим занимается оpen source библиотека, которая называется libslave.

достаточно сильный лебедь

Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.

Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.

Небольшое введение в мир IPsec

Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.

Идея написания web-интерфейса статистики и прослушивания вызовов для IP АТС Asterisk не покидала меня вот уже несколько лет. Решения, найденные в Интернет, не устраивали по тем или иным критериям — где-то не хватало функционала, какие-то из них совсем не радовали глаз.

И вот, вооружившись стеком технологий и оседлав боевого коня, предоставленного компанией ServerClub, я отправился в путь.

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



А под катом вас ждет видео-гайд по интерфейсу, необходимые настройки и подробное описание всего доступного функционала.

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

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

Оглавление:

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

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

В это обзоре мы познакомимся с 30 бесплатными JavaScript плагинами и библиотеками, которые сфокусированы на определенных задачах. Это простые, полезные и легкие решения, которые помогут сделать процесс веб-дизайна и разработки гораздо проще и быстрее.

Как и следовало ожидать ниже вы найдете много плагинов для создания ползунков, галерей с изображениями, адаптивных меню, а также много других полезных плагинов и библиотек. Также в списке представлены плагины, которые предлагают действительно уникальные функциональные возможности. Давайте взглянем на список!

Обычно VRF (Virtual Routing and Forwarding, VPN Routing and Forwarding) используется совместно с MPLS, но без оной в терминологии Cisco называется VRF-Lite. Суть этой технологии в том, что маршрутная информация, принадлежащая различным классам (например, маршруты одного клиента) изолируется друг от друга. Считается, что такие возможности есть только у «взрослых» железных решений, но это не совсем так. Благодаря наличию множественных таблиц маршрутизации, гибких политик маршрутизации всё это можно сделать и в Linux. Кому интересно, добро пожаловать под кат.

Если я попрошу вас назвать факторы личной продуктивности, то, скорее всего, услышу слова типа «целеполагание», «тайм-менеджмент», «упорство». Найдется ли в этом списке место лени? Да-да, обычной, такой близкой, знакомой всем и тщательно скрываемой? Позвольте сделать, на первый взгляд, абсурдное заявление: лень – один из факторов продуктивной работы!

Многие боятся переходить с «мускуля» на «посгрес» из-за того, что лишь смутно понимают, что это даст. Некоторых останавливает мысль, что наверно Postgres — это слишком сложная база и требует обучения. А также, что возможно чего-то придется лишиться в связи с переходом. Попробую немного прояснить ситуацию.

Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.

Статья написана по материалам моего доклада на CodeCamp 2009.

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

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

Так уже получилось что писал статью для howtoforge. И естественно тут же все это оказалось в русском варианте на других сайтах. Только вот незадача: в статье были допущены неточности, и публицисты с других «сайтов» вставили as-is.
Хочу попробовать исправить это оплошность.
Для чего это надо?
Объясню на примере: был у меня фтп с 2мя сетевыми картами, но использовалась одна. Со временем весь 1Гб/с начал забиваться по вечерам — и людям плохо, и у меня iowait растет. Но есть вторая сетевая карта. Так вот такое объединение позволит использовать 2 (3, 4, 5...) как одну с 2Гб/с.

Здравствуйте, уважаемые хабравчане.

Вот уже несколько месяцев ковыряюсь в прекрасном продукте FreeSWITCH. Он не перестает меня удивлять функциональностью, надежностью и производительностью (даже в тех областях, в которых от него этого не ждешь).

Один из моих экспериментов, который в скором времени, скорей всего, перейдет в продакшн касался изумительной, с моей точки зрения, функции mod_sofia recover. Функция recover позволяет FreeSWITCH (FS) восстановить вызовы после краша или же, если FS работает в высоко доступном кластере подхватить вызовы на второй ноде! ВНИМАНИЕ! без обрывов вызовов абонентов, как в случае проксировании RTP, так и без него.

Реализуется это достаточно просто, благодаря использованию внешней СУБД и настройкам mod_sofia, отвечающего за SIP стэк. Т.е. mod_sofia хранит всю информацию о текущих вызовах во внешней БД, и при краше у второй ноды кластера есть возможность эти настройки прочесть и подхватить вызовы.

От переводчика: в двух словах, в декабре 2015 выйдет релиз Python 2.7.11, ускоряющий работу интерпретатора CPython до 20%. Ниже перевод статьи с LWN.net, рассказывающей о сути и процессе произошедших изменений в коде. Имена, в произношении которых я не уверен, даны в оригинальном написании. Об ошибках и неточностях перевода просьба, как обычно, сообщать в личные сообщения.

Несмотря на то, что разработка Python 2 (а конкретно ветки Python 2.7.x) находится сейчас в состоянии «никаких новых фич», которое в обычной ситуации заранее ставит крест на любых крупных изменениях, команда разработки приняла решение рассмотреть и принять backport-патч из Python 3, привносящий заметное улучшение производительности интерпретатора.

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.