Точка присутствия в Интернете

[vitus_wagner]

Тут при оченедном обсуждении мессенждеров 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

Comments

[jno]

ну, в настроечной части - где-то как-то
и то там всё через uci
для опёнка это - нормально, для линуха имени генерала пурпоса - нет

но прикладную часть (все эти вики/форумы) люся не решает вовсе

[vitus_wagner]

Ну мы сейчас решаем вопрост не Генерала Пурпоза, а точки присуствия группы неспециалистов в интернете. То есть настройка почти, матрицы и dns.

Веб для нас - только один, и, вероятно, наименее важный сервис.

У нас там по https ходят еще webmail, web-based matrix client, и CalDAV/CardDAV. И для каждого из них свое, отдельное приложение.

Кстати, еще интересная идея - засадить туда transmission-daemon. Хотя на хостинге такие вещи как-то не очень кузяво держать.

[jno]

дык, платформа-то у нас - не опёнок, а дебиан какой, так?

веб для нас - это транспорт, а вот для НИХ - "важнейшее из искусств"!

а на ля там торренты-то?
кино ОТТУДА смотреть?

[vitus_wagner]

Точка присутствия в интернее отличается тем, что она online 24/7 чего нельзя сказать про ноутбук, и далеко не всегда можно сказать про домашний десктоп. Если мы вылавиливаем в торренах редкий контент, сиды с которым появляются раз в неделю на пару часов, иметь торрент-клиент именно на круглосуочно включенной машине может быть крайне полезно. Если мы раздаем редкий контент, то тоже полезно его сидить 24/7.

[jno]

узок их круг, страшно далеки они от народа...

да, для перечисленного - лучше (и даже хостер особо бухтеть не будет, если тот же трансмишн затроттлить как надо)

но "нормальные люди"™ так не делают.
популярное - потому и популярно, что нифига не редкое

[vitus_wagner]

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

Редкий контент (ака длинный хвост) он на то и редкий, что его существует миллион разновидностей для людей с самыми разными хобби.

[yurikhan]

Тогда ещё RSS-агрегатор типа miniflux’а. Которому тоже полезно быть always online хотя бы в части краулера.

[vitus_wagner]

Это интересная мысль. Но web-based RSS агрегатор требует веб-интерфейса для пользователя, а не только для админа. Нодно время я искал такие решения, в качестве составной части системы стэндэлон-блога. Поскольку в моем представлении блог немыслим без френдленты. И тогда хорошего решения я не нашел. Почему-то все найденные мной решения сортировали выкаченные входы по источникам, а не по дате публикации.

[yurikhan]

Когда закрылся Google Reader, я попробовал некоторое количество агрегаторов и сразу отбрасывал те, что не давали хронологической общей ленты. Выжили — Tiny Tiny RSS (на PHP) и позже Miniflux (Go). К последнему я потом себе написал более устраивающий меня веб-интерфейс читателя (чтоб в ленте был сразу пост с содержимым, а не кликать в каждый заголовок).

[vitus_wagner]

Понятно. В общем задачка из серии "если правильно написать ТЗ то написать с нуля проще, чем допилить готовое". Тем более что у всех приличных языков готовые библиотеки для раздбора фидов уже есть.

[yurikhan]

Ну не, краулер я не переписывал, только морду. И желание самому разбирать фиды, хоть бы даже и с помощью библиотек, резко падает, когда погружаешься хоть поверхностно в вопрос «чем Atom отличается от RSS».

[vitus_wagner]

Ну в общем и то и другое - фигня на палочке. XML технологии как XML-технологии во всей красе. Почему-то этот инструмент, хотя, казалось бы не такой уж и сложный, практически никто никогда не может использовать по уму. Обязательно с каким-нибудь совершенно лишним выподвывертом. Взять хоть xmpp, хоть fb2. Разве что в джава-мире XML существует культура использования XML. И то, как это обычно бывает - не везде.