Пользователь
0,0
рейтинг
8 июля 2013 в 04:14

Администрирование → Создаем личное облако на 3 Тб tutorial

*nix*
Я бы хотел поделиться одним способом создания личного облака на базе трехтеррабайтного 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 root@192.168.X.X

Предлагаю в первую очередь, также сменить пароль на более стойкий (тем более потребуется если в дальнейшем будете открывать доступ через интернет), командой 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 default@freedns.afraid.org
--syslog

Кому интересно, расшифровка
  • username — здесь указываем имя пользователя, с которым регистрировались на freedns.afraid.org
  • password — пароль оттуда же
  • update_period_sec — частота проверки и обновления (если менялся) IP в секундах
  • forced_update_period — частота принудительного обновления IP в секундах
  • alias — строка, в которой через запятую указываем наш домен и его хэш, который мы записывали ранее
  • background — указание исполнять в фоновом режиме
  • строку dyndns_system default@freedns.afraid.org оставляем без изменений, она говорит программе с каким сервером идет работа информацией (указывает на внутренний протокол обмена)
  • 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.

Материалы:
Paul Phönixweiß @phoenixweiss
карма
3,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (68)

  • +4
    Если у wd2go корявы апплеты, то owncloud коряв сам по себе.
    • +2
      С этим не спорю, но:
      1. при использовании wd2go браузер постоянно ругается на Java, с которой из под Mac OS X давно капитальные проблемы, а корявость owncloud конечному пользователю не так сильно бросается в глаза.
      2. owncloud достаточно динамично развивается, как серверная часть, так и клиенты для всех осей. Слежу за проектом довольно давно, и последние полгода им уже вполне можно пользоваться. Во всяком случае, для моих нужд это достаточно хорошее решение.
  • 0
    Еще интересно, как в owncloud сделать вменяемые ЧПУ ссылки
  • 0
    Можно пойти дальше, совсем отказавшись от штатной прошивки. Вы потеряете web-интерфейс и все предустановленные сервисы от WD (подумайте, Вы, хотя бы, половиной пользовались?), но приобретёте чистый debian wheezy и возможность установить и настроить всё так, как нужно именно Вам.

    У меня два MBL: 1) оригинальный на 2ТБ, у которого в chroot крутятся minidlna и transmission-daemon; 2) «pure debian» на «старом» диске, освободившемся после апгрейда десктопа, с nginx, php5-fpm и прочим ПО. Оригинал я пока не перевожу под чистый дебиан по причине банальной лени перекачивать все торренты и перебивать в них пути.
    • 0
      Спасибо за наводку, если выпадет свободное время — обязательно попробую.
  • +5
    Я только что из этого WDLive вырывал свои данные — хард был нужен в большом брате, настольном компе, и данные тоже (полноценно с ними работать, удалять, редактировать). Винда с помощью ext2fsd монтировала диск, однако напрочь отказывалась удалять данные, записанные через WDLive, хотя читать, писать и удалять новые она позволяла. Ресерч на эту тему толку не дал. Ок. Как же нам перегнать 2тб информации в ntfs при отсутствии внешних носителей? Замонтировать в линуксе, стереть 1тб ненужной фигни и в два прохода перегнать в ntfs. Но не тут то было.
    Товарищам из WD кровь из носа нужно было адресовать 2тб диск старым как мои тапки PPCшным процом, и они придумали гениальное решение. А почему бы нам не сделать размер блока больше? Больше размер блока -> меньше блоков -> меньше надо адресовать. Выставили размер в 64, пропатчили ядро, сделали кучу работы — отлично, дело сделано. Только вот диск подмонтировать нельзя вообще нигде, тк ограничение на размер блока — 4. Просто великолепно!
    Я потратил только что 15 часов на ресерч, который ничего не дал: люди в гугле решения проблемы не добились. И вот только вспомнив, что под macosx extX монтируются с помощью fuse решил вбить «fuse ext» и наткнулся, собственно, на проект «fuse-ext2». Совершенно внезапно там есть исходники под линукс и, после некоторого шаманства в live archlinux над скриптами сборки этих исходников, я смог примонтировать фс и начать удалять данные. 15 часов. Сейчас я, гордый собой, иду спать, но хотел хоть как-то опубликовать решение проблемы в этих наших интернетах.

    Что я могу сказать про сам дебиан в этих зверьках… он ужасен. Это самая кривая установка линухи, которую я видел. Я не мог там дернуть iptables, почти любое сколько-нибудь важное телодвижение в пакетном менеджере приводило к поломкам зависимостей (следствие отсутствия поддержки этой, старой, версии дебиана), поднять на этом девайсе transmission — только если через fpkmgr, руками обязательно что-то отлетит по дороге.

    Что я бы сам посоветовал? Дешевейшая материнка с lan и видео, arch (любой Ваш любимый дистрибутив) и хард. Это обойдется и дешевле и гибче WDLive'а. А сложность настройки — туториалы есть в гугле и при большом желании можно умудриться, выполняя их, вообще не включать голову. Зато вы не будете тратить неделю на вопрос того, какого лешего sftp полностью игнорирует установленные *nix права к файлам и почему веб интерфейс совершенно не корелирует с реальным положением дел на харде.
    • +1
      Я потратил в 30 раз меньше времени на поиск решения с fuse_ext, ничего не компилировал, но недоволен не менее Вашего. А чем не устроила работа с данными «штатными средствами» WD MBL?

      P.S.: iptables там просто не работает, ибо либо сам, либо нужные модули выключены в конфиге ядра при сборке, а userspace-часть не соответствует kernalspace. Знаем, нарвались уже.

      P.P.S.: web-интерфейс там тормозное уг, согласен, но, тем не менее, штатную функциональность реализует почти на 100%
      • 0
        Насчет fuse ext — я с fuse работал только под macosx и, тк под этой ос у меня только ноут, в голову вообще не пришла мысль о том, что… я дебил)

        Не устроило меня многое. Я хотел расшарить данные многим пользователям извне по sftp (общага, студенчество). No iptables, стандартные средства не корелируют ни с sftp ни с *nix'овыми пермишенами, вообще живут отдельной жизнью. Совершенно не работает без огромного бубна iTunes sharing, TimeMachine роняет бэкап через 1 месяц использования (трижды проверено), все остальные возможности, выведенные в веб интерфейс, вообще интереса не представляют.

        Про штатную функциональность — ей богу, я ее быстрее руками реализую на месте, чем через это уг.
        • 0
          Самокритично.

          Про функциональность я выше намекал — вполне хватает для mpd, icecast, сайта на php и прочей мелочи. Настраивается один раз, а потом только юзеры добавляются/удаляются/блокируются.
          • 0
            Может быть, но мне не хватило для домашнего использования :).
            • 0
              Я про «pure debian», если что. Штатная веб-морда, сжирающая половину (а то и больше) оперативной памяти и забивающая реально нужные сервисы в своп — это к мазохистам. Ну, или к WD.
              • 0
                А. При условии того, что дебиан не архивный — да.
    • 0
      Под функциональный аналог WD MBL я, находясь в здравом уме и трезвой памяти, никогда не посоветовал бы десктопное железо. А серверное — тем более. Из пушки по воробьям.

      Энергосбережение хромать будет у такой системы. На оба протеза. Так что нафиг, имхо.
      • 0
        Да, энергию я не учитывал тк за нее плачу не я.
        В моем же случае вопрос оправдан тем, что большой брат и без этого в сети 24/7 делами занят иными, уж пошарить какую-то фигню он в состоянии =)
        • 0
          Я в общаге тоже не учитывал. Теперь приходится.
  • 0
    Дополню: диск в ext4 и альтернатив на запись в win7 ext2fsd нет. Невозможность модифицировать — баг ext2fsd, проект заброшен с 2011го.
    • 0
      Ну, Вы, хотя бы, имеете возможность скопировать с этого диска информацию, чего не получилось бы, будь диск, например, в reiserfs отформатирован. Так что, это не смертельно.
      • 0
        Не всегда есть куда копировать =) Я собирал новый комп и все деньги ушли на железо, в кошельке минус трехзначная сумма. Студенчество.
        • 0
          Не «студенчество», а огрехи планирования инфраструктуры, скорее. Хотя бы домашней. Надо было usb-вариант брать, наверное.
          • 0
            Когда нужен дико мощный комп, а денег нет, либо купишь железо слабее, либой уйдешь в минус. Я решил уйти в минус. А хард у меня уже много лет.
            Предлагаете с болтающимся на шнурке usb ноуте по комнате расхаживать, или использовать другую железку для шары? Другой железки не было тогда, пара ноутов. Я не вижу огреха.

            • 0
              Ваше право. Я бы это посчитал огрехом, но мы же домашний вариант рассматриваем — тут у каждого свои критерии. И, тем не менее, Вы раскурочили девайс, дабы вытащить из него диск, тем самым спустив псу под хвост идею шаринга. На одном компе Вы получили быстрый доступ, да.
              • 0
                Раскурочил я его на следующую же неделю после покупки — без корпуса он милее, занимает меньше места, а случае гарантийной ситуации — собрал бы обратно. А шаринг — подниму на этом большом брате. Лишь бы избавиться от этой кривой поделки.
                • 0
                  Я выше отписался про электричество. Сколько Ваш ББ потребляет под нагрузкой? А на холостом ходу? А теперь сравните цифры с нашим злополучным ведром. Кто выиграл?
                  • 0
                    Естественно ведро. Только вот в контекте ситуации это обстоятельство силы вообще говоря не имеет — плачу не я :) Хоть со всего института андроидов соберу и поставлю заряжаться. А с тем, что в общем случае, это фейл — я согласился выше.
                    • 0
                      Точно. Я пропустил.

                      Давайте попробуем вернуться в топик — что ещё было бы полезным/необходимым на ведре, вместо/вместе с owncloud?
                      • 0
                        Очень важно — TimeMachine, но, как я уже сказал выше, оно падало. Сцепка с noip2. Ну а так, воообще говоря, я описал выше все, зачем мне нужен был хард.
  • 0
    Осталось прикрутить https.
    • 0
      Кстати, а для локалки смысл в этом есть?
      • 0
        Для локалки смысла в https особого нет. Но речь же идёт об Облаке :)
        • 0
          Ну, значит, мой вариант, когда ssl «одевается» на трафик WeDra на фронтенде, расположенном на роутере, вполне адекватен.
  • +6
    Ну не Облако это, а установленный ownCloud на linux хост.
    • 0
      А что не так? Кроме отказоустойчивости, естественно.
      • +5
        Если я хочу больше места в дропбоксе, то я просто плачу деньги и получаю больше места. При этом сервис не останавливает работу, подключают еще серверы и перераспределяют нагрузку на них. А это просто сервер с веб-мордой.
      • +1
        да всё не так, кроме того, что у вас есть доступ к своему хранилищу снаружи.
      • 0
        Все не так:

        Национальным институтом стандартов и технологий США зафиксированы следующие обязательные характеристики облачных вычислений[7]:

        Самообслуживание по требованию (англ. self service on demand), потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;

        Универсальный доступ по сети, услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;

        Объединение ресурсов (англ. resource pooling), поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);

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

        Учёт потребления, поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.
  • +7
    Не понятно, к чему весь этот геморрой. Такое ощущение, что делалось всё просто в погоне за модой. Как уже правильно заметили, облаком тут и не пахнет. Куча единых точек отказа (SPoF). Открыли бы доступ через FTP и не парились
  • 0
    Пробовал когда-то экспериментировать с ownCloud на MBL. Отказался по причине несовместимости функционалов — хотелось, чтобы ownCloud был веб-интерфейсом для доступа к файлам на диске из-за пределов локалки, а в локалке чтобы было видно по SMB, однако у ownCloud свой формат хранения и структура каталогов, и файлы либо хорошо видно через ownCloud, но криво видно через SMB, либо видно через SMB, но не видно через ownCloud.
  • 0
    Для себя сделал следующее простое решение. Домашняя сеть с подключением по VPN из вне и SMB сервак. Необходимо получить доступ к файлам. Подключаюсь к VPN (реализовано силами роутера), а далее стартую сервак по WOL (а нефиг ему постоянно электричество жрать) и подключаю диск по SMB. Кроме этого на серваке и торрентокачалка есть и другие нужные мне вещи. Управление сервером по RDP хоть со смартфона, собственно и со смартфона можно получить доступ к файлам. При желании можно для экспресс доступа с незнакомого компа и вебморду поднять(благо апач все равно стоит), но потребностей таких у меня пока не было. Также это решение позволяет сохранять и свой российский ИП при нахождении в командировках — очень бывает полезно и актуально. В результате очень много места, гигабитный доступ из локалки (и при необходимости непосредственный доступ к серверу).
  • +1
    Давайте ещё CalDAV прикрутим!
  • –1
    По поводу кривости debian — его кривость прямо-пропорциональна кривости ваших рук.
    Реально у WD проблема это WD Green, который от интенсивной нагрузки разваливается за год, ext3(4) (не system) которую нормально не смотрировать при подключении к бб, и наконец венец сего творения — 256мб это никуда…
    В остальном хорошая тихая домашняя NAS система)
    • 0
      > Реально у WD проблема это WD Green, который от интенсивной нагрузки разваливается за год

      А что можно считать «интенсивной нагрузкой»?
      У меня WD MBL о 2-х Тб несколько лет в режиме 24/7 торренты раздает/качает, я уж не говорю что аппарат пару раз падал со стола во включенном виде. Все до сих пор живо, сломался только индикаторный светодиод на лицевой морде аппарата.
    • 0
      В гринах как раз проблемы с интенсивной нагрузкой нету. Был опыт использования 1.5 Тб грина под постоянной нагрузкой чтения/записи ~ 30Мб/5Мб 24х7 в течение двух лет. Полёт отличный. Он бы ещё столько же проработал, если бы не понадобилось расширить место.
      А вот с парковкой головок там действительно проблема. Они там, заразы, каждые 8 секунд паркуются, а gnu/linux каждые 10 секунд лезет логи дополнять. Впрочем проблема решается отключением энергосберегающего режима специальной утилитой, которую можно чуть ли не на сайте wd скачать ( ну или у техподдержки выпросить ), хотя с некоторыми отдельными грин моделями для отключения столь агрессивного поведения нужно было отдельно плясать.
      • 0
        У меня за год работы 2000 Reallocated_Sector_Ct на грине. Хотите сказать мне просто не повезло? Сейчас грин заменен на ред.
        По поводу кривого дебиана, не понимаю в чем его кривость? После доработки напильником, вполне себе неплохо работает.
  • 0
    Я бы вместо ownCloud посоветовал Seafile, ну или в дополнение к нему, он больше подходит на замену дропбокса, по моему мнению.
    Правда не уверен, что поставить (читить собрать) его на WD будет простой задачей.
  • 0
    Я понимаю, что вы решали проблему исходя из того, что имелось в наличии, но роутер с ЮСБ диском делает эту задачу намного проще.
  • +1
    Извините за резкость, но это не облако, а фигня на постном масле. В промышленности за словом «облако» скрывается прежде всего масштабируемость и отказоустойчивость, а не: «Ой фоточка с мобилки появилась на компьютере!». Накроется 3 терабайтный винт, и желаю удачи с перезаливкой и пересинхронизацией всех клиентов.
    • 0
      Ну зато как минимум, сами данные не пропадут как при простом хранении и доступе, например по FTP.
      • 0
        Это кто сказал?
        • 0
          При синхронизации через owncloud, данные хранятся на сервере и на локальной машине (а может на нескольких). Если с сервером что-то происходит, на всех локальных машинах с которыми была синхронизация, данные остаются. Так что даже если сервер физически выйдет из строя, как минимум, на локальных машинах останется информация.
          Если просто заливать файлы на FTP, не оставляя копий на локальных машинах, при физическом выходе из строя сервера, данные уйдут в небытие вместе с ним.
          Не логично?
          • 0
            Я даже не знаю плакать мне теперь или смеятся. Выходит мой инкрементальный бекап важных папок с ноутбука на сервер стал вдруг облаком. Инкрементальный, это когда при изменении одного байта в 2-х гиговом файле копируется только это изменение, а не весь файл.
            • 0
              Если верить Википедии, очень грубо, облако подразумевает повсеместный и удобный доступ к устройствам хранения данных, все остальное — это уже технологии.

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

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

              Или я не прав?
              • 0
                Вот именно, повсеместный доступ к устройствам, а не к одному устройству. Если вы сделаете резервирование дисков, хостов, сети, то это можно будет называть маленьким облаком.
                • 0
                  Хорошо, абсолютно та же самая операция применима к MyBookLive Duo, в котором два жестких, которые можно объединить в RAID, таким образом данные будут зеркалироваться. Это уже будет Облаком?
                  А если я содержимое моего MyBookLive зеркалирую по сети на второй такой же?
                  • 0
                    Осталось зарезервировать доступ в сеть и настроить автоматический fail-over.
              • 0
                Квадроцикл = автомобиль. Удивительная логика.

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

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

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

                А у вас просто сочинение на тему «Как я провел лето, после того как узнал про апач».
                • 0
                  Стоит отметить, что для управления квадроциклом требуется удостоверение водителя-тракториста. Это обусловлено техническими характеристиками и другими особенностями квадроцикла, а также тем, что он предназначен для суровых условий эксплуатации.

                  В остальном, не буду спорить. Лето удалось, и сочинение от души писал.
          • 0
            > на всех локальных машинах с которыми была синхронизация, данные остаются.
            Почему? Там же просто монтируется по webdav сетевой фолдер. Если сервер уронить, локально ничего не останется.
            • 0
              По-умолчанию ничего не монтируется, папка и файлы физически остаются на компьютере, для отслеживания изменений и синхронизации используется модуль csync. WebDAV нужно настраивать и прикручивать отдельно.
              На двух компах были файлы в папке owncloud, потом я лично грохнул прошивку MBL при случайном обновлении udev и пришлось разбирать девайс и полностью форматировать винт. На обоих компах файлы физически остались, никуда не делись, только клиент owncloud сообщает о том что нет соединения с сервером.
              Что я делаю не так?

              P.S. на официальном сайте написано:
              ownCloud gives you universal access to your files through a web interface or WebDAV.

              и ссылка. В нашем случае используется веб-интерфейс на сервере и синхрон по csync на клиентах.
              • 0
                > a web interface or WebDAV
                Собственно, нет никакой разницы, какой протокол используется для передачи данных.

                > синхрон по csync на клиентах.
                А вот это другое дело. В таком случае файлы действительно хранятся на всех машинах.
                Не вседа удобно, например, для несколько-терабайтной файло-помойки.
                • 0
                  Тут с Вами согласен, поэтому и написал что не представляю сколько времени потребуется для синхрона 3 Тб и кому это может потребоваться, но сам факт что такое возможно даже посредством MBL уже интересен.
                  Лично я в итоге разобрал MBL, купил док-станцию для жесткого диска, поставил 3-х террабайтник в нее и пользуюсь так, просто как внешним хардом. А для остатков MBL жду когда товарищ принесет старенький винт на 80 Gb чтобы начисто поставить на него Debian Wheezy по инструкции отсюда и сделать отдельно маленький домашний owncloud-серверочек для синхрона особо важных документов.
    • 0
      А причем тут промышленность? Если судить по посту, то автор предлагает некий вариант «облака» для персонального использования. Для себя, правда, я другое решение собрал(см. выше), имеющее аппаратный рейд.
  • 0
    Какая версия прошивки была в сем эксперименте?
  • 0
    По поводу доменов, для Украины можно бесплатно зарегистрировать домен *.pp.ua.
    Регистрация полностью бесплатна, проверено лично.
    • 0
      Не проще ли сразу .tk?
  • –2
    Хотел бы посоветовать во-1, не передавать ваши личные данные через интернет по открытому протоколу в смысле вообще, в смысле закрыть доступ в облако на 80 порт. А SSL ходить только по НЕсамоподписанному сертификату, а использовать бесплатные службы типа cacert.org. Иначе смысл SSL практически сводится на нет.
    • 0
      А чем плох самоподписанный сертификат?
      • 0
        Тем что в таком случае либо сертификат вашего CA должен быть на всех клиентах и сервере, либо Вы легко подвержены атаке MiTM.

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