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

Тут благодаря идее yurikhan написал себе шелловский скриптик, который рисует на экране морду свитча с горящими (или не горящими) лампочками линков. Вот так:

vitus@alcor$ ./switchface 
+----------------------+
| (o)   (O) (o) (O) ( )|
+----------------------+

Чтобы не надо было идти в коридор, открывать шкаф, и залезать на стул, чтобы увидеть физические лампочки.

Большая буква O - это 1000baseT, маленькая o - 100baseT. Факт наличия full-duplex решил пока не отображать.

( А вот и сам скриптик )

Провел сегодня сравнение по производительности Banana PI M2 и Banana PI R1.
В смысле собрал на обоих в pbuilder пакеты Postgres.

Параметры следующие:

Параметр	M2	R1
lscpu	Architecture: armv7l Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Model name: ARMv7 Processor rev 3 (v7l) CPU max MHz: 1008.0000 CPU min MHz: 480.0000	Architecture: armv7l Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 CPU max MHz: 1008.0000 CPU min MHz: 60.0000
Диск	Micro SD UHS-1 16Gb	St500lm012 Seagate 500Gb 5400Rpm Sata-300 2.5Inch 8Mb Cache
Timing cached reads (hdparm>	782 MB in 2.00 seconds = 390.54 MB/sec	834 MB in 2.00 seconds = 416.78 MB/sec
Timing buffered disk reads (hdparm)	60 MB in 3.06 seconds = 19.60 MB/sec	Timing buffered disk reads: 300 MB in 3.01 seconds = 99.70 MB/sec
Сборка Postgres в pbuilder
real	55m57.805s	55m49.479s
user	56m10.250s	72m10.810s
sys	4m0.110s	7m50.450s

Судя по разнице в user и sys time, процессоры у M2 не только в большем количестве, но и более быстрые. Но, увы слабая "дисковая" подсистема не дает воспользоваться этим преимуществом. В результате wall clock time у обоих систем получается одинаковым.

Надо бы попробовать подмонтировать к M2 сетевой диск по NFS и пособираться на нем.
Езернет там номинально гигабитный. Может оказаться и быстрее MicroSD-шки.
(в момент данного теста М2 была вообще подключена к сети через WiFi, но это не играет роли, так как все Build-Dependencies уже лежали в кэше).

Тут на совершенно технический пост с подробностями конфигурирования свитча вдруг куча народу стала задавать вопрос "а зачем эта железяка вообще".

Поэтому я решил написать, что я хочу получить от Banana PI R1. Я уже скоро год как эксплуатирую просто Banana PI в качестве домашнего почтового сервера. 16GB SD для этого вполне достаточно.

Постепенно туда еще и DNS с DHCP уехали. Потому что как я сменил точку доступа с DD-WRT-шной на имеющую родную DLink-овскую прошивку, гибкости стало не хватать.

В результате у меня сейчас в стенном шкафу в коридоре живут два устройства, требующиеся для функционирования сети. И еще некоторые полезные сервисы, которым было бы полезно быть онлайн 24*7 по-прежднему остаются на десктопе. Торрентокачалка например.

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

То есть

1. Почта
2. Какой-то контент, который хочется сделать доступным извне
3. Торрентокачалка

И тут выясняется, что существует устройство, которое позволяет все это, одновременно являясь свитчом и точкой доступа Wi-Fi. И потребляет при этом менее 3 ампер от 5v блока питания.

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

Возможно, в будущем удастся извлечь и какую-то пользу из разъема GPIO который там есть. Вроде управления дверным замком.

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

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

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

На самом деле у меня идея более амбициозная - иметь в трех домах три бананы (из них только одна со свитчом, остальным и Wi-Fi хватит - на дачах устройства без поддержи wifi не бывают) и увязать их посредством openvpn с сервером на VDS на хостинге в единую сеть. Чтобы можно было из деревни послать документ на печать на сетевой принтер в московской квартире.

Тут совершенно неожиданно для самого себя сапгрейдил alcor на jessie. Запустил там bananian-update, а он мне и говорит английским по бэкграунду, мол, у нас тут следующие релизы теперь на базe jessie, а не сказать ли тебе dist-upgrade. Ну я и сказал. Заодно научился апгрейтить wheezy на jessie так чтобы и духу от systemd не было. Благо alcor это безмониторный сервер, на нем нет необходимости запускать программы, зависящие от антиюниксовых по идеологии подсистем.

И еще пофиксил там конфигурацию prayer. А то там по умолчанию предлагается сохранять юзерские настройки в папку .prayer, а Dovecot почему-то не горит желанием такое создавтать. С его точки зрения . - разделитель директорий, равноправный с /.

И default_domain у меня был неправильно прописан. Откуда это взялось, уже не выяснишь. А из-за этого неправильно формировался From в отправляемых письмах, если без сохраненных настроек. В общем, в prayer web mail есть ТРИ способа правильно задать адрес From и ни один у меня не работал. Теперь работают все.

Вчера я, наконец, нашел время и доделал последний штрих к конфигурации почтового сервера на Banana Pi.

Так я вообще-то уже две недели им пользуюсь, но до сих пор у пользователей не было возможности самостоятельно, без обращения к системному администратору, то есть мне, менять свои пароли. Теперь есть. Заодно разобрался в некоторых, еще не во всех, тонкостях взаимодействия Prayer Web mail с managesieve.

На мой взгляд, получилось вполне self-contained решение.

Конечно некоторые могут сказать, что почта должна использовать общесетевую базу пользователей, например из ldap, но эти некоторые пускай сами настраивают.

Собственно, новой для меня задачей в этой истории было сделать так, чтобы почтовые пользователи не должны были быть системными пользователям. Если заводить всех почтовых польозователей как системных, то prayer-accountd из дистрибутива задачу управления паролями и finger information решает из коробки.

Но мне интересно было решить задачу с виртуальными пользователями, авторизационная информация по которым хранится в базе данных (sqlite). Поэтому пришлось нарисовать свой собственный accountd. Благо протокол accountd крайне простой.

Получилось решение, которое

1. Хранит архивы почты у меня на столе, а не где-то в облаке
2. Позволяет доступ по IMAP и отправку почты из любой точки земного шара
3. Позволяет доступ через web-интерфейс, если вдруг по каким-то причинам нет возможности использовать нормальный эргономичный почтовый клинент
4. Осуществляет server-side фильтрацию почты, например раскладывает списки рассылки в отдельные папки. Правила фильтрации настраиваются через стандартный протокол managesieve, к которому есть и отдельные клиенты и плагины к почтовым клиентам, либо через веб-интерфейс.
5. Имеет обучаемый пользователями байесовский спамфильтр, причем общий для всех пользователей.
Обучение сводится к тому что проскочивший фильтры спам надо складывать в папку "спам", а весь не спам куда-то перекладывать из INBOX-а. Можно - в "Корзину".
Кстати, спама почему-то стало ощутимо меньше. Возможно потому что я поменял исторически сложившиеся настройки spamassassin-а на дистрибутивные.
6. Пользователи могут менять пароли (через веб-интерфейс к почте).
7. Потребляет меньше 5 ватт электричества

( Технические подробности )

Таким образом, единственное действие, которое требует захода на эту коробочку по ssh (не считая установки апдейтов и смены сертификатов), это заведение новых пользователей. Все остальное делается самими пользователями либо через почтовый клиент, либо через web-интерфейс.

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

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

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

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