На днях в чате в обсуждении почтовых серверов, как обычно, поднялся вопрос прикрепления к письмам больших файлов. У облачных провайдеров типа Яндекса или Мейла есть возможность большие файлы прикреплять к письмам в виде ссылки, а сами файлы загружаются и хранятся на их файловых сервисах. Когда пользователей пересаживаешь с этих сервисов, они очень грустят и просят такую же функциональность на своих серверах.
В комментариях читатель упомянул плагин для популярного веб интерфейса 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👍98👎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.
👍136👎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👍125👎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
👍138👎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
👍117👎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
👍109👎3