Журнал Витуса

Тут Толченов в комментариях к одному из предыдущих постов предложил держать на VPS у провайдера только внешний роутер локальной сети, соединенный с ней с помощью VPN. А архивы электронной почты и прочий ценный конетент держать дома, под письменным столом.

Это решение имеет очевидные преимущества - нет проблемы с домовыми провайдерами, у которых достижимый извне IP по нынешним временам стоит дороже той VPS, да еще и реверсной зоны к нему нет.

Но имеет и очевидные недостатки - появляется лишняя point of failure, даже две - есть две машины от доступности которых критично зависит доступность коммуникаций и VPN между ними. (и физическая сеть поверх которой этот VPN ходит, которая тоже может глючить. Все же домашние провайдеры не обеспечивают такой доступности сервиса, как хостиноговые)

Исходя из этих соображений я бы по крайней мере SMTP-listener на внешнем сайте реализовывал не как проброс портов внутрь VPN, а как полноценный MTA с релеингом. Соответственно, если у нас домовая сеть лежит, то приходящая извне почта складывается в очередь на этом внешнем сайте, и ждет когда сеть поднимется. С другой стороны если письмо изнутри не отправилось сразу, оно тоже сложится там в очередь и ретрай будет делать внешний сервер, независимо от доступности внутренней сети.

Публичный web-контент тоже стоит туда сложить. Он все равно публичный и несанкционированного доступа к нему быть не может (ибо любое чтение публичного контента - доступ санкционированный). Но исходя из концепции "ничего ценного и невоспроизводимого" это должно быть зеркало внутреннего сайта, регулярно (вплоть до раз в час) синхронизируемого через тот же самый VPN. Тогда даже попытка что-то там несанкционированно изменить доживет только до следующего сеанса синхронизации.

А вот синапс матрицы надо держать внутри. Проксируя с внешнего сайта средствами http сервера. И imap внутри. Вот его можно пробрасывать средствами роутинга. Хотя можно и stunnel-ом. А вебмейл можно на внешнем хосте чтобы ходил к внутреннему imap. Ну нету канала из дома во внешний мир, значит к лежащему дома архиву почты нет доступа из внешнего мира. Если мы считаем физический контроль над этим архивом важнее его доступности из любой точки мира, значит придется с этим мириться. Хотя, конечно возможен автоматический фаллбэк на LTE-модем в случае падения домашнего канала. VPN передподключится и сразу коннект восстановися. Правда почему-то сотовые операторы не любят когда их сим-карты используют в качестве аварийного фоллбэка. А для автоматического фоллбэка явно понадобится отдельная карта.

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

У меня сейчас так веб-интерфейс transmission устроен. В смысле transmisson-то крутится на домашнем десктопе, а с сервера на VPS-ке проксируется ее веб-интерфейс. Поэтому если домашний компьютер включен, я могу с работы или из деревни поставить что-нибудь на закачку.Все равно я обычно качаю через торренты что-то редкое, что будет качаться недели или месяцы, так что доехать до дома и забрать файл скорее всего сумею, качать через узкий канал не потребуется.

X-Post to LJ

Тут при оченедном обсуждении мессенждеров vikarti_anantra задала вопрос: "А что сложно свой сервер поднять?".

Сложно. Для тех для кого адмнистрирование юникс-систем не является основной работой, поднять сервер и сконфигурировать на нем пяток нужных сервисов - занятие и правда не простое. Другой вопрос, что уже давно можно было бы, если бы существовал хоть какой консенсус на тему того, что на таком сервере должно быть, следать коробку "все в одном", настраивать которую было бы не сложнее, чем типичный Wi-Fi роутер. А с ними вроде народ в массе своей справляется. И чтобы можно было в течение нескольких минут накатить этот образ на виртуалку на любом VPS-хостинге.

Что собственно, нужно от точки присутствия в интернете? Предполагается что это может быть не только личная точка присутствия, но и семейная или небольшой группы единомышлинников, вроде мастерской группы LRPG.

1. Сервер электронной почты на пару десятков аккаунтов. При этом чтобы почту с него принимали во всяких gmail-ах (а это, увы, moving target), и чтобы была какая-никакая защита от спама. graylisting+spamassassin вполне хватает по моему опыту.
2. Веб-интерфейс к этой почте. А то вдруг придется доступаться из какого-нибдуь интернет кафе, где ничего кроме браузера не предусмотрено.
3. Сервер федерированного мессенжера (matrix или jabber).
4. К нему тоже web-интерфейс (element)
5. turn-сервер, как совершенно необходимая вещь для голосовых и видеозвонокв через matrix/jabber
6. CalDAV/CardDAV сервер
7. Возможность выложить файл для последующего скачивания. Я в общем обхожусь для этого webdav. Хотя возможно web-based файл-менеджер не помешал бы. В принципе этого уже достаточно для того чтобы сделать сколь угодно навороченный статический web-сайт, благо локальных генераторов сайтов, запускаемых на ноутбуке/рабочей станции существует море. Поэтому пока вам не нужно на сайте комментирование, ничего более другого и не нужно.
8. Фотогалерея. Она отдельно, потому что фотграфируют нынче в основном смартфонами и планшетами, следовательно фотографии должны попадать на сайт непосредственно с мобильного устройства, и минимально обрабатываться уже на сервере.
9. Средства администрирования. Должны позволять завести нового юзера всего предыдущего, заблокировать/удалить старого, сменить пароль. Возможно стоит жестко требовать наличия единого пароля для всего перечисленного, а возможно и нет. Возможно, тот же инструмент должен менеджить authorized_keys для доступа по ssh. Тут, правда, стоит подумать о соотношении системных пользователей и пользователей веб-сервисов (по-моему не должны совпадать). Там же должна быть кнопочка для установки апдейтов.
10. Автомат для обновления сертификатов Let's Encrypt
11. DNS-сервер. Дело в том, для значительной части вышеприведенных сервисов нам понадобятся специальные (SRV, TXT) записи в DNS. Да, и электронной почты это тоже касается. Без TXT-записи _dmarc никто почту принимать с вашего домена не будет. Опять же openpgp-ключи так публиковать можно. Но в общем стоит исходить из того, что именно этот сервер будет первичным DNS вашего домена. Тогда все этои нетривилаьные DNS-записи можно будет автоматизировать.

Можно еще поставить туда прокси/VPN, если юрисдикция хостера не совпадает с юрисдикцией домашней машины, но мы пока этот вопрос рассматривать не будем. На худой конец можно ssh -D использовать.

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

Для решения перечисленных задач нужно

1. dovecot (в дистрибутиве)
2. postfix (в дистрибутиве)
3. ciderwebmail (по-моему в Debian еще не попала версия, которую я год назад патчил на предмет русских имен папок )
4. matrix-synapse (надо брать из бэкпортов, там он заметно новее)
5. element-web (в дистрибутиве нет, но есть отдельный репозиторий с пакетами
6. coturn (в дистрибутиве)
7. radicale (в дистрибутиве)
8. Какой-нибудь web-сервер чтобы все вышеперчисленные интерфейсы проксировать. nginx сойдет, но apache лучше (оба в дистрибутиве)
9. acme-tiny (в дистрибутиве)
10. bind9 (в дистрибутиве.)

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

Деплоймент этой штуки выглядит так:

1. Регистрируем домен.
2. Покупаем VPS-ку
3. Накатываем на VPS-ку образ системы (лично я всегда rsync-ом обходился, но возможны варианты вроде загрузочного ISO-образа)
4. Заходим в эту VPS-ку по HTTP. Указываем домен и IP-адрес выданный хостером. Жмем кнопку "обновить сертификаты"
5. Заходим туда по HTTPS, меняем пароли, загружаем ssh-ключи и проверяем соответветсвие списка включенных сервисов требуемому.
6. Правим в настройках DNS регистратора адрес первичного DNS, указывая вот на этот сервер, и настраиваем вторичный DNS.
7. Пинаем хостера чтобы разрешил слать и принимать почту с этой VPS-ки

Вместо п 2 и 3 можно поставить raspberry pi, и на нее накатить аналогичный образ. Правда перспективы запинывания домашнего провайдера, чтобы разрешил слать/получать почту мне кажутся несколько менее радужными. Зато порыться в вашем почтовом ящике без вашего ведома ни одна спецслужба не сможет - они будут вынуждены прийти к вам домой и предъявить ордер на обыск.

X-Post to LJ

По-моему, вчерашняя история с DNSSEC была как и приснопамятная блокировка "Телеграм", рекламной акцией. Теперь все кто вообще-то в курсе что эта аббревиатура означает, знают, что DNSSEC в зоне .ru есть, и можно пользоваться.

Я даже пошел и попробовал на домене wagner.pp.ru его включить. Правда бестолку - на ru есть, а на pp.ru - нету. Пойти что ли на spacians.net включить...

X-Post to LJ

Вот как можно так настроить веб-сервер, чтобы пакетный менеджер оттуда rpm-ки скачивал с ошибками, а wget и браузер - нормально?

Оказывается, можно. Если отдавать статический файл с диска с Transfer-Encoding: chunked. Как будто это не статический файл, выложенный три месяца назад (и ему надо отдавать Last-Modified, Content-Length, и ETag, а желательно еще и предлагать Accept-Ranges) а динамичски генерируемая страница. (отдельная песня что там еще заглоовка Content-Type не было. Тот кто начинал заниматься веб-программированием в эпоху CGI и конкурирующих семи русских кодировок при виде http-respоnse в которой отсутствует нафиг заголовок Content-Type (даже если там по смыслу application/octet-stream), но зато присуствует Content- Disposition: attachment впадает в ступор.

Авторам apt-rpm тоже не пришло в голову потестировать свое поделие на совместимость с Transfer-Encoding: chunked. А у них собственная гордость, своя библиотека для работы с http которая говорят на целых несколько процентов быстрее curl (это когда это скорость скачивания по http лимитировала клиентская библиотека а не канал где-то посредине?)

А у меня первая мысль когда приходит баг репорт, что-де пакеты скачиваются с не теми контрольными суммами? Что сервер кто-то ломанул и в rpm-ки трояна завернул. И только после того как я сравнил sha256 суммы этих rpm-ок с архивом стало понятно что дело в админах сервера. Нет, современное поколение сисадминов выросшее в эпоху динамически генерируемых страниц - это что-то.

Кстати, почему-то дебиановский apt, yum и dnf скушали chunked и не подавились. Возможно потому что последние два - на питоне написаны и используют его стандартные библиотеки для скачивания файлов.

Народ, а кто может подсказать фреймворки для построения веб-страниц, в которых порядок генерации отдельных фрагментов не принципиален?

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

Ну то есть что-то подобное есть в питоновских вариантах на базе Twisted и Tornado, но у twisted просто ужасный синтаксис в этом месте. Опять же Twisted и Tornado не самые популярные инструменты у веб-разработчков.

Дело в том, что выяснилось, что если не соблюдать четкую последовательность запрос-ответ-запрос-ответ, а вывалить в бэкенд сразу сотню запросов, а потом читать ответы, у постгреса даже на той же машине, получается ускорение примерно вдвое (на простых запросах, сводящихся к одному index range scan или index lookup).

Соответственно, хочется попытаться оторвать от libpq существующую там проверку на "если результат предыдущего запроса не прочитан, со следующим посылаем", и попытаться это применить на каких-то реальных задачах.

Подобные паттерны с сотнями легких запросов в рамках одного коннекта характерны как раз для динамических веб-фреймворков.

У меня возникло подозрение, что подобный стиль работы естественным образом вписывается во всякие решения на базе haskell или ocaml. Но я web-фреймворков на базе этих языков (да и самих-то языков) толком не знаю.

Вот представьте себе, что есть сайт. Файлы на этот сайт выкладываются с помощью rsync, причем не с -e ssh, а с двумя двоеточиями после hostname. Кто не понял, зачем там два двоеточия, прекращает читать этот пост, читает man rsync, и возвращается сюда просветленный.

Так вот, вопрос в том, а стоит ли ограничивать набор хостов, с которых пускают выкладывать на сайт rsync-ом, хостами, доступными через VPN, или можно пускать через публичные сети.

Алгоритм аутентификации у rsync-а хороший, весь из себя challenge-response, открытые пароли по сети бегать не будут.

Данные, выкладываемые на сайт, тоже вроде ничего сенситивного не содержат - файлы паролей для Basic Auth там внутри дерева не лежат, опция ExecCGI на всём, доступном для записи по rsync выключена, php и подобных тоже нету.

Нашел тут замечательный инстурмент SNIProxy

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

Под Bananian собралось, тестирвоать еще не тестировал, потому что для тестирования нужно иметь хотя бы два https-ных сервера, в локальной сети. А у меня в ЭТОЙ сети нет ни одного.

Хотя, конечно, такую штуку надо держать на роутере, а не на одном из серверов внутри сети. Но собирать ее под dd-wrt или openwrt мне ломы.

http://krebsonsecurity.com/2014/09/dread-pirate-sunk-by-leaky-captcha/

Говорил великий batareegryz «Если готовишь салат в пыточной камере, не клади туда осьминога».

Аналогично, если ты делаешь нелегальный сайт, не важно, политический или торгующий за биткойны неодобряемыми правительством вещами, не используй веб-сервисов, не важно, коммерческих или некоммерческих. Все что попадает юзеру в браузер должно идти с твоего сайта. Иначе, если к тебе на страницу встроена, ну скажем, каптча с открытого интернет сервиса, плакала анонимность твоих юзеров. Придут с ордером туда, посмотрят логи, найдут там referer с твоего сайта...

Прикрутил к своему git-у возможность коммитов по https. Чтобы иметь возможность доступаться через файрволы которые не пускают ssh. Попробовал поставить ciderwebmail, но выматерился и снес. Поскольку работать в режиме CGI оно упорно не хочет. С собственным сервером - пожалуйста. А в режиме CGI вводишь логин-пароль, оно заходит на imap-сервер, спрашивает capability и тут же выходит обратно, перезагружая страницу логина.

А нафига мне webmail постоянно в памяти?

В общем, Catalyst это такая же бяка, как PHP, Rails и Django. Хотя играться с ним я, пожалуй, продолжу. Всё-таки некоторые идеи там интересные, хотя и спорные. Например, можно попробовать прикрутить к MVC-веб-фреймворку какой-нибудь совершенно не http-протокол для view. В документации написано, что можно. Впрочем, в документации написано и что ciderwebmail через cgi работает.