Неоднократно видел в комментариях и обсуждениях 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👍102👎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👍200👎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👍156👎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👍164👎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
👍109👎2