​​Для создания своего "облачного" хранилища файлов, похожего на Dropbox, Google Drive, Yandex.Disk и т.д. можно воспользоваться известным open source решением Seafile. Это популярный сервер, про который я вообще ни разу не упоминал, хотя услышал про него впервые очень давно, ещё до того как появился owncloud, который породил форк Nextcloud — наиболее известный на сегодняшний день продукт для автономного файлового хранилища.

Seafile существует как в коммерческой, так и в Community редакции с открытым исходным кодом. Код также открыт и для клиентов под все популярные системы: Windows, Linux, Macos, Android. Для Linux версии есть консольный клиент. Для самого сервера есть веб интерфейс, через который осуществляется управление.

Основной особенностью Seafile можно считать маленькие требования к ресурсам, так что его можно запускать на Raspberry Pi. Для этого существует отдельная сборка сервера.

Несмотря на свою простоту и лёгкость, Seafile предлагает неплохой бесплатный функционал:
◽создание и управление аккаунтами пользователей
◽версионирование файлов и логирование доступа к ним
◽мобильный клиент
◽возможность подключать хранилище в виде виртуального диска
◽создание ссылок для общего доступа к файлам или по паролю
◽шифрование файлов
◽просмотр медиа файлов через веб интерфейс
◽онлайн редактор для совместной работы над текстовыми файлами в формате Markdown (другие форматы, типа docx, xlsx и т.д. не поддерживаются).

Оценить функционал можно в публичном demo - https://demo.seafile.com.
Запустить у себя тоже нет никаких проблем. Есть готовый docker-compose.yml от разработчиков. Там же все инструкции.

Ядро сервера Seafile написано на C 😎 (вспомнилось Папа может в си). Этим объясняется его легкость и быстродействие. Веб интерфейс на Python (django) и JavaScript.

Я сам никогда не использовал этот сервер, поэтому не могу поделиться информацией по эксплуатации. Если кто-то активно пользовался, то дайте обратную связь. Если рассматривать только хранение файлов, на текущий день это решение лучше или хуже Nextcloud?

⇨ Сайт / Исходники / Демо

#fileserver

​​В операционной системе на базе Linux существуют два разных способа назначения прав доступа к файлам. Не все начинающие администраторы об этом знают. Недавно один читатель попросил помочь настроить права доступа к файловой шаре samba. Он описал задачу на основе того, как привык раздавать права на директории в Windows. В Linux у него не получалось настроить так же в рамках стандартных прав доступа через локальных пользователей, групп и утилит chown, chmod.

В Linux, помимо основных прав доступа, которые вы видите при просмотре директории с помощью ls -l, существуют дополнительные списки доступа ACL (access control list). Они позволяют очень гибко управлять доступом. По умолчанию инструменты для управления этими списками в минимальной установке Debian отсутствуют. Устанавливаются так:
# apt install acl

После установки данного пакета у вас появятся две основные утилиты, которые будут нужны для управления доступом: getfacl - посмотреть права доступа, setfacl - установить права доступа.

Я не буду сейчас подробно расписывать как всем этим пользоваться. В интернете масса руководств. Просто знайте, что в Linux правами на файлы и директории можно управлять практически точно так же, как в домене Windows. Есть нюансы и различия, но в базовых случаях несущественные. Если добавить Linux сервер с Samba и ACL в домен, то через систему Windows можно будет управлять доступом к файлами через её свойства папки с галочками и списками групп.

Пример того, как всё это может выглядеть, есть в моей статье:
⇨ https://serveradmin.ru/nastroyka-samba-s-integratsiey-v-ad/
Она очень старая и скорее всего уже неактуальна в технической части. Я сам давно файловые сервера в Linux в домене не настраивал и не эксплуатировал. Но общее понимание картины можно получить. Соответственно, вместо Microsoft AD может выступать любой другой LDAP каталог пользователей и групп.

Подскажите, кто скрещивает Linux с Windows. На текущий момент нет проблем с добавлением Linux в AD под управлением свежих Windows Server? Интеграция упростилась или усложнилась? Давно уже не слежу за этой темой. Я где-то видел новость, что Ubuntu для платных подписчиков выпустила какой-то свой инструмент для упрощения работы в AD.

#linux #fileserver

​​Некоторое время назад в ядро Linux завезли реализацию файлового сервера на базе протокола smb - ksmbd. Давно хотел его попробовать, но всё руки не доходили. А тут возникла потребность в простом файловом сервере для обмена файлами. Решил его попробовать.

Для поддержки ksmbd нужно относительно свежее ядро. В Ubuntu 22 и Debian 12 оно уже точно подходящей версии. Я как раз из анонсов Debian 12 про этот сервер и узнал. А вот в Debian 11 наверняка не знаю, надо уточнять, приехала ли туда поддержка ksmbd. Если нет, то лучше обойтись привычной самбой.

Настроить ksmbd реально очень просто и быстро. Показываю по шагам. Устанавливаем службу:
# apt install ksmbd-tools

Рисуем конфиг /etc/ksmbd/ksmbd.conf:

[global]
netbios name = 1cbackup
map to guest = never

[backup]
comment = 1C_backup
path = /mnt/backup
writeable = yes
users = ksmbduser

Ksmbd использует сопоставление с системным пользователем, так что добавляем его:
# useradd -s /sbin/nologin ksmbduser
И сопоставляем с пользователем ksmbd:
# ksmbd.adduser --add-user=ksmbduser

После изменения конфигурации, необходимо перезапустить службу:
# systemctl restart ksmbd
В автозагрузку она добавляется автоматически после установки.

После этого зашёл через свежий Windows Server 2022. Всё заработало сразу без танцев с бубнами, что бывает нередко, когда настраиваешь самбу. Не забудьте только права проверить, чтобы пользователи ksmbd имели доступ к директории, которую вы расшарили.

Погуглил немного настройки ksmbd. Хотел узнать, можно ли там, как в самбе, делать сразу в конфигурации ограничения на доступ не по пользователям, а по IP. Не увидел таких настроек. В принципе, они не сильно актуальны, так как сейчас почти во всех системах закрыт по умолчанию анонимный доступ по smb. Так что всё равно надо настраивать аутентификацию, а если надо ограничить доступ на уровне сети, использовать firewall.

Кстати, поддержка Win-ACL, Kerberos есть, судя по документации. Если верить тестам из репозитория разработчиков, то ksmbd работает заметно быстрее samba. Так что если для вас это критично, попробуйте.

#fileserver #linux #smb

​​Решил сделать подборку self-hosted решений хранения большого количества фотографий для совместной работы с ними и просмотра. Я одно время заморочился и перетащил весь семейный фотоархив во встроенное приложение в Synology. Но со временем надоело туда вносить правки, всё устарело и потеряло актуальность. Сейчас решил возобновить эту тему, но без привязки к какому-то вендору, на базе open source.

Если кто-то пользуется чем-то и ему оно нравится, то поделитесь своим продуктом. Я и на работе не раз видел потребность в каких-то общих галереях. Например, для выездных специалистов, которые фотографируют объекты. Или просто перетащить куда-то в одно место фотки с корпоративов, которые забивают общие сетевые диски и расползаются по личным папкам пользователей, занимая огромные объёмы. Практически везде с этим сталкивался.

Вот подборка, которую я собрал:

◽Photoprism - самый масштабный и известный продукт. Выглядит монструозно и функционально. Умеет распознавать лица, классифицировать фотографии по содержанию и координатам. Запустить можно быстро через Docker. Написан на Go. Есть мобильное приложение. На первый взгляд хороший вариант.

◽Lychee в противовес предыдущей галерее предлагает более простую функциональность базе PHP фреймворка Laravel, который работает на стандартном стэке LAMP, настройки хранит в MySQL/MariaDB, PostgreSQL или SQLite базе. Каких-то особых фишек нет, просто публичные, либо закрытые альбомы. Если не нужны навороты, то неплохой вариант. Мне нравится Laravel, на его базе получаются простые и шустрые приложения.

◽Librephotos - эта галерея написана на Python. Есть распознавание и классификация лиц, анализ и группировка по гео меткам, анализ сцены, объектов в фотках. В репе есть ссылки на все open source продукты, что используются для распознавания. На вид ничего особенного, интерфейс посмотрел. Но количество звёзд на гитхабе очень много.

◽Photoview на вид простая и лаконичная галерея. Минималистичный, но удобный для своих задач дизайн. Написан на Go и JavaScript примерно в равных пропорциях. Из анализа содержимого заявлено только распознавание лиц. Есть мобильное приложение, но только под iOS. На вид выглядит как середнячок на современном стэке с простой функциональностью.

◽Piwigo - ещё одна галерея на PHP под LAMP. Старичок из далёкого 2002 года, который развивается до сих пор. Есть темы и плагины, API, развитая система управления пользователями и их правами. За время существования проекта накопилось огромное количество плагинов. Я немного полистал список, чего там только нет. Например, плагин аутентификации пользователей через LDAP каталог.

Как я уже написал, лидером выглядит Photoprism, но лично мне, судя по всему, больше подойдёт Photoview, так как распознавания лиц мне будет достаточно.

#fileserver #подборка

​​Кто-нибудь ещё помнит, использует такой продукт, как OwnCloud? Это прародитель файлового сервера Nextcloud, который появился после того, как часть разработчиков что-то не поделила в коллективе owncloud, отделилась и начала его развивать. С тех пор этот форк стал более популярен прародителя. А сам owncloud растерял всю свою популярность.

Недавно я случайно и с удивлением узнал, что оказывается OwnCloud выпустили новый продукт, написав его с нуля на Go (бэк) и Vue.js (фронт). Я не видел ни новостей, ни какой-то ещё информации на эту тему. Случайно прочитал в комментариях в каком-то обсуждении.

Заинтересовался и решил попробовать. Так как продукт относительно новый, функциональности там немного. Получился простой файловый сервер под Linux с клиентами под все популярные системы. Ну или не файловый сервер, а облачный, как их сейчас называют. Ставите себе клиентскую часть, и она автоматически синхронизирует заданные файлы с серверной частью, как яндекс.диск, dropbox, gdrive и т.д.

Основной упор сделан на производительность, отзывчивость, скорость работы. В целом, получилось неплохо. Так как ownCloud Infinite Scale 4.0, а именно так полностью называется продукт, написан на Go, то представляет из себя одиночный бинарник, который достаточно скачать и запустить:

# wget -O /usr/local/bin/ocis \
https://download.owncloud.com/ocis/ocis/stable/4.0.2/ocis-4.0.2-linux-amd64
# chmod +x /usr/local/bin/ocis
# ocis init
# OCIS_INSECURE=true \
IDM_CREATE_DEMO_USERS=true \
PROXY_HTTP_ADDR=0.0.0.0:9200 \
OCIS_URL=https://172.28.240.43:9200 \
ocis server

Скачали, создали конфиг, передали некоторые переменные перед запуском и запустили сервер прямо в консоли. Для запуска в фоне нужно будет юнит systemd сделать или использовать Docker контейнер. Учётку для доступа увидите в консоли после ocis init. Дальше можно идти в веб интерфейс на порт хоста 9200.

Я скачал и установил ownCloud client для Windows. Приложение небольшое, всего 21 мегабайт. Установил, указал IP сервера, подключился, синхронизировал файлы. Закинул туда несколько папок с 500 файлами. Переварил всё нормально и быстро, каких-то лагов, тормозов не заметил. Понятно, что объём и количество небольшое, но полноценные тесты проводить хлопотно и конкретно мне нет большого смысла.

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

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

⇨ Сайт / Исходники

#fileserver

​​Для Linux есть замечательный локальный веб сервер, который можно запустить с помощью python:

# cd /var/log
# python3 -m http.server 8181

Переходим браузером на 8181 порт сервера по IP адресу и видим содержимое директории /var/log. Когда скачали, завершаем работу. Это очень простой способ быстро передать файлы, когда не хочется ничего настраивать. Я регулярно им пользуюсь.

Для Windows есть похожий инструмент из далёкого прошлого, работающий и поддерживающийся до сих пор - HFS (HTTP File Server). Это одиночный исполняемый файл весом 2,1 Мб. Работает на любой системе вплоть до современной Windows 11. Скачиваете, запускаете и заходите через браузер на IP адрес машины, предварительно отключив или настроив firewall. Когда всё скачаете, сервер можно выключить, завершив работу приложения.

Сделано всё максимально просто. Никаких настроек не надо. Можете опубликовать какую-то директорию на компьютере или просто мышкой накидать список файлов. Это быстрее и удобнее, чем по SMB что-то передавать, так как надо настраивать аутентификацию. Плюс не всегда получается без проблем зайти с одной системы на другую. То версии SMB не совпадают, то учётка пользователя без пароля и SMB не работает, то просто гостевые подключения не разрешены. Из простого механизма, через который было удобно шарить папки, он превратился в какой-то геморрой. Мне проще через WSL по SCP передать данные, если есть SSH, что я и делаю, чем по SMB.

☝ Причём у этого веб сервера на самом деле очень много возможностей. Вот некоторые из них:

◽ Аутентификация пользователей
◽ Логирование
◽ Возможность настроить внешний вид с помощью HTML шаблонов
◽ Контроль полосы пропускания и отображение загрузки в режиме реального времени
◽ Может работать в фоновом режиме

В общем, это хорошая добротная программа для решения конкретной задачи. И ко всему прочему - open source. Обращаю внимание, что программа изначально написана на Delphi. На сайте скачивается именно она. А на гитхабе то же самое, только переписанное на JavaScript. Но есть и на Delphi репа.

⇨ Сайт / Исходники

#windows #fileserver

​​❗️Сразу важное предупреждение перед непосредственно содержательной частью. Всё, что дальше будет изложено, не призыв к действию. Пишу только в качестве информации, с которой каждый сам решает, как поступать. Сразу акцентирую на этом внимание, потому что ко всем подобным заметкам постоянно пишут комментарии на тему того, что бесплатный сыр бывает только в мышеловке, свои данные нельзя ни в какие облака загружать, всё, что в облаке, принадлежит не вам и т.д.

Если вам нужны 1024ГБ в бесплатном облачном хранилище, то можете таким воспользоваться - https://www.terabox.com. Для регистрации нужна только почта. Есть возможность использовать клиент в операционной системе. Ограничение на размер файла в бесплатном тарифе - 4ГБ.

Скорость загрузки и выгрузки высокая. Я протестировал лично на большом и группе мелких файлов. Загружал в облако со скоростью примерно в 50 Мбит/с с пиками до 100 Мбит/с, скачивал к себе на комп примерно со скоростью 20 Мбит/с.

Сервис всюду предлагает переход на платный тариф, но в целом работает нормально и бесплатно. Можете использовать на своё усмотрение в качестве дополнительного хранилища зашифрованных бэкапов, в качестве хранилища ISO образов (можно делать публичные ссылки), в качестве хранилища публичного медиаконтента и т.д.

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

#бесплатно #fileserver

​​В рамках темы по синхронизации файлов расскажу про необычный инструмент на основе git - git-annex. Это система управления файлами без индексации содержимого. С помощью git индексируются только имена, пути файлов и хэш содержимого. Для использования необходимо понимание работы git. Эта система больше всего подойдёт для индивидуального или семейного хранения файлов в разных хранилищах.

Я не буду расписывать, как эта штука работает, так как она довольно заморочена, а сразу покажу на примере. Так будет понятнее. Программа есть под все популярные ОС, но под Windows всё ещё в бете, так что запускать лучше Linux версию в WSL. В Debian и Ubuntu ставим стандартно из базовой репы:
# apt install git-annex

Переходим в директорию /mnt/annex, где хранятся какие-то файлы и инициализируем там репозиторий, пометив его как server:
# git config --global user.email "root@serveradmin.ru"
# git config --global user.name "Serveradmin"
# git init .
# git annex init 'server'

Добавляем файлы в репу:
# git annex add .
# git commit -m "Добавил новые файлы"

Все файлы превратились в символьные ссылки, а их содержимое уехало .git/annex/objects.

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

На ноутбуке копируем репозиторий с сервера и сразу синхронизируем:
# git clone ssh://user@1.2.3.4/mnt/annex
# git annex init 'notebook'
# git annex sync

Мы получили на ноутбуке копию репозитория, но вместо файлов у нас битые ссылки. Так и должно быть. Если вы хотите синхронизировать все реальные файлы, то сделать это можно так:
# git annex get .
А если только один файл, то так:
# git annex get docker-iptables.sh

Когда у вас несколько устройств работают с репозиторием, то узнать, где физически находится файл можно так:
# git annex whereis file.txt
whereis file.txt (2 copies)
    01f4d93-480af476 -- server [origin]
    13f223a-e75b6a69 -- notebook [here]

Вернёмся на сервер и добавим в него информацию о ноуте:
# git remote add notebook ssh://user@4.3.2.1/mnt/annex
# git annex sync

Теперь репозитории знают друг о друге. На ноутбук он был клонирован с сервера, а на сервер мы вручную добавили ноутбук. Добавим новый файл в репозиторий с ноутбука:
# git annex add nout.txt
# git commit -m "add nout.txt"

Проверим его местонахождение:
# git annex whereis nout.txt
whereis nout.txt (1 copy) 
  637597c-3f54f8746 -- notebook [here]

Он только на ноутбуке. Идём на сервер, делаем там синхронизацию и поверяем местонахождение файла:
# git annex sync
# git annex get nout.txt
# git annex whereis nout.txt
whereis nout.txt (2 copies) 
  6307597c-3f54f5ff8746 -- [notebook]
   edeab032-7091559a6ca4 -- server [here]

Теперь он располагается в двух местах.

Надеюсь, у меня получилось хоть немного показать, как эта штука работает. У неё много настроек. Можно очень гибко указать какие файлы по весу, количеству копий, типу папок, имени, типу содержимого нужны в каждом репозитории. Есть преднастроенные группы: backup, archive, client, transfer. Например, можно принудительно скачивать все файлы при синхронизации:
# git annex sync --content

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

И не забываем, что у нас все преимущества git в виде версионирования. Более подробно о работе можно почитать в документации. На первый взгляд кажется, что система слишком сложная. Для тех, кто не знаком с git, да. Но я не раз видел восторженные отзывы о системе тех, кто в ней разобрался и активно пользуется.

⇨ Сайт / Обучалка

#git #fileserver

​​В комментариях к заметкам про синхронизацию файлов не раз упоминались отказоустойчивые сетевые файловые системы. Прямым представителем такой файловой системы является GlusterFS. Это условный аналог Ceph, которая по своей сути не файловая система, а отказоустойчивая сеть хранения данных. Но в целом обе эти системы используются для решения одних и тех же задач. Про Ceph я писал (#ceph) уже не раз, а вот про GlusterFS не было ни одного упоминания.

Вообще, когда выбирают, на основе чего построить распределённое файловое хранилище, выбирают и сравнивают как раз GlusterFS и Ceph. Между ними есть серьёзные отличия. Первое и самое основное, GlusterFS - это файловая система Linux. При этом Ceph - объектное, файловое и блочное хранилище с доступом через собственное API, минуя операционную систему. Архитектурно для настройки и использования GlusterFS более простая система и это видно на практике, когда начинаешь её настраивать и сравнивать с Ceph.

Я покажу на конкретном примере, как быстро поднять и потестировать GlusterFS на трёх нодах. Для этого нам понадобятся три идентичных сервера на базе Debian с двумя жёсткими дисками. Один под систему, второй под GlusterFS. Вообще, GlusterFS - детище в том числе RedHat. На её основе у них построен продукт Red Hat Gluster Storage. Поэтому часто можно увидеть рекомендацию настраивать GlusterFS на базе форков RHEL с использованием файловой системы xfs, но это не обязательно.

❗️ВАЖНО. Перед тем, как настраивать, убедитесь, что все 3 сервера доступны друг другу по именам. Добавьте в /etc/hosts на каждый сервер примерно такие записи:
server1 10.20.1.1
server2 10.20.1.2
server3 10.20.1.3

На все 3 сервера устанавливаем glusterfs-server:
# apt install glusterfs-server
Запускаем также на всех серверах:
# service glusterd start

На server1 добавляем в пул два других сервера:
# gluster peer probe server2
# gluster peer probe server3
На остальных серверах делаем то же самое, только указываем соответствующие имена серверов.

Проверяем статус пиров пула:
# gluster peer status
На каждом сервере вы должны видеть два других сервера.

На всех серверах на втором жёстком диске создайте отдельный раздел, отформатируйте его в файловую систему xfs или ext4. Я в своём тесте использовал ext4. И примонтируйте в /mnt/gv0.
# mkfs.ext4 /dev/sdb1
# mkdir /mnt/gv0
# mount /dev/sdb1 /mnt/gv0

Создаём на этой точке монтирования том glusterfs:
# gluster volume create gv0 replica 3 server1:/mnt/gv0 server2:/mnt/gv0 server3:/mnt/gv0
Если получите ошибку:
volume create: gv0: failed: Host server1 is not in 'Peer in Cluster' state
то проверьте ещё раз файл hosts. На каждом хосте должны быть указаны все три ноды кластера. После исправления ошибок, если есть, остановите службу glusterfs и почистите каталог /var/lib/glusterd.

Если всё пошло без ошибок, то можно запускать том:
# gluster volume start gv0
Смотрим о нём информацию:
# gluster volume info

Теперь этот volume можно подключить любому клиенту, в роли которого может выступать один из серверов:
# mkdir /mnt/gluster-test
# mount -t glusterfs server1:/gv0 /mnt/gluster-test

Можете зайти в эту директорию и добавить файлы. Они автоматически появятся на всех нодах кластера в директории /mnt/gv0.

По этому руководству наглядно видно, что запустить glusterfs реально очень просто. Чего нельзя сказать о настройке и промышленно эксплуатации. В подобных системах очень много нюансов, которые трудно учесть и сразу всё сделать правильно. Нужен реальный опыт работы, чтобы правильно отрабатывать отказы, подбирать настройки под свою нагрузку, расширять тома и пулы и т.д. Поэтому в простых ситуациях, если есть возможность, лучше обойтись синхронизацией на базе lsyncd, unison и т.д. Особенно, если хосты территориально разнесены. И отдельное внимание нужно уделить ситуациям, когда у вас сотни тысяч мелких файлов. Настройка распределённых хранилищ будет нетривиальной задачей, так как остро встанет вопрос хранения и репликации метаданных.

⇨ Сайт / Исходники

#fileserver #devops

​​Мне неизвестны какие-то простые и эффективные способы поиска дубликатов файлов в Linux с использованием стандартного набора системных программ и утилит. Если встаёт такая задача, то приходится искать какие-то сторонние средства. Я предлагаю один из них - Deduplicator.

Deduplicator - небольшая open source программа, написанная на Rust. Написана в основном силами одного человека. Им же и поддерживается. Пока регулярно. Автор, судя по всему, любит свой продукт, поэтому старается обновлять.

Основная особенность Deduplicator - очень быстрая работа. Используется сравнение по размеру и хешам, полученных с помощью растовского алгоритма fxhash (впервые слышу о таком).

Использовать лучше самую свежую версию, потому что там появился вывод результата в json, плюс в одной из недавних версий стали выводиться полные пути дубликатов. До этого выводились обрезанные и было неудобно. Есть проблема с тем, что в репозитории собранная под Linux версия есть только годовой давности. Более свежие предлагается собирать самостоятельно. Не знаю, зачем так сделано, но я в итоге собрал сам, благо сделать это не трудно через растовый пакетный менеджер:

# apt install cargo
# cargo install deduplicator

На выходе получаем одиночный бинарник, который можно скопировать на целевой сервер. Сразу скажу про ещё один момент, с которым столкнулся. Deduplicator хочет свежую версию glibc. Не понял точно, какую именно, но на Centos 7 не заработал. Не получилось прогнать на месте. В итоге проверку сделал на бэкап сервере. Там более свежая система - Debian 12, уже успел обновить. На Ubuntu 22 тоже завелась, почистил на своём ноуте дубликаты и домашнем медиасервере. Там дубликатов море было.

Вывод удобно направить сразу в текстовый файл и там уже смотреть:

# ./deduplicator /mnt/backup/design > deduplicator.txt

Он будет в табличном виде. Удобен для ручного просмотра. А если нужна автоматизация, то есть вывод в --json с помощью соответствующего ключа.

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

⇨ Исходники

#fileserver

​​У меня дома есть NAS и на всех компах и ноутах подключены сетевые папки. Домашние слабо представляют, как всё это работает. На смартфоне использую TotalCommander с плагином для доступа к тем же сетевым папкам. Жена наверное через TG или VK перекидывает файлы. По-другому вряд ли умеет. Детям это пока не надо.

Есть простое и удобное open source решение для этого вопроса - LocalSend. Поддерживает все операционные системы, в том числе на смартфонах. Это небольшое приложение, которое запускается на определённом порту (53317), принимает входящие соединения и с помощью нескольких методов (описание протокола, в основе поиска Multicast UDP, если не помогает, то POST запрос на все адреса локальной сети) осуществляет поиск таких же серверов в локальной сети. Передача данных осуществляется по протоколу HTTP.

На практике всё это работает автоматически. Приложение под Windows можно поставить, к примеру, через wingwet или скачать portable версию. На смартфоне ставим через Google Play, F-Droid или просто качаем apk. Работает всё в локальной сети, без необходимости каких-то внешних сервисов в интернете. Запускаем на обоих устройствах приложение, они сразу же находят друг друга. Можно передавать файлы. При этом можно на том же компе настроить такой режим, чтобы он автоматом принимал файлы со смартфона и складывал в определённую директорию.

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

Мне иногда надо сыну передать со своего смартфона из родительского чата информацию от учителя с пояснениями по домашке. Я для этого делал скриншот чата, клал его на NAS, на компе с NAS копировал сыну. Через приложение передать в разы удобнее. Запустил прогу и перекинул на комп с именем СЫН. Всё. Мессенджеров и соц. сетей у него пока нет.

Это приложение, которое я попробовал и сразу развернул на всех устройствах. Жене очень понравилось.

Отдельно отмечу, что приложение написано на языке программирования Dart. Впервые о нём услышал. Сначала показалось, что это типичное приложение на JavaScript под NodeJS. Но смутил небольшой размер. После этого и пошёл смотреть, на чём написано. Оказалось, что этот язык программирования разрабатывает Google как раз для замены JavaScript, взяв от него всё лучшее, но исправив недостатки. В целом, выглядит всё это неплохо.

⇨ Сайт / Исходники

#fileserver

​​Когда мне нужно было быстро поднять smb сервер, чтобы разово перекинуть какие-то файлы, раньше я устанавливал samba и делал для неё простейший конфиг.

Потом в Linux появилась поддержка протокола smb и сервера на его основе в ядре в виде пакета ksmbd. Стал использовать его. Хотя принципиально ни по времени настройки, ни по удобству он особо не выигрывает у самбы. Настройка плюс-минус такая же. В нём основное преимущество в скорости по сравнению с samba, что для разовых задач непринципиально.

На днях в комментариях поделились информацией о том, что есть простой smb сервер на базе python. Решил его попробовать. Он реализован в отдельном пакете python3-impacket.

# apt install python3-impacket

Это довольно обширный набор сетевых утилит, которые обычно используют пентестеры. В том числе там есть и smb сервер. Запустить его можно в одну строку примерно так:

# cd /usr/share/doc/python3-impacket/examples/
# python3 smbserver.py share /mnt/share -smb2support

◽share - имя шары
◽/mnt/share - директория для smb сервера, не забудьте на неё сделать права 777, так как доступ анонимный
◽smb2support - использовать 2-ю версию протокола, если это не добавить, то с Windows 11 подключиться не получится.

Запуск сервера реально простой и быстрый. Не нужны ни конфиги, ни службы. Запускаем в консоли команду, делаем свои дела и завершаем работу сервера. Для разовых задач идеально, если бы не довольно жирный сам пакет impacket.

Если нужна аутентификация, то её можно добавить:

# python3 smbserver.py share /mnt/share -smb2support -username user -password 123

Только учтите, что винда по какой-то причине не предлагает ввести имя пользователя и пароль, а пытается автоматически подключиться, используя имя пользователя и пароль, под которыми вы находитесь в системе в данный момент. Я не очень понял, почему так происходит. Если кто-то знает, поделитесь информацией. По идее, должно вылезать окно аутентификации. Но по логам smbserver вижу, что винда автоматически случится под той учёткой, от которой пытаешься подключиться.

Если подключаться с Linux, то таких проблем нет. Смотрим информацию о сетевых папках сервера:

# smbclient -L 172.20.204.133 --user user --password=123

Подключаемся к настроенной шаре:

# smbclient //172.20.204.133/share --user user --password=123

Такой вот инструмент. В принципе, удобно. Можно использовать наравне с веб сервером.

#python #fileserver

​​Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.

Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.

Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.

Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:

/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными

Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в /etc/snapraid.conf:

parity /mnt/diskp/snapraid.parity
content /var/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

И после этого запускаете синхронизацию:

# snapraid sync

Данные на дисках могут уже присутствовать. Это не принципиально. SnapRAID запустит процесс пересчёта чётности файлов, как в обычном RAID 5. Только проходит это не в режиме онлайн, а после запуска команды.

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

Звучит это немного странно и я до конца не могу осознать, как это работает, потому что толком не понимаю, как контроль чётности помогает восстанавливать файлы. Но в общем это работает. Получается классический RAID 5 с ручной синхронизацией.

Надеюсь основной принцип работы я передал. Насколько я понял, подобная штука может быть очень удобной для дома. К примеру, для хранения медиа контента, к которому доступ в основном в режиме чтения. Не нужны никакие рейд контроллеры и массивы. Берём любые диски, объединяем их в SnapRAID, синхронизируем данные раз в сутки по ночам и спокойно спим. Если выйдет из строя один диск, вы ничего не теряете. Имеете честный RAID 5 с ручной синхронизацией, что для дома приемлемо. Да и не только для дома. Можно ещё где-то придумать применение.

Одной из возможностей SnapRAID является создание некоего пула, который будет объединять символьными ссылками в режиме чтения данные со всех дисков в одну точку монтирования, которую можно расшарить в сеть. То есть берёте NAS из четырёх дисков. Один диск отдаёте на контроль чётности. Три Остальных заполняете, как вам вздумается. Потом создаёте пул, шарите его по сети, подключаете к телевизору. Он видит контент со всех трёх дисков.

Выглядит эта тема на самом деле неплохо. У меня дома как раз NAS на 4 диска и у меня там 2 зеркала RAID 1 на базе mdadm. В основном хранится контент для медиацентра, фотки и немного других файлов. Вариант со SnapRAID смотрится в этом случае более привлекательным, чем два рейд массива.

Я прочитал весь Getting Started. Настраивается и управляется эта штука очень просто. Небольшой конфиг и набор простых команд. Понятен процесс восстановления файлов, добавления новых дисков. Даже если что-то пойдёт не так, то больше данных, чем было на сломавшемся диске, вы не потеряете. Не выйдет так, что массив развалился и вы остались без данных, так как они лежат в исходном виде на файловой системе.

SnapRAID есть в составе openmediavault. Он там очень давно присутствует в виде плагина. Программа представляет из себя один исполняемый файл и конфигурацию к нему. Есть как под Linux, так и Windows.

⇨ Сайт / Исходники

#fileserver #backup

Регулярно приходится настраивать NFS сервер для различных прикладных задач. Причём в основном не на постоянное использование, а временное. На практике именно по nfs достигается максимальная скорость копирования, быстрее чем по scp, ssh, smb или http.

Обычно просто через поиск нахожу какую-то статью и делаю. Своей инструкции нет. Решил написать, уместив максимально кратко и ёмко в одну публикацию, чтобы можно было сохранить и использовать для быстрого копипаста.

Обычно всё хранение файлов под различные нужды делаю в разделе /mnt:

# mkdir /mnt/nfs
# chown nobody:nogroup /mnt/nfs

Устанавливаем пакет для nfs-server:

# apt install nfs-kernel-server

Добавляем в файл /etc/exports описание экспортируемой файловой системы только для ip адреса 10.20.1.56:

/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)

Для всей подсети просто добавляем маску:

/mnt/nfs 10.20.1.56/24(rw,all_squash,no_subtree_check,crossmnt)

Для нескольких IP адресов пишем их каждый в своей строке (так нагляднее, но можно и в одну писать):

/mnt/nfs 10.20.1.56(rw,all_squash,no_subtree_check,crossmnt)
/mnt/nfs 10.20.1.52(rw,all_squash,no_subtree_check,crossmnt)

Перезапускаем сервер

# systemctl restart nfs-server

Проверяем работу:

# systemctl status nfs-server

Для работы NFS сервера должен быть открыт TCP порт 2049. Если всё ок, переходим на клиент. Ставим туда необходимый пакет:

# apt install nfs-common

Проверяем, видит ли клиент что-то на сервере:

# showmount -e 10.20.1.36
Export list for 10.20.1.36:
/mnt/nfs 10.20.1.56

Всё в порядке, видим ресурс для нас. Монтируем его к себе:

# mkdir /mnt/nfs
# mount 10.20.1.36:/mnt/nfs /mnt/nfs

Проверяем:

# df -h | grep nfs
10.20.1.36:/mnt/nfs         48G 3.2G  43G  7% /mnt/nfs

Смотрим версию протокола. Желательно, чтобы работало по v4:

# mount -t nfs4
10.20.1.36:/ on /mnt/nfs type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.1.56,local_lock=none,addr=10.20.1.36)

Создаём файл:

# echo "test" > /mnt/nfs/testfile

При желании можно в fstab добавить на постоянку:

10.20.1.36:/mnt/nfs /mnt/nfs nfs4 defaults 0 0

Не забудьте в конце поставить переход на новую строку. Либо подключайте через systemd unit. В моей заметке есть пример с NFS.

Похожие короткие инструкции для настройки SMB сервера:
◽на базе python
◽на базе ядерного ksmbd

#fileserver #nfs

​​В операционных системах Windows традиционно есть некоторые сложности с использованием протокола NFS. Длительное время она его вообще штатно никак не поддерживала, приходилось использовать сторонний софт. Это объясняется в первую очередь тем, что для передачи файлов по сети у них есть свой протокол SMB. В какой-то момент, уже не помню, в какой точно версии, в Windows появился встроенный NFS клиент.

Установить его можно через Панель управления ⇨ Программы ⇨ Программы и компоненты ⇨ Включение и отключение компонентов Windows ⇨ Службы для NFS ⇨ Клиент для NFS.

Можно включить более простым и быстрым способом через Powershell:

> Enable-WindowsOptionalFeature -FeatureName ServicesForNFS-ClientOnly, ClientForNFS-Infrastructure -Online -NoRestart

Можно примонтировать диск с NFS сервера, к примеру, развёрнутого из этой заметки:

> mount -o anon \\10.20.1.36\mnt\nfs N:
N: успешно подключен к \\10.20.1.36\mnt\nfs
Команда успешно выполнена.
> N:
> dir
..........

Диск N появится в качестве сетевого. С ним можно работать к с обычным сетевым диском. Условно, как с обычным, так как работа под Windows с NFS сервером на Linux будет сопряжена с множеством нюансов и неудобств, связанных с правами доступа, кодировкой, чувствительности к регистру в названиях файлов на Linux. В общем случае использовать такой сценарий работы не рекомендуется. Для постоянной работы с Windows проще поднять SMB сервер на Linux.

Для разовых задач или для использования в скриптах можно воспользоваться каким-то альтернативным консольным клиентом. Например, nfsclient. Это небольшая программа на Go уровня курсовой работы студента. Код самой программы простой, но используются готовые библиотеки для работы с NFS.

Программа кроссплатформенная и не требует установки. Это небольшой консольный клиент, который поддерживает простые операции:

◽просмотр содержимого ресурса
◽скачивание, загрузка, удаление файлов
◽создание и удаление каталогов

Работает примерно так. Монтировать диск не нужно. Смотрим список файлов на nfs диске:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 ls ./

Скачиваем файл syslog:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 down ./syslog

Загружаем в корень диска файл file.txt:

>.\nfsclient.exe 10.20.1.36:/mnt/nfs root:0:0 up .\file.txt ./file.txt

Синтаксис простой, потому что команд не так много: ls/up/down/rm/mkdir/rmdir.

#nfs #fileserver #windows

​​Для редактирования и совместной работы с документами через браузер есть два наиболее популярных движка с открытым исходным кодом:

▪️ OnlyOffice
▪️ Collabora Online

Про #OnlyOffice я регулярно пишу, можно посмотреть материалы под соответствующим тэгом. Там же есть инструкции по быстрому запуску продукта. Решил то же самое подготовить по Collabora Online, чтобы можно было быстро их сравнить и выбрать то, что больше понравится.

Движок для редактирования документов работает в связке с каким-то другим продуктом по управлению файлами. Проще всего потестировать его в связке с ownCloud. Запускаем его:

# docker run -d -p 80:80 owncloud

Идём по IP адресу сервера http://10.20.1.36, создаём учётку админа и логинимся. В левом верхнем углу нажимаем на 3 полоски, раскрывая меню и переходим в раздел Market. Ставим приложение Collabora Online.

Переходим опять в консоль сервера и запускаем сервер collabora:

# docker run -t -d -p 9980:9980 -e "extra_params=--o:ssl.enable=false" collabora/code

Возвращаемся в веб интерфейс owncloud, переходим в Настройки ⇨ Администрирование ⇨ Дополнительно. В качестве адреса сервера Collabora Online указываем http://10.20.1.36:9980. На этом всё. Можно загружать документы и открывать их с помощью Collabora Online. У меня без каких-либо проблем сразу всё заработало по этой инструкции. Работает, кстати, эта связка довольно шустро. Мне понравилось. Погонял там с десяток своих документов и таблиц.

Редактор Collabora Online сильно отличается от Onlyoffice как внешним видом, так и архитектурой. Если у Onlyoffice обработка выполняется на клиенте, что нагружает его, но снимает нагрузку с сервера, то Collabora Online всё обрабатывает на сервере. Мне кажется, это скорее плохо, чем хорошо. Ресурсов сервера потребляет в разы больше, чем Onlyoffice. Но при таком подходе надёжнее работает совместное редактирование, так как реально оно происходит на сервере, а клиентам передаётся только картинка.

Интерфейс Onlyoffice больше похож на Excel, интуитивно с ним проще работать. Основные форматы - .docx, .xlsx, .pptx. Соответственно и совместимость с ними лучше. Collabora построена на базе LibreOffice, а он заметно отличается от Excel, так что переход будет более болезненный. Основные форматы - .odt, .ods, .odp. Майкрософтовские документы открывает хуже.

Какой из этих продуктов лучше и предпочтительнее в использовании, сказать трудно. Надо тестировать самому на своём наборе документов. В целом, оба продукта уже давно на рынке, каких-то критических проблем с ними нет, люди работают. Но, разумеется, есть свои нюансы, проблемы и особенности.

#docs #fileserver

Для построения распределённого файлового хранилища наиболее популярной и зрелой технологией является Ceph. Это программная объектная отказоустойчивая сеть хранения данных. Минимальное количество нод для построения кластера - три. При этом максимальное количество может исчисляться десятками и возможно сотнями. Ceph сложен и в установке, и в эксплуатации.

Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.

Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы /etc/hosts.

Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:

# snap install microceph
# snap refresh --hold microceph

Теперь на node-1 инициализируем кластер и создадим токены для добавления двух других:

# microceph cluster bootstrap
# microceph cluster add node-2
# microceph cluster add node-3

Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:

# microceph cluster join <token node-2>
# microceph cluster join <token node-3>

На каждой ноде добавим диск sdb к хранилищу:

# microceph disk add /dev/sdb --wipe

Смотрим, что получилось:

# microceph status

MicroCeph deployment summary:
- node-1 (10.20.1.34)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-2 (10.20.1.35)
 Services: mds, mgr, mon, osd
 Disks: 1
- node-3 (10.20.1.36)
 Services: mds, mgr, mon, osd
 Disks: 1

Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:

# ceph status

Активировать модуль статистики для Prometheus:

# ceph mgr module enable prometheus

Метрики появятся по адресу http://10.20.1.34:9283/metrics. Смотрим использование кластера:

# ceph df

Он пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:

# ceph osd pool create cephfs_meta
# ceph osd pool create cephfs_data
# ceph fs new newFs cephfs_meta cephfs_data

Смотрим список пулов:

# ceph fs ls
# rados lspools

Смотрим ключ пользователя admin, который создан автоматически:

# ceph auth get-key client.admin

Этот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:

⇨ Установка, настройка и эксплуатация Ceph

Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:

# apt install ceph-common

Подключаем cephfs:

# mkdir /mnt/cephfs
# mount.ceph 10.20.1.34,10.20.1.35,10.20.1.36:/ /mnt/cephfs -o name=admin,secret='AQB8nRpn7MBLAxAANpLgc8UxrLhT487Tt9Y4DA=='

Теперь все созданные файлы в /mnt/cephfs будут автоматически размещаться в кластере. Их будет видно со всех клиентов, к которым подключен этот же пул.

Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.

Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории /var/snap/microceph/current/conf. Но общий смысл тот же самый.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ceph #fileserver