Файловый сервер — это достаточно мощный компьютер, который подключен к сети, наиболее часто такая сеть является локальная сеть (LAN), чья основная функция — служить в качестве централизованного хранилища данных на нескольких компьютерах в рамках клиент-серверной модели компьютерных сетей. Они доступны в ряде различных конфигурациях аппаратного и программного обеспечения. Файловые серверы иногда используются для создания резервных копий важнейших данных. Типичный файл-сервер будет настроен только для отправки и получения файлов, и не выполняет никаких активных процессов для пользователей. Они также могут быть настроены для распространения данных через Интернет с использованием FTP (передача файлов по протоколу) или http (гипертекстовый протокол передачи).
Любой современный компьютер может быть настроен для работы в качестве файлового сервера. Простой персональный компьютер разделяет файлы на протяжении всей домашней сети и работает как файл-сервер. В крупных организациях, файловый сервер, как правило — это выделенные компьютеры которые чаще всего оборудованы массивами очень больших устройств хранения. Наиболее специализированная форма файлового сервера, широко используемого в современной вычислительной схеме состоит из компьютеров, которые предназначены специально для того, чтобы служить только в качестве файловых серверов. Эти устройства обеспечивают сетевые системы хранения данных (NAS) с использованием оборудования, которое обычно настраивается, чтобы максимизировать только свою производительность в хранении и обмене данными и включает в себя только самые базовые методы ввода/вывода и обработки данных.

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

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

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

На мой взгляд, это очень отличная тема для описания. В своё время было интересно поднять какой-либо сервер на своём компьютере для более удобного обмена файлами. Попробовав различные и даже протокол, я понял, что мне они абсолютно не нравятся, первые выглядят в браузере, мягко говоря, убого, вторые хотя и имеют свои явные преимущества, но подключать сетевой диск на чужих компьютерах не хочется. Но в один (прекрасный и солнечный) день я встретил программу под названием HTTP File Server (сокращенно HFS), установил, настроил (так как я начинал работать с самой чистой версией, с этим были некоторые проблемы) и почти влюбился в эту программу. Для доступа к моим файлам теперь достаточно иметь любой браузер, так как весь доступ осуществляется, через обычную веб-страницу. Также у меня создана папка, в которую человек, знающий пароль, может добавить файл прямо через браузер. Файлы с сервера можно качать как по одному, так и сразу папками. Программа сама поместит папку в.tar архив без сжатия и отправит для скачивания. При этом сайт имеет довольно опрятный вид, хотя при желании (и достаточных знаниях) можно самому написать шаблон сайта. Признайте, что это отличный способ для легкой и удобной передачи файлов?

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

Хотя её меню полностью на английском языке, для меня это не является помехой. А для тех, кто плохо знает английский, в конце статьи я постараюсь максимально полно объяснить за что отвечают все разделы меню и как ими пользоваться.

Итак, перейдем к установке и настройке HTTP File Server:

1) Чтобы несколько сэкономить вам время, я приготовил сборку HFS с русскоязычным шаблоном сайта и произвел первоначальную настройку самой программы. Скачать сборку можно с моего Яндекс.Диск’а по ссылке . Если же вы уверены в своих способностях, то можете скачать чистую версию программу на официальном сайте http://www.rejetto.com/hfs/

На этом всё. Надеюсь эта статья оказалась вам полезной, нажмите одну из кнопок ниже, чтобы рассказать о ней друзьям. Также подпишитесь на обновления сайта, введя свой e-mail в поле справа.

Спасибо за внимание:)

8. Основные типы и классификация корпоративных систем.

9. Этапы жизненного цикла, поддерживаемые корпоративными системами.

10. Понятие платформы Microsoft .Net. Структура Microsoft.Net Framework. Программы для платформы Microsoft.Net.

11. Приемы и методы разработки графического интерфейса пользователя.

12. Библиотека классов Windows Forms. Объекты библиотеки.

13. Порядок построения формы ввода данных для корпоративных приложений на конкретном примере.

14. Особенности разработки распределенных приложений корпоративного типа технология Microsoft Remoting.

15. Общая последовательность на примере разработки распределенного высоконадежного и безопасного с использованием технологии Microsoft Remoting.

16. Концепция веб-сервиса. Инструментальные средства Microsoft используемые при создании сервисов.

17. Разработка сервисно-ориентированных корпоративных приложений.

18. Особенности и проблемы построения корпоративных приложений на основе сервисно-ориентированной архитектуры.

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

20. Структуры ис (физическая, логическая, программная, функциональная) и их взаимосвязь.

21. Подсистемы ис. Основные концептуальные принципы функционирования и построения.

22. Информационное, техническое, программное, математическое и другие виды обеспечения. Их характеристика и состав.

23. Характеристики аппаратно-программных платформы и их виды.

24. Программное обеспечение ис и его классификация.

25. Серверное и клиентское программное обеспечение.

26. Серверы управления (сетевые операционные системы) и задачи, решаемые с их помощью

27. Файловые серверы. Назначение и принципы работы.

28. Серверы терминалов. Серверы печати. Почтовые сервера. Принципы функционирования.

31. Характеристики iis (Internet Information Server or Microsoft). Брандмауэры. Прокси серверы.

32. Серверы приложений. Двухзвенная и трехзвенная архитектуры клиент-сервер. Общая схема сервера приложений.

33. Интерфейс сервера приложений. Тонкий, толстый клиент. Хранимые процедуры сервера приложений. Серверы безопасности их функции.

34. Протокол tcp/ip применительно к ис.

35. Задачи администрирования серверного программного обеспечения.

36. Приемы администрирования серверного программного обеспечения.

37. Стандартные и специализированные программные пакеты, и утилиты администрирования.

38. Dns, dhcp сервер.

37. Active Directory

40. Управление политики безопасности.

41. Эксплуатация различных видов серверного программного обеспечения аис и ее особенности.

42. Управление операционной системой с помощью консоли.

43. Настройка и эксплуатация файлового сервера.

1. Предварительная подготовка

2. Добавление серверу роли файлового сервера

44. Настройка и эксплуатация информационного сервера и сервера безопасности.

1. Понятие проект и управление проектами

2. Отличие проекта от других форм преобразования социально-экономической реальности. Признаки проекта.

3. Методология и стандарты управления проектами.

4. Внешняя и внутренняя среда проекта.

5. Проект как система. Системный подход к управлению проектами.

6. Цель и результат проекта.

7. Качественные и количественные требования к проекту.

8. Методология smart. Основные понятия и определения.

9. Методология prince2. Основные понятия и определения.

10. Жизненный цикл и структура проекта.

11. Команда проекта. Определение ролей проекта. Виды мотивации партнеров.

12. Организация проектного офиса.

13. Обязанности специалиста по проектной деятельности.

14. Классификация проектов по критериям менеджера и экономиста. Экономичная модель проекта.

15. Договорное регулирование проектной деятельности.

16. Типы контрактов в проектной детальности.

17. Разработка актуальности проекта. Анализ поля проблем.

22. Обеспечение хранения документов. Основные положения и обязанности.

23. Эффект и эффективность реализации проекта. Эффекты и индикаторы успешности реализации проекта.

24. Эффект и эффективность реализации проекта. Эффективность реализации проекта и ее виды.

25. Управление проектными рисками. Понятие риска и неопределенности.

26. Классификация проектных рисков.

27. Система управления проектными рисками. Основные подходы к оценке риска. Методы управления рисками.

28. Планирование проекта. Иерархическая структура работ.

29. Основные задачи планирования проекта. Иерархическая структура работ проекта.

30. Сетевой анализ и календарное планирование проекта. Функции сетевого анализа в планировании проекта. Анализ критического пути.

31. Определение длительности проекта при неопределенном времени операций. Распределение ресурсов. Разработка расписания проекта.

32. Диаграмма контрольных событий. Построение диаграммы контрольных событий.

33. Формирование финансовых ресурсов проекта. Основные статьи расходов. Оценка стоимости проекта.

34. Планирование затрат по проекту (бюджетирование). Контроль выполнения плана и условий финансирования.

35. Управление коммуникациями. Роль коммуникаций в проекте.

36. Планирование управления коммуникациями. Коммуникационные технологии.

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

5) Аккуратное форматирование и верстка текста.

Контрольный список по реализации коммуникаций

38. Матрица ответственности проекта.

39. Закрепление функций и полномочий в проекте. Реестр навыков.

40. Управление конфликтами. Управление ожиданиями стейкхолдеров проекта. Конфликты и их разрешение.

41. Контроль реализации проекта. Понятие качества и его применение в проектах. Планирование качества.

42. Мониторинг проекта. Управление изменениями. Управление конфигурацией.

43. Управление качеством проекта. Понятие качества и его применение в проектах. Планирование качества.

44. Обеспечение качества проекта. Контроль качества проекта.

46. Оценка реализуемости проектного расписания. Оценка достижимости и нагрузки человеческих ресурсов.

47. Фаза завышения проекта. Закрытие контрактов проекта.

48. Постаудит проекта. Основные программные продукты в управлении проектом.

49. Формирование итоговой ведомости проекта.

50. Дальнейшее развитие проекта. Масштабируемость проекта.

27. Файловые серверы. Назначение и принципы работы.

Ответ:

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

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

Файловые серверы иногда используются для создания резервных копий важнейших данных.

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

28. Серверы терминалов. Серверы печати. Почтовые сервера. Принципы функционирования.

Ответ:

Серверы терминалов

Терминальный сервер (сервер терминалов ) – это сервер, предоставляющий клиентам вычислительные ресурсы (процессорное время, память, дисковое пространство) для решения задач.

Терминальный сервер – это мощный компьютер (либо кластер), соединенный по сети с клиентами (маломощные компьютеры или устаревшие рабочие станции).

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

Серверы печати

Принт-сервер – это ПО или устройство, позволяющее группе пользователей проводных и беспроводных сетей совместно использовать принтер.

Почтовый сервер

Почтовый сервер – это сервер, получающий и отправляющий электронные сообщения.

Сервер, получающий электронные сообщения, работает по протоколу POP (Post Office Protocol).

Сервер, отправляющий электронные сообщения работает по протоколу SMTP (Simple Mail Transfer Protocol).

Почтовый сервер , сервер электронной почты, мейл-сервер – в системе пересылки электронной почты так обычно называют агент пересылки сообщений.

Это компьютерная программа , которая передаёт сообщения от одного компьютера к другому. Обычно почтовый сервер работает «за кулисами », а пользователи имеют дело с другой программой – клиентом электронной почты .

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

Почтовый сервер отправителя взаимодействует с почтовым сервером получателя. На почтовом сервере получателя сообщение попадает в почтовый ящик посредством агента доставки сообщений MDA . MDA может быть частью POP/IMAP сервера, частью SMTP сервера, или отдельным ПО. Для финальной доставки полученных сообщений используется POP3 или IMAP.

29. Веб-серверы, их функции. Методы взаимодействия с клиентом. Виды веб-серверов.

Ответ:

Веб-серверы, их функции

Веб-сервер – это программа, которая принимает входящие HTTP-запросы, обрабатывает эти запросы, генерирует HTTP-ответ и отправляет его клиенту.

Функции веб-серверов:

прием запроса от Web-броузера по протоколу HTTP с использованием TCP/IP;

поиск и отсылка файла гипертекста или документа в броузер по HTTP;

обслуживание запросов mailto, ftp, telnet и др.;

запуск прикладных программ на Web-сервере с передачей и возвратом параметров обработки через интерфейс CGI;

обслуживание навигационных карт изображения imagemap;

служит источником загружаемых программ на языке Java;

контроль доступа на основе имен и паролей доступа;

ведение регистрационного журнала;

административное и оперативное управление сервером.

Взаимодействие с клиентом:

После того, как пользователь обратился к определенному ресурсу по протоколу HTTP, клиент (обычно браузер) формирует HTTP-запрос к веб-серверу. Обычно указывается символическое имя сервера (например, "http://www.microsoft.com") – в этом случае браузер предварительно преобразует это имя в IP-адрес при помощи сервисов DNS. После этого по протоколу HTTP на веб-сервер отправляется сформированное HTTP-сообщение. В этом сообщении браузер указывает какой ресурс необходимо загрузить и всю дополнительную информацию. Задача веб-сервера – прослушивать определенный TCP-порт (обычно порт 80) и принимать все входящие HTTP-сообщения. Если входящие данные не соответствуют формату сообщения HTTP, то такой запрос игнорируется, а клиенту возвращается сообщение об ошибке.

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

Виды веб-серверов:

Статический веб-сервер – состоит из компьютера с сервером. Сервер посылает различные файлы в браузер «как есть».

Динамический веб-сервер – состоит из статического плюс динамического ПО, наиболее часто с сервером приложений и БД. Сервер приложений изменяет исходник файла перед отправкой в веб-браузер по НТТР.

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

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

Рисунок 13 Нагрузка на процессор файлового сервера

Как видно из диаграмм нагрузки, данные аппаратные платформы более чем справляются с возложенными на них обязанностями, даже в моменты пиковой загрузки потенциал аппаратных средств не задействуется на все 100%. Таким образом, физические ресурсы используются нерационально. Фактически, для полноценной работы системы, будет достаточно как минимум вдвое меньшее количество серверов. Но сократить их количество не представляется возможным, ввиду некоторых особенностей. К примеру, в некоторых случаях, невозможно установить несколько программных комплексов в связи с их несовместимостью, или конфликтов по приоритетам доступа к аппаратным средствам. Например, файловые сервера в некоторых случаях удобно использовать на платформе Windows, а специализированные сервера приложение (к примеру Oracle), на Linux. Таким образом, сервис отвечающий за файловый сервер, базирующийся на платформе Windows, уже не сможет совмещать функции сервера приложений на базе Linux, ввиду конфликта программного обеспечения. С экономической точки это является значительным минусом, так как перспективы в использовании избыточных ресурсов практически нулевые.

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

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

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

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

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

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

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

Нет похожих статей.

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

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

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

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

Что требуется?

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

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

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

OwnCloud

Недавно вышла новая версия (4.5) системы для организации хранения, синхронизации и обмена данными OwnCloud. Ранее на Хабрахабре уже появлялась замечательная об OwnCloud, которая и мотивировала меня познакомиться с облаком поближе.
Об особенностях процесса установки OwnCloud хабраюзером была написана прекрасная статья .
Первое впечатление было просто волшебным: современный 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

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

UPD: Amahi

Благодаря , мы узнали об 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) и др. Более подробно прошу на