Прочитал интересную серию статей Building A 'Mini' 100TB NAS, где человек в трёх частях рассказывает, как он себе домой NAS собирал и обновлял. Железо там хорошее для дома. Было интересно почитать.
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
И после этого запускаете синхронизацию:
Данные на дисках могут уже присутствовать. Это не принципиально. 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
Меня в третьей части привлёк один проект для создания хранилища с дублированием информации - SnapRAID. Я раньше не слышал про него. Это такая необычная штука не то бэкапилка, не то рейд массив. Наполовину и то, и другое. Расскажу, как она работает.
Образно SnapRAID можно сравнить с RAID 5 или RAID 6, но с ручной синхронизацией. И реализован он программно поверх уже существующей файловой системы.
Допустим, у вас сервер с четырьмя дисками. Вы хотите быть готовым к тому, что выход из строя одного из дисков не приведёт к потере данных. Тогда вы настраиваете SnapRAID следующим образом:
/mnt/diskp <- диск для контроля чётности
/mnt/disk1 <- первый диск с данными
/mnt/disk2 <- второй диск с данными
/mnt/disk3 <- третий диск с данными
Принцип получается как в обычном RAID5. Вы создаёте настройки для SnapRAID в
/etc/snapraid.conf:parity /mnt/diskp/snapraid.paritycontent /var/snapraid/snapraid.contentcontent /mnt/disk1/snapraid.contentcontent /mnt/disk2/snapraid.contentdata 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
👍75👎1
Регулярно приходится настраивать NFS сервер для различных прикладных задач. Причём в основном не на постоянное использование, а временное. На практике именно по nfs достигается максимальная скорость копирования, быстрее чем по scp, ssh, smb или http.
Обычно просто через поиск нахожу какую-то статью и делаю. Своей инструкции нет. Решил написать, уместив максимально кратко и ёмко в одну публикацию, чтобы можно было сохранить и использовать для быстрого копипаста.
Обычно всё хранение файлов под различные нужды делаю в разделе
Устанавливаем пакет для nfs-server:
Добавляем в файл
Для всей подсети просто добавляем маску:
Для нескольких IP адресов пишем их каждый в своей строке (так нагляднее, но можно и в одну писать):
Перезапускаем сервер
Проверяем работу:
Для работы NFS сервера должен быть открыт TCP порт 2049. Если всё ок, переходим на клиент. Ставим туда необходимый пакет:
Проверяем, видит ли клиент что-то на сервере:
Всё в порядке, видим ресурс для нас. Монтируем его к себе:
Проверяем:
Смотрим версию протокола. Желательно, чтобы работало по v4:
Создаём файл:
При желании можно в fstab добавить на постоянку:
Не забудьте в конце поставить переход на новую строку. Либо подключайте через systemd unit. В моей заметке есть пример с NFS.
Похожие короткие инструкции для настройки SMB сервера:
◽на базе python
◽на базе ядерного ksmbd
#fileserver #nfs
Обычно просто через поиск нахожу какую-то статью и делаю. Своей инструкции нет. Решил написать, уместив максимально кратко и ёмко в одну публикацию, чтобы можно было сохранить и использовать для быстрого копипаста.
Обычно всё хранение файлов под различные нужды делаю в разделе
/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.36Export 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 nfs10.20.1.36:/mnt/nfs 48G 3.2G 43G 7% /mnt/nfsСмотрим версию протокола. Желательно, чтобы работало по v4:
# mount -t nfs410.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
👍164👎2
В операционных системах Windows традиционно есть некоторые сложности с использованием протокола NFS. Длительное время она его вообще штатно никак не поддерживала, приходилось использовать сторонний софт. Это объясняется в первую очередь тем, что для передачи файлов по сети у них есть свой протокол SMB. В какой-то момент, уже не помню, в какой точно версии, в Windows появился встроенный NFS клиент.
Установить его можно через Панель управления ⇨ Программы ⇨ Программы и компоненты ⇨ Включение и отключение компонентов Windows ⇨ Службы для NFS ⇨ Клиент для NFS.
Можно включить более простым и быстрым способом через Powershell:
Можно примонтировать диск с NFS сервера, к примеру, развёрнутого из этой заметки:
Диск N появится в качестве сетевого. С ним можно работать к с обычным сетевым диском. Условно, как с обычным, так как работа под Windows с NFS сервером на Linux будет сопряжена с множеством нюансов и неудобств, связанных с правами доступа, кодировкой, чувствительности к регистру в названиях файлов на Linux. В общем случае использовать такой сценарий работы не рекомендуется. Для постоянной работы с Windows проще поднять SMB сервер на Linux.
Для разовых задач или для использования в скриптах можно воспользоваться каким-то альтернативным консольным клиентом. Например, nfsclient. Это небольшая программа на Go уровня курсовой работы студента. Код самой программы простой, но используются готовые библиотеки для работы с NFS.
Программа кроссплатформенная и не требует установки. Это небольшой консольный клиент, который поддерживает простые операции:
◽просмотр содержимого ресурса
◽скачивание, загрузка, удаление файлов
◽создание и удаление каталогов
Работает примерно так. Монтировать диск не нужно. Смотрим список файлов на nfs диске:
Скачиваем файл syslog:
Загружаем в корень диска файл file.txt:
Синтаксис простой, потому что команд не так много: ls/up/down/rm/mkdir/rmdir.
#nfs #fileserver #windows
Установить его можно через Панель управления ⇨ Программы ⇨ Программы и компоненты ⇨ Включение и отключение компонентов 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
👍67👎2
Для редактирования и совместной работы с документами через браузер есть два наиболее популярных движка с открытым исходным кодом:
▪️ OnlyOffice
▪️ Collabora Online
Про #OnlyOffice я регулярно пишу, можно посмотреть материалы под соответствующим тэгом. Там же есть инструкции по быстрому запуску продукта. Решил то же самое подготовить по Collabora Online, чтобы можно было быстро их сравнить и выбрать то, что больше понравится.
Движок для редактирования документов работает в связке с каким-то другим продуктом по управлению файлами. Проще всего потестировать его в связке с ownCloud. Запускаем его:
Идём по IP адресу сервера http://10.20.1.36, создаём учётку админа и логинимся. В левом верхнем углу нажимаем на 3 полоски, раскрывая меню и переходим в раздел Market. Ставим приложение Collabora Online.
Переходим опять в консоль сервера и запускаем сервер collabora:
Возвращаемся в веб интерфейс 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
▪️ 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
2👍67👎3
Для построения распределённого файлового хранилища наиболее популярной и зрелой технологией является Ceph. Это программная объектная отказоустойчивая сеть хранения данных. Минимальное количество нод для построения кластера - три. При этом максимальное количество может исчисляться десятками и возможно сотнями. Ceph сложен и в установке, и в эксплуатации.
Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.
Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы
Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:
Теперь на node-1 инициализируем кластер и создадим токены для добавления двух других:
Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:
На каждой ноде добавим диск sdb к хранилищу:
Смотрим, что получилось:
Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:
Активировать модуль статистики для Prometheus:
Метрики появятся по адресу http://10.20.1.34:9283/metrics. Смотрим использование кластера:
Он пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:
Смотрим список пулов:
Смотрим ключ пользователя admin, который создан автоматически:
Этот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:
⇨ Установка, настройка и эксплуатация Ceph
Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:
Подключаем cephfs:
Теперь все созданные файлы в
Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.
Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ceph #fileserver
Компания 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 statusMicroCeph 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
👍196👎8
Неоднократно видел в комментариях и обсуждениях Ceph упоминание о VitaStor. Автор называет её быстрой и простой распределённой программной СХД. Архитектурно она сильно похожа на Ceph, так что если кто-то с ней знаком, попробовать Vitastor не составит труда. Я где-то за пару часов разобрался, настроил тестовый стенд и проверил в работе.
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
1️⃣ Настраиваем мониторы на основе etcd. Аналог MON в Ceph.
2️⃣ Настраиваем OSD (Object Storage Device). В Ceph так же называется.
3️⃣ Создаём пул.
4️⃣ Создаём образ диска.
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
/dev/vda. Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍103👎2
Существует очень простой способ объединить несколько различных дисков в единый логический раздел. Речь идёт именно о логическом объединении. То есть у вас могут быть два абсолютно любых хранилища, смонтированных в разные разделы. Например,
Сразу поясню, где это может пригодиться.
🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.
🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.
🔹Сервер со статикой или кэшом, где не нужна отказоустойчивость. Можно просто расширять отдельными дисками, а веб серверу отдать единую точку монтирования, где будут видны все файлы.
🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.
Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:
Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:
Я добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.
С такими настройками если записывать на общее хранилище одинаковые по размеру файлы, то они будут по очереди записываться на разные диски. Их можно будет напрямую увидеть в
В репозитории описаны все настройки и возможные политики записи. Они могут быть применены к каждому диску индивидуально. Например, какое-то хранилище может быть подключено только для чтения, на какое-то перестаём писать, когда там остаётся свободно 10G, записываем данные последовательно, заполняя диски по очереди и т.д.
Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.
Полезный прикладной софт. Работает просто, решает конкретную задачу.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
/mnt/sda и /mnt/sdb. Вы можете объединить их в единый диск в новой точке монтирования /mnt/sdab. Объём двух разделов суммируется в новой точке монтирования. При этом файлы будут писаться в зависимости от настроек в оба исходных диска, а /mnt/sdab просто будет единое место, к которому можно обращаться для работы с файлами.Сразу поясню, где это может пригодиться.
🔹Видеосервер с записями камер. Можно объединить разнородные хранилища в единую точку монтирования и указать её в настройках видеосервера.
🔹У меня не раз бывали ситуации, когда мне нужно было объединить в единый раздел несколько raid1 или raid10. Для этого я их объединял с помощью LVM. Бывает так, что у вас есть сервер с 4-мя дисками, но при этом они одинаковые парами, например 2 по 2TB и 2 по 3TB. Вы делаете 2 зеркала mdadm, а потом поверх него пускаете LVM. Получаете 5TB в одном разделе. В некоторых случаях удобнее и безопаснее обойтись без LVM, а сделать логическое объединение.
🔹Сервер со статикой или кэшом, где не нужна отказоустойчивость. Можно просто расширять отдельными дисками, а веб серверу отдать единую точку монтирования, где будут видны все файлы.
🔹Сервер для бэкапов, где допустимо логическое объединение дисков. А для бэкапов это часто допустимо.
Работает всё это на базе mergerfs. Покажу сразу на практике. Допустим, у нас есть 2 диска sda и sdb по 20G. Создаём на них по одному разделу и монтируем в систему:
# cfdisk /dev/sda# cfdisk /dev/sdb# lsblk# mkfs.ext4 /dev/sda1# mkfs.ext4 /dev/sdb1# mkdir /mnt/sda# mkdir /mnt/sdb# mount /dev/sda1 /mnt/sda# mount /dev/sdb1 /mnt/sdb# df -h/dev/sda1 20G 24K 19G 1% /mnt/sda1/dev/sdb1 20G 24K 19G 1% /mnt/sdb1Создали, примонтировали, убедились, что всё работает. Устанавливаем mergerfs и создаём общий диск:
# apt install mergerfs# mkdir /mnt/sdbc# mergerfs -o defaults,allow_other,category.create=mfs,moveonenospc=true,minfreespace=1G /mnt/sda1:/mnt/sdb1 /mnt/sdab# df -h | grep sdaba1:b1 40G 48K 38G 1% /mnt/sdabЯ добавил к параметрам по умолчанию следующие:
◽️allow_other - позволяет пользователям видеть файловую систему, иначе увидит только root.
◽️category.create=mfs - политика распределения файлов по дискам в зависимости от наличия там свободного места, где больше места, туда пишем.
◽️moveonenospc=true - при сбое записи если, к примеру, на устройстве не осталось места или превышена квота, файл будет записан в другое место.
◽️minfreespace=1G - если на устройстве меньше 1G места, туда больше не пишем.
С такими настройками если записывать на общее хранилище одинаковые по размеру файлы, то они будут по очереди записываться на разные диски. Их можно будет напрямую увидеть в
/mnt/sda1 и /mnt/sdb1. # dd if=/dev/zero of=/mnt/sdab/tempfile1 bs=1M count=1000# dd if=/dev/zero of=/mnt/sdab/tempfile2 bs=1M count=1000# ls /mnt/sdabtempfile1 tempfile2# ls /mnt/sda1tempfile2# ls /mnt/sdb1tempfile1В репозитории описаны все настройки и возможные политики записи. Они могут быть применены к каждому диску индивидуально. Например, какое-то хранилище может быть подключено только для чтения, на какое-то перестаём писать, когда там остаётся свободно 10G, записываем данные последовательно, заполняя диски по очереди и т.д.
Общее хранилище можно подключать через fstab или systemd-mount. Примеры есть в репозитории.
Полезный прикладной софт. Работает просто, решает конкретную задачу.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
1👍204👎3
На днях в чате в обсуждении почтовых серверов, как обычно, поднялся вопрос прикрепления к письмам больших файлов. У облачных провайдеров типа Яндекса или Мейла есть возможность большие файлы прикреплять к письмам в виде ссылки, а сами файлы загружаются и хранятся на их файловых сервисах. Когда пользователей пересаживаешь с этих сервисов, они очень грустят и просят такую же функциональность на своих серверах.
В комментариях читатель упомянул плагин для популярного веб интерфейса Roundcube, который позволяет так же просто и удобно прикреплять к письмам большие файлы в виде ссылок на собственное хранилище NextCloud. Раньше я не встречал подобной функциональности. Её реально не хватает на настроенных у себя почтовых серверах.
Решил сразу же проверить, как это работает. Развернул быстро Nextcloud, поднял Roundcube и установил на него плагин Nextcloud Attachments for Roundcube. Никаких особых проблем не возникло. Работает просто и удобно. У меня сходу всё получилось настроить. Правда я хорошо знаю всю эту кухню, но тем не менее. Все файлы, что выходят за разрешённый лимит сервера, предлагается загрузить в Nextcloud.
Roundcube и Nextcloud можно настроить в стороне от вашего сервера, никак его не трогая. Потестировать эту связку нет никаких проблем. Отдельным вопросом стоит сквозная аутентификация. Но даже если её вообще не настраивать, то при первом прикреплении пользователю выскочит предложение пройти аутентификацию в Nextcloud и разрешить Roundcube загружать туда файлы.
В репозитории автора есть описание доступных настроек и картинка с примером, как это работает. Если честно, я по картинке ничего не понял. Ниже мои скрины, которые отражают весь процесс добавления вложения: предложение аутентификации, ссылка на файл в теле письма, как это письмо со ссылкой выглядит у получателя, и как этот файл выглядит, когда перейдёшь по ссылке.
Вообще, это очень крутая функциональность. Если обмен идёт неприватными файлами, то можно быстро поднять Nextcloud, сделать там одну учётку для всех своих пользователей и пусть они под ней прикрепляют туда свои большие файлы и отправляют. Получатели будут видеть только каждый свой файл из письма.
Из минусов – нет перевода на русский язык. Но там текста всего несколько фраз. Можно и вручную в исходниках перевести.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #fileserver
В комментариях читатель упомянул плагин для популярного веб интерфейса Roundcube, который позволяет так же просто и удобно прикреплять к письмам большие файлы в виде ссылок на собственное хранилище NextCloud. Раньше я не встречал подобной функциональности. Её реально не хватает на настроенных у себя почтовых серверах.
Решил сразу же проверить, как это работает. Развернул быстро Nextcloud, поднял Roundcube и установил на него плагин Nextcloud Attachments for Roundcube. Никаких особых проблем не возникло. Работает просто и удобно. У меня сходу всё получилось настроить. Правда я хорошо знаю всю эту кухню, но тем не менее. Все файлы, что выходят за разрешённый лимит сервера, предлагается загрузить в Nextcloud.
Roundcube и Nextcloud можно настроить в стороне от вашего сервера, никак его не трогая. Потестировать эту связку нет никаких проблем. Отдельным вопросом стоит сквозная аутентификация. Но даже если её вообще не настраивать, то при первом прикреплении пользователю выскочит предложение пройти аутентификацию в Nextcloud и разрешить Roundcube загружать туда файлы.
В репозитории автора есть описание доступных настроек и картинка с примером, как это работает. Если честно, я по картинке ничего не понял. Ниже мои скрины, которые отражают весь процесс добавления вложения: предложение аутентификации, ссылка на файл в теле письма, как это письмо со ссылкой выглядит у получателя, и как этот файл выглядит, когда перейдёшь по ссылке.
Вообще, это очень крутая функциональность. Если обмен идёт неприватными файлами, то можно быстро поднять Nextcloud, сделать там одну учётку для всех своих пользователей и пусть они под ней прикрепляют туда свои большие файлы и отправляют. Получатели будут видеть только каждый свой файл из письма.
Из минусов – нет перевода на русский язык. Но там текста всего несколько фраз. Можно и вручную в исходниках перевести.
⇨ 🌐 Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mailserver #fileserver
1👍157👎3
Я уже как-то рассказывал про утилиту sshfs, которая позволяет монтировать удалённую файловую систему через SSH. То есть просто монтируете сетевой диск, используя только SSH соединение. Это не очень быстро, так как подключение выполняется в пространстве пользователя, да и в целом по SSH не очень быстрые соединения. Но для некоторых задач это бывает удобно. Доступ по SSH есть практически всегда.
Сделал готовую инструкцию, чтобы можно было быстро всё настроить с аутентификацией по ключам и с systemd юнитом для автомонтирования при загрузке.
Ставим sshfs:
Генерируем и копируем на удалённую машину ключ:
Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.
Всё готово, монтируем д иректорию
Проверяем:
Размонтировать можно вот так:
Создаём службу systemd:
Сохраняем, запускаем, добавляем в автозагрузку:
Если хотим отмонтировать, то просто останавливаем:
Я показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры
Можно в systemd указать пользователя, под которым всё это будет монтироваться.
Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #fileserver
Сделал готовую инструкцию, чтобы можно было быстро всё настроить с аутентификацией по ключам и с systemd юнитом для автомонтирования при загрузке.
Ставим sshfs:
# apt install sshfsГенерируем и копируем на удалённую машину ключ:
# ssh-keygen -t ed25519# ssh-copy-id root@10.20.1.6Можно подключаться с помощью пароля, но для этого его нужно будет интерактивно вводить вручную. Не получится настроить автомонтирование. Хотя если применить утилиту expect, то и это ограничение можно обойти. Но с сертификатом удобнее и проще.
Всё готово, монтируем д иректорию
/etc/letsencrypt с сервера 10.20.1.6 к себе в /mnt/letsencrypt:# sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencryptПроверяем:
# df -h | grep 10.20.1.6root@10.20.1.6:/etc/letsencrypt 20G 1.8G 17G 10% /mnt/letsencryptРазмонтировать можно вот так:
# fusermount -u /mnt/letsencryptСоздаём службу systemd:
# systemctl edit --force --full sshfs.service[Unit]Description=Mount sshfsAfter=network-online.targetWants=network-online.target[Service]Type=oneshotRemainAfterExit=trueExecStart=sshfs root@10.20.1.6:/etc/letsencrypt /mnt/letsencryptExecStop=fusermount -u /mnt/letsencrypt[Install]WantedBy=multi-user.targetСохраняем, запускаем, добавляем в автозагрузку:
# systemctl start sshfs.service# systemctl enable sshfs.serviceЕсли хотим отмонтировать, то просто останавливаем:
# systemctl stop sshfs.serviceЯ показал примеры на тестовом сервере, сделав всё от root. Если будете настраивать куда-то на постоянку, то скорее всего будете запускать под каким-то другим пользователем (хотя кого я обманываю). Через параметры
User=sftp-userGroup=sftp-userМожно в systemd указать пользователя, под которым всё это будет монтироваться.
Способ подключения дисков через sshfs костыльный, но вполне рабочий. Пользоваться можно. Если есть возможность настроить nfs или smb, с ними будет лучше. Но, например, конкретно для монтирования директории с сертификатами, разницы никакой нет. Сразу подчеркну, что эту задачу можно решать и по-другому. Например, хуками и копированием сертификатов на целевой хост. Решения задачи может быть много. Я показал один из них.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #fileserver
14👍165👎2
Для передачи файлов между устройствами существует огромное количество разных способов. В локальной сети отлично работает LocalSend. Я постоянно пользуюсь дома. За пределами локалки через интернет можно передавать файлы через облачные диски. Я использую Яндекс.Диск, но это долго и не очень удобно. Для небольших файлов можно использовать Telegram. Это удобный передатчик файлов, но не всё туда хочется грузить, так как останется навечно.
Расскажу про ещё один простой и безопасный способ передачи своих файлов - croc. Это сервис, который можно поднять у себя и безопасно передавать файлы через интернет в шифрованном виде. То есть вы полностью будете замкнуты на свою инфраструктуру. В репозитории скудное описание и если следовать только ему, то использование croc не кажется удобным. Я с ним немного поразбирался и настроил всё так, чтобы было удобно. Сразу показываю итоговый вариант.
Croc - одиночный бинарник, который может работать и как клиент, и как relay сервер. Если вы не настроите свой relay, то croc будет работать через свой – croc.schollz.com.
Берём любую VPS в интернете, настраиваем доменное имя и скачиваем туда croc. Можно автоматом загрузить:
В macOS, Windows, Arch, Fedora, Gentoo и даже Freebsd croc есть в стандартных репах. Для Debian/Ubuntu почему-то нет.
Показываю systemd unit для запуска croc relay. Обращаю внимание на переменную CROC_PASS=serveradmin. Это пароль для доступа к relay, чтобы пользоваться им могли только вы.
Теперь ставим клиент на любое устройство. Он есть под все популярные системы, в том числе Android. Живёт приложение в F-Droid. Разработчик сторонний, не автор croc.
Прежде чем начнём передавать файлы, переведём croc в режим работы classic. В нём можно передавать парольные фразы в виде ключей запуска. Это небезопасно, если системой пользуется кто-то ещё, так как ключи можно посмотреть в описании запущенного процесса. В данном случае это некритично, так как мы запустим процесс с ключами ровно один раз и сразу запишем их в конфигурационный файл, чтобы не вводить каждый раз.
◽️
◽️
◽️
◽️
Ключ
После запуска передачи в консоли увидите строку для клиента:
Идём на другую Linux машину и выполняем там команду, добавив и туда ключ
Параметры тоже будут сохранены и в следующий раз файл можно принять так:
В таком виде этой штукой пользоваться уже удобно. Я ставил клиента на Windows, пробовал передавать файлы. Нормально работает, конфиг сохраняет. В приложении на Android параметры нужно будет задать через GUI.
В целом удобное приложение, замыкающее передачу файлов через интернет полностью на вашу инфраструктуру. Настраивается легко. Там есть ещё некоторые параметры, которые можно поменять. Проект старый, довольно популярный (30.4k звёзд), автор его поддерживает.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
Расскажу про ещё один простой и безопасный способ передачи своих файлов - croc. Это сервис, который можно поднять у себя и безопасно передавать файлы через интернет в шифрованном виде. То есть вы полностью будете замкнуты на свою инфраструктуру. В репозитории скудное описание и если следовать только ему, то использование croc не кажется удобным. Я с ним немного поразбирался и настроил всё так, чтобы было удобно. Сразу показываю итоговый вариант.
Croc - одиночный бинарник, который может работать и как клиент, и как relay сервер. Если вы не настроите свой relay, то croc будет работать через свой – croc.schollz.com.
Берём любую VPS в интернете, настраиваем доменное имя и скачиваем туда croc. Можно автоматом загрузить:
# curl https://getcroc.schollz.com | bashВ macOS, Windows, Arch, Fedora, Gentoo и даже Freebsd croc есть в стандартных репах. Для Debian/Ubuntu почему-то нет.
Показываю systemd unit для запуска croc relay. Обращаю внимание на переменную CROC_PASS=serveradmin. Это пароль для доступа к relay, чтобы пользоваться им могли только вы.
# cat /etc/systemd/system/croc-relay.service[Unit]Description=Croc Relay ServerAfter=network.target[Service]Environment="CROC_PASS=serveradmin"ExecStart=/usr/local/bin/croc relayRestart=on-failureUser=nobodyGroup=nogroup[Install]WantedBy=multi-user.targetТеперь ставим клиент на любое устройство. Он есть под все популярные системы, в том числе Android. Живёт приложение в F-Droid. Разработчик сторонний, не автор croc.
Прежде чем начнём передавать файлы, переведём croc в режим работы classic. В нём можно передавать парольные фразы в виде ключей запуска. Это небезопасно, если системой пользуется кто-то ещё, так как ключи можно посмотреть в описании запущенного процесса. В данном случае это некритично, так как мы запустим процесс с ключами ровно один раз и сразу запишем их в конфигурационный файл, чтобы не вводить каждый раз.
# croc --classic# croc --remember --relay 339127.simplecloud.ru --pass serveradmin send --code serveradmin /file◽️
--relay 339127.simplecloud.ru - адрес моего сервера с релеем◽️
--pass serveradmin - пароль доступа к релею◽️
--code serveradmin - кодовая фраза, которой шифруются передаваемые данные◽️
/file - файл, который передаю, можно передать сразу директориюКлюч
--remember позволяет записать все используемые параметры в конфиг ~/.config/croc/receive.json. Теперь можно просто написать:# croc send /fileПосле запуска передачи в консоли увидите строку для клиента:
CROC_SECRET="serveradmin" croc --relay 339127.simplecloud.ru --pass serveradminИдём на другую Linux машину и выполняем там команду, добавив и туда ключ
--remember:# croc --classic# CROC_SECRET="serveradmin" croc --remember --relay 339127.simplecloud.ru --pass serveradminПараметры тоже будут сохранены и в следующий раз файл можно принять так:
# crocВ таком виде этой штукой пользоваться уже удобно. Я ставил клиента на Windows, пробовал передавать файлы. Нормально работает, конфиг сохраняет. В приложении на Android параметры нужно будет задать через GUI.
В целом удобное приложение, замыкающее передачу файлов через интернет полностью на вашу инфраструктуру. Настраивается легко. Там есть ещё некоторые параметры, которые можно поменять. Проект старый, довольно популярный (30.4k звёзд), автор его поддерживает.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#fileserver
👍110👎2
У меня уже год в закладках лежит сервис OpenCloud. Это платформа для обмена файлами, форк OwnCloud. Первый релиз вышел в феврале 2025 года. Я тогда его увидел, записал и решил подождать, чтобы посмотреть, что в итоге получится. Недавно в новостях проскочило, что вышла уже 6-я версия. Как-то бодро они релизы выпускают. Думаю, сейчас уже можно развернуть и посмотреть, что получилось.
При беглом обзоре продукта создаётся впечатление, что это что-то неплохое. Серверная часть написана на Go, фронтенд на Vue.js, клиентская на C++. То есть это как минимум должно работать быстро. Продукт метит в конкуренцию с NextCloud и с таким стеком он как минимум в скорости работы его победит. А по функциональности надо смотреть, что в итоге получилось.
На этапе тестового запуская я немного погрустнел. OpenCloud - многокомпонентная система. Все её составные части надо увязать между собой: сам OpenCloud, прокси сервер Traefik, сервис онлайн документов Collabora Online, сервис идентификации и доступа Keycloak и некоторые другие компоненты. Вручную всё это настраивать было бы совсем хлопотно. В репозитории есть Docker Compose файлы для всего этого хозяйства.
Пробую запускать. Клонирую к себе отдельный репозиторий с compose:
Дальше надо заполнить файл с переменными:
Я указал только пароль и основные директории, остальное не трогал:
У директорий должны быть полные права для id 1000:
Попробовал запустить, ничего не получилось. Сервер запущен, но непонятно, как к нему обращаться. Нет открытых для HTTP портов. Пошёл читать документацию. Оказывается, по умолчанию сервер документов запускается без веб сервера. Надо запускать вместе с Traefik. Ну и для полноты картины добавлю сразу Collabora:
Если запускаете в тестовом окружении без настроенного домена, то Traefik запустится с тестовыми доменами. Вам нужно будет в свой hosts файл добавить записи:
192.168.137.29 - адрес сервера, на котором запущен OpenCloud. Теперь через браузер по адресу https://cloud.opencloud.test я смог зайти в веб интерфейс, используя учётку admin / secret_password, как я указал в compose.yml.
Для того, чтобы корректно работала связка хранилища файлов и collabora, необходимо оба самоподписанных сертификата от доменов cloud.opencloud.test и collabora.opencloud.test добавить в доверенные. Без этого онлайн редактирование документов не заработает, браузер будет ругаться.
Веб доступ у меня нормально заработал. Я сразу через браузер залил туда папочку 10 ГБ с 4000 файлов. И пошёл ставить десктопные приложения. Для macOS и Linux они есть прямо в репозитории, а для Windows почему-то только ссылка на установщик, который лежит в Microsoft Store. Как напрямую скачать и установить приложение, я не понял. Пришлось качать установщик, который потом сам откуда-то скачал приложение.
Этот момент не понравился и выглядит странно. Продукт европейский, но они почему-то сознательно или не очень, но привязались к магазину Microsoft.
Android приложение есть в Google Store и F-Droid. Я установил из Google Store. Приложение маленькое и простое.
Я себе всё установил и настроил. Получилась заметка об установке. О работе с приложениями и общем впечатлении расскажу в вечерней заметке, так как тут уже кончился лимит на объём.
В целом, продукт неплохой, но пока ещё сильно похож на прародителя - ownCloud Infinite Scale. Чего-то нового и необычного я в нём не увидел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
При беглом обзоре продукта создаётся впечатление, что это что-то неплохое. Серверная часть написана на Go, фронтенд на Vue.js, клиентская на C++. То есть это как минимум должно работать быстро. Продукт метит в конкуренцию с NextCloud и с таким стеком он как минимум в скорости работы его победит. А по функциональности надо смотреть, что в итоге получилось.
На этапе тестового запуская я немного погрустнел. OpenCloud - многокомпонентная система. Все её составные части надо увязать между собой: сам OpenCloud, прокси сервер Traefik, сервис онлайн документов Collabora Online, сервис идентификации и доступа Keycloak и некоторые другие компоненты. Вручную всё это настраивать было бы совсем хлопотно. В репозитории есть Docker Compose файлы для всего этого хозяйства.
Пробую запускать. Клонирую к себе отдельный репозиторий с compose:
# git clone https://github.com/opencloud-eu/opencloud-composeДальше надо заполнить файл с переменными:
# cp .env.example .envЯ указал только пароль и основные директории, остальное не трогал:
INITIAL_ADMIN_PASSWORD=secret_passwordOC_CONFIG_DIR=/mnt/opencloud_data/configOC_DATA_DIR=/mnt/opencloud_data/dataУ директорий должны быть полные права для id 1000:
# chown -R 1000:1000 /mnt/opencloud_dataПопробовал запустить, ничего не получилось. Сервер запущен, но непонятно, как к нему обращаться. Нет открытых для HTTP портов. Пошёл читать документацию. Оказывается, по умолчанию сервер документов запускается без веб сервера. Надо запускать вместе с Traefik. Ну и для полноты картины добавлю сразу Collabora:
# docker compose -f docker-compose.yml -f weboffice/collabora.yml -f traefik/opencloud.yml -f traefik/collabora.yml up -dЕсли запускаете в тестовом окружении без настроенного домена, то Traefik запустится с тестовыми доменами. Вам нужно будет в свой hosts файл добавить записи:
192.168.137.29 cloud.opencloud.test192.168.137.29 traefik.opencloud.test192.168.137.29 keycloak.opencloud.test192.168.137.29 collabora.opencloud.test192.168.137.29 wopiserver.opencloud.test192.168.137.29 - адрес сервера, на котором запущен OpenCloud. Теперь через браузер по адресу https://cloud.opencloud.test я смог зайти в веб интерфейс, используя учётку admin / secret_password, как я указал в compose.yml.
Для того, чтобы корректно работала связка хранилища файлов и collabora, необходимо оба самоподписанных сертификата от доменов cloud.opencloud.test и collabora.opencloud.test добавить в доверенные. Без этого онлайн редактирование документов не заработает, браузер будет ругаться.
Веб доступ у меня нормально заработал. Я сразу через браузер залил туда папочку 10 ГБ с 4000 файлов. И пошёл ставить десктопные приложения. Для macOS и Linux они есть прямо в репозитории, а для Windows почему-то только ссылка на установщик, который лежит в Microsoft Store. Как напрямую скачать и установить приложение, я не понял. Пришлось качать установщик, который потом сам откуда-то скачал приложение.
Этот момент не понравился и выглядит странно. Продукт европейский, но они почему-то сознательно или не очень, но привязались к магазину Microsoft.
Android приложение есть в Google Store и F-Droid. Я установил из Google Store. Приложение маленькое и простое.
Я себе всё установил и настроил. Получилась заметка об установке. О работе с приложениями и общем впечатлении расскажу в вечерней заметке, так как тут уже кончился лимит на объём.
В целом, продукт неплохой, но пока ещё сильно похож на прародителя - ownCloud Infinite Scale. Чего-то нового и необычного я в нём не увидел.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍98👎4
Продолжение темы с OpenCloud. Я рассказал, как его развернуть. Теперь поделюсь своими впечатлениями. Я в итоге установил:
▪️Веб интерфейс для работы в браузере
▪️Приложение под Windows
▪️Приложение под Android
📌 Возможности администратора
Администратор может сам создавать пользователей. Назначать им квоты на доступное место. Пользователей можно объединять в группы. Каких-то особых прав группам не назначить. Они используются для того, чтобы можно было дать группе права доступа к какому-то пространству.
Пространство - место для хранения файлов, которое не привязано к пользователю.
◽️Файлы пространства принадлежат только ему и даже при удалении пользователя, автора фала, сохраняются в пространстве.
◽️В пространстве ведётся логирование действий с файлами.
◽️Пространства можно по желанию подключать и отключать в приложениях.
Кроме управления пользователями, группами и пространствами в админке никаких настроек нет.
📌 Приложение под Windows
Оно простое как по интерфейсу и возможностям, так и по потребляемым ресурсам. Умеет работать через прокси и ограничивать трафик во время синхронизации.
Сетевое хранилище встраивается в проводник, наподобие того, как это реализовано в Яндекс.Диск. По умолчанию, отображаются все файлы, но сразу они не скачиваются. Если вы хотите, чтобы какой-то файл постоянно хранился локально, надо это явно указать.
Каких-то проблем или неудобств с синхронизацией я не заметил. Кладёшь на компьютере в директорию файлы, они автоматом улетают на сервер. В веб интерфейсе сразу их видишь.
📌 Веб интерфейс
Помимо доступа к файлам, с которыми можно работать (загружать, скачивать) в веб интерфейсе можно редактировать документы. Причём как одному, так и в режиме реального времени с другими пользователями. Они будут видеть ваши изменения практически мгновенно. Реализовано это всё на базе небезизвестной Collabora Online, так что добавить особо нечего. Про неё много информации в сети.
По сути кроме Collabora и Onlyoffice нет бесплатных движков для онлайн работы с документами. У них принципиальное отличие в том, что Collabora обрабатывает всё на сервере, а в Onlyoffice - на клиентах. Соответственно, первому нужно в разы больше серверных ресурсов для совместной работы, но зато клиентов не нагружает, поэтому и на смартфонах можно спокойно всё редактировать.
Как я уже упоминал, веб интерфейс очень простой и быстрый. С ним комфортно работать, особенно в сравнении с NextCloud, который лишний раз открывать не хочется. Помимо офисных форматов веб интерфейс поддерживает редактирование txt и markdown.
📌 Android приложение
Приложение умеет автоматически загружать фото и видео из галереи на сервер. Так же, как и десктопное приложение, по умолчанию ничего не хранит локально, если ты явно не укажешь, какие файлы и директории надо синхронизировать.
У меня было задвоение некоторых файлов в интерфейсе приложения. Загрузил через десктоп 2 файла, в вебе тоже увидел 2 файла, а в мобильном приложении их оказалось 4. После того, как я в мобильном приложении удалил копии, на самом деле удалились оригиналы. Они уехали в корзину, откуда я их восстановил. Приложение вышло совсем недавно, так что скорее всего найдутся и другие баги.
На смартфоне тоже можно редактировать файлы, зайдя в веб интерфейс. Можно collabora отдельно установить на смартфон, но не вижу большого смысла в этом. На смартфоне редактировать в любом случае неудобно, но если уж приспичит, можно и веб интерфейс открыть.
Продукт мне в целом понравился. Простой и лаконичный интерфейс. Минимум лишней функциональности. Реализована только работа с файлами и документами. Работает всё быстро, хороший отклик у веб интерфейса, пользоваться комфортно. Если взять мой опыт использования Яндекс.Диска, то OpenCloud закрыл бы все мои потребности. Отдельный вопрос с надёжностью и отсутствием багов. Но это без активного использования никак не проверить.
☝️Отдельно упомяну, что на сервере все файлы хранятся в открытом виде с оригинальными именами. Их легко бэкапить.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
▪️Веб интерфейс для работы в браузере
▪️Приложение под Windows
▪️Приложение под Android
📌 Возможности администратора
Администратор может сам создавать пользователей. Назначать им квоты на доступное место. Пользователей можно объединять в группы. Каких-то особых прав группам не назначить. Они используются для того, чтобы можно было дать группе права доступа к какому-то пространству.
Пространство - место для хранения файлов, которое не привязано к пользователю.
◽️Файлы пространства принадлежат только ему и даже при удалении пользователя, автора фала, сохраняются в пространстве.
◽️В пространстве ведётся логирование действий с файлами.
◽️Пространства можно по желанию подключать и отключать в приложениях.
Кроме управления пользователями, группами и пространствами в админке никаких настроек нет.
📌 Приложение под Windows
Оно простое как по интерфейсу и возможностям, так и по потребляемым ресурсам. Умеет работать через прокси и ограничивать трафик во время синхронизации.
Сетевое хранилище встраивается в проводник, наподобие того, как это реализовано в Яндекс.Диск. По умолчанию, отображаются все файлы, но сразу они не скачиваются. Если вы хотите, чтобы какой-то файл постоянно хранился локально, надо это явно указать.
Каких-то проблем или неудобств с синхронизацией я не заметил. Кладёшь на компьютере в директорию файлы, они автоматом улетают на сервер. В веб интерфейсе сразу их видишь.
📌 Веб интерфейс
Помимо доступа к файлам, с которыми можно работать (загружать, скачивать) в веб интерфейсе можно редактировать документы. Причём как одному, так и в режиме реального времени с другими пользователями. Они будут видеть ваши изменения практически мгновенно. Реализовано это всё на базе небезизвестной Collabora Online, так что добавить особо нечего. Про неё много информации в сети.
По сути кроме Collabora и Onlyoffice нет бесплатных движков для онлайн работы с документами. У них принципиальное отличие в том, что Collabora обрабатывает всё на сервере, а в Onlyoffice - на клиентах. Соответственно, первому нужно в разы больше серверных ресурсов для совместной работы, но зато клиентов не нагружает, поэтому и на смартфонах можно спокойно всё редактировать.
Как я уже упоминал, веб интерфейс очень простой и быстрый. С ним комфортно работать, особенно в сравнении с NextCloud, который лишний раз открывать не хочется. Помимо офисных форматов веб интерфейс поддерживает редактирование txt и markdown.
📌 Android приложение
Приложение умеет автоматически загружать фото и видео из галереи на сервер. Так же, как и десктопное приложение, по умолчанию ничего не хранит локально, если ты явно не укажешь, какие файлы и директории надо синхронизировать.
У меня было задвоение некоторых файлов в интерфейсе приложения. Загрузил через десктоп 2 файла, в вебе тоже увидел 2 файла, а в мобильном приложении их оказалось 4. После того, как я в мобильном приложении удалил копии, на самом деле удалились оригиналы. Они уехали в корзину, откуда я их восстановил. Приложение вышло совсем недавно, так что скорее всего найдутся и другие баги.
На смартфоне тоже можно редактировать файлы, зайдя в веб интерфейс. Можно collabora отдельно установить на смартфон, но не вижу большого смысла в этом. На смартфоне редактировать в любом случае неудобно, но если уж приспичит, можно и веб интерфейс открыть.
Продукт мне в целом понравился. Простой и лаконичный интерфейс. Минимум лишней функциональности. Реализована только работа с файлами и документами. Работает всё быстро, хороший отклик у веб интерфейса, пользоваться комфортно. Если взять мой опыт использования Яндекс.Диска, то OpenCloud закрыл бы все мои потребности. Отдельный вопрос с надёжностью и отсутствием багов. Но это без активного использования никак не проверить.
☝️Отдельно упомяну, что на сервере все файлы хранятся в открытом виде с оригинальными именами. Их легко бэкапить.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍83👎1
Уже не раз слышал упоминания о сетевом сервисе для хранения файлов - Cloudreve. Причём в основном в положительном ключе в плане удобства и функциональности, из отрицательного - продукт относительно новый, есть баги, что-то работает плохо. Это по своей сути - прямой конкурент и аналог Nextcloud в плане хранения файлов и совместной работы.
Я развернул Cloudreve и немного попользовался. Понравился с первого взгляда. Очень приятный интерфейс и базовая функциональность по работе с файлами. Залил туда картинки, видео, музыку. Cloudreve автоматом определил типы файлов. Для картинок сразу обзор в виде галереи заработал, для музыки - аудиоплеер, видео можно прям тут же смотреть через встроенный плеер.
Cloudreve очень много всего умеет. Перечислю наиболее интересное, помимо базы для таких сервисов:
▪️В качестве бэкенда для хранения поддерживает различные облачные сервисы и S3 API.
▪️Написан на Go, весь проект - один бинарник, работает быстро.
▪️Умеет загружать удалённые файлы по ссылкам, выстраивать их в очередь загрузок.
▪️Имеет встроенные приложения для открытия файлов. Работает как на компьютере. Выбираешь файл, нажимаешь "открыть с помощью" и выбираешь медиаплеер, текстовый редактор, редактор схем и т.д.
▪️Интеграция с качалками торрентов для фоновой загрузки файлов
Для редактирования офисных документов есть встроенная интеграция с облачными сервисами Microsoft и Google. При желании можно интегрировать со своим onlyoffice или callabora, поддерживается WOPI протокол.
Проект китайский. Есть открытая бесплатная версия и платная с одноразовой покупкой и привязкой к домену. Цена платной всего $90, бессрочно. Основное отличие платной версии - акцент на командной работе с расширенной функциональностью для этого - политики хранения, настройка прав, балансировка нагрузки и т.д. И возможность монетизировать свою Cloudreve через предоставление сервиса - тарифные планы для хранения, платные загрузки файлов, промокоды и т.д.
По своей сути Cloudreve - одиночный бинарник на Go. Но ему нужна СУБД для хранения и Redis для кэша. Есть готовый Docker Compose с PostgreSQL. Я запускал в нём:
Запускает с настройками по умолчанию по HTTP с доступом по IP. Домен и всё остальное можно настроить уже в админке. Порт для подключения - 5212. При первом входе нужно будет создать администратора. Все дальнейшие настройки уже в админке.
Клиент Cloudreve под Windows есть в репозитории и MS Store. Он нативно интегрируется в системный проводник, 1 в 1 как последняя версия Яндекс Диска. Тебе сразу видны все файлы в хранилище, можешь вручную выбирать файлы и каталоги, которые будут жить локально.
Я недавно писал про аналог - OpenCloud. Он в целом неплохой, мне понравился. Но Cloudreve по всем параметрам лучше, и функционально, и по внешнему виду, и по клиенту в Windows.
☝️ У Cloudreve один существенный недостаток по сравнению с многими аналогами. В бесплатной версии нет никакой совместной работы вообще. Да, у вас есть пользователи и группы со своими настройками и квотами, но работают они сами по себе каждый в своём пространстве. Могут только шарить ссылками какие-то отдельные файлы. Вся совместная работа только в платной версии. Но с другой стороны, если уж она и нужна, то за $90 разово можно себе позволить её оплатить.
Резюме такое. Продукт относительно новый и не очень популярный. Активное развитие получил не так давно. В репозитории полно открытых багов и в целом много issues. Плюс, он китайский, со всей спецификой китайской разработки. Хотя на первый взгляд всё выглядит добротно, аккуратно, с английским языком и документацией на нём я особых проблем не увидел. У меня всё завелось сразу и без проблем.
Если выбираете себе подобный продукт, то обязательно попробуйте Cloudreve.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Я развернул Cloudreve и немного попользовался. Понравился с первого взгляда. Очень приятный интерфейс и базовая функциональность по работе с файлами. Залил туда картинки, видео, музыку. Cloudreve автоматом определил типы файлов. Для картинок сразу обзор в виде галереи заработал, для музыки - аудиоплеер, видео можно прям тут же смотреть через встроенный плеер.
Cloudreve очень много всего умеет. Перечислю наиболее интересное, помимо базы для таких сервисов:
▪️В качестве бэкенда для хранения поддерживает различные облачные сервисы и S3 API.
▪️Написан на Go, весь проект - один бинарник, работает быстро.
▪️Умеет загружать удалённые файлы по ссылкам, выстраивать их в очередь загрузок.
▪️Имеет встроенные приложения для открытия файлов. Работает как на компьютере. Выбираешь файл, нажимаешь "открыть с помощью" и выбираешь медиаплеер, текстовый редактор, редактор схем и т.д.
▪️Интеграция с качалками торрентов для фоновой загрузки файлов
Для редактирования офисных документов есть встроенная интеграция с облачными сервисами Microsoft и Google. При желании можно интегрировать со своим onlyoffice или callabora, поддерживается WOPI протокол.
Проект китайский. Есть открытая бесплатная версия и платная с одноразовой покупкой и привязкой к домену. Цена платной всего $90, бессрочно. Основное отличие платной версии - акцент на командной работе с расширенной функциональностью для этого - политики хранения, настройка прав, балансировка нагрузки и т.д. И возможность монетизировать свою Cloudreve через предоставление сервиса - тарифные планы для хранения, платные загрузки файлов, промокоды и т.д.
По своей сути Cloudreve - одиночный бинарник на Go. Но ему нужна СУБД для хранения и Redis для кэша. Есть готовый Docker Compose с PostgreSQL. Я запускал в нём:
# git clone https://github.com/cloudreve/docker-compose.git ~/cloudreve# cd ~/cloudreve# cp .env.example .env# docker compose up -dЗапускает с настройками по умолчанию по HTTP с доступом по IP. Домен и всё остальное можно настроить уже в админке. Порт для подключения - 5212. При первом входе нужно будет создать администратора. Все дальнейшие настройки уже в админке.
Клиент Cloudreve под Windows есть в репозитории и MS Store. Он нативно интегрируется в системный проводник, 1 в 1 как последняя версия Яндекс Диска. Тебе сразу видны все файлы в хранилище, можешь вручную выбирать файлы и каталоги, которые будут жить локально.
Я недавно писал про аналог - OpenCloud. Он в целом неплохой, мне понравился. Но Cloudreve по всем параметрам лучше, и функционально, и по внешнему виду, и по клиенту в Windows.
☝️ У Cloudreve один существенный недостаток по сравнению с многими аналогами. В бесплатной версии нет никакой совместной работы вообще. Да, у вас есть пользователи и группы со своими настройками и квотами, но работают они сами по себе каждый в своём пространстве. Могут только шарить ссылками какие-то отдельные файлы. Вся совместная работа только в платной версии. Но с другой стороны, если уж она и нужна, то за $90 разово можно себе позволить её оплатить.
Резюме такое. Продукт относительно новый и не очень популярный. Активное развитие получил не так давно. В репозитории полно открытых багов и в целом много issues. Плюс, он китайский, со всей спецификой китайской разработки. Хотя на первый взгляд всё выглядит добротно, аккуратно, с английским языком и документацией на нём я особых проблем не увидел. У меня всё завелось сразу и без проблем.
Если выбираете себе подобный продукт, то обязательно попробуйте Cloudreve.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍103👎4
При переходе на Linux с Freebsd, я почти сразу пересел на Centos, где по умолчанию была файловая система XFS. Я особо не заморачивался, и везде использовал её. Каких-то нюансов или проблем у меня с ней не было. По мере того, как стал потихоньку использовать другие ОC, в частности Ubuntu и Debian, где по умолчанию используется EXT4, стал появляться вопрос, а какую файловую систему использовать? Можно выбрать и ту, и другую.
Первое, что приходит в голову, RedHat - крупная именитая компания с огромным количеством различных разработок. Если она рекомендует и по умолчанию использует XFS, почему бы просто не довериться ей.
Я уже поднимал когда-то давно эту тему на канале и было много отзывов по этим ФС. Решил для себя и вас актуализировать этот вопрос, прочитав обсуждения на эту тему, некоторые статьи и поспрашивав ИИ. Вот что в итоге вынес для себя.
📌 На основе комментариев в канале и нескольких обсуждений на Reddit:
◽️XFS архитектурно более сложная система, восстановить с неё данные, если что-то пойдёт не так, намного сложнее, чем с EXT4.
◽️Аварийные выключения с гораздо большей вероятностью приведут к сбоям XFS. На эту тему прям много отзывов.
◽️XFS не получится уменьшить в размере, в отличие от EXT4.
◽️В EXT4 количество доступных inodes задаётся в момент создания, либо используется значение по умолчанию, и их вполне реально все исчерпать. Я лично с этим сталкивался. В XFS такой проблемы нет, они выделяются динамически.
◽️Из-за активного развития XFS, в разных системах могут быть разные версии ФС, так что не получится примонтировать том из одной системы в другую, где отличаются версии ФС в ядре. Это в основном актуально при подключении томов из новых версий в старые. Например, том из Centos 7 можно примонтировать в Centos 9, а наоборот - нет. Даже из Centos 9 в 8-ю версию не примонтировать.
С точки зрения пользовательского опыта, EXT4 проще, универсальнее, надёжнее.
📌 Теперь набор архитектурных отличий:
◽️У XFS есть так называемые Allocation Groups (AG) - независимые группы, на которые разбита файловая система. Каждая AG работает как отдельная мини файловая система. Благодаря этому XFS более эффективно работает с параллельной нагрузкой по чтению-записи по сравнению с EXT4. Это их основное архитектурное отличие. Важно понимать, что разница эта будет заметна только при больших нагрузках на больших же хранилищах.
◽️В XFS есть поддержка Reflink - позволяет нескольким файлам использовать одни и те же блоки данных, что экономит место на диске. Она основана на механизме копирования при записи (Copy-on-Write, CoW).
И ещё важный нюанс. В 2020 году вышла известная статья со сравнением производительности XFS и EXT4 в контексте использования под MySQL сервер. С учётом изменений в MySQL того времени и тестам, автор сделал однозначный вывод, что с XFS работа значительно быстрее, так что он рекомендовал использовать именно её. С тех пор было много обновлений, в том числе и EXT4 и такой разницы в производительности больше нет. Так что та рекомендация потеряла актуальность. Если верить современным тестам, то разница между этими файловыми системами в смешанной нагрузке стала минимальна.
❓ Какой я в итоге для себя сделал вывод?
- Для смешанной нагрузки в различных VPS использовать EXT4 и не забивать себе голову.
- XFS рассматривать только в больших хранилищах, собранных в RAID, например под видеонаблюдение, образы VM или бэкапы. Последнее наиболее актуально. Например, Veeam поддерживает технологию reflink, что существенно экономит место и увеличивает производительность хранилища с бэкапами. У меня есть одна такая большая хранилка с Veeam и там, к сожалению, EXT4. Надо было раньше эту заметку писать. Так что имейте это в виду. Я на тот момент не стал заморачиваться и сделал всё по умолчанию. И теперь Synthetic Full длится часами, а мог бы за минуты выполняться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Первое, что приходит в голову, RedHat - крупная именитая компания с огромным количеством различных разработок. Если она рекомендует и по умолчанию использует XFS, почему бы просто не довериться ей.
Я уже поднимал когда-то давно эту тему на канале и было много отзывов по этим ФС. Решил для себя и вас актуализировать этот вопрос, прочитав обсуждения на эту тему, некоторые статьи и поспрашивав ИИ. Вот что в итоге вынес для себя.
📌 На основе комментариев в канале и нескольких обсуждений на Reddit:
◽️XFS архитектурно более сложная система, восстановить с неё данные, если что-то пойдёт не так, намного сложнее, чем с EXT4.
◽️Аварийные выключения с гораздо большей вероятностью приведут к сбоям XFS. На эту тему прям много отзывов.
◽️XFS не получится уменьшить в размере, в отличие от EXT4.
◽️В EXT4 количество доступных inodes задаётся в момент создания, либо используется значение по умолчанию, и их вполне реально все исчерпать. Я лично с этим сталкивался. В XFS такой проблемы нет, они выделяются динамически.
◽️Из-за активного развития XFS, в разных системах могут быть разные версии ФС, так что не получится примонтировать том из одной системы в другую, где отличаются версии ФС в ядре. Это в основном актуально при подключении томов из новых версий в старые. Например, том из Centos 7 можно примонтировать в Centos 9, а наоборот - нет. Даже из Centos 9 в 8-ю версию не примонтировать.
С точки зрения пользовательского опыта, EXT4 проще, универсальнее, надёжнее.
📌 Теперь набор архитектурных отличий:
◽️У XFS есть так называемые Allocation Groups (AG) - независимые группы, на которые разбита файловая система. Каждая AG работает как отдельная мини файловая система. Благодаря этому XFS более эффективно работает с параллельной нагрузкой по чтению-записи по сравнению с EXT4. Это их основное архитектурное отличие. Важно понимать, что разница эта будет заметна только при больших нагрузках на больших же хранилищах.
◽️В XFS есть поддержка Reflink - позволяет нескольким файлам использовать одни и те же блоки данных, что экономит место на диске. Она основана на механизме копирования при записи (Copy-on-Write, CoW).
И ещё важный нюанс. В 2020 году вышла известная статья со сравнением производительности XFS и EXT4 в контексте использования под MySQL сервер. С учётом изменений в MySQL того времени и тестам, автор сделал однозначный вывод, что с XFS работа значительно быстрее, так что он рекомендовал использовать именно её. С тех пор было много обновлений, в том числе и EXT4 и такой разницы в производительности больше нет. Так что та рекомендация потеряла актуальность. Если верить современным тестам, то разница между этими файловыми системами в смешанной нагрузке стала минимальна.
❓ Какой я в итоге для себя сделал вывод?
- Для смешанной нагрузки в различных VPS использовать EXT4 и не забивать себе голову.
- XFS рассматривать только в больших хранилищах, собранных в RAID, например под видеонаблюдение, образы VM или бэкапы. Последнее наиболее актуально. Например, Veeam поддерживает технологию reflink, что существенно экономит место и увеличивает производительность хранилища с бэкапами. У меня есть одна такая большая хранилка с Veeam и там, к сожалению, EXT4. Надо было раньше эту заметку писать. Так что имейте это в виду. Я на тот момент не стал заморачиваться и сделал всё по умолчанию. И теперь Synthetic Full длится часами, а мог бы за минуты выполняться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Phoronix
Linux 6.12 Through Linux 7.0 File-System Benchmarks For EXT4 + XFS
Earlier this month were various Linux 7.0 file-system benchmarks showing how XFS is leading the race in the overall upstream Linux file-system performance on this forthcoming kernel.
👍141👎2
У меня наконец-то дошли руки заняться семейным видеоархивом. Он так разросся, что вручную его вести затруднительно. Решил подключить технологии машинного обучения в лице хранилища Immich. Это известный open source продукт, который постоянно обозревают блогеры. Посмотреть обзор - это одно, а реально попользоваться - другое дело.
Меня всегда останавливало от поднятия какого-то сервиса для медиа то, что у тебя параллельно возникает ещё один архив, куда надо загружать новые файлы. Можно столкнуться с тем, что при каких-то проблемах с сервисом, можно потерять либо саму структуру файлов в нём, либо вообще сами файлы, так как они превратятся в кашу.
Сейчас у меня архив хранится в сетевой папке с ручной разбивкой по событиям, датам и т.д. Это просто и надёжно, но хлопотно в плане каталогизации, потому что поток новых файлов большой, времени в нём разбираться нету. В итоге последние года всё валится в папки "Разобрать", "2025", "Старый смартфон" и т.д. Никто туда не заходит и ничего не разбирает.
Всё это дело копируется в Яндекс.Диск и в ещё один локальный бэкап. Яндекс диск в целом прост и неприхотлив. По расписанию туда копируются все изменения. Файлы при желании можно посмотреть в браузере. Из аналитики только временная шкала и некоторый интеллектуальный поиск, но не понятно, как и чем он строится. Иногда могу что-то быстро найти, иногда нет. К примеру, по запросу "деревянный дом" вижу фотки своего дома. Довольно удобно. Но иногда что-то ищу, но нахожу.
В итоге развернул Immich и скормил ему свой архив. Расскажу по пунктам, чем он привлёк и как там всё работает:
🔥Самое главное, почему решил его использовать - в Immich можно подключить свой уже существующий архив в виде внешнего хранилища. Для меня это ключевое преимущество. Я по прежнему всё сгружаю в сетевую папку, при желании распределяю по директориям, как мне нравится, бэкаплю по той же схеме, чтобы в случае потери Immich у меня не пострадал сам архив. Immich в него ходит в режиме чтения.
🔹Поверх моего архива Immich делает следующее:
◽️Создаёт миниатюры фотографий для просмотра в браузере.
◽️Извлекает метаданные из фоток для поиска по ним.
◽️Распознаёт содержимое фоток для поиска. К примеру, я могу найти все фотографии, где есть море, коричневая футболка, деревянный дом и т.д. Примерно так же, как в Яндекс Диске. Качество среднее. Что-то находит, что-то нет. Это всё калибруется настройками локальной LLM и качеством миниатюр, по которым ведётся поиск.
◽️Поиск дубликатов по содержимому, а не метаданным.
◽️Обнаружение и распознавание лиц. Это то, что понравилось больше всего. Распознаёт лица нормально, даже детей. Где-то после 2-3 лет детей уже не путает. Грудничка и трехлетку видит как разных детей, но это решается ручным объединением.
◽️Распознаёт текст. Я особо не проверял, как работает, у меня почти нет текста на фотках.
◽️ Кодирует видео в заданные форматы и разрешения. Я не стал это делать, не хочу плодить дубликаты файлов. То, что надо, сжимаю сам в изначальном архиве.
◽️По геометкам, если они есть, отображает на карте фотографии.
Благодаря метаданным, геометкам, распознаванию содержимого и лиц можно выполнять расширенный поиск. Например, вывести все фотки какого-то ребёнка в конкретный год. Под аналитику можно использовать как встроенные небольшие локальные модели, так и подключать внешние. Не тестировал, как это работает.
Из своих данных Immich генерирует миниатюры и хранит всё своё состояние в PostgreSQL. Основную ценность представляет она, если вы фотки подключаете из внешнего хранилища. Миниатюры, если что, можно пересоздать, как и переиндексировать всю медиатеку. Это процесс небыстрый, но и потеря данных некритична, если что. Пару тройку дней можно подождать, если нужно будет заново разметить.
Я пока остановился на том, буду вести архив как раньше, а Immich использовать только для аналитики. Загружать фото непосредственно в него, например, через приложение на смартфоне, не буду. Это удобно, но будет приводить к раздвоению архива.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Меня всегда останавливало от поднятия какого-то сервиса для медиа то, что у тебя параллельно возникает ещё один архив, куда надо загружать новые файлы. Можно столкнуться с тем, что при каких-то проблемах с сервисом, можно потерять либо саму структуру файлов в нём, либо вообще сами файлы, так как они превратятся в кашу.
Сейчас у меня архив хранится в сетевой папке с ручной разбивкой по событиям, датам и т.д. Это просто и надёжно, но хлопотно в плане каталогизации, потому что поток новых файлов большой, времени в нём разбираться нету. В итоге последние года всё валится в папки "Разобрать", "2025", "Старый смартфон" и т.д. Никто туда не заходит и ничего не разбирает.
Всё это дело копируется в Яндекс.Диск и в ещё один локальный бэкап. Яндекс диск в целом прост и неприхотлив. По расписанию туда копируются все изменения. Файлы при желании можно посмотреть в браузере. Из аналитики только временная шкала и некоторый интеллектуальный поиск, но не понятно, как и чем он строится. Иногда могу что-то быстро найти, иногда нет. К примеру, по запросу "деревянный дом" вижу фотки своего дома. Довольно удобно. Но иногда что-то ищу, но нахожу.
В итоге развернул Immich и скормил ему свой архив. Расскажу по пунктам, чем он привлёк и как там всё работает:
🔥Самое главное, почему решил его использовать - в Immich можно подключить свой уже существующий архив в виде внешнего хранилища. Для меня это ключевое преимущество. Я по прежнему всё сгружаю в сетевую папку, при желании распределяю по директориям, как мне нравится, бэкаплю по той же схеме, чтобы в случае потери Immich у меня не пострадал сам архив. Immich в него ходит в режиме чтения.
🔹Поверх моего архива Immich делает следующее:
◽️Создаёт миниатюры фотографий для просмотра в браузере.
◽️Извлекает метаданные из фоток для поиска по ним.
◽️Распознаёт содержимое фоток для поиска. К примеру, я могу найти все фотографии, где есть море, коричневая футболка, деревянный дом и т.д. Примерно так же, как в Яндекс Диске. Качество среднее. Что-то находит, что-то нет. Это всё калибруется настройками локальной LLM и качеством миниатюр, по которым ведётся поиск.
◽️Поиск дубликатов по содержимому, а не метаданным.
◽️Обнаружение и распознавание лиц. Это то, что понравилось больше всего. Распознаёт лица нормально, даже детей. Где-то после 2-3 лет детей уже не путает. Грудничка и трехлетку видит как разных детей, но это решается ручным объединением.
◽️Распознаёт текст. Я особо не проверял, как работает, у меня почти нет текста на фотках.
◽️ Кодирует видео в заданные форматы и разрешения. Я не стал это делать, не хочу плодить дубликаты файлов. То, что надо, сжимаю сам в изначальном архиве.
◽️По геометкам, если они есть, отображает на карте фотографии.
Благодаря метаданным, геометкам, распознаванию содержимого и лиц можно выполнять расширенный поиск. Например, вывести все фотки какого-то ребёнка в конкретный год. Под аналитику можно использовать как встроенные небольшие локальные модели, так и подключать внешние. Не тестировал, как это работает.
Из своих данных Immich генерирует миниатюры и хранит всё своё состояние в PostgreSQL. Основную ценность представляет она, если вы фотки подключаете из внешнего хранилища. Миниатюры, если что, можно пересоздать, как и переиндексировать всю медиатеку. Это процесс небыстрый, но и потеря данных некритична, если что. Пару тройку дней можно подождать, если нужно будет заново разметить.
Я пока остановился на том, буду вести архив как раньше, а Immich использовать только для аналитики. Загружать фото непосредственно в него, например, через приложение на смартфоне, не буду. Это удобно, но будет приводить к раздвоению архива.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍128👎2
Предупреждение для тех, кто использует облачные хранилища файлов, как основные. Как я уже не раз говорил, у меня используется Яндекс.Диск, но исключительно, как резервное хранилище. Основное у меня дома на NAS. Оно копируется ещё в одно место локально, и в облако. Объём основной полезной информации в районе 1,5 ТБ и это ~175 тыс. файлов.
Я провёл несколько экспериментов с облачным хранилищем, о которых хочу рассказать. Если у вас там хранится важная информация, то рекомендую обратить на это внимание.
1️⃣ Взял чистую систему, установил туда клиент Яндекс.Диска и запустил синхронизацию, чтобы проверить, сколько времени займёт загрузка облачного архива. Канал в интернет - 100 мегабит, размер файлов в облаке - 1,1 ТБ. В идеальных условиях это должно качаться 25-30 часов. У меня в итоге ушла неделя. Большую часть времени клиент что-то обрабатывал и не занимал канал, и компьютер тоже особо не нагружал. Он не был узким местом. Если храните там какие-то важные бэкапы, которые нужно будет быстро забрать в случае аварии, имейте ввиду, что не факт, что получится это сделать.
2️⃣ Взял примерно полугодовалую локальную копию и сравнил MD5 хэши с тем, что скачалось из облака. Примерно у 500 файлов хэши не совпали, при полном совпадении всех остальных атрибутов. То есть без сверки хэшей разницу не заметить. Бегло проверил несколько из них. Это были фотки. На них наглядно видно повреждения. Проблемы были именно в облачных файлах. Где они побились - не понятно. Может во время хранения, может во время загрузки в облако или скачивания.
3️⃣ Примерно у 80% файлов были неверные даты создания. Сравнивал с основным хранилищем. Когда и почему они изменились - не знаю. Раньше никогда не обращал на это внимание. Размеры файлов одинаковые, а даты - разные. Это не сказать, что критично, но может создавать неудобства. И не понятно, как исправить, кроме как заливать туда заново все файлы с изменёнными датами.
4️⃣ Отдельно добавлю, о чём уже ранее писал. У меня был случай, когда часть файлов в Яндекс.Диске пропала. Заметил не сразу и только благодаря локальным копиям с большой глубиной хранения.
Я не знаю, как обстоят дела у других облаков, но мне кажется, плюс-минус примерно так же. Стоимость хранения везде относительно низкая для такого рода услуг. Обеспечивать надёжный сервис за эти деньги вряд ли получится, поэтому могут случаться накладки. Используйте их как один из дополнительных бэкапов, но не как основное хранилище.
У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней.
Все сравнения и синхронизации обычно делаю с помощью программы Goodsync.
#fileserver
Я провёл несколько экспериментов с облачным хранилищем, о которых хочу рассказать. Если у вас там хранится важная информация, то рекомендую обратить на это внимание.
Я не знаю, как обстоят дела у других облаков, но мне кажется, плюс-минус примерно так же. Стоимость хранения везде относительно низкая для такого рода услуг. Обеспечивать надёжный сервис за эти деньги вряд ли получится, поэтому могут случаться накладки. Используйте их как один из дополнительных бэкапов, но не как основное хранилище.
У меня Яндекс.Диск используется как для хранения бэкапов, так и для совместного хранилища для разных устройств, которые только частично синхронизируют информацию с ним. Но всегда есть отдельный компьютер или виртуалка, которая синхронизируют себе полную копию облачных данных, и с этой копии делается инкрементный бэкап с глубиной хранения 180 дней.
Все сравнения и синхронизации обычно делаю с помощью программы Goodsync.
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
👍142👎2
Продолжу тему с Immich, так как плотно занялся настройкой. Подробной практической информации по настройке я почти не встречал, так что со всем разбирался сам. Чтобы не забыть и помочь тем, кто будет настраивать, зафиксирую основные моменты.
▪️Сам сервис Immich для просмотра фотографий требует немного ресурсов. Я запустил на 4 CPU старого i3, 4 ГБ оперативы, RAID1 на 2 HDD. Выделил 200 ГБ под его базу данных и миниатюры. На 110 000 фоток (500 ГБ) миниатюры заняли примерно 80 ГБ. Параметры миниатюр можно настроить. ИИ анализирует только миниатюры, а не реальные фото. Так что от них зависит качество аналитики.
▪️Всю аналитику на базе LLM можно вынести на другую машину, что я и сделал. Берём секцию из docker-compose.yml для контейнера immich-machine-learning и запускаем его на любой производительной машине, желательно с видеокартой. Потом в разделе Settings ⇨ Machine learning settings добавляем url этой машины, примерно так - http://192.168.137.29:3003.
Я рассчитывал, что добавив несколько серверов, можно будет параллелить задачи, но это так не работает. Выполняется проверка доступности всех добавленных серверов. Какой первый по списку будет доступен, туда и пойдут все запросы. Если сервер становится недоступен, запросы идут на следующий. То есть имеет смысл добавить один внешний сервер и для подстраховки за ним оставить локальный. Если удалённый становится недоступен, запросы пойдут на локальный.
Основная нагрузка идёт в момент добавления новых файлов. После того, как всё обработается, LLM почти не проявляет активность. Если вы никуда не торопитесь, то можно не заморачиваться с производительной LLM.
▪️Модели для поиска и распознавания лиц можно выбирать там же в настройках ML. По умолчанию для поиска используется простая LLM, которая даже русского языка не знает. Выбрать модель с поддержкой русского можно тут. Все поддерживаемые для всех задач модели перечислены здесь, можно выбрать более качественные. Я для поиска выбрал среднюю модельку ViT-L-16-SigLIP2-256__webli. Меня качество поиска на русском языке устроило. Без проблем находит, к примеру, море, лес, собак, кошек, самолёты и прочие предметы. Мне этого достаточно.
▪️По умолчанию запускаются сразу все задачи по обработке - создание миниатюр, поиск метаданных, поисковой индекс, поиск и распознавание лиц, поиск дубликатов. Если разом залить много фоток или подключить большую внешнюю библиотеку, всё это будет выполняться медленно и мешать друг другу в битве за ресурсы. Лучше включать всё последовательно: сначала миниатюры, потом метаданные, а дальше по потребностям. С миниатюрами хотя бы можно будет просматривать фотки и формировать альбомы.
▪️В веб интерфейсе по умолчанию отключен просмотр медиа через обозреватель файлов в файловой системе, а это удобно, если у вас там уже выстроена структура. Включить его можно в настройках профиля пользователя, в разделе Features.
▪️По умолчанию все загружаемые файлы складываются в иерархию со случайными именами папок и файлов, что неудобно, так как структура жёстко привязана к потрохам immich. Это можно исправить, задав шаблон для архива. Настраивается в Settings ⇨ Storage Template. Шаблон по умолчанию будет вида
▪️Поиск дубликатов работает средствами LLM, и работает хорошо. Можно либо вручную с ними разбираться, либо автоматом убрать все дубликаты. Система оставляет файл наибольшего размера и с наибольшим количеством метаданных. Если внешняя библиотека подключена в режиме rw, то дубликаты могут быть физически удалены.
Система мне понравилась, когда вник во все нюансы, особенно с настройками LLM. Реализовано так или иначе всё, что мне нужно от подобной системы. Это хороший пример того, как небольшие локальные модели могут эффективно решать поставленные задачи.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
▪️Сам сервис Immich для просмотра фотографий требует немного ресурсов. Я запустил на 4 CPU старого i3, 4 ГБ оперативы, RAID1 на 2 HDD. Выделил 200 ГБ под его базу данных и миниатюры. На 110 000 фоток (500 ГБ) миниатюры заняли примерно 80 ГБ. Параметры миниатюр можно настроить. ИИ анализирует только миниатюры, а не реальные фото. Так что от них зависит качество аналитики.
▪️Всю аналитику на базе LLM можно вынести на другую машину, что я и сделал. Берём секцию из docker-compose.yml для контейнера immich-machine-learning и запускаем его на любой производительной машине, желательно с видеокартой. Потом в разделе Settings ⇨ Machine learning settings добавляем url этой машины, примерно так - http://192.168.137.29:3003.
Я рассчитывал, что добавив несколько серверов, можно будет параллелить задачи, но это так не работает. Выполняется проверка доступности всех добавленных серверов. Какой первый по списку будет доступен, туда и пойдут все запросы. Если сервер становится недоступен, запросы идут на следующий. То есть имеет смысл добавить один внешний сервер и для подстраховки за ним оставить локальный. Если удалённый становится недоступен, запросы пойдут на локальный.
Основная нагрузка идёт в момент добавления новых файлов. После того, как всё обработается, LLM почти не проявляет активность. Если вы никуда не торопитесь, то можно не заморачиваться с производительной LLM.
▪️Модели для поиска и распознавания лиц можно выбирать там же в настройках ML. По умолчанию для поиска используется простая LLM, которая даже русского языка не знает. Выбрать модель с поддержкой русского можно тут. Все поддерживаемые для всех задач модели перечислены здесь, можно выбрать более качественные. Я для поиска выбрал среднюю модельку ViT-L-16-SigLIP2-256__webli. Меня качество поиска на русском языке устроило. Без проблем находит, к примеру, море, лес, собак, кошек, самолёты и прочие предметы. Мне этого достаточно.
▪️По умолчанию запускаются сразу все задачи по обработке - создание миниатюр, поиск метаданных, поисковой индекс, поиск и распознавание лиц, поиск дубликатов. Если разом залить много фоток или подключить большую внешнюю библиотеку, всё это будет выполняться медленно и мешать друг другу в битве за ресурсы. Лучше включать всё последовательно: сначала миниатюры, потом метаданные, а дальше по потребностям. С миниатюрами хотя бы можно будет просматривать фотки и формировать альбомы.
▪️В веб интерфейсе по умолчанию отключен просмотр медиа через обозреватель файлов в файловой системе, а это удобно, если у вас там уже выстроена структура. Включить его можно в настройках профиля пользователя, в разделе Features.
▪️По умолчанию все загружаемые файлы складываются в иерархию со случайными именами папок и файлов, что неудобно, так как структура жёстко привязана к потрохам immich. Это можно исправить, задав шаблон для архива. Настраивается в Settings ⇨ Storage Template. Шаблон по умолчанию будет вида
/library/admin/2026/2026-03-24, что лично меня вполне устроило. Просто включил его. Даты файлов берутся не из времени заливки, а из метаданных, если они там есть. ☝️ Шаблон можно менять и потом конвертировать текущую структуру в новый формат.▪️Поиск дубликатов работает средствами LLM, и работает хорошо. Можно либо вручную с ними разбираться, либо автоматом убрать все дубликаты. Система оставляет файл наибольшего размера и с наибольшим количеством метаданных. Если внешняя библиотека подключена в режиме rw, то дубликаты могут быть физически удалены.
Система мне понравилась, когда вник во все нюансы, особенно с настройками LLM. Реализовано так или иначе всё, что мне нужно от подобной системы. Это хороший пример того, как небольшие локальные модели могут эффективно решать поставленные задачи.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍123👎2
У устройств Synology есть особый тип дисковых пулов под названием Synology Hybrid RAID (SHR). С его помощью можно создавать отказоустойчивое хранилище из дисков разного объёма. Сами они описывают его вот так:
Synology Hybrid RAID (SHR) - это автоматизированная система управления RAID от компании Synology. SHR позволяет пользователям создавать гибкие решения для хранения данных с оптимизированной емкостью и производительностью.
SHR основана на системе управления Linux RAID и предназначена для ускорения и упрощения развертывания системы хранения по сравнению с классическими системами RAID. Это делает его особенно подходящим для пользователей, которые не знакомы с технологией RAID.
Мне всегда было интересно посмотреть реализацию. Покажу на простом примере, как это работает. Допустим, у вас есть 3 диска 2ТБ и 3 диска 3ТБ. Вы хотите сделать хранилище, которое без потери данных переживёт отказ одного или двух дисков. В классических моделях RAID у вас только один вариант - отрезать от дисков 3ТБ по 1ТБ, превратив их в 2ТБ диски и собрать RAID 5 или 6 из всех дисков.
Synology предлагает ничего не отрезать и использовать весь объём дисков. Я недавно настраивал Xpenology, поэтому смог посмотреть, как они это делают. Там на самом деле одновременно всё просто и всё сложно. Synology точно так же отрезает от дисков в 3ТБ куски по 1ТБ и создаёт RAID5 с помощью всё того же MDADM, который уже лет 10 хоронят, но он живее всех живых, потому что это максимально простая и надёжная софтовая реализация отказоустойчивых хранилищ.
Из оставшихся трёх отрезков в 1ТБ от трехтерабайтных дисков опять же с помощью MDADM собирают отдельный RAID5 из трёх дисков. В итоге мы имеем:
▪️RAID5 из шести дисков с разделами по 2ТБ
▪️RAID5 из трёх дисков с разделами в 1ТБ
И потом оба эти раздела объединяются в общий Volume Group (VG) с помощью LVM. А дальше создаётся либо один логический том на всю ёмкость, либо несколько. Всё это делается через веб панель. От пользователя реализация скрыта. Он в конце сможет выбрать файловую систему: ext4 или btrfs.
Контроль целостности файлов реализуется через возможности btrfs. Что интересно, разработчики Synology не стали использовать возможности btrfs по созданию raid, а доверились проверенному mdadm.
Я многократно слышал мнение, что mdadm устарел и подлежит замене более современными решениями, потому что у него нет контроля целостности. Не согласен с этим мнением и неоднократно об этом писал и приводил примеры. Контроль за содержимым - не задача устройства хранения, коим является mdadm. Он решает ровно одну задачу - создание отказоустойчивых, надёжных массивов. А за файлами можно следить другими инструментами - btrfs, ceph, linux dm-integrity или множеством реализаций на уровне контроля за файлами.
Подход Synology не нов и не уникален. Я ещё лет 10 назад делал подобное на железном контроллере, который позволял делить диски. Точно так же отрезал куски от больших дисков и объединял их в отдельные массивы. Основной объём дисков объединял в RAID10 для горячих данных, а отрезанные куски в RAID1 для холодного хранения.
Посмотрев на всё это, не стал в Xpenology объединять разные диски. У меня как раз было 3 по 2ТБ и 4 по 3 ТБ. Сделал два пула, объединив одинаковые диски (на скрине внизу, как это выглядит на уровне системы). В целом, всё это вполне надёжно, но не знаю, насколько хорошо все ситуации обыграли инженеры Synology. Не хочется в случае ошибок получить проблемы на таком огромном пуле с разными дисками. Решил не усложнять.
Вообще, мне нравится Synology как раз тем, что ничего особо не выдумывает, а использует проверенные линуксовые решения. Да и под капотом там обычный Linux. У меня как-то были проблемы с одиночным диском, перестал определяться в Synology, слетела таблица разделов. Я без проблем подкцепил диск к обычной системе с Linux, восстановил таблицу и забрал оттуда данные. Писал об этом статью в своё время.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Synology Hybrid RAID (SHR) - это автоматизированная система управления RAID от компании Synology. SHR позволяет пользователям создавать гибкие решения для хранения данных с оптимизированной емкостью и производительностью.
SHR основана на системе управления Linux RAID и предназначена для ускорения и упрощения развертывания системы хранения по сравнению с классическими системами RAID. Это делает его особенно подходящим для пользователей, которые не знакомы с технологией RAID.
Мне всегда было интересно посмотреть реализацию. Покажу на простом примере, как это работает. Допустим, у вас есть 3 диска 2ТБ и 3 диска 3ТБ. Вы хотите сделать хранилище, которое без потери данных переживёт отказ одного или двух дисков. В классических моделях RAID у вас только один вариант - отрезать от дисков 3ТБ по 1ТБ, превратив их в 2ТБ диски и собрать RAID 5 или 6 из всех дисков.
Synology предлагает ничего не отрезать и использовать весь объём дисков. Я недавно настраивал Xpenology, поэтому смог посмотреть, как они это делают. Там на самом деле одновременно всё просто и всё сложно. Synology точно так же отрезает от дисков в 3ТБ куски по 1ТБ и создаёт RAID5 с помощью всё того же MDADM, который уже лет 10 хоронят, но он живее всех живых, потому что это максимально простая и надёжная софтовая реализация отказоустойчивых хранилищ.
Из оставшихся трёх отрезков в 1ТБ от трехтерабайтных дисков опять же с помощью MDADM собирают отдельный RAID5 из трёх дисков. В итоге мы имеем:
▪️RAID5 из шести дисков с разделами по 2ТБ
▪️RAID5 из трёх дисков с разделами в 1ТБ
И потом оба эти раздела объединяются в общий Volume Group (VG) с помощью LVM. А дальше создаётся либо один логический том на всю ёмкость, либо несколько. Всё это делается через веб панель. От пользователя реализация скрыта. Он в конце сможет выбрать файловую систему: ext4 или btrfs.
Контроль целостности файлов реализуется через возможности btrfs. Что интересно, разработчики Synology не стали использовать возможности btrfs по созданию raid, а доверились проверенному mdadm.
Я многократно слышал мнение, что mdadm устарел и подлежит замене более современными решениями, потому что у него нет контроля целостности. Не согласен с этим мнением и неоднократно об этом писал и приводил примеры. Контроль за содержимым - не задача устройства хранения, коим является mdadm. Он решает ровно одну задачу - создание отказоустойчивых, надёжных массивов. А за файлами можно следить другими инструментами - btrfs, ceph, linux dm-integrity или множеством реализаций на уровне контроля за файлами.
Подход Synology не нов и не уникален. Я ещё лет 10 назад делал подобное на железном контроллере, который позволял делить диски. Точно так же отрезал куски от больших дисков и объединял их в отдельные массивы. Основной объём дисков объединял в RAID10 для горячих данных, а отрезанные куски в RAID1 для холодного хранения.
Посмотрев на всё это, не стал в Xpenology объединять разные диски. У меня как раз было 3 по 2ТБ и 4 по 3 ТБ. Сделал два пула, объединив одинаковые диски (на скрине внизу, как это выглядит на уровне системы). В целом, всё это вполне надёжно, но не знаю, насколько хорошо все ситуации обыграли инженеры Synology. Не хочется в случае ошибок получить проблемы на таком огромном пуле с разными дисками. Решил не усложнять.
Вообще, мне нравится Synology как раз тем, что ничего особо не выдумывает, а использует проверенные линуксовые решения. Да и под капотом там обычный Linux. У меня как-то были проблемы с одиночным диском, перестал определяться в Synology, слетела таблица разделов. Я без проблем подкцепил диск к обычной системе с Linux, восстановил таблицу и забрал оттуда данные. Писал об этом статью в своё время.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
👍119👎3
Я себе настроил дома для личных нужд сервер на Xpenology. Прошло уже больше месяца, в настройки лазить перестал, так что можно подвести некоторые итоги и поделиться с вами информацией. Для тех, кто не знает, что такое Xpenology, поясню - это копия операционной системы Synology DiskStation Manager (DSM), которую можно установить только на устройства этой же компании. Проект Xpenology ничего не меняет в оригинальной ОС, а только запускает её практически на любом железе.
Я долго думал, как всё организовать. У меня было 4 диска по 3ТБ и 3 диска по 2ТБ. Всего 7 дисков. Вариантов установки, из которых выбирал, было 3:
1️⃣ Установить PVE, туда виртуалку с Xpenology, пробросить к ней диски напрямую. Я подозревал, что это так себе вариант, потому что наблюдал при пробросе дисков напрямую, что они как-то нестабильно работают. Стараюсь избегать таких схем. А тут целых 7 дисков.
Знакомый подтвердил, что это реально будет глючить, так как он пробовал. Но он же предложил другой вариант. Купить рейд контроллер, который умеет передавать в систему диски напрямую, и пробросить уже его. Это работает стабильно, Xpenology увидит напрямую диски и будет с ними работать, как обычно. Такие контроллеры на Авито стоят 2-4 т.р., работают нормально. У меня такой есть (LSI Logic SAS 9207-8i в HBA pежиме IТ-mоde) для ZFS, трудится, хороший аппарат.
2️⃣ Купить рейд контроллер и установить Xpenology напрямую на железе. Изначально склонялся к этому варианту. PVE рассматривал, потому что привык всё держать на гипервизорах, а не на железе. Но тут получается такая жирная виртуалка, которая 100% не будет бэкапиться целиком и куда-то переезжать, так что смысла в гипервизоре нет.
3️⃣ Подключить все диски напрямую к материнской плате и установить на неё Xpenology. У меня была материнская плата с 8 SATA портами. Мне хватает, ещё один порт про запас остаётся. Остановился в итоге на этом варианте, как самом простом и надёжном. Если бы использовал 2-й вариант, то теоретически можно было бы подключить больше дисков, но практически больше 8-ми я вряд ли поставлю. Этих и так хватает, а дополнительные очень дорогие.
Есть несколько разных способов установить Xpenology. Я выбрал загрузчик Arc Loader. Это сейчас самый простой и распространённый вариант. Записал образ на флешку, загрузился с него и там всё настроил. Далее устанавливается оригинальная Synology DiskStation Manager. Настройки и использование ничем не отличается от оригинальных устройств Synology.
Я сразу же снял посекторный образ флешки, сохранил его и записал на ещё одну флешку. Убедился, что со второй флешки тоже всё грузится. Эту операцию нужно будет проделывать каждый раз при обновлении загрузчика (не системы). Это происходит нечасто. Прошлую Xpenology вообще ни разу не обновлял после установки в течении 13 лет. Нормально отработала. Даже флешка не умерла, хотя под конец иногда подвисала при загрузке.
Диски можно было бы объединить в один общий массив с помощью технологии Synology Hybrid RAID (SHR). Не стал так делать, показалось не слишком надёжным на таком количестве разных дисков. Собрал в итоге с помощью того же SHR два массива из одинаковых дисков. По факту там собирается RAID5 средствами MDADM и поверх файловая система BTRFS. Выбрал всё же SHR, потому что эта технология позволяет потом добавлять диски бОльшего объёма и постепенно заменять старые. Это удобно и задел на будущее.
Я знаю, что сейчас многие переживают по поводу RAID5, якобы это ненадёжно. Для холодных данных я в проде постоянно использую RAID6, иногда RAID5, если дисков мало. У меня была куча ребилдов. На практике я не сталкивался с проблемами. Диски все до 6ТБ. С более объёмными не работал. Так что каких-то повышенных рисков на ребилдах лично я не наблюдал.
Xpenology использую в основном как непосредственно сетевое хранилище, torrent клиент и в качестве сервера мультимедиа для телевизоров. Мне нравится их стандартный пакет для этого за его простоту и удобство. Кинул фильм в папку мультимедиа и пошёл смотреть на телевизоре.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
Я долго думал, как всё организовать. У меня было 4 диска по 3ТБ и 3 диска по 2ТБ. Всего 7 дисков. Вариантов установки, из которых выбирал, было 3:
Знакомый подтвердил, что это реально будет глючить, так как он пробовал. Но он же предложил другой вариант. Купить рейд контроллер, который умеет передавать в систему диски напрямую, и пробросить уже его. Это работает стабильно, Xpenology увидит напрямую диски и будет с ними работать, как обычно. Такие контроллеры на Авито стоят 2-4 т.р., работают нормально. У меня такой есть (LSI Logic SAS 9207-8i в HBA pежиме IТ-mоde) для ZFS, трудится, хороший аппарат.
Есть несколько разных способов установить Xpenology. Я выбрал загрузчик Arc Loader. Это сейчас самый простой и распространённый вариант. Записал образ на флешку, загрузился с него и там всё настроил. Далее устанавливается оригинальная Synology DiskStation Manager. Настройки и использование ничем не отличается от оригинальных устройств Synology.
Я сразу же снял посекторный образ флешки, сохранил его и записал на ещё одну флешку. Убедился, что со второй флешки тоже всё грузится. Эту операцию нужно будет проделывать каждый раз при обновлении загрузчика (не системы). Это происходит нечасто. Прошлую Xpenology вообще ни разу не обновлял после установки в течении 13 лет. Нормально отработала. Даже флешка не умерла, хотя под конец иногда подвисала при загрузке.
Диски можно было бы объединить в один общий массив с помощью технологии Synology Hybrid RAID (SHR). Не стал так делать, показалось не слишком надёжным на таком количестве разных дисков. Собрал в итоге с помощью того же SHR два массива из одинаковых дисков. По факту там собирается RAID5 средствами MDADM и поверх файловая система BTRFS. Выбрал всё же SHR, потому что эта технология позволяет потом добавлять диски бОльшего объёма и постепенно заменять старые. Это удобно и задел на будущее.
Я знаю, что сейчас многие переживают по поводу RAID5, якобы это ненадёжно. Для холодных данных я в проде постоянно использую RAID6, иногда RAID5, если дисков мало. У меня была куча ребилдов. На практике я не сталкивался с проблемами. Диски все до 6ТБ. С более объёмными не работал. Так что каких-то повышенных рисков на ребилдах лично я не наблюдал.
Xpenology использую в основном как непосредственно сетевое хранилище, torrent клиент и в качестве сервера мультимедиа для телевизоров. Мне нравится их стандартный пакет для этого за его простоту и удобство. Кинул фильм в папку мультимедиа и пошёл смотреть на телевизоре.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍107👎6
Вчера разбирался и настраивал очень необычный файловый сервер, состоящий из одного файла на Python, работающий даже с Windows XP и IE6, в том числе на парковке. Речь пойдёт про open source проект Copyparty. Он меня впечатлил своей самобытностью и функциональностью. И при этом показался полезным в конкретных прикладных задачах. Потратил некоторое время на его изучение, так что постараюсь кратко и по существу рассказать про него.
📌Перечислю его возможности, которые показались мне наиболее интересными. Он умеет кучу всего, всё перечислять слишком объёмно.
▪️Очень простой запуск:
▪️Поддержка протоколов: HTTP, WebDAV, SFTP, FTP, TFTP, SMB/CIFS, то есть может работать и через браузер, и как сетевой диск в винде и т.д.
▪️Многопоточная передача, дедупликация, дозагрузка при разрыве связи. Сервис очень хорошо себя ведёт на загрузке больших файлов. Файлы бьёт на чанки с проверкой их хэшей. Дозаливает или перезаписывает только изменения.
▪️Есть cli, что вкупе с предыдущими возможностями делает этот сервер удобным в некоторых случаях в качестве замены rsync.
▪️Сохранение метаданных файла даже при загрузке через браузер. Сохраняется оригинальная дата создания файла, плюс добавляется время загрузки.
▪️Приложение под Android для быстрой загрузки файлов.
▪️Гибкие права доступа и аутентификация (в том числе по IP). Например, можно настраивать доступ к файлам только по прямым ссылкам, без обзора директорий. Можно разрешить только загружать файлы или только перемещать из текущей директории.
▪️Гибкие правила загрузки. Например, запрет на загрузку файлов больше определённого размера, автоудаление файлов через 5 минут после загрузки, автосоздание структуры каталогов в виде даты и времени (для фоток удобно).
▪️Хуки на загрузки и скачивания.
▪️Подробное логирование, метрики для мониторинга
▪️Смотреть картинки, видео, слушать музыку можно прямо через браузер.
Из минусов отмечу странный и неинтуитивный веб интерфейс. Видно, что автор его сделал таким по приколу. Ему так захотелось. Проект на удивление стал весьма популярным. На него много обзоров, звёзд ни гитхабе (46.7k ⭐️). Я про него узнал случайно в комментариях к заметкам.
Покажу на одном небольшом и вполне реальном примере удобство этого сервера. Допустим, у нас есть сетевой сканер. Мы хотим, чтобы он складывал сканы в сетевую папку. У самого сканера доступ только на запись файлов и больше ничего. Он даже не будет видеть содержимое сетевого диска. У пользователей будет анонимный доступ на чтение в эту директорию. Они смогут смотреть сканы через браузер, в том числе на смартфоне или в сетевом диске в Windows. У администратора будет полный доступ.
Copyparty настраивается с помощью файла конфигурации:
Запускаем:
SMB протокол работает плохо в Copyparty. Автор прямо об этом предупреждает. Если сканер поддерживает ftp или webdav, лучше использовать их.
Приложение под Android очень простое. В основном нужно для быстрой загрузки файлов в пару кликов. Веб интерфейс адаптивен, можно использовать его без приложения.
Кому понравился проект, посмотрите видео с обзором. Если понимаете английский на слух, слушайте оригинал. Автор остроумен и интересен, поэтому у обзора на такой специфичный продукт 606 😳 тысяч просмотров. Вот ещё демка на потыкать. Стоит за CF, поэтому напрямую не откроется. Обратите внимание на страничке с демо на правый нижний угол. Это тоже шуточка от автора.
Меня очень впечатлил этот файловый сервер. Я прочитал всю инструкцию в репозитории, оценил все возможности, посмотрел несколько обзоров. Классная штука. Может упростить велосипедостроение на bash, взяв на себя часть функциональности, например, по удалению старых файлов, созданию директорий, нужному именованию файлов и т.д.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#fileserver
📌Перечислю его возможности, которые показались мне наиболее интересными. Он умеет кучу всего, всё перечислять слишком объёмно.
▪️Очень простой запуск:
# python3 copyparty-sfx.py▪️Поддержка протоколов: HTTP, WebDAV, SFTP, FTP, TFTP, SMB/CIFS, то есть может работать и через браузер, и как сетевой диск в винде и т.д.
▪️Многопоточная передача, дедупликация, дозагрузка при разрыве связи. Сервис очень хорошо себя ведёт на загрузке больших файлов. Файлы бьёт на чанки с проверкой их хэшей. Дозаливает или перезаписывает только изменения.
▪️Есть cli, что вкупе с предыдущими возможностями делает этот сервер удобным в некоторых случаях в качестве замены rsync.
▪️Сохранение метаданных файла даже при загрузке через браузер. Сохраняется оригинальная дата создания файла, плюс добавляется время загрузки.
▪️Приложение под Android для быстрой загрузки файлов.
▪️Гибкие права доступа и аутентификация (в том числе по IP). Например, можно настраивать доступ к файлам только по прямым ссылкам, без обзора директорий. Можно разрешить только загружать файлы или только перемещать из текущей директории.
▪️Гибкие правила загрузки. Например, запрет на загрузку файлов больше определённого размера, автоудаление файлов через 5 минут после загрузки, автосоздание структуры каталогов в виде даты и времени (для фоток удобно).
▪️Хуки на загрузки и скачивания.
▪️Подробное логирование, метрики для мониторинга
▪️Смотреть картинки, видео, слушать музыку можно прямо через браузер.
Из минусов отмечу странный и неинтуитивный веб интерфейс. Видно, что автор его сделал таким по приколу. Ему так захотелось. Проект на удивление стал весьма популярным. На него много обзоров, звёзд ни гитхабе (46.7k ⭐️). Я про него узнал случайно в комментариях к заметкам.
Покажу на одном небольшом и вполне реальном примере удобство этого сервера. Допустим, у нас есть сетевой сканер. Мы хотим, чтобы он складывал сканы в сетевую папку. У самого сканера доступ только на запись файлов и больше ничего. Он даже не будет видеть содержимое сетевого диска. У пользователей будет анонимный доступ на чтение в эту директорию. Они смогут смотреть сканы через браузер, в том числе на смартфоне или в сетевом диске в Windows. У администратора будет полный доступ.
Copyparty настраивается с помощью файла конфигурации:
[global]
e2dsa, smbw, z
smb-port: 445
[accounts]
scanner: SCAN_PASS
admin: ADMIN_PASS
[/scans]
/mnt/scans
accs:
r: *
w: scanner
A: admin
Запускаем:
# wget https://github.com/9001/copyparty/releases/latest/download/copyparty-sfx.py# python3 copyparty-sfx.py -c copyparty.confSMB протокол работает плохо в Copyparty. Автор прямо об этом предупреждает. Если сканер поддерживает ftp или webdav, лучше использовать их.
Приложение под Android очень простое. В основном нужно для быстрой загрузки файлов в пару кликов. Веб интерфейс адаптивен, можно использовать его без приложения.
Кому понравился проект, посмотрите видео с обзором. Если понимаете английский на слух, слушайте оригинал. Автор остроумен и интересен, поэтому у обзора на такой специфичный продукт 606 😳 тысяч просмотров. Вот ещё демка на потыкать. Стоит за CF, поэтому напрямую не откроется. Обратите внимание на страничке с демо на правый нижний угол. Это тоже шуточка от автора.
Меня очень впечатлил этот файловый сервер. Я прочитал всю инструкцию в репозитории, оценил все возможности, посмотрел несколько обзоров. Классная штука. Может упростить велосипедостроение на bash, взяв на себя часть функциональности, например, по удалению старых файлов, созданию директорий, нужному именованию файлов и т.д.
———
ServerAdmin:
#fileserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍116👎1