Написал программу для автоматического выписывания ssl-сертификатов налету (при первом запросе к домену). Для начала работы программы её достаточно просто запустить, настраивать не надо совсем (даже домены для сертификатов указывать не надо).

Подробности внутри.

Суть

Разработал программу для простого расширения раздела и файловой системы (xfs, ext3,4) без потери данных. github.com/rekby/fsextender/releases/latest

Исходная проблема

После расширения диска виртуальной машины c ос семейства linux расширить внутри неё раздел данных.

Произошел упс — в 18.45 упала сеть РТКОММ и лежит до сих пор (уже почти 6 часов). В результате недоступны несколько хостингов (знаю об www.1gb.ru, www.jino.ru) целиком.
Это повторение проблемы от 2-го июля — тогда она была ночью и сеть лежала полчаса — гораздо менее заметно.

P.S. Вот только на днях на одном из форумов я убеждал сеошников выбирать геораспределённые площадки (это мой конёк), а меня в ответ убеждали, что современные ДЦ обычно больше, чем на 10 минут не падают.

Сайты падают. Я работаю в хостинге 7 лет и последние 5 лет (кроме всего прочего) предоставляю услуги по географически-распределённым кластерам, чтобы при аварии в одном из дата-центров сайт продолжил работу в другом. На выходе такое решение стоит минимум от 4 тысяч рублей в месяц за 1 виртуальный сервер. Небольшому интернет-магазину это может оказаться дорого для «страховки», которая потребуется 1-3 раза в год, а если повезет — не потребуется совсем. Соответственно, многим нужен вариант дешевле, подходящий для малого и среднего бизнеса. Сейчас расскажу, как это решить очень и очень просто.

Цель работы — сократить накладные расходы на хранение большого количества утилит, написанных на golang.

Один из побочных эффектов статической компиляции golang — относительно большие накладные расходы на хранение рантайма и всех используемых библиотек внутри каждого исполняемого файла. Например небольшая утилитка, которая только и делает что обращается через сеть к серверу и выполняет простые полученные команды — весит 5.5Мб.
Когда такая утилитка одна — это в современных условиях это еще не страшно. Когда утилиты накапливаются и их становится уже несколько десятков или сотен — чисто по-человечески становится жалко сотен мегабайтов, утекающих «вникуда».

Для решения этой проблемы я написал библиотеку multiex, которой и делюсь с сообществом. С её помощью можно объединить несколько программ в один исполняемый файл с минимальными изменениями внутри кода программ и без изменения внешнего поведения. Мысль была взята у busybox — все программы компилируются в один файл, а выполняемый код выбирается при запуске, исходя из имени запускаемого файла.

Бывает, сайты падают из-за отказа площадки хостера, каналов и так далее. Я 7 лет работаю в хостинге, и часто вижу такие проблемы.

Пару лет назад я понял, что услуга резервной площадки (без доработки их сайта или сервиса) очень важна клиентам. Теоретически тут всё просто:
1. Иметь копию всех данных в другом дата-центре.
2. При сбое переключать работу на резервный ДЦ.

На практике система пережила 2 полные технические реорганизации (сохранение основных идей со сменой значительной части инструментария), 3 переезда на новое оборудование, 1 переезд между поставщиками услуг (переезд из немецкого дата-центра в два российских). На исследование поведения разных систем в реальных условиях под клиентской нагрузкой ушло 2 года.

В статье будет рассмотрена маршрутизация внешнего IP-адреса внутрь локальной без пробрасывания ethernet-шлюза и переписывания адресов в iptables. В итоге на сетевой карте внутреннего сервера будет один правильный внешний IP-адрес, внутренние IP-адреса будут отсутствовать.

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

Время от времени появляется задача: сделать скрипт для публикации, который нужно обновлять но невозможно изменять. Например, это может быть скрипт инициализации, зашитый внутрь образа виртуальной машины или скрипт для установки движка сайта (публикуемый разработчиком движка).

В статье я расскажу о приемах, которые применяю для создания таких скриптов, они помогут избежать некоторых граблей, сохранить простоту и гибкость скриптов. Подход подойдет для тех скриптов, поведение которых должно меняться в зависимости от потребностей автора, обновлений и т.п. Подход НЕ подойдет для скриптов, которые должны работать автономно (без связи с системой автора).

Я использую такой подход в bash-скриптах, но общий принцип можно применять независимо от языка.

Краткая шпаргалка:

HOST1: ip link add grelan type gretap  local <IP1> remote <IP2>
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
HOST2: ip link add grelan type gretap local <IP2> remote <IP1>
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT

Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.