Як зробити власний сервер Dropbox / Ubuntu One вдома?

Хтось знає про будь-які ресурси, які можуть показати мені, як зробити власний сервер "Dropbox, Ubuntu One" вдома?

Мені дуже подобається ідея цих послуг, але я не хочу ставити свої «речі» в хмари. В ідеалі він повинен мати клієнта, який працює на Linux та Windows.

Я намагався налаштувати iFolder на свій Ubuntu 10.04, але поки що без успіху.

В даний час не існує чудової альтернативи з відкритим кодом, яка вийде нестандартно. Найкраще слідкувати за проектами блискавки: http://www.sparkleshare.org/

Сподіваємось, що перетвориться на чудову, зробіть це самостійно, альтернативу.

Їх насправді дуже багато.

• SparkleShare (deps: git / subversion, mono, python) у програмному забезпеченні для синхронізації на основі github .

  а. Версія: через систему управління джерелом, отже, вона заснована на мьютекс на центральному сервері через номер версії.

  б. Держава: в стадії розробки

  c. Плюси: OSS, на основі моно настільки легко модифікований, Мінуси: процес на рівні користувача, залежний від GC, неефективний протокол спільного використання на величини, так як git - це в першу чергу для невеликих текстових файлів, досить важких для складання (я намагався). Використання інструментів високого рівня.

• lipync (deps: Unison, rsync) Програмне забезпечення, засноване на сервісному командному рядку.

  а. Версія: через алгоритм дельти rsync . Я припускаю, що програміст повинен вибрати вирішення конфлікту.

  б. Штат: Я не можу знайти його вихідний код, тому я не маю уявлення. Єдині речі в його git repo - бінарні файли.

  c. Плюси: гарне налаштування, використання інструментів середнього рівня.

• iFolder - Dropbox Novell. Я ще не вивчив її джерело. Я просто хочу завершити цю редакцію, і якщо люди зацікавляться, я додам більше.

  а. Версія:

  б. Стан: Проблематично отримати його навіть для компіляції на Ubuntu, не кажучи вже про пакети. Ось докладний посібник із встановлення .

  c. Плюси: клієнт Windows X64, зрілий, AD-інтеграція з ACL, особливості жодного іншого проекту не почали реалізовувати. Я думаю, що це може бути хорошою відправною точкою. Мінуси: Novell може не використовувати своє загальнодоступне репортаж svn як основне репо, а робити лише краплі коду. Я про це точно не знаю. Може бути занадто поєднаним з openSUSE, щоб легко встановити на Ubuntu. Щоб перевірити його алгоритми.

• scp / rcp - застаріла на користь rsync

• DRDB - блок дзеркальних інструментів пристрою для розподіленого RAID-1, тобто серверний варіант дроп-боксу . Я ще не перевірив його вихідний код, але це лише Linux. Фактичний алгоритм, ймовірно, було б легко поєднати з вихідним кодом у моїх програмах нижче цього списку програм.

  а. Версія: внутрішній формат повідомлення через LAN / WAN

  б. Стан: здається досить зрілим

  c. Плюси: достатньо стабільний для Linux, Мінуси: жодна інша операційна система не підтримується

Зараз я розслідую вдосконалення часу компіляції у віртуалізованій Windows 7, де час компіляції для Windows 7 на металі складає 40 с, але віртуалізовано приблизно 3м 20х. Я думаю про те, щоб написати драйвер ioctl, це кеш-запис, що схожий на ram-диск для вибраних папок на NTFS.

Використовуючи вищезазначене програмне забезпечення, я думаю, що тиждень, що займає повний робочий день на 2-3 людини, дозволить створити корисну альфа, яка не втрачає ваші файли, поєднуючи вищевказані програмні засоби.

У моїй системі тоді загальна ідея була б;

1. Змонтуйте віртуальний диск \? {GUID}, тобто оперативний диск і кеш-пам'ять RW. Програмне забезпечення, що створює цей віртуальний привід, має два вхідні параметри (які є життєво важливими):

   а. Цільова папка; це папка SMB, тому я дозволяю мережевому стеку операційної системи обробляти фактичний IO. У моєму випадку це, в свою чергу, віртуальна папка VMWare, яка сама по собі є ціллю на приводі ext4, але це легко може бути вашим файловим сервером за допомогою SAMBA / SMB.

   б. Шлях папки, яку потрібно встановити, наприклад, C: \ ramdisk

   Цей код для створення віртуальних томів буде взято з коду TrueCrypt в /Driver/DriverFilter.c (серед інших файлів)

2. Привід використовує SMB / протокол VMWare / мережі для отримання даних при його запуску; він отримує низький пріоритет завдання, асинхронно з мережі та заповнює кеш. Він міг би використовувати простий алгоритм ущільнення та мати 1 потік, який використовує продовження передачі типу коробки повідомлень для отримання великої продуктивності. У Windows він може використовувати звичайні виклики асинхронного вводу-виводу, а в Linux може використовувати реалізацію epoll / inotify та приймати код з nginx .

3. У моїй службі, що знаходиться на ram-диску, монтується неназваний накопичувач ramdisk у вигляді папки NTFS. Усі програми можуть продовжувати писати на C: \ ramdisk, або як я його називаю.

4. Асинхронізація копії з мережі все ще триває. При швидкості зчитування приблизно 100 Мбіт / с і 2 ГБ оперативної пам’яті було б 20,5 с прочитати всі дані.

Кожен виклик для читання виконував би обчислення індексу в CPU у фіксованому масиві n: ulong GiB max. Це вимагатиме вирішення конфліктів, хоча або блокування читання-запису. Якби ми реалізували алгоритм вирішення конфлікту, як той, що доступний через Microsoft Sync, ми могли б передати кожен фрагмент, який конфліктує, як повідомлення в інший процес вирішення конфлікту. Dropbox вирішує його, створюючи новий файл і називаючи його "PrevFileName Copyled Copy Copy (yyyy-MM-dd) .ext". Можливо, це могло б бути змінено через невеликий віджет, якщо один збирається проти цього єдиного джерела - віджет виявлятиме непомітні зміни як повідомлення / події та вибирає протокол вирішення конфлікту. Таким чином, програмуючи папки в ексклюзивному режимі, Windows VM може встановити віджет на "ексклюзивний".

Це були б ці ПРО

• Це було б не блокує / асинхронізує
• Це може зробити припущення, але не вимагати, щоб один комп'ютер записував переважно у файли.
• Він буде працювати для довільно великих файлів
• Він би працював над * nix та Windows, зв’язуючи разом згадані проекти.
• Він буде працювати, коли потрібна висока продуктивність читання (тобто файли фізично розташовані на диску)
• Коли конфліктні події будуть досягнуті, можна надати додаток для інтерфейсу користувача, який дозволяє користувачеві писати / завантажувати плагіни, які діють нормально для різного роду подій, тобто різних типів файлів. Наприклад, текстовий файл може бути виведений з Kompare / WinDiff, а двійковий файл буде дублюватися та зберігатися як інший файл.

OwnCloud ! звучить як щось, що ви шукаєте.

Я чув про Syncany в Ubuntu UK Podcast , наразі бета-версія, але схоже, що вона відповідає вимогам

Я не думаю, що це саме те, що ви шукаєте, але це залежить від призначеного вами використання.

CrashPlan - це пакет програмного забезпечення для резервного копіювання та пов’язаний з ним сервіс хостингу резервного копіювання в Інтернеті, але що відрізняється тим, що їх програмне забезпечення має режим, який дозволяє створювати резервні копії даних через Інтернет (або локальну мережу) на іншому ПК, на якому працює програмне забезпечення.

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

Базовий програмний пакет безкоштовний і підтримує режим "резервного копіювання на інший комп'ютер", але виконує лише заплановане резервне копіювання, але є "Pro" версія програмного забезпечення, яка також коштує і робить синхронізацію в режимі реального часу, а не просто заплановані резервні копії. (Хмарне сховище - це також додаткова оплата за місяць додатково)

Я використовую Unison для клієнта та rsnapshot (rsync with perl script) для резервного копіювання сервера.

Подивіться, чи це допомагає:

http://fak3r.com/2009/09/14/howto-build-your-own-open-source-dropbox-clone/

Якщо ви хочете налаштувати два (або більше) машини з повторюваною папкою, погляньте на glusterfs.

Його легко налаштувати, якщо слідувати Посібнику користувача GlusterFS .

Ніхто не згадав синхронізацію bitorrent ? Працює на чому завгодно - Ubuntu, windows, багато розповсюджених ОС смартфонів, малиновий пі .... ви називаєте це, ймовірно, працює і як звичайний користувач. Зашифровані передачі, файли не зберігаються у хмарі (хоча я думаю, що Bittorrent запускає трекер для цього), досить швидко, ви можете вибірково ділитися папками, і майже ніяких ускладнень не виникає, вам просто потрібно скопіювати та вставити ключ до іншого система.

Після його налаштування він просто працює.

Я стежу за AeroFS . Схоже, це може бути служба, схожа на Dropbox, де зберігання у хмарі необов’язково. Не знаю, чи / коли вони будуть реалізовувати мобільну підтримку, і я думаю, що це зажадає синхронізації цих файлів із хмарою. Мене насамперед цікавить досить безболісне рішення синхронізації між комп'ютерами Windows, Mac та Linux.

Вони на початку бета-версії, але ви можете зареєструватися на запрошення, якщо хочете.

Я використовую apache з mod_dav (webdav) для веб-сервера apache, можу встановити його як накопичувач та завантажувати / завантажувати файли через Інтернет. Це досить просто, але може охопити ваші потреби.

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

Тому я хочу поділитися власним досвідом. Моє поточне рішення для власного розміщеного хмарного середовища - Seafile .

Особливості морського файлу:

• Хмарний доступ до Інтернету
• Клієнти для Linux, Windows, Mac, iOS (не безкоштовно), Android
• Керування користувачами / групами
• Організація файлів через різні бібліотеки
• Автоматична синхронізація файлів через програмне забезпечення клієнта
• Можливість публікації файлів за допомогою створення загальнодоступних посилань

Мій досвід Seafile:

• Установка була мертвою легко та швидко! (на тонкому VM Debian, з файлами, що зберігаються через спільний доступ до фізичного хоста dmraid 5)
• Інтерфейс користувача чистий та функціональний
• Програмне забезпечення клієнта чисте та функціональне
• Там не було ні одного функціональних питань , для мене досі! (використовуючи це вже кілька тижнів)
• Набір функцій є базовим (порівняно з owncloud, наприклад), але наголошую, що тут все працює!
• Немає прямої підтримки проксі (принаймні для клієнта Linux - та веб-інтерфейсу!). Примітка: веб-інтерфейс працює, але завантаження файлів через веб-інтерфейс не працює за проксі-сервером - не знаю, чи можливо це якось можливо

Оскільки мені не потрібна підтримка проксі, я дуже задоволений Seafile!

Я використовую SSHFS для монтажу каталогів на своєму сервері як локальних каталогів на робочому столі та ноутбуці. Всі зміни файлів зберігаються безпосередньо на сервері. На відміну від dropbox, файли не зберігаються локально на ваших клієнтських машинах. Я думаю, що це чудово, тому що вам не потрібно турбуватися про синхронізацію та версію, але це не ідеально для використання в режимі офлайн або дуже великих файлів.

Це дуже прямо і просто, і я вважаю це найкращим рішенням. Єдине, для чого я не використовую це великі медіа, такі як фотографії та фільми, тому що всі файли отримують доступ через мережу. Ті, які я синхронізую з Rsync.

Посилання на документацію SSHFS -> http://fuse.sourceforge.net/sshfs.html