Как создать свое облачное хранилище


Создаем личное облако на 3 Тб / Habr

Я бы хотел поделиться одним способом создания личного облака на базе трехтеррабайтного WD MyBook Live. Нет, я не буду даже упоминать про wd2go и их «полуоблака», которые по сути являются только доступами к самому NAS через сервисы WD при помощи довольно корявых Java-апплетов. В этой статье речь пойдет о «честном» облаке, работающем на MBL при помощи ownCloud.
Это решение подойдет тем, кто мечтает о личном аналоге Dropbox, файлы в котором хранятся не «где-то там», а на конкретном физическом носителе, и ограничены только его объемом, без необходимости платить ежемесячно за этот объем (пренебрегая абонентской платой за интернет и стоимостью электроэнергии).
Большинство решений подобной задачи требуют достаточно много покопаться в интернете и опираются на хорошее знание Linux-систем. В данном посте я попытаюсь дать наиболее полный и адекватный HOW-TO на русском, чего сам в интернете не нашел. Так что многое пришлось делать методом проб и ошибок на свой страх и риск. Реализация данного решения не требует каких-либо фундаментальных знаний Linux, и я постараюсь расписать все наиболее доступно, по шагам.

Если интересно что из этого вышло — добро пожаловать под кат.

Прежде всего, хотел бы сказать что все манипуляции над своим MyBook Live вы делаете только под собственную ответственность. Теоретически, при неправильной последовательности действий, есть возможность сделать его не работоспособным, и хотя в подавляющем большинстве случаев, коробочку можно воскресить, а данные — спасти, все равно постарайтесь сделать бэкап содержимого на другой носитель. Либо, если есть такая возможность, лучше работать над чистым носителем.

Современная линейка WD MyBook Live — это процессор 800 МГц, 256 Мбайт оперативной памяти и практически полноценный вариант Debian Linux в качестве прошивки, правда это уже не поддерживаемый Lenny с примесью файлов прошивки от WD, да еще и под архитектуру PPC, так что с пакетами повозиться все же придется, однако apt-get, wget и dpkg тут самые что ни на есть обычные, а значит работать с репозиториями возможно в полной мере.

На хабре уже была статья об ownCloud, поэтому останавливаться подробно на том что это такое и как оно устанавливается в общем случае я не буду, перейду сразу к конкретике для MBL. Прежде всего, ownCloud – это серверное приложение, которое работает максимально похоже на сервисы Dropbox, Google Drive и подобные, только хостится оно на вашем железе, что само по себе совершенно бесплатно, да и MBL – далеко не худший вариант для хостинга подобного решения.

В первую очередь, нам нужно будет включить доступ к нашему MBL по SSH для дальнейшей работы. Делается это довольно просто — зайдя по адресу mybooklive/UI/ssh и поставив галочку напротив протокола SSH:

Как видно, пароль по-умолчанию для доступа – welc0me.
Дальше останется только войти по SSH через терминал (на windows-машине можно использовать PuTTY):

ssh [email protected] 

Предлагаю в первую очередь, также сменить пароль на более стойкий (тем более потребуется если в дальнейшем будете открывать доступ через интернет), командой passwd, после чего будет необходимо два раза ввести новый пароль.ВАЖНО!Ни в коем случае не пытайтесь проапгрейдить дистрибутив на мажорную версию, а лучше вообще забудьте о существовании команд full-upgrade, safe-upgrade или любой другой upgrade, это неминуемо приводит к тому, что вы больше не сможете загрузить девайс. Мне пришлось-таки поплатиться за свое любопытство ручным разбором устройства и восстановлением через анбрик. Ничего смертельного, но чрезвычайно неприятно и отнимает уйму времени.
Также, советую тщательно следить за пакетами, которые устанавливаете или удаляете. Так можно в лучшем случае утянуть уйму ненужного мусора, а в худшем — при удалении какого-либо ненужного пакета вместе с зависимостями, грохнуть что-то жизненно важное. Так, например если вы умудритесь грохнуть ssh, то единственный вариант вернуть коробку к жизни также, будет через разбор и анбрик начисто.
Ну и на последок, чего вообще делать нельзя — так это трогать udev, его даже апдейтить опасно, в этом случае рискуете получить вместо My Book Live кирпич, непригодный к восстановлению. Лучше всего от греха подальше, запретить ему обновляться командой:
aptitude hold udev 

Это заморозит данный пакет, тем самым предотвратив возможность его обновления.

Потом, нам потребуется подготовить платформу для установки стороннего ПО. И ключевым здесь будет удаление пакетов wd-nas, дабы apt-get не ругался в дальнейшем по каждому пустяку. Как ни странно, этой информации нет практически нигде, кроме официального источника:
rm -f /var/lib/dpkg/info/wd-nas.* 

Это устранит пакеты, зависимые от прошивки.

Следующим шагом, нам будет необходимо добавить в список доступных репозиториев две ссылки. Сделать это удобнее всего в редакторе nano, командой:

nano /etc/apt/sources.list 

А вот что необходимо добавить:
deb http://ftp.us.debian.org/debian/ squeeze main deb-src http://ftp.us.debian.org/debian/ squeeze main 

Возможно у кого-то возникнут вопросы, зачем добавлять репозитории squeeze если версия самого WD MBL — lenny? Отвечу — просто потому что lenny с февраля 2012 года более не поддерживается, и большинство необходимых пакетов для него давно устарели, что может привести к неразрешимым зависимостям (пришлось откатываться к заводским настройкам после первой неудачной попытки). В интернете достаточно много советов по тому какие еще репозитории можно добавить, включая тестовые ветки, но я советую не слишком увлекаться, потому что не зная что ты делаешь, можно превратить эту шуструю коробочку в безжизненный кирпичик.
Во избежание путаницы, привожу содержимое моего sources.list, с которым все работаетdeb archive.debian.org/debian lenny main
deb-src archive.debian.org/debian lenny main
deb ftp.us.debian.org/debian squeeze main
deb-src ftp.us.debian.org/debian squeeze main
После добавления нужных строк и сохранения списка репозиториев, нужно попробовать обновиться командой:
apt-get update 

Не забываем, что ownCloud все же написан на PHP, поэтому для его полноценной работы нам потребуется установить ряд необходимых пакетов, включая актуальную версию PHP5 и несколько необходимых модулей:

apt-get install php5 php5-gd php-xml-parser php5-intl zlib1g 

Установщик может ругнуться на недоверенные пакеты. Это происходит потому что подписанные ключи для репозиториев Дебиан уже не актуальны. У этой проблемы существует решение, однако можно и проигнорировать предупреждение просто нажав пару раз на «Y». Также, в процессе установки возможны конфликты разных версий пакетов, часть из которых была предустановлена в системе. По-умолчанию, предпочтение будет дано уже установленным пакетам (это же Debian), так что вполне можно согласиться с этим решением (хотя ничего страшного не должно произойти даже если заменить эти пакеты на новые).

Если все прошло успешно, самое время перейти непосредственно к установке ownCloud. Это достаточно простая часть. Нужно перейти в каталог /www/ и скачать туда веб-установщик при помощи wget. А также, убедиться что установлены соответствующие групповые права на запись:

cd /var/www/ wget https://download.owncloud.com/download/community/setup-owncloud.php --no-check-certificate chmod 755 setup-owncloud.php chgrp www-data /var/www chmod g+w /var/www 

Далее, нужно перейти в браузере по адресу mybooklive/setup-owncloud.php чтобы продолжить установку. Можно установить ownCloud в любой каталог, но чтобы не запутаться в дальнейшем, советую все же, ставить его в одноименный каталог /owncloud/.
Если в конце установки, вы увидите подобную картину
то не пугайтесь. Все требуемые модули мы устанавливали еще на прошлом шаге, но для того чтобы они заработали, нужно всего-навсего, перезагрузить веб-сервер apache:
/etc/init.d/apache2 restart 

Хотя я бы не стал на данный момент этого делать, потому что немного позже мы все равно его будем перезагружать.
После того как мы определились с каталогом установки, останется лишь немного допилить напильничком доступы извне для http и SSL https, а также вернуть групповые права для /www/. Для этого, необходимо будет прописать следующие строки:
 <Directory /var/www/owncloud/> AllowOverride All Options +FollowSymLinks </Directory> <Directory /var/www/owncloud/data> Order deny,allow Deny from all </Directory> 

между подобных модулей ... в следующих файлах:
nano /etc/apache2/sites-enabled/000-wdnas 
nano /etc/apache2/sites-enabled/000-wdnas-ssl 

Вот теперь можно перезагружать апач и возвращать права доступа для /www/:
/etc/init.d/apache2 restart chmod g-w /var/www 

Технически, данные вновь установленного owncloud хоть и находятся на жестком диске, однако логически они принадлежат системному разделу MBL, который имеет ограничение в 2 Гб. Для того, чтобы иметь возможность использовать весь доступный объем под owncloud (честно, не представляю кому и зачем это может понадобиться и сколько лет будут синхронизироваться все 3TB, забитые данными), а не ограничиваться системным разделом, мы сделаем символическую ссылку в основной раздел DataVolume, предварительно остановив апач на время наших манипуляций:
/etc/init.d/apache2 stop mv /var/www/owncloud/data /DataVolume/owncloud_data chgrp www-data /DataVolume/owncloud_data chmod 770 /DataVolume/owncloud_data ln -s /DataVolume/owncloud_data /var/www/owncloud/data 

Я категорически не советую прокидывать линк в папку Public из соображений безопасности.

По сути, нам останется только вновь запустить апач и основная цель будет достигнута:

/etc/init.d/apache2 start 

Теперь по адресу mybooklive/owncloud нам доступно собственное облако, в котором можно держать и синхронизировать огромное количество документов, доступ к которым можно получить с Win, Mac, Linux, Android и даже iOS при помощи нативных клиентов для каждой из осей, просто настроив клиент на синхронизацию с вышеуказанным адресом.
Похоже, это победа.
Однако...

По правде, это еще далеко не победа, а только полпути, потому что адрес mybooklive/owncloud является локальным, и работать наше облако будет только в рамках домашней сети, благодаря чему толку от него будет очень немного. Но что же сделать чтобы пользоваться ownCloud можно было отовсюду? Конечно, счастливые обладатели статических IP скажут что нужно просто заменить «mybooklive» в адресе на IP устройства, предварительно пробросив нужные порты через роутер, и будут правы. Но такая роскошь есть не у каждого, и подавляющее большинство пользователей имеют-таки самые обычные динамические IP, которые меняются постоянно, так что каждый раз устройство будет иметь новый адрес.
Как ни странно, у этой задачи есть достаточно несложное решение. Нет, даже не подумайте что мы посмотрим в сторону неудобного сервиса wd2go (хотя была пара идей как можно использовать и его) – напротив, мы опять поработаем головой и воспользуемся такой полезной штукой как Dynamic DNS.

Для этого нам понадобится:

  1. Зарегистрировать домен.
  2. Зарегистрироваться на каком-либо сервисе, предоставляющем DynDNS.
  3. Установить DynDNS клиент на наш MyBookLive

Для первого пункта вполне подойдут даже любые бесплатные домены третьего уровня (гуглятся на ура), но лучше конечно зарегистрировать собственный домен. Есть вполне дешевые доменные зоны, например домен в зоне .pw (острова Палау, хотя некоторые регистраторы раскручивают его как Professional Web) обойдется даже чуть меньше 7 € в год. Как вариант — посмотреть по акциям на GoDaddy (там часто можно урвать какой-то лакомый кусочек всего за 5 баксов).

В качестве сервера DynDNS лично я выбрал совершенно бесплатный от freedns.afraid.org, потому что платить за не используемые фишки от dyn.com/dns даже минимальную абонентку в год, как-то не хотелось. Для нашей задачи отлично подойдет самый минимальный функционал. Подробно расписывать процедуру регистрации домена и привязки его к сервису DynDNS в рамках данной статьи я не буду. Достаточно просто зарегистрироваться на сервисе и на странице freedns.afraid.org/domain найти пункт «Add A Domain into FreeDNS», после чего добавить в качестве DNS у вашего регистратора следующие ns-сервера:

NS1.AFRAID.ORG NS2.AFRAID.ORG NS3.AFRAID.ORG NS4.AFRAID.ORG 

При этом не стоит пугаться красного статуса Broken — если все нормально, он исчезнет сам в течение 24-х часов.

Далее нам необходимо выбрать и установить какой-либо Dynamic DNS клиент на MyBookLive. На самом деле, это задача не из легких, потому что подобных решений действительно огромное множество на Perl, Python, PHP, есть также отдельные демоны для *nix всех видов и мастей. Перед тем как найти подходящее решение, мне пришлось перепробовать достаточно много вариантов, но везде что-то не устраивало — то настройка через одно место, то стабильность работы не устраивает, то с выбранным сервером не совместим, то с версией протокола, то слишком неповоротливо. В итоге решил остановиться на самом маленьком, простом и незатейливом клиенте inadyn. Из плюсов — шустрая работа, очень маленький размер, совместимость с выбранным сервером, довольно гибкая настройка, поддержка крона, запуск в режиме демона и обновление IP через заданный интервал. Из минусов разве что отсутствие какого-либо GUI, и то это даже минусом назвать сложно для такой консольной утилитки.

Устанавливается она просто командой:

apt-get install inadyn 

Также важное замечание что для работы inadyn может потребоваться curl, если он не был установлен. Решается так:
apt-get install curl 

Далее нам необходимо войти под своим аккаунтом на freedns.afraid.org/dynamic и выбрать пункт Direct URL напротив домена, который мы привязывали ранее. Обратите внимание, что в строке браузера будет нечто подобное:
http://freedns.afraid.org/dynamic/update.php?OHphN3RsHY0SEFtZ1JrQ2V2Z1pTOjk2NzEwOTTVM1cc= 

Нас интересует все, что стоит справа от ?. Это — хэш, действительный только для вашего домена (значения в примере изменены). Скопируйте его куда-нибудь, он нам вскоре понадобится.
Теперь создаем конфигурационный файл inadyn командой:
nano /etc/inadyn.conf 

в который вставляем необходимые настройки и сохраняем:
--username <имя_пользователя> --password <пароль> --update_period_sec 60 --forced_update_period 120 --alias <имя_домена>,<хэш> --background --dyndns_system [email protected] --syslog 

Кому интересно, расшифровка
  • username — здесь указываем имя пользователя, с которым регистрировались на freedns.afraid.org
  • password — пароль оттуда же
  • update_period_sec — частота проверки и обновления (если менялся) IP в секундах
  • forced_update_period — частота принудительного обновления IP в секундах
  • alias — строка, в которой через запятую указываем наш домен и его хэш, который мы записывали ранее
  • background — указание исполнять в фоновом режиме
  • строку dyndns_system [email protected] оставляем без изменений, она говорит программе с каким сервером идет работа информацией (указывает на внутренний протокол обмена)
  • syslog — события пишем в системный лог


Теперь нам нужно добавить inadyn в крон как автоматическое событие при перезагрузке, чтобы каждый раз при перезагрузке MyBookLive, она стартовала автоматически. Для этого:
crontab -e 

Добавляем строку:
@reboot /usr/sbin/inadyn 

Чтобы проверить работоспособность программки после наших манипуляций, можно перезагрузить MBL командой
reboot 

Затем подождать 3-5 минут пока он перезагрузится и стартует, после чего проверить процессы:
ps -A | grep inadyn 

Нам останется только проверить доступность нашего майбука по имени домена командой ping:
ping <yourdomain.com> 

Если все прошло нормально, и отправленные пакеты доходят, можно смело заходить на yourdomain.com/owncloud и радоваться большому выполненному делу.
При настройке десктопных и мобильных клиентов owncloud, в качестве адреса нужно указывать полностью строку yourdomain.com/owncloud, чтобы они понимали где находится наш /owncloud/.

P.S. за время написания статьи, методом проб и ошибок, пришлось один раз делать полный программный сброс к заводским настройкам и два раза разбирать устройство чтобы воскресить (по инструкции отсюда), поэтому очень прошу, отнестись ко всем предостережения серьезно, с пониманием собственной ответственности и возможности испортить железку и потерять информацию. Также, не забывайте, что MyBookLive прежде всего, просто бюджетный nas, и использовать его в качестве полноценного сервера все же не стоит, для этого есть куда более подходящие решения.

P.P.S. о каких-то ошибках или неточностях, просьба писать в личных сообщениях. Тема лично мне очень интересна, и я не обладаю большими фундаментальными познаниями в администрировании Linux, так что замечания могут быть очень полезны. Вполне возможно, что статья будет еще дополняться, расширяться, а если она будет востребована, то возможно и обзаведется второй частью (есть еще несколько идей как можно прокачать MyBookLive)

Ответы на вопросы:

Вопрос: Нужно ли устанавливать apache? В статье об этом ни слова.
Ответ: Нет, apache на MyBookLive установлен по-умолчанию. При первом подключении, настройка происходит через веб-интерфейс по адресу: mybooklive.local. Важно, что при неправильном обновлении или модификации apache, можно лишиться веб-интерфейса и оказаться в ситуации, когда его невозможно будет запустить без сброса к заводским настройкам. Бездумно обновлять его также не стоит, т.к. можно наткнуться на неразрешимые зависимости, а на Lenny, да еще и под архитектуру PPC альтернативных вариантов не так много.

Вопрос: На какой версии прошивки проводился эксперимент?
Ответ: Все делалось на 02.42.03-027, но по идее, должно работать и с более ранними. К сожалению, информации по различным прошивкам нет.

Вопрос: Может ли Feature Pack Manager повлиять каким-либо образом на описанное в статье?
Ответ: По своей сути, fpkmgr — просто некий расширенный менеджер пакетов, который устанавливает тот набор пакетов, который выберет пользователь. На моем MBL спокойно работали параллельно Transmission из fpkmgr и owncloud. Возможно, есть какие-то пакеты, устанавливаемые при помощи fpkmgr, которые могут конфликтовать, но информацией об этом я пока не обладаю. Если кто-то сталкивался и напишет об этом, я включу замечание сюда.

Вопрос: После действий, описанных в статье, будет ли owncloud отключаться, когда MBL уходит в сон?
Ответ: Самое интересное, что судя по поведению светодиода, он-таки в сон уходил пока я не отключил энергосбережение. По факту работал с некоторой задержкой чтобы «проснуться» и показать содержимое owncloud при заходе из браузера, хотя технически этот аспект я не изучал. При отключенном энергосбережении все отлично работает.

Вопрос: Все сделал по инструкции, но при попытке доступа пишет что невозможно подключиться к серверу. Что делать?
Ответ: Для нормальной работы owncloud, необходимо пробросить на роутере порты 80 и 443. Как это сделать, подскажет гугл при запросе port-forwarding.

Материалы:

habr.com

Персональное облако / Habr

Облачное хранилище позволяет не только хранить данные, но и обеспечивать совместную работу с ними в NAS.


Возможные решения

Существует несколько вариантов облачных сервисов: NextCloud, Seafile, Pydio и т.д…
Ниже рассмотрена часть из них.


Реализации облачных сервисов.

OwnCloud

Реализован на PHP/Javascript.

Возможности:


  • Возможно расширять функционал, устанавливая приложения из репозитория облака.
  • Есть интеграция с офисом Collabora и OnlyOffice.
  • Возможно использовать существующие хранилища, такие как FTP, Swift, S3, Dropbox и т.п.,
    распределяя данные между ними и локальным облаком.
  • Шифрование на клиенте.
  • Возможность предоставлять файлы внешним пользователям по e-mail.
  • Есть автоматизация операций с файлами (например, автоматическое добавление тэгов).
  • LDAP.
  • Есть аудио плеер, музыкальная коллекция, галерея плагин чтения PDF.
  • Интеграция с Zimbra.
  • Есть календари, списки задач, текстовые редакторы и т.п.
  • Антивирус и защита от ransomware.
  • Двуфакторная аутентификация.
  • Возможность имперсонации под другого пользователя (с целью отладки).

NextCloud

Форк OwnCloud. Реализован на PHP/Javascript.

Возможности:


  • Хранение файлов с использованием обычных структур каталогов, или с использованием WebDAV.
  • Есть NextCloud Talk, через который возможно делать видеозвонки и видеоконференции.
  • Синхронизация между клиентами под управлением Windows (Windows XP, Vista, 7 и 8), Mac OS X (10.6 и новее) или Linux.
  • Синхронизация с мобильными устройствами.
  • Календарь (также как CalDAV).
  • Планировщик задач.
  • Адресная книга (также как CardDAV).
  • Потоковое мультимедиа (используется Ampache).
  • Поддерживает разные провайдеры авторизации: LDAP, OpenID, Shibboleth.
  • Двуфакторная авторизация.
  • Разделение контента между группами или используя публичные URL. Тонкая настройка правил.
  • Онлайн текстовый редактор с подсветкой синтаксиса и сворачиванием. Анонсирована поддержка онлайн-версий редакторов LibreOffice.
  • Закладки.
  • Механизм сокращения URL.
  • Фотогалерея.
  • Просмотрщик PDF (используется PDF.js)
  • Интеграция с Collabora и OnlyOffice.
  • Модуль логирования.
  • Возможность создания свои Web-сайтов (на PicoCMS).
  • Интеграция с Outlook и Thunderbird.
  • Интеграция клиента в Gnome.
  • Возможность использовать внешнее хранилище.
  • Полнотекстовый поиск.
  • Интеграция с антивирусом.

SparkleShare

Реализован на C#.

Возможности:


  • Версионирование.
  • Шифрование на клиенте.
  • Прозрачная синхронизация между несколькими пользователями: удалённые изменения появятся в локальном каталоге, выделенном для SparkleShare.

Особенности:


  • Использует git, как бэкэнд.

Seafile

Реализован на C/Javascript.

Возможности:


  • Файлы могут быть организованы в библиотеки, которые могут быть синхронизированы между устройствами.
  • Есть клиент, позволяющий создать локальный "диск", отображённый на облако.
  • Встроенное шифрование. Все файлы шифруются клиентом и хранятся в облаке зашифрованными.
  • Поддержка мобильных устройств.
  • HTTS/TLS шифрование.
  • Есть LDAP.
  • Тонкая настройка прав.
  • Версионирование файлов.
  • Возможность создания снимка каталога, к которому потом возможно вернуться.
  • Дедупликация.
  • Поддержка блокировки файлов.
  • Совместное редактирование файлов онлайн.
  • Антивирус.
  • Тонкая настройка прав.
  • Периодический бэкап через rsync.
  • WebDAV.
  • REST API.
  • Возможность интеграции с Collabora.

Особенности:


  • Быстрый и нетребовательный к ресурсам.
  • Считается надёжным.
  • Установка прав на подкаталоги поддерживается только в платной Pro версии.
  • Интеграция с антивирусом — только в Pro версии.
  • Аудит — только в Pro версии.
  • Полнотекстовый поиск — только в Pro версии.
  • Интеграция с S3 и Ceph — только в Pro версии.
  • Онлайн просмотр Doc/PPT/Excel — только в Pro версии.

Pydio

Реализован на PHP/Javascript.

Возможности:


  • Обмен файлами не только между пользователями, но и между несколькими экземплярами Pydio.
  • SSL/TLS шифрование.
  • WebDAV.
  • Возможность создать несколько рабочих пространств.
  • Обмен файлами с внешними пользователями, с тонкой настройкой обмена (например, прямые ссылки, пароль и т.п.).
  • Встроен офис Collabora.
  • Предосмотр и редактирование изображений.
  • Есть встроенный аудио и видео проигрыватель.

ProjectSend

Реализован на PHP/Javascript.

Возможности:


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

SpiderOak

Возможности:


  • Экономия места в хранилище и времени выгрузки файлов за счёт дедупликации и внесения изменений в уже имеющиеся файлы (вместо перезаписи файлов целиком).
  • Настраиваемая мультиплатформенная синхронизация.
    DropBox для синхронизации создаёт специальную папку, в которую надо помещать все синхронизируемые файлы. SpiderOak может работать с любым каталогом.
  • Сохранение всех хронологических версий файлов и удаленных файлов
  • Совместное использование папок при помощи так называемых ShareRooms, на которые устанавливается пароль.
    Файлы, обновлённые на локальном компьютере, автоматически обновляются в хранилище. Пользователи извещаются об изменениях по RSS.
  • Получение файлов с любого подключенного к Интернету устройства.
  • Полное шифрование данных по принципу «нулевого знания».
  • Поддержка неограниченного количества устройств.
  • Шифрование данных на стороне клиента.
  • Двуфакторная аутентификация.

Особенности:

Закрытая проприетарная система.

С учётом того, что данное ПО платное и частично закрытое, его использование исключается.


Установка NextCloud

Изначально было желание использовать Seafile: серверная часть реализована на C, он эффективен и стабилен. Но выяснилось, что в бесплатной версии есть далеко не всё.

Потому, я попробовал Nextcloud и остался доволен. Он предоставляет больше возможностей и полностью бесплатен.

Посмотреть, как он работает в демо-режиме вы можете здесь.

Вот общие точки сопряжения между облачным хранилищем и системой:


  • /tank0/apps/cloud/nextcloud — хранилище облачного сервиса.
  • /tank0/apps/onlyoffice — данные офиса.
  • https://cloud.NAS.cloudns.cc — WEB интерфейс облачного сервиса.

Т.к. конфигурация NextCloud достаточно объёмна и состоит из нескольких файлов, я не буду приводить их здесь.

Всё, что нужно вы найдёте в репозитории на Github.

Там же доступна конфигурация для SeaFile.

Сначала установите и запустите NextCloud.

Для этого надо скопировать конфигурацию в каталог /tank0/docker/services/nextcloud и выполнить:

# docker-compose up -d

Будет собран новый образ на основе Nextcloud 13.0.7. Если вы хотите изменить версию базового образа, сделайте это в app/Dockerfile. Я использую версию 15, но стоит заметить, что в ней не работают многие плагины, такие как загрузчик ocDownloader и заметки, а также я ещё не восстановил работоспособность OnlyOffice.

Кардинальных отличий или сильного улучшения производительности я не заметил.

Ниже я считаю, что вы используете версию 13+.

Далее, зайдите в NextCloud и выбрав в меню справа вверху "Приложения", выполните установку необходимых плагинов.

Потребуются обязательно:


  • LDAP user and group backend — сопряжение с LDAP.
  • External Storage Support — поддержка внешних хранилищ. Нужна будет далее, с целью интеграции NextCloud и общих файлов, а также сопряжения с внешними облачными хранилищами. Про настройку внешних хранилищ я расскажу в другой статье.
  • ocDownloader — загрузчик файлов. Расширяет функциональность облака. Docker образ специально пересобран так, чтобы он работал.
  • ONLYOFFICE — интеграция с офисом. Без этого приложения, файлы документов не будут открываться в облаке.
  • End-to-End Encryption — сквозное шифрование на клиенте. Если облако используют несколько пользователей, плагин необходим, чтобы удобно обеспечить безопасность их файлов.

Желательные приложения:


  • Brute-force settings — защита от подбора учётных данных. NextCloud смотрит в Интернет, потому лучше установить.
  • Impersonate — позволяет администратору заходить под другими пользователями. Полезно для отладки и устранения проблем.
  • Talk — видеочат.
  • Calendar — говорит сам за себя, позволяет вести календари в облаке.
  • File Access Control — позволяет запрещать доступ к файлам и каталогам пользователям на основе тэгов и правил.
  • Checksum — позволяет вычислять и просматривать контрольные суммы файлов.
  • External sites — создаёт ссылки на произвольные сайты на панельке вверху.

Особенности контейнера:


  • Установлен загрузчик Aria2.
  • Установлен загрузчик Youtube-DL.
  • Установлены inotify-tools.
  • Увеличены лимиты памяти для PHP.
  • Web-сервер настроен под лучшую работу с LDAP.

Замечу, что если вы установите версию 13+, но потом решите обновиться на версию 15, это и многое другое вы сможете сделать с помощью утилиты occ.


LDAP

Настройка LDAP не тривиальна, потому я расскажу подробнее.

Зайдите в "Настройки->Интеграция с LDAP/AD".
Добавьте сервер 172.21.0.1 с портом 389.
Логин: cn=admin,dc=nas,dc=nas.
NextCloud может управлять пользователями в базе LDAP и для этого ему потребуется администратор.

Нажимайте кнопку "Проверить конфигурацию DN" и, если индикатор проверки зелёный, кнопку "Далее".

Каждый пользователь имеет атрибут inetOrgPerson и состоит в группе users_cloud.

Фильтр будет выглядеть так:

(&(|(objectclass=inetOrgPerson))(|(memberof=cn=users_cloud,ou=groups,dc=nas,dc=nas)))

Нажимайте "Проверить базу настроек и пересчитать пользователей", и если всё корректно, должно быть выведено количество пользователей. Нажимайте "Далее".

На следующей странице будет настроен фильтр пользователей, по которому NextCloud их будет искать.

Фильтр:

(&(objectclass=inetOrgPerson)(uid=%uid))

На этой странице надо ввести логин какого-либо пользователя и нажать "Проверить настройки".
Последний раз "Далее".

Тут нажмите "Дополнительно" и проверьте, что поле "База дерева групп" равно полю "База дерева пользователей" и имеет значение dc=nas,dc=nas.

Вернитесь в группы и установите в поле "Только эти классы объектов" галочку напротив groupOfUniqueNames.

Итоговый фильтр здесь такой:

(&(|(objectclass=groupOfUniqueNames)))

Поле "Только из этих групп" я не устанавливал, т.к. хочу увидеть в интерфейсе NextCloud всех пользователей, а те кто не входит в группу users_cloud, отсеиваются фильтром на предыдущем этапе.


OnlyOffice

OnlyOffice — это прекрасный кроссплатформенный офисный пакет, который поддерживает работу с документами MS Office. Он бесплатный и открытый, также как и LibreOffice и также способен работать, как сервер.

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

Также он из коробки интегрируется с NextCloud.

Кстати, есть и Desktop версия OnlyOffice, в том числе под Linux. В общем, намучавшись с тяжёлой и нестабильной Collabora (это LibreOffice), я выбрал OnlyOffice и пока вполне доволен.

Конфигурация OnlyOffice доступна на Github и ниже, под спойлером.

На Github есть конфигурация и для Collabora.


/tank0/docker/services/office/onlyoffice/docker-compose.yml
version: '2' # https://helpcenter.onlyoffice.com/ru/server/docker/document/docker-installation.aspx networks: onlyoffice: driver: 'bridge' docker0: external: name: docker0 services: onlyoffice-redis: container_name: onlyoffice-redis image: redis restart: always networks: - onlyoffice expose: - '6379' onlyoffice-rabbitmq: container_name: onlyoffice-rabbitmq image: rabbitmq restart: always networks: - onlyoffice expose: - '5672' onlyoffice-postgresql: container_name: onlyoffice-postgresql image: postgres environment: - POSTGRES_DB=onlyoffice - POSTGRES_USER=onlyoffice networks: - onlyoffice restart: always expose: - '5432' volumes: - /tank0/apps/onlyoffice/postgresql_data:/var/lib/postgresql onlyoffice-documentserver-data: container_name: onlyoffice-documentserver-data image: onlyoffice/documentserver:latest environment: - ONLYOFFICE_DATA_CONTAINER=true - POSTGRESQL_SERVER_HOST=onlyoffice-postgresql - POSTGRESQL_SERVER_PORT=5432 - POSTGRESQL_SERVER_DB_NAME=onlyoffice - POSTGRESQL_SERVER_USER=onlyoffice - RABBITMQ_SERVER_URL=amqp://guest:[email protected] - REDIS_SERVER_HOST=onlyoffice-redis - REDIS_SERVER_PORT=6379 stdin_open: true restart: always networks: - onlyoffice volumes: - /tank0/apps/onlyoffice/document-server-data/data:/var/www/onlyoffice/Data - /tank0/apps/onlyoffice/document-server-data/logs:/var/log/onlyoffice - /tank0/apps/onlyoffice/document-server-data/cache:/var/lib/onlyoffice/documentserver/App_Data/cache/files - /tank0/apps/onlyoffice/document-server-data/files:/var/www/onlyoffice/documentserver-example/public/files - /usr/share/fonts onlyoffice-documentserver: image: onlyoffice/documentserver:latest depends_on: - onlyoffice-postgresql - onlyoffice-redis - onlyoffice-rabbitmq - onlyoffice-documentserver-data environment: - ONLYOFFICE_DATA_CONTAINER_HOST=onlyoffice-documentserver-data - BALANCE=uri depth 3 - EXCLUDE_PORTS=443 - HTTP_CHECK=GET /healthcheck - EXTRA_SETTINGS=http-check expect string true - JWT_ENABLED=true - JWT_SECRET=<JWT_SECRET_TOKEN> # Uncomment the string below to redirect HTTP request to HTTPS request. #- FORCE_SSL=true - VIRTUAL_HOST=office.* - VIRTUAL_PORT=80 - VIRTUAL_PROTO=http - CERT_NAME=NAS.cloudns.cc stdin_open: true restart: always networks: - onlyoffice - docker0 expose: - '80' volumes: - /tank0/apps/onlyoffice/document-server/logs:/var/log/onlyoffice - /tank0/apps/onlyoffice/document-server/data:/var/www/onlyoffice/Data - /tank0/apps/onlyoffice/document-server/lib:/var/lib/onlyoffice - /tank0/apps/onlyoffice/document-server/db:/var/lib/postgresql volumes_from: - onlyoffice-documentserver-data

Поясню некоторые моменты:


  • Вам надо изменить <JWT_SECRET_TOKEN> на свой, также как и NAS на имя своей DNS зоны.
  • HTTPS здесь не требуется включать, потому что хотя офис и виден снаружи, обмен с ним идёт через обратный прокси, который работает с пользователем исключительно по HTTPS. Так построена архитектура NAS.

Теперь надо поднять офис:

docker-compose up -d

И, если всё работает, по адресу office.NAS.cloudns.cc будет следующая страница:

Затем, в настройках NextCloud требуется выбрать Пункт "Администрирование->ONLYOFFICE" и прописать в первых двух полях адрес сервера документов: https://office.NAS.cloudns.cc/ и ваш JWT token.

В третьем поле надо прописать адрес облака.

JWT токен возможно сгенерировать, например здесь.

Если сервер настроен правильно, в меню создания документов облака появятся дополнительные пункты для офисных документов, а .docx файлы будут открывать в офисе.


Выводы

Облачное хранилище является центральным звеном для взаимодействия пользователей между собой и другими сервисами.

В этой роли NextCloud весьма удобен и обладает широким функционалом.

У него есть свои в процессе обновления между версиями, но в целом, это хранилище возможно рекомендовать.

habr.com

Как создать собственное облако, где можно бесплатно хранить любой объём данных

Мы все пользуемся облачными хранилищами, а некоторые из нас даже платят абонентскую плату за возможность хранить файлы сверх выделенного лимита. Это удобно — при наличии интернета нам в любой момент доступны все файлы, которые мы скопировали в облако. Но у таких сервисов есть и недостатки: их могут взломать хакеры, файлы могут попасть к посторонним, а если владельцев облака не устроит контент, который вы храните у них, ваш аккаунт могут заблокировать, и тогда все файлы пропадут. Создание собственного облака — отличное решение, хотя и у него есть свои недостатки.

Премущества персонального облака:

— Нет лимитов. Вы можете хранить столько файлов, сколько вмещается на накопители в вашем компьютере.
— Никаких платежей, всё бесплатно (кроме электроэнергии).
— Полная приватность. Файлы копируются с компьютера на другие устройства без использования стороннего сервера.
— Возможность делиться неограниченным количеством папок и файлов с другими пользователями.
— Управление уровнями доступа к файлам и папкам.

Недостатки персонального облака:

— Придётся держать компьютер постоянно включённым, иначе удалённый доступ к файлам пропадёт.
— Не получится прикрутить ваше облако к большей части приложений, которые работают с популярными хранилищами.
— Риск лишиться файлов из-за сбоя в компьютере.

Как создать своё облако:


1. Зайдите на сайт Tonido и создайте учётную запись.

2. Скачайте программу Tonido Server. Установите её, запустите и разрешите ей доступ к сети (если выскочит диалоговое окно брандмауэра). Эта программа создаёт из компьютера сервер, благодаря чему доступ к хранящимся на нём файлам может осуществляться из любой точки мира через интернет.

3. Значок Tonido Server висит в панели уведомлений. По нажатию на нему в браузере открывается локальный адрес http://127.0.0.1:10001 с интерфейсом сервиса, где можно указать, какие папки будут добавлены в облако.

4. Скачайте мобильное или десктопное приложение Tonido. Запустите его и зайдите в свою учётную запись. Если вы увидите в приложении файлы, которые хранятся на компьютере, значит облако готово и им можно пользоваться. Теперь у вас всегда будут при себе все нужные вам файлы.

Приложение может открывать некоторые типы файлов, в том числе видео, музыку и тексты. Любой файл можно скачать на устройство или отправить другу (по электронной почте или с прямым доступом по ссылке в сервисе Tonido).

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

www.iguides.ru

Бюджетное облачное хранилище на облачном хостинге за полчаса / Habr

Здравствуйте!

Я работаю в компании, оказывающей услуги для бизнеса.
Часто бывает, что нужно принять от заказчика или передать ему файл большого размера.
Наши менеджеры не сильно искушены технически, поэтому обычно они пытаются вложить в сообщения электронной почты абсолютно всё. С файлами размером более 10-15 МБ это, разумеется, не проходит.

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

Итак, вопрос: как передавать больше файлы на расстоянии?

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

В случае с веб-системами все более-менее просто, тут и говорить не о чем. Общение с ftp-сервером для некоторых заказчиков (которые технически еще менее продвинуты, чем наши сотрудники) превращается в непроходимый квест.

Чаще всего затруднения связаны с попытками работать с ftp-сервером через браузер:

  • не получается зайти на сервер
  • не получается загрузить файл на маленькой скорости (ошибка тайм-аута случается быстрее, чем завершается загрузка)
  • не получается отправить (upload) файл

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

Поэтому у нас назрела потребность в каком-то средстве передачи файлов, удовлетворяющем следующим условиям:

  1. Чтобы работало в браузере и не требовало обязательной установки клиентских программ.
  2. Чтобы было просто в использовании (щелкнул ссылку в письме, по ней начал загружаться файл или открылась страница, с которой можно загрузить файл из хранилища или отправить в хранилище).
  3. Чтобы было бюджетно (по этой причине не подошли корпоративный Dropbox и Google Apps for Business).
  4. Чтобы было конфиденциально (хранение данных на своем или арендованном сервере).

Я регулярно читаю ленту лучших постов на хабре, интересуюсь облачными хранилищами и хостингами, поэтому у меня сходу возник сценарий "OwnCloud на VPS Digital Ocean". Про OwnCloud на хабре написано много, про Digital Ocean я тоже узнал на хабре и решил при первом удобном случае опробовать его в деле.

Заодно решил в очередной раз проверить, насколько я совместим с Linux. До этого несколько раз устанавливал из любопытства Ubuntu, Linux Mint и т.п. с GUI, но сразу или почти сразу сталкивался с проблемами, которые были несовместимы с дальнейшей регулярной эксплуатацией ОС и которые не удавалось решить за разумное время.

1. Регистрация на Digital Ocean заняла минут 10. За это время я, собственно, зарегистрировался, нашел в гугле купон на $10, добавил своих $5 через PayPal, создал самый дешевый виртуальный сервер (Droplet) на Ubuntu 12.04 и добавил его адрес в DNS.

2. Минут 20 заняла установка OwnCloud через SSH по инструкции от Digital Ocean. Весь путь прошел два раза, т.к. в первый раз установил OwnCloud на Ubuntu + LAMP stack, после чего затупил и искал OwnCloud в корне веб-сервера. Разумеется, не нашел и решил, что что-то там не сложилось с Apache. Переустановил еще раз, заметил, что к URL сервера нужно добавить папку /OwnCloud/, и уж по этому-то адресу все открылось.

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

4. Потом до кучи установил wsftpd, чтобы можно было использовать этот же сервер в качестве FTP, после чего освоил SSH и редактор vi, когда подкручивал конфиг wsftpd. Вспомнил времена MS-DOS, BBS, FIDO и текстовых конфигов ;-)

5. По тестам для меня (в Мск) самым быстрым по скорости отправки/загрузки файлов оказался их дата-центр в Амстердаме (от 3 до 6 МБит/c), но там у них нет свободных мощностей и создать новую виртуальную машину нельзя. А вторым по скорости (от 1 до 4 МБит/c) оказался New York 2 — его они предлагают использовать по умолчанию, так что сервер был создан там. Там же я решил его и оставить. Хотя в принципе есть интересная возможность остановить машину, отправить ее образ в облако и запустить в другом дата-центре Digital Ocean, но пока смысла менять ДЦ я не вижу.

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

Я знаю, что на хабр пишут в основном очень технически продвинутые люди, и при прочтении некоторых постов я иcкренне восхищаюсь умственными и креативными (от слова «создавать») способностями этих людей.

Вместе с тем мне очень приятно, когда что-то вот такое вроде бы сложное (для меня) по факту оказывается достижимым. Поэтому цель данного поста — подтвердить, что мир Linux и Open Source становится определенно доступнее для неподготовленных людей.

Спасибо!

habr.com

Как сделать домашнее облако для хранения фото и других данных

Облако — место для хранения данных в Интернете с доступом к ним с любого устройства в любой точке мира. Но перед тем, как создать облачное хранилище, следует убедиться, что при синхронизации сервис не удалит данные после их ликвидации с компьютера.

Достоинства и недостатки

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

Таким образом, облачное хранилище удобно и обеспечивает большую гибкость.

Но как сделать так, чтобы такое хранение было надежным и безопасным?

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

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

Популярные облачные хранилища

Число провайдеров услуг хранения данных в сети постоянно растет, как и объем доступного виртуального дискового пространства:

  • Google Docs позволяют загружать документы, электронные таблицы и презентации на серверы Google. Пользователи могут редактировать файлы и публиковать их, чтобы другие могли их читать и тоже редактировать.
  • Поставщики услуг электронной почты, такие как Gmail, Hotmail и Yahoo, хранят данные на своих серверах. Клиенты могут получать доступ к своей учетной записи с компьютеров и других устройств, подключенных к Интернету.
  • Flickr и Picasa размещают у себя миллионы цифровых фотографий. Пользователи создают онлайн-фотоальбомы, загружая изображения непосредственно на их серверы.
  • YouTube хранит огромное количество видео.
  • Веб-хостинговые компании, такие как StartLogic, Hostmonster и GoDaddy, сберегают файлы и данные клиентских веб-сайтов.
  • Социальные сети, такие как Facebook и MySpace, позволяют участникам публиковать снимки и другой контент. Все это хранится на серверах соответствующего сайта.
  • Сервисы, подобные Xdrive, MediaMax и Strongspace, предлагают пространство для хранения любых цифровых данных.

Облако для дома своими руками

Облачное хранилище своими руками можно организовать, используя клиент-серверное ПО (либо с открытым исходным кодом, либо запатентованное), которое позволяет настраивать и поддерживать свою собственную файловую сеть. Ее можно настроить на физическом сервере, который придется поддерживать самостоятельно, или на виртуальном (например, Digital Ocean), если роль системного администратора не по плечу.

Клиентское программное обеспечение обычно работает так же, как и Dropbox или Sync.com. Это означает, что на жестком диске установлена ​​папка синхронизации. Любые папки или файлы, находящиеся в ней, будут отправлены в облачное хранилище, а затем на любые другие устройства с установленными клиентами. Nextcloud, например, предоставляет три корпоративных плана, способных обслуживать от 10 до 50 млн пользователей. Желающим просто запустить облачное хранилище для дома платить ничего не нужно.

Прежде всего, нужно скачать и установить два приложения. Nextcloud Server предназначен для установки на домашнем сервере пользователя или на общем веб-сервере. Можно приобрести и предварительно сконфигурированное оборудование, такое как Spreedbox, Syncloud и Nextcloud Box.

Кроме того, требуется установка клиента синхронизации. Есть версии для компьютеров под управлением Windows, MacOS и Linux, а также для мобильных устройств на «Андроид» и iOS. Кроме того, файлы можно просматривать из любого совместимого браузера.

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

Nextcloud также включает набор полезных приложений. К ним относятся программы для ведения видеоконференций, организации рабочего процесса, текстового поиска и конверсии.

Вариант 1 Хранение данных с телефона

Для этого необходимо:

  • Скачать и установить клиент Nextcloud из магазина приложений Google.
  • Установить соединение, введя сетевой адрес сервера, логин и пароль. Пользователю откроется страница Files его учетной записи.
  • Нажать синюю кнопку в правом нижнем углу, чтобы открыть пункты меню «Загрузить», «Контент из других приложений» и «Новая папка». При этом первая опция добавляет файлы из Android в учетную запись Nextcloud, а вторая позволяет, например, загрузить фото из «Галереи».

Также возможен доступ к облачному хранилищу через веб-интерфейс. Он открывается после соединения с сервером и ввода логина и пароля. Загрузить файлы с телефона можно, выбрав опцию «+» в строке навигации.

Вариант 2 Хранение файлов с компьютера

Клиент синхронизации рабочего стола Nextcloud работает в фоновом режиме и виден как иконка на панели задач (Windows), статусной строке (MacOS) или области уведомлений (Linux). Ее вид говорит о статусе синхронизации. Щелчок правой клавишей мыши по ней открывает контекстное меню с опциями быстрого доступа к учетным записям и выхода из них, списку последних действий, установкам, помощи. Левой кнопкой открывается окно параметров учетной записи.

Клиент интегрируется с файловым менеджером: Finder на macOS, Explorer в Windows и Nautilus на Linux.

Можно создавать ссылки для общего доступа и делиться данными из компьютера с пользователями Nextcloud.

Для этого необходимо:

  • Щелкнув правой кнопкой мыши по значку клиента, навести указатель на учетную запись и выбрать опцию «Открыть папку».
  • Ввести имя локального каталога Nextcloud.
  • Кликнуть правой клавишей по файлу или папке, которой необходимо открыть доступ, и в контекстном меню выбрать «Поделиться в Nextcloud».
  • Отметить авторизованных пользователей, установить пароль и дату истечения срока доступа.

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

Собственное облачное хранилище позволит избежать сканирования данных или метаданных посторонними.

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

xn----7sbaruhf3cgg7c6c.xn--p1ai

Организация хранения личных файлов локально и в облаках / Habr

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

  1. Единую структуру папок для хранения и «обозрения» всех файлов.
  2. Способ реализации такой единой структуры с использованием преимуществ всех облачных хранилищ.


Дано

  1. Со временем мы накапливаем все больший объем информации (большая часть которого по-прежнему хранится в файлах). Эти файлы требуют организованного хранения и управления.
  2. Сейчас широко распространено не менее 5 основных облачных хранилищ (причем каждое обладает своими преимуществами):
    — Google Drive — интеграция со всеми сервисами Google, распространено среди коллег (людей, с которыми часто приходится обмениваться информацией), удобный облачный офис;
    — DropBox — распространено среди коллег;
    — SkyDrive — распространено среди коллег, удобный облачный офис для работы с документами MS Office;
    — Яндекс.Диск — (UPD) подарили навсегда 200 Гб за ошибку в одной из версий десктопного клиента, подарили 2 Гб на 2014 год;
    — Облако.Mail.ru — подарили 1 Тб навсегда.
  3. Файлы единой организованной структуры не могут быть размещены в одном облаке под двум причинам:
    — бесплатные объемы недостаточны, и чем больше бесплатный объем тем беднее функционал и качество работы сервиса,
    — предпочтения коллег также накладывают серьезные ограничения (по одному проекту могут быть одновременно файлы совместно редактируемые на Google Drive и SkyDrive, общие папки на DropBox).
  4. Операционные системы
    — десктоп: Windows 8.1,
    — смартфон и планшет: Android 4.4.
  5. Имею несколько мест работы, готовлюсь к поступлению в аспирантуру, файловый архив “коплю” уже около 15 лет, то есть информации, с которой приходится работать, достаточно много.
  6. Это вопрос, который так или иначе вынуждены решать для себя все, и все явно чувствуют несовершенство получаемых решений. В большой степени статья вдохновлена нижеследующими тщетными поисками:
    — habrahabr.ru/post/68092
    — habrahabr.ru/post/90326
  7. Сложность, трудоемкость, необходимость высокой квалификации не приветствуются.
Вариант решения

Файловая структура

Мне кажется, для организации хранения файлов уместна следующая классификация данных (файлов).
  1. Хранить вечно, доступ в будущем не предполагается. Эта категория данных, которую я называю “архивом”. Туда попадают документы “для истории”, которые в обозримом будущем нужны не будут, но когда-нибудь будут представлять “историческую ценность”.
  2. Хранить вечно, доступ в будущем очень вероятен. Это данные, относящиеся к категории постоянного (перманентного) хранения, доступ к таким данным периодически необходим. Это могут быть книги, музыка, дистрибутивы, сканы личных документов (паспорт, ИНН, прочее) и что угодно еще.
  3. Срок хранения не определен, доступ в будущем необходим. Это категория файлов проектов и “входящих” (в терминах GTD). Файлы разделены по папкам, каждая из которых соответствует одному проекту (в терминах GTD), и конечно отдельная папка для “входящих”.

Такое разделение данных позволяет четко понимать, что необходимо “старательно” бэкапить и что, в случае отсутствия потерь данных, будет доступно мне в любой момент в будущем.

Также важно, чтобы данное разделение данных было реализовано на одном уровне папок (без вложений), зачем это нужно — будет понятно из следующего раздела.

Структура каталогов, к которой я пришел, выглядит так (назовем ее базовой структурой каталогов):

\ |-archive (архив) |-permanent_books (доступ в будущем будет нужен) |-permanent_music |-permanent_pics |-permanent_scans |-permanent_soft |-permanent_video |-project_pr1 (файлы проекта) |-project_pr2 |-project_pr3 |-project_pr4 |-project_pr5 |-project_pr6 |-temp (“входящие”) 
Использование облачных хранилищ

Для унификации структуры хранения данных в каждом из облаков следует создать базовую структуру каталогов (если на данном облаке, например, файлы по проекту Х не хранятся, папку проекта можно не создавать, то же относится к архивам и данным постоянного хранения). После этого становится легко понятным — где именно в том или ином облаке сохранять данные, например, по тому или иному проекту.

Для удобства представления данных на компьютере базовую структуру каталогов (не обязательно полностью, по необходимости) предлагается реализовать на уровне библиотек Windows (про библиотеки можно почитать здесь: www.outsidethebox.ms/15096). Именно для этого базовая структура папок должна быть одноуровневой. Библиотеки отображают файлы, расположенные в нескольких папках на диске, и позволяют удобно управлять ими. Кроме того полезно создать библиотеку “Облака”, отображающую содержимое корневых папок всех используемых облачных хранилищ (в этой библиотеке будет несколько папок с одним именем — по одной из каждого облачного хранилища).

Удобны два представления библиотеки:

  • “Общие элементы”. Все содержимое папок библиотеки выводится в единой таблице, без группировки по папке библиотеки (в нашем случае по облачному хранилищу).
  • “Видео”. Содержимое библиотеки разбито по папкам библиотеки (облачным хранилищам), и представлено в виде крупных значков.

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

Библиотеки как инструмент крайне просты и удобны для централизованного управления облачными хранилищами и переброски файлов из одного облака в другое буквально в один клик.

Кстати, не все файлы нужно хранить на диске (объем доступного пространства в облачных хранилищах как правило больше объема физического диска). Например, папки “permanent_video” и “permanent_music” я вообще не синхронизирую с компьютером, а обмен с этими папками осуществляю через папку “temp” соответствующего облачного хранилища. Посмотрев какое-то видео, если я хочу сохранить его в облаке, я перемещаю его в папку “temp”, а затем через веб-интерфейс облака перемещаю файл в папку “permanent_video” — файл удаляется с диска компьютера, но сохраняется в облаке.

И еще одна небольшая “фишка”. Расположение папки “Рабочий стол” я перенастроил на папку “temp” в моем основном облаке (Google Drive), в эту же папку по умолчанию сохраняются все файлы, скачиваемые через браузер и торрент-клиент. Таким образом все новые файлы автоматически оказываются в одном единственном месте и сразу же попадают в облако.

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

habr.com

Выбор оборудования для корпоративного облачного хранилища

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

Конечно, можно и нужно обеспечивать сохранность и доступность информации правильным выбором серверного ПО и грамотной конфигурацией. Но не менее важно и железо — оборудование, которое хранит и обрабатывает данные. Если оно не соответствует потребностям компании, то никакой софт не сделает его достаточно надежным и отказоустойчивым.

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

Почему облако?


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

Почему своё?


Сейчас на рынке есть множество публичных облачных сервисов. Для многих малых и средних компаний они действительно становятся хорошим выбором, особенно если речь идет об услугах с оплатой только за использованные ресурсы либо проведении тестирования сервиса. Однако свое облачное хранилище также дает ряд преимуществ. Оно придется очень кстати, если:
  • Деятельность компании налагает ограничения на местоположение серверов. Российские гос. учреждения, а также организации, занимающиеся обработкой персональных данных, по закону обязаны хранить всю свою информацию на территории РФ. Соответственно, арендовать заграничные серверы для них не представляется возможным, да и в целом очень нежелательно доверять деликатную информацию подрядчикам. Создание частного хранилища поможет использовать все преимущества облака без нарушения правовых норм.
  • Необходимо полное управление политиками безопасности. Как устроена защита данных в сервисах Microsoft или Amazon, точно узнать невозможно. Полностью обезопасить информацию так, как вы считаете это необходимым, можно только в собственном облаке.
  • Настройка оборудования под себя. При аренде приходится работать с тем, что дает поставщик. Однако имея в распоряжении собственные серверы, можно сконфигурировать их на под решение конкретных задач именно для вашего бизнеса, а также использовать то ПО, которым в совершенстве владеет ваша IT-команда.

Выбор оборудования


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

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

Четко определить цель, для которой будет использоваться сервер. В нашем случае — это файловое хранилище. Соответственно, наибольший интерес представляют накопители. На что следует обратить внимание при их выборе:

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

В среднем для работы с текстовыми файлами, презентациями, PDF и небольшим количеством изображений нужно в среднем 10-15 Гб на сотрудника. Для работы с большими объемами высококачественных картинок и фотографий нужно увеличить минимум до 50-100 Гб, а то и больше. Потребности персонала, занимающегося обработкой видео и аудио, могут достигать нескольких терабайт на человека. В ряде случаев, например, при использовании крупных корпоративных программных пакетов с поддержкой версионности проектов, речь может идти и о 10 терабайтах на одного пользователя облака. Не забудьте учесть емкость под резервные копии файлов и непредвиденные нужды компании.

Что касается RAID-контроллеров, то для корпоративного облака лучше не использовать набортные решения. Их производительности может оказаться недостаточно для обслуживания большого количества запросов с удовлетворительной скоростью. Так что лучше выбрать дискретные модели из нижнего и среднего ценовых диапазонов.

Также необходимо определиться с вычислительной мощностью. Если вы создаёте облачное хранилище на базе нескольких серверов, то рекомендуется подбирать идентичные или очень близкие конфигурации. Это несколько упростит управление распределением нагрузки. И вообще лучше не делать ставку на одну мощную машину, комплектуя её дорогим процессором и оперативной памятью, а купить подешевле 2-3 машины. Почему?

Если ваше хранилище будет только принимать и отдавать статичные файлы, без возможности их запуска, то мощность процессора не слишком важна. Поэтому лучше не гнаться за количеством ядер и выбрать модель с хорошим «тактом». Из недорогих вариантов неплохо подойдут процессоры Intel Xeon серии E56XX с 4 ядрами, из более дорогих моделей можно порекомендовать машины на Intel Core i5.

Примеры моделей серверов


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

Dell PowerEdge T110. Сервер оснащен процессором Intel Core i3 2120 с всего двумя ядрами, но зато каждое из них обладает неплохой тактовой частотой в 3,3 ГГц, что для нашего облака важнее. Начальная конфигурация оперативной памяти не очень велика — 4 Гб, однако может быть расширена до 32 Гб. Сервер поставляется в двух комплектациях — без предустановленного жесткого диска или с HDD-накопителем емкостью в 1 Тб и интерфейсом SATA.

Lenovo ThinkServer RS140. Имеет мощный процессор Intel Xeon E3 с четырьмя ядрами по 3,3 Ггц каждое. Оперативная память «из коробки» — 4 Гб, плюс еще четыре слота для ее расширения. Также в комплект входят два жестких диска по 1 Тб с SATA-интерфейсом.

HP ProLiant ML10 Gen9. Во многом схож с описанной выше моделью — всё тот же Intel Xeon E3 и два терабайтовых HDD. Основное отличие в оперативной памяти — сервер HP имеет две пластины по 4 Гб каждая.

Достаточно ли места для хранения файлов?


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

В случае виртуализации хранилища вы практически всегда (при разумном подходе к планированию СХД) сможете расширить дисковую подсистему виртуальной машины или увеличить LUN. В случае физического файлового сервера и локальных дисков, ваши возможности будут значительно скромнее. Даже не смотря на наличие свободных слотов в сервере для дополнительных дисков, можно столкнуться с проблемой подбора накопителей, подходящих для вашего RAID-массива.

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

Дисковые квоты NTFS

Один из самых старых и надежных механизмов ограничения пользователей — квоты файловой системы.

Включив квоты для тома, вы можете ограничивать объем файлов, сохраняемых каждым пользователем. В квоту пользователя попадают файлы, для которых на уровне NTFS он является владельцем. Главным недостатком механизма является то, что, во-первых, не так просто определить, какие файлы принадлежат конкретному пользователю, а во-вторых, файлы, созданные администраторами, не будут включены в квоту. Механизм квот редко используется на практике, его практически полностью заместил File Server Resource Manager, впервые появившийся в Windows Server 2003 R2.

File Server Resource Manager

Этот компонент Windows Server позволит квотировать дисковое пространство на уровне конкретной папки. Если вы выделяете для сотрудников персональные домашние каталоги на файловых серверах, а также выделенные папки для общих документов отделов, то FSRM — наилучший выбор.

Конечно, квотирование само по себе не увеличит объем файлового хранилища. Но пользователи, как правило, лояльно относятся к справедливому (равному) делению ресурсов, а в случае нехватки готовы преодолеть небольшие бюрократические процедуры для расширения дискового пространства.

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

Кроме того, FSRM включает в себя механизм «скрининга» (фильтрации) файлов, которые можно сохранять на сервере. Если вы уверены в том, что mp3- и avi- файлам не место на файловом сервере, то можно запретить их сохранения средствами FSRM.

Компрессия NTFS

Обычные файлы хорошо поддаются сжатию средствами NTFS, а с учетом производительности современных процессоров, у сервера достаточно ресурсов на эту операцию. Если места не хватает — можно смело включать её для тома или отдельных папок. К примеру, в Windows Server 2012 появился более совершенный механизм, при использовании которого NTFS-сжатие на файловых серверах для большинства сценариев остается в прошлом.

Дедупликация

Windows Server 2012 включает в себя возможность дедупликации данных, расположенных в томе NTFS. Это достаточно продвинутый и гибкий механизм, сочетающий в себе как дедупликацию с переменной длинной блока, так и эффективную компрессию сохраняемых блоков. При этом для разных типов данных механизм может использовать разные алгоритмы сжатия, а если сжатие не эффективно — не использовать её. Такие тонкости недоступны традиционному сжатию средствами NTFS.

Кроме того, дедупликация не оптимизирует файлы, с которыми пользователи работали последние 30 дней (этот интервал можно настроить) для того, чтобы не снижать скорость работы с динамично изменяемыми данными.

Оценить потенциальную прибавку свободного места можно утилитой ddpeval. На типичном файловом сервере экономия составляет 30-50%.

Производительность файлового сервера

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

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

Если посмотреть на статистику Perfmon, средняя скорость чтения/записи для 150-200 пользователей достаточно низка и составляет всего лишь несколько мегабайт в секунду. Более интересны пиковые значения. Но следует иметь в виду, что и эти пики ограничены скоростью сетевого интерфейса, а для обычного сервера это 1 Гбит/с (т.е. 100 Мб обмена с дисковой подсистемой).

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

Для 150-200 сотрудников показатели достаточно скромны — 10-20 операций ввода вывода в секунду с дисковой очередью в пределах 1-2.

Этим требованиям удовлетворит любой массив из стандартных SATA дисков.

Для 500-1000 активных пользователей количетсво операции подскакивает до 250-300, а дисковая очередь достигает 5-10. Когда очередь достигает этой величины, пользователи могу заметить, что файловый сервер «подтормаживает».

На практике для достижения производительности в 300 IOPS вам уже потребуется массив как минимум из 3-4 дисков типичных SATA-дисков.

При этом следует учесть не только «сырую производительность», но и задержку, вносимую работой RAID-контроллера — так называемую RAID penalty. Эта тема доступно разъяснена в статье https://habrahabr.ru/post/164325/.

Для определения необходимого количества дисков используем формулу:

Total number of Disks required = ((Total Read IOPS + (Total Write IOPS*RAID Penalty))/Disk Speed IOPS)

RAID-5 с penalty на запись в 4 операции, профилем чтение 50%, запись 50%, скоростью диска в 75 IOPS, целевая производительность в 300 IOPS:
(300*0,5 + (300*0,5*4))/75 = 10 дисков.

Если у вас много активных пользователей, то вам потребуется ёмкий сервер или более производительные диски, такие как SAS со скоростью вращения 10 000 RPM.

Скорость сетевого интерфейса
Низкая скорость сетевого интерфейса — одна из причин задержек при работе с файловым сервером. В 2016 году сервер с 100 Мбит/с сетевой картой — нонсенс.

Типичный сервер оборудован сетевой картой со скоростью 1 Гбит/с, но и это ограничивает дисковый обмен скоростью около 100 Мб/с. Если в сервере несколько сетевых карт, то вы можете объединить их (агрегировать) в один логический интерфейс для увеличения как производительности, так и доступности облака. Хорошая новость в том, что для файлового сервера («много клиентов обращаются к одному серверу») агрегация работает хорошо.

Владельцы серверов HP могут использовать фирменную утилиту HP Network Configuration Utility

Если вы используете Windows Server 2012, то более простым и надежным способом будет использование штатного средства NIC Teaming.

Подробнее об этой настройке и нюансах использования ее в среде Hyper-V вы можете узнать из этой статьи.

habr.com

Большое файловое хранилище для маленькой такой компании / Habr

Думаю, что любая группа разработчиков рано или поздно сталкивается с такой, казалось бы, примитивной задачей как
  • вики, учет задач, тикетов, дефектов;
  • система управления версиями/репозиторий;
  • файловый сервер.


И если в случае первого и второго предлагается множество прекрасных средств, в частности для багтрекинга существуют известные каждому Redmine, Trac, а для управления версиями Subversion, Git, Mercurial, то для грамотной организации файлового хранилища приходится в очередной раз изобретать велосипед.
Что требуется?

Что я понимаю под файловым сервером? Хороший вопрос. В идеале это должна быть система по типу каталога, способная хранить большие объемы двоичных файлов (pdf, doc, xls, msi, avi и др.), позволяющая тегировать файлы для гибкого поиска по хранилищу, автоматически индексировать их содержимое и метаданные, производить поиск по множеству критериев, предоставлять доступ к файлам как локально, так и через браузер (web-интерфейс), совместно редактировать файлы, иметь клиенты для разных ОС, синхронизирующие версии с сервера, но что-то я замечтался… Конечно, же, такой системы не существует. Сейчас, наверное, многие возразят мне и укажут на Microsoft SharePoint Server, однако для небольшой компании этот продукт неподъемен ввиду сложности в обслуживании и астрономической цены.

Такие варианты как Dropbox, SkyDrive и другие сразу же отбрасываются, так как руководство не хочет распространять проекты компании неизвестно куда, опять же есть ограничения на скорость доступа (в случае файлового сервера в локальной сети большинство запросов поступает по высокоскоростным соединениям и лишь часть — через веб-интерфейс), а также на размер хранимых данных.

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

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

OwnCloud


Недавно вышла новая версия (4.5) системы для организации хранения, синхронизации и обмена данными OwnCloud. Ранее на Хабрахабре уже появлялась замечательная статья об OwnCloud, которая и мотивировала меня познакомиться с облаком поближе.
Об особенностях процесса установки OwnCloud хабраюзером BlackIce13 была написана прекрасная статья Опыт установки ownCloud 6 на Debian 7 wheezy.
Первое впечатление было просто волшебным: современный web-интерфейс, возможность онлайн просмотра (txt, PDF, ODF) и редактирования (txt) файлов, календарь, задачи, адресная книга, синхронизация по протоколу WebDAV, поиск по содержимому, а что самое главное — возможность монтирования локальных папок и внешних хранилищ по протоколам FTP, Samba, и др. Однако после более плотного знакомства обнаружилось огромное количество багов и глюков, как достаточно безобидных и даже забавных, так полное и безвозвратное падение системы. С OwnCloud врагам не нужно применять хитрые DDoS-атаки ибо эта функция изначально заложена разработчиками в ядро системы.
Больше всего интересовала функция монтирования удаленной файловой системы через Samba. То есть в локальной сети выделялся web-сервер с системой управления проектами и OwnCloud, а также простой Windows-файловый сервер, с которого web-интерфейс и подтягивал бы данные для удаленного доступа. Однако монтирование через Samba не захотело функционировать ни при каких условиях, несмотря на официально заявленную функциональность и примеры на сайте OwnCloud. Была произведена попытка обмануть OwnCloud и подсунуть её «локальную» папку с примонтированной Samba-шарой, но это вгоняло OwnCloud в неадекватное состояние.
Вообще, средство достаточно неплохое для домашнего использования, или если Вам достаточно пространства жесткого диска сервера на всю компанию. Стоит отметить развитое сообщество разработчиков OwnCloud, в котором Вам всегда подскажут как бороться с очередным фэйлом. Добавьте ссылку на их багтрекер себе в избранное, так как вам часто придется общаться с этими ребятами.
iFolder


Разрабатываемое компанией Novell, средство iFolderтакже предоставляет так необходимые нам возможности — распределение на несколько серверов, синхронизация между клиентами, веб-интерфейс к хранилищу.
Горьким фактом является то, что iFolder со стороны Linux поддерживает openSUSE, для которого процесс установки состоит из одной команды.
Для других дистрибутивов Linux установка iFolder — это практически невыполнимая задача несмотря на множество мануалов, например iFolderInstall. Мне, к сожалению, не удалось установить iFolder ввиду специфичных версий пакетов, которые требуются для работы системы и которые уже давно не доступны на сайте iFolder Novell. Возможно, читатели Хабра более удачливые и продвинутые и у них получится найти общий язык с iFolder.
Помимо iFolder на том же сайте компания Novell предлагает еще два проекта для совместной работы (Kablink Teaming) и для обмена сообщениями (Kablink Conferencing), впрочем они были мне не так интересны, поэтому оставляю знакомство с ними вам на десерт.
SparkleShare


Достаточно интересное средство, написанное согласно приданию некими хакерами, которым надоело синхронизировать свои файлы. Оно основано на системе управления версиями git и по сути является надстройкой. Для файлового сервера создается отдельный репозиторий и затем над ним навешивается SparkleShare. Клиенты, работая с файлами, синхронизируют их между собой и сервером по аналогии клиента для Dropbox. Кроме официального сайта, есть неплохая инструкция по установке и работе с SparkleShare. «Благодаря» фундаменту в виде git возникают и недостатки, свойственные системам такого класса: клиенты хранят полную локальную копию репозитория, что в случае больших объемов просто невозможно. Существует способ «ленивого» доступа к репозиторию посредством git-fs, но только в режиме чтения. Опять же для непрограммистов (экономисты, отдел кадров), это слишком высокотехнологичное решение и они скорее будут пересылать друг другу документацию бесконечными e-mail, чем воспользуются git. Опять же ненависть репозиториев к бинарным файлам окончательно исключает SparkleShare из списка возможных решений.
Syncany


Казалось бы вот она, мечта: облачное файловое хранилище с поддержкой FTP, IMAP, WebDAV, Windows NetBIOS/CIFS, SFTP/SSH, шифрованием данных и т.п. Но проект находится в разработке вот уже два года и официальных релизов системы не поступало. Авторы приветливо предлагают вступить в ряды разработчиков или пожертвовать то, что не жалко… Так что, Хабрачитатели, мечтающие внести свою лепту в Cloud Storage, есть прекрасный вариант реализовать себя.
Rsync и Lsyncd

Выполняют функции, сходные с Dropbox, то есть синхронизацию локальной и удаленной папки. Это не совсем то, что я искал, поэтому не буду слишком подробно останавливаться на этом решении. Отмечу лишь отсутствие графического интерфейса и клиентов для ОС Windows, что автоматически исключает Rsync и Lsyncd из списка.
AeroFS


Если предыдущие продукты можно было скромно называть облачными, то AeroFS использует это понятие по полной. По сути AeroFS — это p2p сеть, которая коллективно хранит файлы не обязательно с использованием центрального сервера! Система полностью распределенная и использует сложные алгоритмы репликации данных. Есть возможность выделить центральный сервер, который привносил бы два положительных момента — web-интерфейс и дополнительную дупликацию данных (вдруг все уедут в командировку и сеть начнет испытывать истощение). До сих пор у меня к AeroFS много вопросов, ответы на которые получить пока не удается. Скачивание релиза доступно только по инвайтам, поэтому ждемс… Обязательно отпишусь по результата разворачивания AeroFS.
UPD: AjaXplorer


Благодаря umcherrel мы можем познакомиться с ещё одним средством: AjaXplorer. Впечатление, как и от OwnCloud, самые положительные. На сайте разработчиков есть возможность протестировать демо-хранилище за что им огромный плюс. Стоит также отметить простоту установки и добавления репозиториев. С технической точки зрения AjaXplorer характеризуется свойствами: онлайн просмотр (txt, pdf, zip, графика, мультимедиа) и редактирование файлов (txt), разграничение прав, адаптируется под браузеры iOS и Android, поиск (c внешними хранилищами все же лучше не использовать, к сожалению), множество плагинов на любой случай жизни. Также нужно отметить возможность дружбы AjaXplorer с различными системами управления версиями посредством плагина, что для нас тоже важно. Внешние хранилища можно подключать по Samba, FTP(S), WebDAV, IMAP, POP. И это прекрасно. Из недостатков можно отметить лишь ресурсоемкость. С другой стороны, за все нужно платить…
UPD: Amahi


Благодаря srs2k, мы узнали об Amahi. Что это за зверь? На самом деле Amahi — прекрасная платформа для домашнего медиа-центра в концепции «умного дома». Сразу бросается в глаза медиа ориентированность: Squeezebox сервер, DLNA сервер, Gallery 2, UPnP сервер uShare, медиа стриммеры Jinzora и Ampache, медиа-библиотеки OpenDB и VCD-db, учет домашнего хозяйства Home Inventory, хранение рецептов phpRecipeBook, торрент-клиенты, вики, форумы и пр. Стоит отметить также «бесплатную» услугу отслеживания динамического IP, то есть в некоторых случаях (стоит сказать, весьма ограниченных), Вам не понадобится покупать белый статический IP-адрес. Также существует возможность расширять функциональность плагинами.
Установка хоть и выполняется из терминала, но Вам настойчиво и весьма бесцеремонно установят графическую панель конфигурирования, сменят IP-адрес сервера, включат DHCP, перезагрузят сервер и вообще будут себя чувствовать как дома. Конечно, для неопытных пользователей такое решение «из коробки» просто необходимо, но в большинстве случаев, я считаю, это недопустимо.
С технической точки зрения Amahi поддерживает Samba, VPN, WebDAV (Outlook, iCal) и др. Более подробно прошу на сайт за красочными презентациями.
С точки зрения применимости Amahi для корпоративных нужд вопрос пока остается открытым.
Вывод

Подводя итог, скажу, что мы пока выбрали в качестве временной альтернативы решение OwnCloud. Согласно поговорке нет ничего более постоянного, чем нечто временное, но мы надеемся найти альтернативный вариант, так как вероятность, что OwnCloud в ближайшие сроки избавится абсолютно от всех недостатков, к сожалению, стремится к 0. Скорее всего, мы перейдем на AjaXplorer, если лучшей альтернативы не появится.

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

Хотелось бы узнать, как решается такая проблема в более крупных компаниях с поставленным процессом разработки?

Post scriptum: Встречался ли кто с системами оповещения работников (по email, sms и др.) о запланированных или циклических задачах с веб-интерфейсом? Наверное, это тема другой статьи. Поэтому to be continued....

habr.com

Бэкапьтесь в облако, друзья / Сервер Молл corporate blog / Habr

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

Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.


Считается, что история правила бэкапа «3-2-1» начинается с Питера Крога (Peter Krogh), который изложил его в книге «Управление цифровыми активами для фотографов». Вкратце напомню этот принцип:


  • Копий данных должно быть минимум 3.
  • Как минимум 2 копии должны быть на физических носителях разного типа. Например, одна копия — рабочие данные на дисковом массиве, вторая копия — данные на магнитной ленте.
  • Как минимум одна резервная копия должна храниться не в офисе.

Лично я чаще всего использую чуть другие правила в формировании резервных копий.

Классическая схема «3-2-1».

Во-первых, в качестве изначальных данных я беру резервные копии, а во-вторых, не всегда удобно и бюджетно хранить их на носителях различного типа — особенно для малого и среднего бизнеса. Моя обычная стратегия хранения резервных копий такова:


  • Оперативные резервные копии. Основная их цель — в случае небольшого сбоя обеспечить максимально быстрое восстановление. В зависимости от инфраструктуры храниться эти резервные копии могут даже на копируемом сервере — только на отдельном диске.
  • Архивные резервные копии. Они хранятся уже обязательно как минимум на другом сервере и с историей (чаще всего — 6 ежедневных резервных копий, 4 еженедельных и 4 ежеквартальных).
  • Удаленные резервные копии. Резервные копии хранятся обязательно в другом месте — на сервере в удаленном ЦОД или в облаке. Неплохой вариант — по возможности синхронизировать с удаленным хранилищем каталог архивных резервных копий.

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


Рекомендации:
  • Сервер с резервными копиями по-хорошему должен быть так или иначе изолирован от рабочей сети на случай, если вдруг заведется шифровальщик.
  • Неплохой вариант, когда сервер забирает резервные копии, а не получает их — на случай компрометации архивируемого сервера.
  • История архивов — must have. Часто встречал инфраструктуры, где хранилась только одна резервная копия важных данных, и в случае атаки шифровальщика или потери данных «позавчера», данные в резервной копии были уже испорчены или не те, что нужно.
  • Не забываем копировать не только данные, но и операционную систему.
  • Теневые копии и прочие снапшоты — это очень хорошо и здорово, но это не резервное копирование. Можно их использовать как замену оперативным резервным копиям, но лучше совмещать.
  • Архивы с расширением .exe или .dll — неплохой вариант обмануть так-себе-шифровальщика.
  • RAID — это совсем не про резервное копирование. Совсем-совсем.

А вот с удаленными резервными копиями вопросов много. В частности, надо выбирать, где хранить эти самые копии и чем их туда забрасывать. Сначала приведу несколько примеров «где».


Одним из вариантов будет простая и незамысловатая аренда выделенного сервера или установка своего сервера в ЦОД на колокейшн.

Действительно, «облако», которое построил сам, дает больше контроля над происходящим, да и выбор решения для хранения и непосредственно резервного копирования остается на усмотрение системного администратора. Можно даже сервер включить в домен «на земле», как я описывал в статье «Как я базы 1С в Германии прятал».

С другой стороны, контроль означает и ответственность — необходимо будет мониторить состояние сервера на случай аппаратных и программных проблем, при этом недостаток облаков в виде зависимости от интернета и вопроса доверия сторонним людям никто не отменял.

А не ваш ли это арендованный сервер у недорогого хостера?

Другим вариантом будет использование специализированных сервисов, которые создавались как раз для хранения резервных копий. Самым известным примером являются сервисы Amazon Glacier. Они окутаны легендами на тему используемых технологий — начиная от ленточных кассет и заканчивая blu ray-дисками и робо-руками. Но официально это недорогие HDD.

В отличие от арендованного сервера, решение уже начинает пахнуть кровавым энтерпрайзом со многими «девятками надежности» после запятой. Правда, как и многое у веб-сервисов Amazon, он обладает непростой формулой расчета стоимости. Если грубо упрощать, то загрузка данных на сервис — бесплатна, хранение — совсем недорогое ($1 за 1 Тб в месяц), а вот за получение данных придется заплатить. Как на старых ярмарках — «вход бесплатный, выход 15 копеек».

Классические сервисы хранения данных вроде Amazon S3 и Yandex Object Storage тоже, конечно, можно использовать для резервных копий, но ценник в таком случае будет менее гуманный — ~$10\мес за 1 ТБ у Яндекса. Также нельзя не упомянуть решения вида «все включено» от производителей систем резервного копирования, благо своего облака сейчас нет только у ленивого. Например, Acronis Cloud Storage как дополнение к продуктам Acronis буквально за $299 в год даст 250 Гб на своих серверах.

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


Я сейчас не буду сравнивать облачные платформы, отдам это на откуп многочисленным материалам в сети. Например, статье «Облачные хранилища для физических лиц: что выбрать и почему». Лично я для своих нужд остановился на Яндекс.Диске, потому что он один из немногих, кто на бесплатных планах умеет WebDAV, API и снапшоты (историю) файлов на диске. Ну и, конечно, у меня скопилось некоторое количество бесплатных гигабайтов на нем.

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


Лично мне ПО, предоставленное сервисами, не очень нравится использовать (если, конечно, речь не про специализированный сервис вроде Acronis): не всегда есть возможность настроить расписание синхронизации, да и еще жива в памяти история, когда Яндекс.Диск при обновлении устраивал патч Бармина операционной системе. По счастью, существуют специальные ПО, поддерживающие различных провайдеров. Как обычно, приведу несколько примеров в основном бесплатных и околобесплатных решений.

Handy Backup. Выдается на первой странице гугла по запросу «резервное копирование в облако». Есть платные версии различного функционала, отдельные плагины (например, для Exchange и 1C). Есть даже свое облако — HBDrive. Но самое главное, пока еще есть бесплатная версия, которая умеет бэкапить только в облако — Handy Backup Free for Cloud. К сожалению, в рамках тестирования мне не удалось заставить ее стабильно работать с Яндекс.Диском — периодически назначенное задание не срабатывало. Сложно что-то хотеть от бесплатного решения, но от использования этого ПО я отказался.

CloudBerry Backup. Всем хорош продукт, есть даже решения для восстановления отдельных объектов Exchange, есть поддержка множества разных провайдеров. От использования остановило отсутствие бесплатной версии и поддержки обычного Яндекс.Диска, только S3 совместимое хранилище Yandex Object Storage.

Список поддерживаемых провайдеров решения от CloudBerry Lab.

Duplicati 2. Уже совсем бесплатный продукт, даже для коммерческого использования. Есть под все популярные платформы от Windows до GNU\Linux, работать можно как через веб-интерфейс, так и через командную строку, также есть и шифрование бэкапов «из коробки».

Интерфейс Duplicati, поддерживаемые провайдеры.

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

Rclone. Пожалуй, это мой бесспорный лидер среди прочего ПО. Утилита командной строки под множество платформ, на официальном сайте доступна загрузка в том числе и под редкие операционные системы вроде Plan9 и Solaris. Список поддерживаемых облачных провайдеров тоже впечатляет — в нем есть поддержка даже Cephs и OwnCloud. И да, Яндекс.Диск в списке. Конфигурация до недавнего времени производилась только через интерактивное консольное меню, но относительно недавно появилась возможность запускать веб-интерфейс и настраивать через него.

Веб-интерфейс rclone.

К минусам стоит отнести отсутствие каких-либо встроенных планировщиков. Утилита работает исключительно как транспорт на\с облаков, зато и не требует установки. В том числе и из-за этого я ее использую в связке с Яндекс.Диском для переноса информации с одних удаленных серверов на другие — оказалось, что крупные файлы быстрее закинуть на облако и скачать с облака, чем организовывать прямой файлообмен. Да и подгружать резервные копии одно удовольствие. Например, чтобы скопировать в облако только свежие файлы, можно использовать команду:

rclone copy --max-age 24h --no-traverse D:\backups yandex:backups 

Где yandex — имя конфига, созданного заранее, а backups — папка с бэкапами.

Более подробно принципы работы rclone разобраны в официальной документации и в статье «Rclone: rsync для облаков».

В принципе, как уже полноценное решение для резервного копирования, rclone можно использовать вместе с Duplicati, выбрав rclonе как тип хранилища. Тогда Duplicati будет создавать резервные копии с использованием vss (снапшотов) по планировщику, а первое будет отвечать за загрузку резервных копий в нужное нам облако. Конечно, можно использовать и любое другое решение вроде Cobian или вовсе делать снапшоты vss командой diskshadow, архивировать и заливать в облако при помощи rclone. Правда, если совсем уж изобретать велосипед, то и никакой rclone не нужен.


Конечно, если облачный провайдер предоставляет доступ по WebDAV, загрузка данных будет простой. Пример для cmd и Яндекс.Диска:

net use Z: "https://webdav.yandex.ru/backup/" /User:[email protected] password rem копируем файлы любым способом net use Z: /delete 

Но не все провайдеры умеют в WebDAV, и есть вопросы по скорости и стабильности работы. Поэтому можно использовать API, если, конечно, провайдер предоставляет такой доступ. Разберем пример с тем же Яндексом.

Для авторизации Яндекс использует OAuth, поэтому для нашего скрипта понадобится завести специальный токен. Сначала нужно создать приложение в разделе «Создание приложения» на сайте.

Нужно не забыть дать доступ приложению на Яндекс.Диске:

Доступ скрипта к API Яндекс.Диска.

И подставить URL для разработки в Callback URI (будет доступен после установки галочки «Веб-сервисы» на доступных платформах):

Настройка Callback URI.

После получения ID приложения следует перейти по ссылке:

https://oauth.yandex.ru/authorize?response_type=token&client_id=12345678&display=popup

Где 12345678 — полученный ID. После предоставления приложению доступа мы получим желанный OAuth-токен, который уже можно применять в скриптах. Вот, например, загрузка файла на Яндекс.Диск при помощи PowerShell:

#путь к файлу $filepath = "D:\backup.zip" $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]" $headers.Add("Authorization" ,'OAuth НашOauthТокен') $headers.Add("Content-Type","application/json") #получаем от Яндекса URL для загрузки файла $UploadUrl= (Invoke-RestMethod -method GET -URI ("https://cloud-api.yandex.net:443/v1/disk/resources/upload?path=backup.zip") -Headers $headers).href #загружаем сам файл Invoke-WebRequest -uri $UploadUrl -Method Put -Infile $filepath -ContentType 'application/zip' 

Организовать ротацию файлов, контроль загрузки и прочий «обвес» предлагается самостоятельно, благо API Яндекса хорошо документировано. Но лично я предпочитаю не изобретать велосипед, а использовать rclone.

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

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

habr.com

ShadowCloud — универсальный облачный клиент / Habr

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

Как-то так он выглядит:



  • Прямая загрузка (без использования локального диска) в Google Drive, Яндекс Диск (WebDAV), Облако Mail.Ru, Dropbox
  • Полное шифрование по умолчанию, большой выбор алгоритмов и настроек
  • Защищённая паролем база данных
  • Чексуммы и дедупликация
  • Убирает ограничение на размер файла
  • Репликация или разбиение файлов по разным хранилищам
  • Стриминг медиа без ограничений
  • Создаёт превью и извлекает метаданные и текст документов
  • Версионирование файлов и всей структуры директорий
  • Markdown заметки, подсветка кода
  • Быстрое сохранение веб-страниц со встроенными ресурсами
  • Кэширование файлов в памяти
  • Использование в виде локального диска с помощью FUSE (требуется winfsp)
  • Открытый исходный код, почти каждый аспект настраивается через shadowcloud.conf


Собственно, репозиторий

Для использования необходимо:


  • Сгенерировать ключ шифрования (позже его нужно импортировать на других устройствах)
  • Настроить облачное хранилище
  • Создать регион данных и подключить к нему хранилище (ID региона должны совпадать на всех устройствах)

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


Программа написана на Scala и практически целиком построена на фреймворке Akka (акторы, стримы, http, persistence), фронтенд написан полностью на Scala.js.

Для шифрования используется Bouncy Castle и опционально libsodium (алгоритмы по умолчанию: Blake2b/ChaCha20/ECIES/ECDSA).

Из версии light исключены Apache Tika и JavaCV из-за большого размера, они используются для извлечения метаданных из документов и создания превью для видеозаписей.

habr.com

Как создать свое облачное хранилище

Онлайновые файловые хранилища завоевали огромную популярность и сегодня на компьютерах большинства пользователей установлен клиенты Dropbox, Google Drive или SkyDrive. Практически во всех случаях бесплатных возможностей этих служб вполне хватает для удовлетворения всех обычных потребностей. Но иногда бывают ситуации, когда объем синхронизируемых данных ну никак не вписывается даже в платные тарифы или их секретность настолько высока, что не может быть доверена сторонним сервисам. В этом случае можно создать свой собственный сервис резервного сетевого копирования и синхронизации файлов.

Syncbox — программное решение, с помощью которого вы сможете организовать свой собственный облачный сервис наподобие Dropbox. Только все данные будут храниться на одном из ваших компьютеров (сервере), а все остальные устройства смогут беспрепятственно получать к ним доступ через специальные программы-клиенты. Таким образом, вы не арендуете для хранения данных место у сторонних сервисов и не имеете никаких ограничений на размер общего пространства.

Для начала вам нужно скачать и установить серверную часть на компьютер c ОС Windows, который будет использоваться в качестве сервера. Установка программы стандартна и не должна вызвать каких-либо вопросов.

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

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

Учтите, что основной компьютер, выполняющий роль сервера, должен быть постоянно включен.

Источник: lifehacker.ru/2013/01/09/khotite-bezrazmernyjj-dropbox-ispolzujjte-syncbox/

Syncbox - www.isyncbox.com

Альтернатива: owncloud.org

Синхронизация файлов на компьютерах без облака:

Программа BitTorrent Sync - labs.bittorrent.com

Для синхронизации используется протокол BitTorrent, файлы передаются в шифрованном виде. Нужно только установить программу, выбрать папку для синхронизации и сгенерировать ключ. Этот ключ понадобится для тех компьютеров, с которыми будет проводится синхронизации. У программы BitTorrent Sync есть клиенты для платформ Windows, Mac, и Linux.

Программа AeroFS - aerofs.com

Бесплатна при условии, что вам не нужны дополнительные возможности. На компьютере создается папка, которая синхронизируются между компьютерами, с установленной программой. В основе синхронизации лежит система пользовательских аккаунтов – существует центральный сервер, управляющий пользовательскими аккаунтами, сами файлы не хранятся на серверах AeroFS. Файлы хранятся на ваших компьютерах.  Поддерживаемые платформы: Windows, Mac, и Linux.

 

 

Понравилось? =) Поделись с друзьями:

Опубликовано в рубрике Софт

elims.org.ua


Смотрите также



© 2010- GutenBlog.ru Карта сайта, XML.