Общие положения

Прежде чем перейти к практической реализации, сперва нужно спланировать файлообменную систему и учесть приемущества\недостатки\особенности различных операционных систем. Об этом и пойдёт речь в этой статье.

Варианты организации

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

1. Децентрализованный

Иллюстрация децентрализованного варианта организации

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

2. Централизованный

Иллюстрация централизованного варианта организации (с сервером)

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

  • нет необходимости на домашних машинах ставить большие по объёму накопители;
  • файлы доступны всегда и всем, пока сервер работает. Также можно настроить доступ по логину\паролю к отдельным каталогам на сервере;
  • более простое администрирование;

Есть также и недостатки:

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

Выбор программных средств

Немного о выборе программных средств для организации файлообмена. Есть множество технологий связать компьютеры для передачи файлов. Учитывая, что в нашей сети присутствуют компьютеры с разными операционными системами, должен работать какой-то общий протокол, который бы был понятен каждой операционной системе. С точки зрения сетевых протоколов, простоты реализации, удобства и безопасности, для нашей сети подойдёт вариант приведения сети к "сети Майкрософт". Другими словами, не-Windows-компьютеры мы настроим так, чтобы они взаимодействовали с компьютерами Windows. В этом нам поможет пакет SAMBA - свободная реализация протокола SMB/CIFS (протокол используется в сетях Майкрософт).

SAMBA в сети Microsoft Windows

Для понимания, какие компоненты задействуются в операционных системах, рассмотрим схему ниже:

Компоненты и взаимодействие

Сеть Windows имеет клиент-серверную архитектуру. Каждый компьютер может выступать одновременно как сервером - представителем ресурсов, так и клиентом - получателем ресурсов. Разберём отдельно 2 этих случая: слева, в роли сервера выступает компьютер с Windows. Файлообменный (ресурсообменный) функционал выполнен в виде служб "Сервер" и "Служба доступа к файлам и принтерам". Любой каталог в локальной файловой системе может быть расшарен (опубликован) в сети посредством этих компонентов. Если в качестве клиента выступает тоже Windows-машина, то за клиентский функционал отвечает компонент "Клиент для сетей Майкрософт". Если в качестве клиента выступает *nix-машина, то взаимодействие обеспечивается библиотекой smbclient, входящей в состав пакета SAMBA. На рисунке слева изображён случай, когда на Windows-машине публикуются каталоги Dir1 и Dir2, они становятся доступны по сети и любой компьютер может "подключить" (примонтировать) эти каталоги к локальной файловой системе. Работа с сетевыми каталогами практически не отличается от работы с каталогами в локальной файловой системе.

На рисунке справа, изображён вариант, когда *nix-машина выступает в качестве сервера. В этом случае, функционал представителя ресурсов выполняет даемон smbd пакета SAMBA, который публикует в сеть каталоги Dir1 и Dir2. Windows-машина использует их как: 1) подключает их в виде устройств с буквами D,E,F, и тд. или 2) проецирует на какие-то каталоги локальной файловой системы или 3) пользователь получает доступ через "Обозреватель сети" (в этом случае "подключения" (монтирования) не происходит.

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

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

Модель схемы домашней сети

Самый простой способ всех пользовавателей Windows-машин - это открыть полный доступ целиком к диску или дискам, чтобы была возможность записывать и читать все файлы. Как показывает практика, так делают практически все пользователи Windows-машин, но ЭТО НЕПРАВИЛЬНЫЙ МЕТОД! Если на одном из компьютеров появится вирус, все Windows-компьютеры в сети будут заражены за несколько секунд. Представьте также, что у вас дипломная работа, а дети по сети взяли и удалили всё содержимое диска C:

Чтобы не происходило таких казусов, нужно чётко планировать что нужно сделать доступным в сети, а что нет. Логично будет на каждом компьютере разрешить доступ "только на чтение" к каталогам, где хранятся данные, которые нужно только читать, не не изменять. Для обмена между машинами, нужно сделать каталог с правами на "чтение и запись" и использовать при обмене данными только его. Например, на comp1 есть коллекция музыки в /data/music и видео в /data/video - чтобы кто-то из домочадцев не стёр по ошибке эти коллекции, эти каталоги нужно публиковать с правами "только чтение". Рассуждаем дальше: например, пользователю comp4 нужно передавать файлы на comp1 - эта задача решается 2-мя способами:

  1. На comp4 организовать каталог (например C:\Documents) и опубликовать его в сети с правами "только чтение", чтобы пользователь comp1 имел возможность по сети скопировать с него информацию. Недостаток такого способа - необходимость копировать данные в нужный каталог и недоступность данных, если компьютер выключен;
  2. На comp1 создаётся каталог (например /data/tmp) с правами "чтение-запись" для всех и остальные пользователи записывают в него необходимые документы. Таким образом данные становятся доступны даже после выключения comp4.

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

В Windows есть 2 способа публикации каталогов в сети - "простой" и "расширенный". "Простой" способ обеспечивает простоту в настройке, без привязки к правам доступа - подключение к ресурсу возможно без указания логина\пароля т.е. гостевой вход.

С Linux немного сложнее - нужно учитывать (соответственно и конфигурировать) и локальные права к файлам и каталогам и сетевые. Особенность здесь заключается при работе каталога с правами чтение-запись. Например, на машине comp1 заведён пользователь user1 . В сеть публикуется 3 каталога:

  • Только чтение: /data/video
  • Только чтение: /data/music
  • Чтение и запись: /data/tmp

Все файлы, которые находятся в подкаталогах этих каталогов должны иметь доступ на "чтение" "для всех". Для каталогов - "чтение" и "выполнение" "для всех" . По умолчанию, любой создаваемый файл или каталог имеют такие разрешения и файлы\каталоги в video и music будут без проблем доступны по сети. Иначе дело обстоит с каталогом tmp: предположим, что пользователь user1 на этом же компьютере записал в него файл. По умолчанию этот файл запрещён для модификации "для всех", но модификация разрешена для него самого и группы в которой он состоит по умолчанию, поэтому файл можно будет только скопировать из этого каталога через сеть. Тоже относится и к каталогам. Получается несколько ограниченный доступ, а не полный.

Обратные процесс несколько проще - если же с других компьютеров в каталог tmp по сети записывается файл, то SAMBA сама назначит файлам или каталогам права того или иного пользователя. Например, можно настроить чтобы все файлы, которые были записаны через сеть в этот каталог, изменяли владельца на user1. На этом же компьютере user1 может без проблем этот файл модифицировать. Однако, если на данном компьютере работает не один пользователь, а несколько, то придётся этих пользователей объединить в группу и настроить SAMB`у так, чтобы владелец файлов\каталогов менялся на имя группы, а не только одного пользователя. В этом случае доступ к файлам в tmp будет у всех локальных и сетевых пользователей.

В среде с разными операционными системами также следует позаботиться о кодировках имён файлов. В Windows, по умолчанию, для кириллицы применяется кодовая таблица cp866, в Linux и MacOS - UTF-8, FreeBSD - koi8-ru. Обычно в таких случаях имена файлов\каталогов, транслируемые в рамках сетевых соединений CIFS оставляют в кодировке cp866, но сами имена файлов\каталогов при сохранении или отображении в *nix системах конвертируются SAMB`ой в UTF-8. Другими словами, все подстраиваются под Windows ^-^

Монтирование сетевых ресурсов

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

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

Для монтирования и автомонтирования ресурсов, используются такие средства:

  • в Windows - функция "Подключить сетевой диск" с восстановлением подключения,
  • в Linux - демон autofs, позволяющий подключать ресурс по мере обращения к нему. Монтирование через fstab в децентрализованной системе не сработает, если машина с ресурсом будет отключена.
  • в MacOS - нет информации.

Практическая реализация

Практическая реализация централизованного и децентрализованного варианта вынесена в отдельные статьи:

Смотрите также
Печать/экспорт