CUPS SAMBA

Доброго времени, гости и читатели блога! Сегодня продолжу рассматривать возможности пакета SAMBA. Перед прочтением данного материала я бы посоветовал ознакомиться со статьями основы SAMBA и CUPS. Итак, из прошлых статей мы знаем как установить пакет samba. После установки, файлы пакета могут располагаться в следующих каталогах:

  • Демоны и утилиты помещаются в каталог: /usr/sbin
  • Файлы настройки в: /etc/samba/
  • Файлы журналов в: /var/log/samba/
  • Некоторые управляющие файлы помещаются в: /var/lib/samba

конечно, возможны некоторые отклонения, например в старых версиях SAMBA настройки хранятся в /etc, а логи в /var/log, при сборке из исходников, samba устанавливается в /usr/local/samba. Т.о. можно убедиться, что SAMBA у нас установлена.

Настройка SAMBA

Настройка SAMBA заключается в редактировании конфигурационного файла /etc/samba/smb.conf. Структура конфига самба схожа с форматом файлов .ini в Windows и представляет собой записи вида:

[stanza0]
   key0=value0
   key1=value1
[stanza1]
   key0=value0
   key1=value1

То есть параметры, они же ключи (key0, key1 и т.д.) собраны в группы, которые называют стансами или строфами (stanza0, stanza1 и т.д.), название которых заключены в фигурные скобки. Каждый каталог или принтер, предоставляемый в общий доступ в Windows называется разделяемым ресурсом (share) или сервисом (service), или в простой терминологии — шАра :) Каждый ресурс можно представить в Linux отдельным разделом строфой с особым именем и набором параметров. SAMBA понимает громадное количество параметров, с которыми можно ознакомиться тут man smb.conf. Я опишу основные. Существует так же специальный раздел [global], хранящий параметры по умолчанию ко всем сервисам и к серверу в целом. Для начала, я бы посоветовал скопировать оригинальный файл (т.к. в нем большое количество комментариев, с которыми на досуге можно ознакомиться) и создать (например, с помощью редактора vi) на его месте новый, со следующими параметрами:

samba-server:~# cp /etc/samba/smb.conf /etc/samba/smb.conf.orig
samba-server:~# cat /etc/samba/smb.conf
[global]
 workgroup = WORKGROUP
 netbios name = SAMBA
 printing = CUPS
 wins support = yes
[homes]
 browsable = no
 read only = no
[printers]
 printable = yes
 printing = CUPS
 path = /var/spool/samba
[data]
 path = /export/data
 read only = no
 map archive = no

Давайте разберем параметры и разделы по порядку:

[global]

Как уже говорилось — содержит параметры, настраивающие пакет SAMBA в целом. Параметр workgroup определяет имя рабочей группы, к которой принадлежит сервер samba. Соответственно, если есть необходимость — нужно переименовать группу на подходящую Вам. Данный параметр необязательный, если его не указывать, то сервер будет принадлежать группе WORKGROUP. Далее, параметр netbios name, который указывает на имя сервера, которое будет отображаться в сетевом окружении Windows. Данный параметр так же необязательный, если его не указывать, то сервер будет отображаться под именем локального хоста (которое можно узнать командой echo $HOSTNAME). Тут необходимо сделать акцент на том, что указывать значение localhost в данном параметре неприемлемо, т.к. данное имя на машинах Wondows всегда будет разрешаться в адрес 127.0.0.1. Так же, в данном станзе можно указать параметр encrypt passwords, который указывает SAMBA шифровать пароли. Это необходимо для клиентов с ОС версией выше windows 98. Если используется версия SAMBA выше 3.0, то данный параметр указывать не обязательно, т.к. он используется по умолчанию. Параметр wins support требует от samba работать в качестве WINS сервера, это не обязательно, но способствует более эффективной работе, о чем я говорил в прошлой статье о SAMBA. Если Ваш Samba сервер использует несколько сетевых интерфейсов, то можно явно указать, на каком из интерфейсов слушать подключения с помощью параметра: interfaces = 192.168.1.1/24.

[homes]

Раздел [homes] определяет виртуальный сервис, указывая SAMBA автоматически расшаривать домашний каталог пользователя. То есть, при подключении к серверу SAMBA производится поиск имени пользователя в файле /etc/passwd и если в локальной системе есть учетная запись пользователя и она имеет домашний каталог, то данный каталог раcшаривается для подключенного пользователя. Параметр read only = no указывает предоставлять домашние каталоги в режиме чтения-записи. Параметр browsable=no указывает не отображать каталог homes в списке расшаренных ресурсов (но домашний каталог подключенного пользователя будет виден пользователю). Данное разрешение учитывает права доступа в Linux, то есть если файл в расшаренной папке с правами только на чтение, то он не станет доступным на запись. Иначе сказав: сервер не предоставит доступа больше чем UNIX система. В данной директории так же полезно указать параметр path = /path/to/homedir/%S, если вы хотите разделить системные домашние папки от расшариваемых.

[printers]

Раздел [printers], в  SAMBA, хранит настройки печати, то есть SAMBA получает указание сделать принтеры, подключенные к системе Linux, доступными клиентам сети. Точнее будет сказать, что данный раздел определяет доступ ко всем принтерам, указанным в файле /etc/printcap. Разделы, они же строфы, которые определяют совместно используемый принтер, включая раздел [printers] должен содержать строку printable = yes. Для доступа к принтерам, необходимо прописать в файле /etc/printcap настройки доступа к принтеру. Параметр printing = CUPS указывает использовать систему печати CUPS (возможно так же указать более старые системы печати, такие как BSD и LPRNG). Для того чтобы использовать свой файл printcap, необходимо его создать и указать в виде параметра printcap = /path/to/printcap. Параметр path = /var/spool/samba указывает, где будет размещен спулер (каталог временного хранилища очереди печати). Для данного каталога необходим установленный StickyBit.

[data]

Данный раздел приведен в качестве примера, как открыть совместный доступ к каталогу. Следуя данному примеру можно расшарить сколько угодно каталогов, указав для каждого свое имя раздела и значение path. Название раздела используется в качестве имени разделяемого ресурса и отображается клиентам Windows, как папка с таким именем. Параметр, отвечающий за функциональность, описанную ниже — map archive — установлен в no.

SAMBA не всегда выполняет задачу — заставить файловую систему UNIX выглядеть как файловая система Windows для клиентов Windows. Одно из различий между файловыми системами Windows и UNIX в том, что в Windows существует атрибут archive, с помощью которого программы резервного копирования определяют, был ли файл модифицирован с момента последнего копирования. В UNIX прямого аналога данного атрибута нет. SAMBA моделирует данный атрибут архивации с помощью бита исполнения для владельца файла UNIX. Данный костыль позволяет программам резервного копирования Windows корректно производить инкрементальное резервное копирование с ресурсов SAMBA. Но есть побочный эффект — файлы с данным атрибутом выглядят в Linux как исполняемые. В конфиге SAMBA в странсе [data] параметр, отвечающий за данную функцию называется map archive.

Хочу отметить кое-какие характеристики при разборе файла smb.conf:

  • Имена разделов и параметров не чувствительны к регистру.
  • Только первый символ равенства значимый.
  • Пробелы до и после первого символа равенства игнорируются.
  • Начальные, концевые и внутренние пробелы некорректны в названиях секций и именах параметров.
  • Начальные и концевые пробелы в значении параметров игнорируются.
  • Внутренний пробел в значении параметра сохраняется дословно.
  • Все строки начинающиеся с символа «;» с запятой или «#» игнорируются как строки содержащие только пробел (комментируются).
  • Все строки оканчивающиеся символом «\» продолжаются на следующей строке в стиле UNIX.
  • Значения после символа равенства в параметрах содержат строку (без кавычек) или логическое значение, как то да/нет, 0/1 или истина/ложь.
  • Регистр не имеет значения в логических значениях, но сохраняется в строковых значениях.

После внесения изменений в конфигурационный файл, необходимо проверить его на корректность. Для этого есть команда testparm. Данная программа проверяет наличие ошибок и несовместимостей в конфигурационном файле SAMBA. Очень хорошая практика — документировать конфигурационные файлы. Но данная практика вступает в противоречие со способом, которым работает самба. Конфигурационный файл очень часто перечитывается демоном smbd, т.о. чем больше строк в файле и чем больше его объем, тем больше это сказывается на производительности системы. Для решения данной проблемы необходимо создать «редактируемый» конфиг, в котором все описано как нужно и из редактируемого файла создать рабочий с помощью команды:

samba-server: ~# testparam -s /etc/samba/smb.conf.edit > /etc/samba/smb.conf

Из редактируемого файла будут удалены все комментарии и будут находится только те параметры, которые отличаются от значения по умолчанию. Так же, стоит отметить, что из файла будут удалены все макросы, которые необходимо будет восстановить вручную. Например, строка include=/etc/samba/%m.conf превратиться в строку include=/etc/samba/.conf.

После запуска проверки параметров командой testparm возможно вы увидите дамп конфига, в котором отсутствуют некоторые наши параметры. Это говорит о том, что данные параметры совпадают с параметрами Samba по-умолчанию.

Запуск сервера SAMBA

Основу Samba составляют три демона, два из которых необходимы всегда:

nmbd

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

smbd

Демон smbd обслуживает все соединения на базе протоколов TCP/IP к сервисам доступа к файлам и к принтерам. Кроме этого, демон заведует процессом локальной аутентификации. Должен запускаться сразу после nmbd.

winbindd

Демон winbindd должен запускаться, когда сервер Samba выступает в роли члена домена Win NT4 или Active Directory. Запуск так же необходим, когда Samba вступает в доверительные отношения с другим доменом. Демон winbindd проверяет файл smb.conf на наличие параметров idmap id и idmap gid, которые затем будут использоваться для отображения идентификаторов системы безопасности Windows (SID).  Указываемый в этих параметрах диапазон не должен находится в противоречии с уже используемыми в системе идентификаторами (начало значений пользовательских ID указывается в файле /etc/login.defs). Если указанные параметры не заданы, то демон winbindd не будет выполнять отображение Windows SID, а аутентификация будет выполняться только на уровне аутентификации пользователей.

Запуск данных демонов возможен как в standealone режиме, так и с помощью супердемона xinetd. В первом случае службы запущены постоянно и прослушивают сетевой интерфейс, во втором, службы запускаются с помощью демона inetd/xinetd и отвечают на запросы только при поступлении запроса от клиента. Для запуска Samba с помощью  супердемона необходимо добавить описание запуска в конфигурационный файл /etc/inetd.conf для inetd или /etc/xinetd.conf для xinetd. Супердемону xinetd обязательно посвящу отдельную тему и на сегодня с xinetd остановим обсуждение.

Запуск демонов Samba

Об уровнях выполнения, можно почитать тут. Данный демон должен быть разрешен для запуска на необходимых уровнях выполнения ОС (команда в RedHat-подобных дистрибутивах — /sbin/chkconfig samba on, в Debian — /usr/sbin/update-rc.d samba defaults). Хотя я и не делал акцент на сборку Samba из исходников, но описание запуска все же затрону для общего понимания. Итак, после сборки Samba, в двоичном пакете необходимо отыскать сценарий, который будет запускать и останавливать демоны в необходимом порядке. При этом необходимо проверить сценарий на корректность имен каталогов, где лежит исполняемый файл демона. Сценарий необходимо сделать исполняемым с помощью команды chmod +x,  положить в каталог /etc/init.d/ и создать соответствующие ссылки на скрипт в каталогах уровней запуска Linux (/etc/rc*.d), в которых необходим запуск демона и соответственно — остановка.

Запуск демона из bash вручную производится командой:

samba-server: ~# /etc/init.d/samba start

соответственно, для остановки заменить start на stop, для перезапуска restart.

Проверка Samba

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

samba-server:~# smbclient -L localhost -U%
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.6]

 Sharename       Type      Comment
 ---------       ----      -------
 data            Disk
 IPC$            IPC       IPC Service (Samba 3.5.6)
 it_216          Printer   Printer
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.6]

 Server               Comment
 ---------            -------
 HOST
 SAMBA                Samba 3.5.6

 Workgroup            Master
 ---------            -------
 WORKGROUP            SAMBA

Полученные результаты показывают, что сервер SAMBA допускает возможность анонимного подключения. В данном случае подключившийся пользователь получает права доступа гостевой учетной записи, которая обычно соответствует учетной записи пользователя nobody в файле /etc/passwd. Если на данном шаге получить информацию не удалось, то это означает, что трафик Samba блокируется фаерволом, либо гостевая учетка не была найдена в файле /etc/passwd.

Так же, в диагностике отлично помогает утилита smbstatus, которая отображает текущих подключенных клиентов.

Добавление пользователей

В нашей конфигурации клиенты должны быть аутентифицированы Samba, чтобы получить доступ к разделяемым ресурсам. От клиента требуется указать имя и пароль, которые имеются на хосте Linux, а так же, если в smb.conf есть раздел [homes], то у пользователя должен быть домашний каталог. Об управлении пользователями в Linux можно почитать тут. Обычно, добавление пользователей в Linux производится командой:

samba-server: ~# useradd -m username

Кроме того, у Samba есть свой файл паролей /etc/samba/smbpasswd, хранящий Microsoft Windows-совместимые зашифрованные пароли. Для каждого пользователя необходимо выполнить команду smbpasswd, чтобы добавить учетную запись Samba для этого пользователя. При этом, имя и пароль должны соответствовать тем, которые имеются у учетных записей Linux:

samba-server:~# smbpasswd -a username
New SMB password:
Retype new SMB password:

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

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

Для начала, необходимо понимание, как организовать гостевой доступ к серверу samba. В разделе глобальных параметров [global] есть такой параметр как security, который отвечает за порядок доступа к расшаренным ресурсам. Данный параметр определяет режим безопасности для доступа к серверу и может принимать следующие значения:

USER

Значение USER используется по-умолчанию (в версиях Samba от 3.0 и выше), даже если параметр не задан в smb.conf. При этом параметре, клиент должен сначала произвести вход, с существующим именем пользователя и паролем Linux.

SHARE

Значение SHARE в старых версиях Samba использовалось по-умолчанию. При подключении к ресурсу с параметром security = SHARE клиентам не нужно регистрироваться с использованием действительного имени пользователя и пароля. Вместо этого, клиенты посылают информацию аутентификации (пароли) на конкретный ресурс, в тот момент, когда хотят получить доступ к этому ресурсу. Заметьте, что демон smbd ВСЕГДА использует реального пользователя UNIX, когда обслуживает клиента, даже если установлено security = SHARE. Т.к. в режиме SHARE от пользователя не требуется посыла его имени, smbd использует несколько приемов для определения пользователя UNIX.

Список предполагаемых имен пользователей UNIX и соответствующих им паролей определяется следующим образом:

  • Если установлен параметр guest only, тогда все остальные сценарии пропускаются и используется только имя гостевой учетки (guest account).
  • Если имя пользователя послано вместе с запросом на установление соединения после сопоставления (см. параметр username map), добавляется в список.
  • Если клиент выполнял запрос logon (вызов SessionSetup SMB), тогда имя пользователя, использовавшееся в этом вызове будет добавлено в список.
  • Если параметр guest only не установлен, тогда этот список пользователей обрабатывается с соответствующими паролями. Первый пользователь, пароль которого совпадет с реальным будет использован в качестве действующего пользователя UNIX.
  • Если параметр guest only установлен или не найдено подходящего имени пользователя, тогда, если Samba разрешено «принимать гостей» (usershare allow guests), будет использоваться гостевая учетка, в противном случае доступ будет запрещен.

Существуют так же такие значения параметра security, как SERVER, ADS и DOMAIN, которые используют удаленную аутентификацию. Но в данной статье я не буду затрагивать данные параметры.

Итак, из изложенного становиться понятно, что для гостевого доступа к серверу необходимо использовать параметр security = SHAREЧтобы не вникать в схему работы сопоставления пользователей запрашивающих доступ к ресурсам samba и локальных системных пользователей linux, предлагаю пойти по пути первого шага и задать параметр guest only.

При этом, чтобы система знала, с кем ассоциировать гостевую учетную запись, то есть с какой учетной записью UNIX ассоциировать неизвестного подключенного клиента, необходимо указать параметр guest account, равный одной из системной учетной записи Linux. Естественно, данная учетная запись Linux должна иметь необходимый доступ к разделяемым ресурсам, чтобы не возникло вопросов с удалением/добавлением/изменением файлов. Давайте взглянем на рабочий файл файлопомойки:

samba-server:~# cat /etc/samba/smb.conf
[global]
 netbios name = SAMBA
 security = SHARE
 guest account = dostup
 wins support = Yes
[printers]
 path = /var/spool/samba
 guest only = Yes
 read only = No
 printable = Yes
 browseable = No
[obmennik]
 path = /tmp/obmen
 guest only = Yes
 force user = dostup
 force group = dostup
 read only = No
 create mask = 0777
 directory mask = 0777
 guest only = Yes

Как видно, в нашем конфиге появилось несколько уже известных нам параметров и параметров, о которых мы не говорили… Итак по порядку: параметр guest account задает имя учетной записи Linux, с помощью которой анонимные пользователи будут получать доступ к разделяемым ресурсам. Данный пользователь (в нашем случае — dostup) должен  иметь права на чтение и запись в каталог, который будет указан в разделяемом ресурсе (в нашем примере — раздел [obmennik] и каталог /tmp/obmen). Следующий параметр guest only — разрешает только гостевые соединения к общему ресурсу, то есть для сетевого ресурса нет необходимости указывать пароль. Далее появились 2 параметра — force user и force group, которые определяют владельца и группу Linux, с правами которых в разделяемом ресурсе будут создаваться файлы и каталоги при гостевом доступе. Параметры create mask и directory mask, не трудно догадаться, что это маски прав доступа для создания файлов. (Без данных параметров у меня на Debian 6 и samba присваивались права rwxr—r— на файлы в подкаталогах расшаренного ресурса, в результате чего было невозможно удалить созданные файлы.) Вот собственно и весь конфиг.

Примечание: указывать параметр guest account нет особой необходимости. При установке samba через пакетный менеджер, по умолчанию уже будет задан некий пользователь (скорей всего nobody). Узнать, какой пользователь задан по умолчанию можно командой /usr/bin/testparm -sv /etc/samba/smb.conf | grep acco. При этом, необходимо учитывать права доступа заданного пользователя на файловую систему.

Автоматическая загрузка драйвера принтера

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

Итак, в Linux есть два способа сделать системный принтер доступным для совместного использования клиентами Windows.  Первый — в режиме неформатированных данных (raw mode), второй — интеллектуальный режим (smart mode). Давайте рассмотрим оба способа.

режим неформатированных данных (raw mode)

В raw mode система печати просто передает на принтер полученное задание для печати без какой-либо обработки. Для работы CUPS в режиме неформатированных данных, необходимо указать в конфиге параметр cups option — raw. Если данный параметр отсутствует и CUPS получит задание для печати, которое содержит последовательность фильтров не известное системе печати, то задание может быть удалено так и не увидев бумагу. Чтобы исправить данную ситуацию, необходимо отредактировать файлы /etc/cups/mime.types и /etc/cups/mime.convs и раскомментировать строку application/octet-stream. Данное действие позволит CUPS отправлять на принтер задания с неизвестными последовательностями символов.

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

интеллектуальный режим (smart mode)

Для режима smart mode необходимо установить на сервере CUPS локальную систему фильтрации. В данном режиме, сервер будет пытаться интерпретировать тип файла, отправленный на принтер, и затем фильтровать данные, автоматически выбирая преобразование соответствующие принтеру. При работе CUPS в интеллектуальном режиме, на клиенты Windows допускается использовать драйвер CUPS Post Script. Данный режим мы рассматривать не будем.

Итак, режим RAW. Давайте подредактируем конфигурационный файл /etc/samba/smb.conf до следующего вида и рассмотрим его параметры:

samba-server:# cat /etc/samba/smb.conf
[global]
 workgroup = WORKGROUP
 printing = CUPS
 wins support = yes
 netbios name = SAMBA
 security = SHARE
 guest account = dostup
 cups options = raw
 show add printer wizard = yes
 printer admin = root, dostup
[printers]
 comment = Очередь печати SMB
 printable = yes
 path = /var/spool/samba
 guest only = Yes
 guest ok = yes
 read only = No
[print$]
 comment = Драйверы принтера
 path = /var/lib/samba/drivers
 guest only = Yes
 guest ok = yes
 read only = No
 create mask = 0777
 directory mask = 0777
 force user = dostup
 force group = dostup
 write list = root, dostup
[obmennik]
 path = /share/obmen
 guest only = Yes
 guest ok = yes
 read only = No
 create mask = 0777
 directory mask = 0777
 force user = dostup
 force group = dostup

общий ресурс драйверов принтеров WindowsУ нас добавились следующие пункты: параметр cups options, который определяет режим raw и раздел [print$], аналогичный общему ресурсу Windows (\\host\print$), в котором хранятся файлы драйверов, параметр printer admin задает пользователей Linux, которым разрешено иметь полный доступ для управления свойствами расшаренных принтеров, а так же параметр write list, задающий список пользователей Linux, имеющих право добавлять драйвер в ресурс [print$]. Для корректной работы ресурса [print$], нам необходимо создать указанный в параметре path каталог со структурой аналогичной Windows, для этого необходимо выполнить следующее:

samba-server:~# mkdir /var/lib/samba/drivers
samba-server:~# cd /var/lib/samba/
samba-server:/var/lib/samba# mkdir -p drivers/{W32ALPHA,W32MIPS,W32PPC}
samba-server:/var/lib/samba# mkdir -p drivers/{W32X86/{2,3},WIN40,COLOR,IA64,x64}
samba-server:/var/lib/samba# chown -R dostup:root drivers
samba-server:/var/lib/samba# chmod -R u+rwx,g+rwx,o+rx-w drivers

Далее, необходимо установить и настроить локальные принтеры в систему печати. Для загрузки драйверов в SAMBA, после установки принтеров, необходимо выполнить следующие шаги (шаги рассматриваются на ОС Windows XP):

  1. Загрузить Windows и залогинется.
  2. отображение каталога принетры и факсыВ сетевом окружении найти машину, которую мы планируем использовать для общего доступа и как сервер печати. (в нашем случае — samba). При этом, должен отобразиться список общих ресурсов и расшаренных принтеров, а так же специальная папка «Принтеры и факсы«. Если данного каталога нет, то скорее всего удален куст реестра, отвечающий за его отображение. Для восстановления, необходимо скачать файл и из архива импортировать в реестр его параметры.
  3. В данном каталоге будет список принтеров Samba. Из списка выбираем правой кнопкой необходимый нам принтер (тот, для которого хотим организовать загрузку драйверов), нажимаем «Свойства«. При этом появиться предложение на установку драйверов данного принтера — НЕ соглашаемся. Далее появиться сообщение «Сервер для данного принтера не имеет требуемого установленного драйвера принтера сервер печати….» — нажимаем Отмена.
  4. копирование драйвера принтера на сервер самбаПереходим на вкладку «Дополнительно» и напротив поля «Драйвер» нажимаем «Сменить…«. При этом запуститься «Мастер установки драйверов принтера на «имя_сервера_печати»», нажимаем Далее и отвечаем на вопросы местера. На втором шаге, драйвер желательно устанавливать свежий, скачанный с сайта производителя принтера. После выбора драйвера и нажатия кнопки «Готово» начнется копирование драйвера на сервер-samba!!!
  5. После данной процедуры при установке принтера на клиента Windows, драйвер должен устанавливаться автоматически.

Фух, тяжелая получилась статься и немного размытая. Надеюсь, что будет понятно.

Резюме.

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

GNS3 установка и запуск Cisco Routers and Switches

Качаем программу GNS3 с официального сайта, регаемся там и скачиваем https://www.gns3.com/  файлик на конце all-in-one

я обычно ставлю полный пакет включая wireshark и прочее. Мало ли надо будет определить почему не ходит трафик и тд.

далее с рутрэкера качаем пакет ios cisco, там представлено куча разных иосов для роутеро и тд. Есть небольшое лирическое отступление, на GNS3 нельзя реализовать виртуализацию cisco catalyst коммутаторов (коммутаторы 3 уровня, модели OSI).

 

 

Bind

Настройка DNS -сервера BIND

# named -v
BIND 9.4.3-P2

Расположение файлов BIND:

> tree /var/named/
/var/named/
|-- dev
|-- etc
|   `-- namedb #Каталог, в котором располагается вся информация о зонах BIND
|       |-- dynamic
|       |-- master
|       |   |-- empty.db
|       |   |-- localhost-forward.db
|       |   `-- localhost-reverse.db
|       |-- named.conf #Конфигурационный файл для даемона
|       |-- named.root 
|       `-- slave
`-- var
    |-- dump
    |-- log
    |-- run
    |   `-- named
    `-- stats

Разрешаем запуск DNS сервера:

# echo 'named_enable="YES"' >> /etc/rc.conf

Файл зоны

  • Синтаксис файлов зон

    ; - коментарий
    @ - символ подставновки. Подставляется имя домена из named.conf (название файла зоны) или если задан переменная $ORIGIN
    () - используется для переноса длинных строк.

named.root или db.root обновление

Файл named.root (db.root) содержит списки корневых серверов DNS. Этот файл меняется достаточно редко, но его последнюю официальную версию всегда можно скачать с ftp.internic.net (ftp.rs.internic.net). Содержимое db.root (иногда называемого named.ca для «certifying authority») носит достаточно специальный характер. Оно представляет из себя описание набора канонических корневых серверов, собственно регистрирующих домены.

> pwd
/var/named/etc/namedb
> fetch ftp://ftp.internic.net/domain/named.root
named.root                                    100% of 2994  B 4470 kBps

resolv.conf

Редактируем файл /etc/resolv.conf: первый DNS сервер это закольцовывание на ваш локальный сервер DNS (127.0.0.1), вторым ближайший к вам DNS сервер (обычно предоставляется вашим провайдером интернета), список остальных DNS на ваше усмотрение (они не являются обязательными). Файл resolv.conf, говорит нам о том, что в случае неудачного DNS запроса к вашему серверу (127.0.0.1), запрос будет автоматически переадресован ко второму по списку DNS серверу и т.д..

> ee /etc/resolv.conf
domain  your.domen
nameserver      127.0.0.1
#DNS your ISP
nameserver      x.x.x.x
nameserver      x.x.x.x

Резолвер(resolver) — это набор подпрограмм в библиотеке C, которые предоставляют доступ к Internel DNS (Domain Name System) (Системе Доменных Имен Интернет) (прим. пер. – DNS обеспечивает возможность преобразования символьных имен машин в IP-адреса и наоборот, IP-адресов в символьные имена). Файл с настройками /etc/resolv.conf для резолвера содержит информацию, которую первым делом читают подпрограммы резолвера, вызванные каким-либо процессом. Данный файл устроен так, чтобы его мог читать человек и содержит список ключевых слов и значений, которые предоставляют резолверу различную информацию.

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

Параметры конфигурации:

  • nameserver

адрес сервера имен в Интернет (в нотации xxx.xxx.xxx.xxx), который будет обрабатывать запросы от резолвера. Серверов имен может быть максимум 3 (остальные игнорируются), по одному на каждой строке. Если задано несколько серверов, то библиотека резолвера опрашивает их в порядке перечисления. Если записей nameserver нет, то по умолчанию используется сервер имен на локальной машине. (Используемый алгоритм пытается подключиться к серверу имен и, если запрос не был обработан через некоторый промежуток времени, делается попытка подключиться к следующему серверу имен, и так до тех пор пока не будет обработан весь список серверов, затем повторить процедуру, пока не будет достигнуто максимальное количество повторов).

  • domain

Локальное имя домена. Большинство запросов на имена машин в этом домене смогут использовать лишь краткие имена, без указания имени домена. Если записей domain нет, то домен определяется из имени локальной машины, которое возвращается функцией gethostname(); доменной частью имени считается все, что следует после первой точки `.’. Наконец, если имя машины не содержит доменной части, назначается корневой домен.

  • search

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

  • sortlist

Разрешает сортировку адресов, которые возвращаются вызовом gethostbyname(). Опция sortlist задается с помощью пары: IP адрес/маска сети. Маска сети является необязательной, по умолчанию используется текущая маска сети. Пары из IP-адреса и необязательной маски сети разделяются прямой косой чертой. Может быть задано до 10 пар. пример: sortlist 130.155.160.0/255.255.240.0 130.155.0.0

  • options

Данная опция разрешает изменение определенных переменных резолвера. Синтаксис такой:

options опция ...
где опция может принимать одно из следующих значений:
debug --- устанавливает RES_DEBUG в _res.options.
ndots:n --- устанавливает порог для количества точек, которое должно быть в имени, заданном в res_query (см. resolver(@LIB_NETWORK_EXT@))
перед тем как будет создан начальный абсолютный запрос (initial absolute query). По умолчанию, n ``1'', означает, что если в имени есть
хоть одна точка, будет попытка считать это имя абсолютным перед добавлением к нему элементов из списка search.
Ключевые слова domain и search являются взаимно исключающими. Если эти слова заданы оба, то будет работать то, которое задано последним.
Ключевое слово и значение должны быть в одной строке, и кроме того, ключевое слово (например, nameserver), должно быть первым в строке. Значение должно отделяться от ключевого слова пробелом.

named.conf

Настраиваем named.conf

> ee /etc/namedb/named.conf
...
options {
...
//listen-on [ port ip_port ] { список-шаблонов-адресов };  (по умолчанию - все интерфейсы, порт 53; адрес и порт для приема запросов;
//может быть несколько таких предложений)
//
// укажем явно, на каких интерфейсах обслуживать запросы
        listen-on       { 127.0.0.1; адрес-сервера; };
//
// listen-on-v6 [ port ip_port ] { список-шаблонов-адресов }; (none; для IPv6)
//      listen-on-v6    { ::1; };

//allow-recursion { список-шаблонов-адресов }; (any; от кого принимать рекурсивные запросы; данные из кеша под запрет не попадают)
       allow-recursion { localhost; 127.0.0.1/8; ваша сеть; };
...
}

//Описание зон
//master - сервер является первичным уполномоченным сервером для данной зоны, т.е. загружает содержимое зоны из файла зоны,
// указанного опцией file
//slave - сервер является вторичным уполномоченным сервером для данной зоны; содержимое зоны считывается от одного из серверов,
//указанных в опции masters; указание имени файла в опции file  позволяет сохранять резервную копию зоны в файле
//
zone "your.com.ua" {
        type master;
        file "master/your.com.ua";
        allow-transfer{
        127.0.0.1;
//IP вашего сервера DNS
        x.x.x.x;
//IP slave
        195.24.128.164;
        };
};

Стартуем DNS нашего сервера.

> /etc/rc.d/named start
wrote key file "/var/named/etc/namedb/rndc.key"
Starting named.

Проверяем и видим ошибку «the working directory is not writable»

> tail -F /var/log/messages
...
Oct 25 16:12:48 ns named[59827]: starting BIND 9.4.3-P2 -t /var/named -u bind
Oct 25 16:12:48 ns named[59827]: command channel listening on 127.0.0.1#953
Oct 25 16:12:48 ns named[59827]: command channel listening on ::1#953
Oct 25 16:12:48 ns named[59827]: the working directory is not writable
Oct 25 16:12:48 ns named[59827]: running
...

BIND изначально запускается в песочнице. За настройки в песочнице отвечает файл BIND.chroot.dist. Изменим в этом файле строки для директорий namedb и master.

> cp /etc/mtree/BIND.chroot.dist /etc/mtree/BIND.chroot.dist.orig
> ee /etc/mtree/BIND.chroot.dist
...
    etc
        namedb uname=bind
            dynamic uname=bind
            ..
            master  uname=bind
...
> chown -R bind:wheel /etc/namedb/

Ошибка устранена.

Логирование DNS запросов

Для логирования всего происходящего при работе BIND нужно создать раздел logging в named.conf и создать нужные директории. В разделе logging задаются 2 параметра channel (можно и больше двух — на ваше усмотрение), эти параметры дословно можно назвать «канал» записи. Каждый канал определяет имя канала и настройки параметров записи (что записывать, а что — нет и куда писать). Директива category задает какую категорию сообщений в какой канал отправлять. Исходя из этого, мы имеем: запись стандартной информации в канал misc, а приходящие запросы посылаются в канал query. При этом, если файлы журнала достигают 4Мб (size 4m), он переименовывается добавлением к имени .1 и начинается запись в новый журнал, числа в конце других журналов увеличиваются. Журналы с номером, более указанного в version (в нашем случае 4) удаляются. Параметры print* определяют заносить ли в журнал время появления, важность и категорию информации. Более подробно про настройки раздела logging можно почитать в man (5) named.conf.

// настройки логирования
logging {
          channel "misc" {
                    file "/var/log/bind/misc.log" versions 4 size 4m;
                    print-time yes;
                    print-severity yes;
                    print-category yes;
          };

          channel "query" {
                    file "/var/log/bind/query.log" versions 4 size 4m;
                    print-time yes;
                    print-severity no;
                    print-category no;
          };

          category default {
                    "misc";
          };

          category queries {
                    "query";
          };
};

rndc — управление DNS сервером BIND 9

В то время как управление работающим сервером BIND 4 осуществлялось простой посылкой сигнала процессу (HUP — перезагрузить файл настройки и зоны; TERM — остановить; INT — сбросить базу данных в файл named_dump.db; ABRT — записать статистику в конец файла named.stats), управление сервером BIND 9 производится с помощью специальной утилиты rndc, которая соединяется с сервером (по умолчанию — TCP порт 953) и использует специальный протокол для передачи ему команд. Однако сигналы HUP, TERM пока действуют.

Настраивая сервер, необходимо обеспечить права доступа к управляющему порту (controls) и ключ (key), смотри ниже rndc-confgen.

Файл настройки rndc (/etc/rndc.conf) имеет такой же синтаксис, что и named.conf. Комментарии могут записываться в стиле C, C++ или sh. Файл настройки состоит из утверждений, завершающихся точкой с запятой. Утверждения содержат блок предложений, заключенный в фигурные скобки. Предложение в блоке также завершается точкой с запятой. Права на чтение этого файла должны быть только у того, кто имеет право запускать rndc. Предусматириваются следующие типы утверждений:

    * options {
          o default-server имя-или-адрес-сервера;
          o default-key "имя-ключа";
          o default-port номер-управляющего-порта;
      }
    * server имя-или-адрес-сервера { // адрес в двойных кавычках
          o key "имя-ключа";
          o port номер-управляющего-порта;
      }
    * key "имя-ключа"
          o algorithm hmac-md5;
          o secret "base-64-кодированный-ключ";
      }

Утилита rndc-confgen позволяет сгенерировать /etc/rndc.conf со случайным ключом (и закоментаренные предложения controls и key для /etc/named.conf). Следующими ключами можно модифицировать получаемый файл:

  • -b размер-ключа (по умолчанию — 128; от 1 до 512)
  • -k имя-ключа (по умолчанию — rndc-key)
  • -p номер-управляющего-порта (по умолчанию — 953)
  • -s имя-или-адрес-сервера (по умолчанию — 127.0.0.1)

Утилита rndc позволяет менять параметры соединения с сервером с помощью ключей:

  • -c имя-файла-настройки
  • -s имя-или-адрес-сервера
  • -p номер-управляющего-порта
  • -y имя-ключа
  • -V (трассировка исполнения для отладки)

Если запустить rndc без указания команды, то она выдаст список поддерживаемых команд:

  • reload (перезагрузить файл настройки и зоны)
  • reload зона [класс [вид]] (перезагрузить зону)
  • refresh зона [класс [вид]] (запланировать немедленное обновление зоны)
  • reconfig (перезагрузить файл настройки и новые зоны)
  • stats (записать статистику в конец файла named.stats)
  • querylog (включить/выключить журнализацию запросов) — после включения в логах можно будет увидеть с какого IP приходят запросы.
  • dumpdb (сбросить базу данных в файл named_dump.db, например: rndc dumpdb -all)
  • stop (сохранить изменения в файлы зон и остановить сервер)
  • halt (остановить сервер без сохранения изменений)
  • trace (увеличить уровень отладки на 1) в файле named.run -появятся отладочные сообщения
  • trace уровень (установить уровень отладки)
  • notrace (отключить отладку)
  • flush (сбросить весь кеш)
  • flush вид (сбросить кеш для указанного вида)
  • flushname (сбросить кеш для указанного домена, например, сбросить для домена mx.example.ru: rndc flushname mx.example.ru)
  • status (показать состояние сервера)
  • restart (перезапустить сервер; не реализовано)

Ссылки

Samba

Samba — программа, которая позволяет обращаться к сетевым дискам на различных операционных системах по протоколу SMB/CIFS. Samba использует 137-139 порты UDP и TCP.

  • Server requested LANMAN password (share-level security) but ‘client lanman auth’ is disabled
  • Samba4WINS — WINS -сервер

Утилиты Samba:

  • smbget позволяет скачивать с windows, linux (д.уст. samba) файлы через SMB протокол. Скачать рекурсивно все директории и файлы:

    smbget -Rr smb://ip_addr/share
  • smbclient — утилита для подключения к общедоступным папкам.
    • Отобразить общедоступные ресурсы на удаленном хосте:

      smbclient -L ip_addr/hostname
    • Просмотреть папку vip под пользователем tatyana

      $ smbclient \\\\10.26.95.220\\vip -U tatyana
  • nbtscan

    nbtscan ip_addr разрешить netbios-имя nbtscan не во всех системах ставится по-умолчанию,
    возможно, придётся доустанавливать вручную. nmblookup включен в пакет samba.
    nmblookup -A ip_addr

smb.conf

# testparm -v | grep lanman
Load smb config files from /etc/samba/smb.conf
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
...
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

	lanman auth = No
	client lanman auth = No

Samba 4

  • Проблема. Windows 7 не разрешает доступ к расшаренным папкам Samba 4 + LDAP по логину и паролю, без ввода Windows 7 в домен. Решение: Нужно отключить 128- битное шифрование (оно включено по умолчанию) при работе по сети. И тогда Windows 7 разрешит подключения дисков как сетвевых шар, но через стандартное сетевое окружение папки все равно не будут доступны. Полный бред однако!!!

Ссылки

Squid

Squid

Homepage: Squid

Squid (кальмар) — кэширующий прокси- сервер для протоколов HTTP, FTP, HTTPS (при соответствующих настройках). Лицензия GNU GPL.

Одной из особенностей squid является возможность работать в режиме «обратного прокси» («reverse proxy»), так же известного как «ускоритель» («HTTP accelerator»). В этом случае вместо кэширования запросов нескольких пользователей к множеству сайтов, кэшируются запросы множества пользователей к нескольким сайтам. В этом режиме принятый запрос проверяется на «динамичность» (нужно ли каждый раз обрабатывать запрос с нуля) и «возраст» (актуальны ли ещё данные). Если данные ещё актуальны и не поменялись, то запрос не передаётся серверу, а отдаётся из кэша squid. Таким образом существенно снижается нагрузка на серверы. «Обратный прокси» способен распределять запросы между несколькими серверами, балансируя нагрузку и/или обеспечивая отказоустойчивость, то есть фактически предоставляет функциональность, аналогичную кластеру.

Squid поддерживает работу в режиме «прозрачного прокси». В режиме прозрачности не проксируются FTP— и HTTPS- запросы.

Squid и Debian

  • OC: Debian GNU/Linux wheezy/sid 3.0.0-1-amd64 #1 SMP x86_64 GNU/Linux
  • Squid 3.1.18-1 Stable
# aptitude install squid3

Squid и FreeBSD

OC FreeBSD 7.2-RELEASE squid-3.1.0.17 beta. В этой версии наконец-то упростили (уменьшили) конфигурационный файл Squid.

Конечная цель настройка прозрачного прокси Squid с использованием пакетного фильтра Packet Filter Firewall (PF).

> > cd /usr/ports/www/squid31
> make config
...
[X] SQUID_PF             Enable transparent proxying with PF
...
> make install clean

squid.conf

> ee /usr/local/etc/squid/squid.conf
# выводить сообщения пользователям на украинском языке, по умолчанию английский
error_default_language uk-ua
# Squid слушает порт только на localhost. intercept включаем прозрачный прокси
http_port 127.0.0.1:3128 intercept
visible_hostname = local
# например есть ОЗУ 192 Мб -  можно выставить 64 Mб. Выделение ОЗУ по кеш, а не под процесс SQUID.
cache_mem 64 MB
# размер папки с кешем 800 Мб
cache_dir ufs /usr/local/squid/cache 800 16 256
# пределы для включения механизма очистки кеша от устаревших данных, в процентах
# кеш при достижении 95% заполнения начинает очищаться
cache_swap_low 90
cache_swap_high 95
# политика очистки кеша по умолчанию
memory_replacement_policy lru
#Этот тэг задает размер объекта который может хранится в памяти. Объекты
#больше этого размера, сохранятся в памяти не будут. Объекты из памяти
#достаются быстрее, поэтому там должны содержатся только объекты, которые
#часто запрашиваются клиентами. Увеличение значения этого тэга приводит к снижению производительности сервера.
maximum_object_size_in_memory 512 KB
# минимальный размер файл для сохранения в кеше
minimum_object_size 0 KB 
# максимальный размер файл для сохранения в кеше
maximum_object_size 4096 KB
# Этот тэг позволяет задать пароль ftp пользователю Anonymous(!!!) от имени 
# которого Squid будет осуществлять просмотр анонимных ресурсов по FTP протоколу.
ftp_user Squid@your.domen
# разрешить/запретить пассивный режим FTP
ftp_passive on

#Этот тэг определяет количество ротаций лог-файла. По умолчанию - 10. Это означает, что когда вы введете команду 'squid -k rotate',
то текущий файл журнала получит расширение от 0 до 9 и будет отложен. Вместо него создастся новый файл для ведения журнала и теперь
все записи будут вестись уже в новый файл. Если установить значение тэга logfile_rotate 0, то это отключит ротацию файлов.
logfile_rotate 4
access_log /var/log/squid/access.log squid
# отладочная информация. содержит основную информацию об использовании кэша.
cache_log /var/log/squid/cache.log
# Default: none
#cache_store_log /var/log/squid/store.log

#Этот тэг задает список слов, которые при нахождении их(этих слов) в URL, 
#сообщают Squid то, что объект расположенный по этому URL надо брать 
#напрямую, а не из кэша.
hierarchy_stoplist cgi-bin ?

Проверим конфигурационный файл Squid на ошибки.

> squid -f /usr/local/etc/squid/squid.conf -k parse
2010/03/16 16:40:32| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)

Перед первым запуском нужно создать кеш Squid.

> squid -z
2010/03/16 16:42:05| Creating Swap Directories
2010/03/16 16:42:05| /usr/local/squid/cache exists
2010/03/16 16:42:05| Making directories in /usr/local/squid/cache/00
...

Для запуска Squid нужно добавить строку squid_enable=yes в файл rc.conf

> /usr/local/etc/rc.d/squid start

Настройки файервола для прозрачного проксирования

PF

  • Настройка Packet Filter Firewall (PF)
ext_if_a="tun0"
int_if_a="rl0"
int_if_b="rl1"
LanAll =  "{10.90.90.0/24, 192.168.35.0/24, 192.168.1.0/24}"
Lanint_if_b = "{10.90.90.0/24, 192.168.35.0/24}"

# RDR transparent proxy
rdr on $int_if_b inet proto tcp from $Lanint_if_b to any port 80 -> 127.0.0.1 port 3128
rdr on $int_if_a inet proto tcp from 192.168.1.0/24 to any port 80 -> 127.0.0.1 port 3128
# NAT
nat on $ext_if_a inet from $LanAll to any -> ($ext_if_a)
  • Ошибка: IpIntercept.cc(316) PfInterception: PF open failed: (13) Permission denied. Для ее устранения нужно дать доступ (чтение) Squid к PF.
chown root:squid /dev/pf
chmod 660 /dev/pf

iptables

Cron Squid

> crontab -e
@daily squidstat.sh
> ee squidstat.sh
#!/bin/sh
#
/usr/local/www/lightsquid/lightparser.pl
/usr/local/sbin/squid -k rotate
rm /usr/local/squid/logs/access.log.0
rm /usr/local/squid/logs/cache.log.0
rm /usr/local/squid/logs/store.log.0
  • Скрипт для проверки работы Squid: если Squid упал -запускает его.
> ee cron_start_squid.sh
#!/bin/sh

if [ -s /usr/local/squid/squid.pid ]
        then 
        else echo start squid: `date` >> /var/log/squid_down.log ; `/usr/local/etc/rc.d/squid start >> /dev/null`
fi

ACL Squid

Настройка доступа в Squid настраивается через списки доступа ACL. Правила читаются и применяются сверху вниз — то есть последовательность расположения директив http_access важна.

Ограничения к ресурсам происходит в два этапа:

  • определение условия запроса
  • разрешить или запретить определенное на первом шаге условие
acl dbserv src 192.168.1.11/32 #описывает единственную машину с адресом 192.168.1.11 и назначает ей ACL с dbserv
http_access deny dbserv #запрет доступа в интернет ACL dbserv

Настройка аутентификации Squid

Настройка аутентификации при помощи программы ncsa_auth. Пользователи и пароли хранятся в файле /etc/squid/passwd, который создается при помощи утилиты htpasswd.

#Recommended minimum configuration per scheme:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd 
auth_param basic children 5
# после realm можно написать любу. строку. Она будет отображаться в заголовке окна ввода пароля
auth_param basic realm Squid proxy-caching DARK
# проверяет изменил ли сис. администратор пароль в файле /etc/squid/passwd. Если да пользователя попросят ввести новый пароль.
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Эти правила должны быть применены к ACL, например

# Указали Squid что настроили аутентификацию
acl auth proxy_auth REQUIRED
# Описали единичный компьютер
acl winxp src 10.5.21.4/32
# Указали разрешить доступ этому компьютеру после ввода логина и пароля
http_access allow winxp auth

Ограничение ширины канала Squid

  • Squid на практике. Ограничение скорости доступа в Интернет
  • Разделение внешнего канала
Squid должен быть собран с опцией [х] SQUID_DELAY_POOLS Enable delay pools
http_access allow winxp

delay_pools 1
delay_class 1 1
delay_parameters 1 8000/8000
#64KB
delay_access 1 allow winxp
delay_access 1 deny all
  • delay_pools Этот тэг отвечает за количество используемых delay pools. Например, если у вас есть один delay pool класса 2 и один delay pool класса 3, то в целом вы имеете 2 delay pool. Соответственно, в этом случае, тэгу следует задать значение равное 2. По умолчанию: delay_pools 0
  • delay_parameters ограничить скорость на пулах, например

    # без ограничений
    #delay_parameters 1 -1/-1
    # ограничить скорость 64Kbit/c
    #delay_parameters 1 8000/8000
    # ограничить скорость 256Kbit/c
    #delay_parameters 1 32000/32000
    # если пользователь пытается скачать файл размера больше чем 32000 - тогда ограничить скорость 800
    #delay_parameters 1 800/32000
    

ERROR PfInterception: PF open failed

В файле /var/log/squid/cache.log появляется строка с ошибкой:

2010/07/19 13:29:28| IpIntercept.cc(316) PfInterception: PF open failed: (13) Permission denied

Исправить эту ошибку можно несколькими способами

  • Первый: chmod +r /dev/pf — что не является безопасным.
  • Второй:

    > ee /etc/devfs.conf
    # Allow Squid read acess to /dev/pf
    own     pf      root:squid
    perm    pf      0640
    /etc/rc.d/devfs restart

Статистика Squid

Скриптов для сбора статистики Squid довольно много.

Ссылки

Настройка PPTP в Debian Ubuntu сервера и клиента

В качестве исходных данных будем использовать:

Debian Lenny 5.0.4 с адресом в локальной сети 192.168.0.10.

Для начала устанавливаем всё необходимое:

apt-get install ppp pptpd

Далее приступаем к настройке. Всё достаточно просто.

Первым делом открываем в редакторе файл /etc/pptpd.conf и дописываем в конец следующие строки:

$ nano /etc/pptpd.conf
… .. ..
# IP-адрес сервера в локальной сети
localip 192.168.0.10
# Диапазон адресов для клиентов PPTP-сервера
remoteip 192.168.0.200-235
… .. ..

Так же добавляем в /etc/ppp/pptpd-options следующие строчки:

$ nano /etc/ppp/pptpd-options
… .. ..
# требуем авторизацию у клиентов
auth
# Используем шифрование
require-mppe
… .. ..
# Укажем файл, в который писать лог:
logfile /var/log/pptpd.log

$ touch /var/log/pptpd.log

Добавляем наших пользователей в /etc/ppp/chap-secrets, таким видом:

$ nano /etc/ppp/chap-secrets

# Если пользователь должен динамически получать IP-адрес

# из диапазона remoteip в pptpd.conf:

user1 pptpd password «*»

# Если мы хотим привязать определённый IP к логину:

user2 pptpd password2 «192.168.0.205»

Быстрое и удобное добавления пользователей из консоли:

$ echo "test1 pptpd 11111 * " >> /etc/ppp/chap-secrets

Рестанем pptpd:

$ /etc/init.d/pptpd restart

Настройка PPTP-клиента в Debian/Ubuntu

$ apt-get install pptp-linux

Для простоты введем переменные:

название нашего соединения ($NameVPN)

IP address(host) нашего сервера — ($SERVER),

наше имя пользователя (username)($USERNAME),

наш пароль (password)($PASSWORD),

так же если есть домен (domain)($DOMAIN)

Приводим наши файлы до следующего вида:

$ nano /etc/ppp/options.pptp

lock
nodetach
noauth
refuse-eap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate

$ nano /etc/ppp/chap-secrets

Внимание: параметр nodetach, выводит в стандартный поток вывода ошибок — stderr, выводится на терминал. Это удобно для отладки соединения. После того, как Вы убедились, что скрипт работает, как задумано, параметр nodetach можно убрать и pppd при запуске будет уходить в фоновый режим, перенаправляя stderr скрипта в файл /etc/ppp/connect-errors.

# Secrets for authentication using CHAP
# client server secret IP addresses
($USERNAME) PPTP ($PASSWORD) *
Замечания: если вы используете домен, то используете косые черты и имя домена.
$DOMAIN\\$USERNAME PPTP $PASSWORD *

Создаем файл $NameVPN в /etc/ppp/peers/:

$ nano /etc/ppp/peers/$NameVPN

pty «pptp $SERVER —nolaunchpppd»
name $DOMAIN\\$USERNAME
remotename PPTP
require-mppe-128
defaultroute
file /etc/ppp/options.pptp
ipparam $TUNNEL

Если нам ни нужна поддержка MPPE,то удаляем строчку из require-mppe-128 из файла.

Подключения:

$ pon $NameVPN

Разрыв связи:

$ poff $NameVPN

Если нужно увидеть отладочную информацию:

pon $NameVPN debug nodetach

Если нужен автоматический запуск при загрузке системы, добавьте в файл /etc/network/interfaces следующие строки:

$ nano /etc/network/interfaces

auto tunnel
iface tunnel inet ppp
provider $NameVPN
up route del default
up route add default dev ppp0

Заметка: мне пришлось поставить апперанд & после ($NameVPN&), иначе загрузка шла до подключения ppp и на этом останавливалась.

Добавлено:

так же можно прописать в rc.local pon [$NameVPN]
sleep 5
route add default dev ppp0
# если надо другие роуты
route add -net 192.0.0.0 netmask 255.255.0.0 gw 192.168.0.7

Openstack swift

Cтенд из 3х нод:
swift1.swift.nct = 10.7.29.1
swift2.swift.nct = 10.7.29.2
swift3.swift.nct = 10.7.29.3
Все ноды выполняют роль прокси, а также хранилища объектов, контейнеров и аккаунтов.

cat /etc/swift/make_block_dev.sh

>>
#!/bin/sh
# Device size in GB
SIZE=1
DATA=/data
MOUNT=/srv/node
mkdir ${DATA}
for ZONE in 1; do
for DEVICE in 1 2 ; do
truncate ${DATA}/swift-z${ZONE}d${DEVICE} —size ${SIZE}G
LOOPDEVICE=$(losetup —show -f ${DATA}/swift-z${ZONE}d${DEVICE})
mkfs.ext4 -I 1024 ${LOOPDEVICE}
mkdir -p ${MOUNT}/z${ZONE}d${DEVICE}
mount -o noatime,nodiratime,nobarrier,user_xattr ${LOOPDEVICE} \
${MOUNT}/z${ZONE}d${DEVICE}
done
done
chown -R swift:swift /srv/node
exit 0

cat   ring_create.sh

>>
#!/bin/bash
swift-ring-builder /etc/swift/account.builder create 12 2 1
swift-ring-builder /etc/swift/container.builder create 12 2 1
swift-ring-builder /etc/swift/object.builder create 12 2 1
swift-ring-builder /etc/swift/account.builder add z1-10.7.29.1:6002/z1d1 100
swift-ring-builder /etc/swift/account.builder add z2-10.7.29.2:6002/z1d1 100
swift-ring-builder /etc/swift/account.builder add z3-10.7.29.3:6002/z1d1 100
swift-ring-builder /etc/swift/container.builder add z1-10.7.29.1:6001/z1d1 100
swift-ring-builder /etc/swift/container.builder add z2-10.7.29.2:6001/z1d1 100
swift-ring-builder /etc/swift/container.builder add z3-10.7.29.3:6001/z1d1 100
swift-ring-builder /etc/swift/object.builder add z1-10.7.29.1:6000/z1d1 100
swift-ring-builder /etc/swift/object.builder add z2-10.7.29.2:6000/z1d1 100
swift-ring-builder /etc/swift/object.builder add z3-10.7.29.3:6000/z1d1 100
exit 0

cat /etc/rsyncd.conf

>>
uid = swift
gid = swift
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
address = 10.7.29.1

[account]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/account.lock

[container]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/container.lock

[object]
max connections = 2
path = /srv/node/
read only = false
lock file = /var/lock/object.lock

cat /etc/swift/account-server.conf

>>
[DEFAULT]
bind_ip = 10.7.29.1
bind_port = 6002
workers = 2
[pipeline:main]
pipeline = recon account-server
[app:account-server]
use = egg:swift#account
[account-replicator]
[account-auditor]
[account-reaper]
[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift
account_recon = true

cat /etc/swift/container-server.conf

>>
[DEFAULT]
bind_ip = 10.7.29.1
bind_port = 6001
workers = 2
[pipeline:main]
pipeline = recon container-server
[app:container-server]
use = egg:swift#container
[container-replicator]
[container-updater]
[container-auditor]
[container-sync]
[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift
container_recon = true

cat object-server.conf

>>
[DEFAULT]
bind_ip = 10.7.29.1
bind_port = 6000
workers = 3
[pipeline:main]
pipeline = recon object-server
[app:object-server]
use = egg:swift#object
[object-replicator]
[object-updater]
[object-auditor]
[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift
object_recon = true

cat /etc/xinetd.d/rsync

>>
service rsync

{

disable    = no
flags        = IPv6
socket_type     = stream
wait            = no
user            = root
server          = /usr/bin/rsync
server_args     = —daemon
log_on_failure  += USERID

}

cat openrc                                                                          

>>
export ST_AUTH=http://10.7.29.1:8080/auth/v1.0
export ST_USER=admin:admin
export ST_KEY=admin

cat cat /etc/swift/proxy-server.conf
>>

[DEFAULT]
bind_ip = 10.7.29.2
bind_port = 8080
workers = 8
user = swift

[pipeline:main]
pipeline = healthcheck cache tempauth proxy-server

[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
account_autocreate = true

[filter:cache]
use = egg:swift#memcache
memcache_servers = 10.7.29.2:11211

[filter:catch_errors]
use = egg:swift#catch_errors

[filter:healthcheck]
use = egg:swift#healthcheck

[filter:tempauth]
use = egg:swift#tempauth
# user_<tenant>_<username> = <password> <privileges>
user_admin_admin = admin .admin .reseller_admin
user_test_tester = testing .admin
user_test2_tester2 = testing2 .admin
user_test_tester3 = testing3

                                                                                                                        
$ bash make_block_dev.sh
$ bash ring_create.sh

$ swift-ring-builder account.builder rebalance
$ swift-ring-builder container.builder rebalance
$ swift-ring-builder object.builder rebalance
$ chkconfig memcached on
$ service memcached start

$ for service in openstack-swift-object openstack-swift-object-replicator openstack-swift-object-updater openstack-swift-object-auditor openstack-swift-container openstack-swift-container-replicator openstack-swift-container-updater openstack-swift-container-auditor openstack-swift-account openstack-swift-account-replicator openstack-swift-account-reaper openstack-swift-account-auditor; do service $service start; chkconfig $service on; done

$ scp /etc/swift/*.ring.gz root@swift2.swift.nct:/etc/swift/
$ scp /etc/swift/*.ring.gz root@swift3.swift.nct:/etc/swift/
$ swift-init all restart
$ source openrc
$ swift list

$ yaourt -S cloudfuse
cat .cloudfuse

>>
username=admin:admin
api_key=admin
authurl=http://10.7.29.2:8080/auth/v1.0/
verify_ssl=false

$ mkdir /mnt/swift
$ cloudfuse /mnt/swift

скрипт проверки доступности маршрута при использовании 2х провайдеров + балансировки маршрутами

#!/bin/bash


# what to check for
mt_ro='77.88.8.7'
ntr_ro='77.88.8.3'

# up routers
mt_up_router='X.X.X.25'
ntr_up_router='Y.Y.Y.1'

# our own ips
mt_iface='vlan101'
mt_ip='X.X.X.27'

ntr_iface='eth0'
ntr_ip='Y.Y.Y.11'
ntr_ips=( 
'Y.Y.Y.11' 
'Y.Y.Y.12' 
'Y.Y.Y.13' 
'Y.Y.Y.14' 
'Y.Y.Y.15' 
'Y.Y.Y.20' 
'Y.Y.Y.21' 
)

sleep_interval='2' # sec

soft=(
'grep'
'ping'
#'curl'
'ip'
'touch'
'mkdir'
'test'
)

# check if essential soft is installed
check_soft(){
 for soft in "${soft[@]}"; do
                ( command -v "${soft}" > /dev/null ) || { exit 1 ; }
        done
        return 0
}

ping_count='2'
ping_timeout='1'
log_dir="/var/log/routes"

# debug 
log="$log_dir"/routes

helper_log="$log_dir"/helper_routes
log_size_max='3000' #Kb

# run here

test -d "$log_dir" || mkdir "$log_dir"
test -f "$helper_log" || touch "$helper_log"

# mt route
ip route add "$mt_ro" via "$mt_up_router" dev "$mt_iface"
# ntr route
ip route add "$ntr_ro" via "$ntr_up_router" dev "$ntr_iface"

#debug 
test -f "$log" || touch "$log"

while true; do
 # adding routes for testing ISPs if not exist
 { ip route | grep "$ntr_ro" ; } || ip route add "$ntr_ro" via "$ntr_up_router" dev "$ntr_iface"
 { ip route | grep "$mt_ro"; } || ip route add "$mt_ro" via "$mt_up_router" dev "$mt_iface"     
 sleep "$sleep_interval" 
  
 { ping -c "$ping_count" -W "$ping_timeout" -I "$ntr_iface" "$ntr_ro" >/dev/null 2>&1; } \
  && ping_via_ntr_ec="0" || ping_via_ntr_ec='1'
 { ping -c "$ping_count" -W "$ping_timeout" -I "$mt_iface" "$mt_ro" >/dev/null 2>&1; } \
  && ping_via_mt_ec="0" || ping_via_mt_ec='1' 

 # debug
 #echo "ping_via_mt_ec: $ping_via_mt_ec" >> "$log"
 #echo "ping_via_ntr_ec: $ping_via_ntr_ec" >> "$log"  

 if_d_gw_nrt(){
         echo "$(date) gw ntr" >> "$helper_log"
         
  ip route delete table 101
  ip route delete table 102
  ip route change default via "$ntr_up_router" dev "$ntr_iface"  
 # ip route add default via "$ntr_up_router" dev "$ntr_iface"  
  
  ip route flush table 101
  ip route flush table 102
  
  return 0
 }


 if_d_dw_mt(){
         echo "$(date) gw mt" >> "$helper_log"
         
  ip route delete table 101
                ip route delete table 102
  ip route change default via "$mt_up_router" dev "$mt_iface" 
 # ip route add default via "$mt_up_router" dev "$mt_iface" 
         
  ip route flush table 101
  ip route flush table 102
  
  return 0
 }

 if_d_gw_both(){
         
  echo "$(date) gw both" >> "$helper_log"
  
  ip route add default via "$mt_up_router" table 101
  ip route add default via  "$ntr_up_router" table 102

  ip route add 10.7.0.0/16 dev br0 table 101
  ip route add X.X.X.24/29 dev vlan101 table 101
  ip route add 127.0.0.0/8 dev lo   table 101
  ip route add 10.7.0.0/16 dev br0 table 102
  ip route add Y.Y.Y.0/24 dev eth0 table 102
  ip route add 127.0.0.0/8 dev lo table 102 

  
  { ip rule sh | grep 'from Y.Y.Y.11 lookup 102'; } || ip rule add from "$mt_ip" table 101 
  { ip rule sh | grep 'from X.X.X.27 lookup 101'; } || ip rule add from "$ntr_ip" table 102
  
  for x in "${ntr_ips[@]}"; do 
   { ip rule sh | grep "$x" ; } || ip rule add from "$x" table 102
  done  

  ip route replace default scope global \
   nexthop via "$ntr_up_router" dev "$ntr_iface" weight 1 \
   nexthop via "$mt_up_router" dev "$mt_iface" weight 1

         return 0
 }


 if_d_gw_none(){
         echo gw none > $helper_log
         if_d_gw_both
  return 0
 }

 { [[ "$ping_via_mt_ec" == '1' ]] && [[ "$ping_via_ntr_ec" == '1' ]] ; } && if_d_gw_none > /dev/null 2>&1
 { [[ "$ping_via_mt_ec" == '0' ]] && [[ "$ping_via_ntr_ec" == '0' ]] ; } && if_d_gw_both > /dev/null 2>&1
 { [[ "$ping_via_mt_ec" == '0' ]] && [[ "$ping_via_ntr_ec" != '0' ]] ; } && if_d_dw_mt > /dev/null 2>&1
 { [[ "$ping_via_mt_ec" != '0' ]] && [[ "$ping_via_ntr_ec" == '0' ]] ; } && if_d_gw_nrt > /dev/null 2>&1


 helper_log_size=$(du "$helper_log" | while read -r q w ; do echo $q ;done)
 if [[ "$helper_log_size" -gt "$log_size_max" ]]; then
  rm -f "$helper_log"
  touch "$helper_log"
 fi
 
 # debug
 #log_size=$(du "$log" | while read -r q w ; do echo $q ;done)
 #if [[ "$log_size" -gt "$log_size_max" ]]; then
 # rm -f "$log"
 # touch "$log"
 #fi
 
done

exit 1

LACP и общая настройка HP 1920-48G V1910-48G switch

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

 

Пришел я в компанию работать системным администратором. В продакшене стояли две железки HP V1910-48G switch, с практически настройками из коробки. Порты были настроены в Hybrid режим, если кто-то когда-то сталкивался с этим поймет что в нормальном продакшене никаких гибридов быть не может. Также имелся шлюз на Debian 7 который был установлен на mac mini. Свои комментарии по поводу этого я опущу. Но не смотря на это все работало и очень даже неплохо.  Но дак не об этом сейчас. В скором будущем после моего прихода компания должна была мигрировать на другую локацию, соответственно всё оборудование переезжало. Для переезда была подготовлена нормальная стойка с нормальными патч панелями. Монтаж коммутаторов предполагался один через две. Т.е. один свитч через две панели, что приблизительно вмещало в себя почти всё порты (розетки) в офисе. До этого я работал в другой компании, где бюджет на оборудование был резиновым и купить можно было практически любую кошку. Соответственно всё было в кошках и хрюшках (HP), что было очень удобно в построении и администрировании. Но в этой компании политика партии несколько другая. Преимущественно везде использовался Open Source. Сообственно поэтому выбор пал на Proxmox 3, о котором я рассказывал в другой статье. Ну дак вообщем-то достались мне эти чудесные HP 1920-48G V1910-48G свитчи, которые в прошлом именовались не что иное как 3COM. Умееют они в принципе многое, но не то что как я задумывал для своей реализации в офисной сети, а задумывал я сделать отказоустойчивость в свитчинге за счет резервирования Core коммутатора, а также портов в LACP в этом стеке до гипервизора, до NAS и тд. Но не тут было. После недолгих (долгих) раздумий я решил соорудить схему кольцо из этих коммутаторов по принципу один сдыхает все остальное работает кроме него, какая никакая отказоустойчивость. Посему обвязка проводами между коммутаторами тоже предполагала отказоустойчивость по порту, по проводу. К тому же агрегирование портов суммарно даёт увеличение в пропускной способности.

Было решено использовать вот такую схему:

133314_html_787aa200

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

Итак приступим к общей настройке первого коммутатора. Кладем его перед собой включаем и берем консольный кабель. У меня был вот такой CAB-CONSOLE-RJ45=и переходник к нему на USB 001-600x600

Подключаем к нашему «умному» коммутатору разъёмом RJ-45, соединяем между собой кабели и разъем USB себе в машину. У вас должен автоматически установиться драйвер для этого провода, чтобы понять к какому «эмулированному» COM порту мы будем подключаться надо открыть диспетчер устройств и посмотреть только что установленное оборудование

 

 

com

Видим что кабель подключен на COM3

Качаем Putty, это такая программа Клиент ко всему чему можно себе представить: Telnet, SSH и тд и тп, кому интересно почитайте на яндексе. Запускаем и выбираем Serial, скорость подключения для коммутаторов серии HP 1920-48G V1910-48G равна 38400, выставляем ее, а также меняем COM1 который был по умолчанию на COM3 который мы увидели в диспетчере устройств.

putty

Нажимаем Open, у нас открывается консоль, нажимаем пару раз Enter и мы видим приглашение нашего коммутатора.

switch1

Username: admin

Password: пустой

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

так вот после попадания в «первый» режим коммутатора нам необходимо зайти в привилегированный режим (enable в cisco)

пишем наисложнючую команду

_cmdline_mode on

стараемся не ошибаться потому как помним путти не умеет стирать.

Соглашаемся с выводом о том что вы попадаете режим бога:

All commands can be displayed and executed. Continue? [Y/N]

Y

и вводим пароль по умолчанию, который запрограммирован производтелем, который нельзя поменять (глупость какая то), например в кошках меняется так enable password PASSWORD. но нееет.

Далее есть интересный момент, для коммутаторов V1910-48G свой пароль 512900, а для 1920-48G свой и, он, внимание: jinhua1920unauthorized. После настройки 4 коммутатора через путти я писал этот пароль за одну секунду. Соответственно вводим пароль для вашего коммутатора и мы попадаем в режим где мы можем задать ip адрес, sysname и тд. В принципе этого достаточно если вам нужен тупой коммутатор в локалке с одной подсетью.Вы указываете ему ip адрес, далее логинетесь через веб интерфейс и настраиваете его по своему вкусу.

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

system-view | аналог на кошках configure terminal

Вообще, такое ощущение что 3COM, простите HP долго не думали и в тупую содрали все команды у cisco и придумали им свои алиасы. Ну да не суди другого, да не судимым будешь.

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

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

vlan 7

description Mgmt

quit

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

далее настроим интерфейс:

interface vlan 7 | напомню что можно сокращать команды до такого например вида in v 7

ip address 192.7.0.2 255.255.255.0 | назначаем интерфейсу адрес и маску подсети, я прописал второй (третий, если брать адрес сети) адрес из сети, поскольку на первом у нас шлюз.

quit

Выходим из интерфейса и теперь мы можем посмотреть его:

display current-configuration interface Vlan-interface 7 | вся команда может быть написана так di cu in v 7

#
interface Vlan-interface7
 ip address 172.7.0.2 255.255.255.0
#

Видим что интерфейс у нас настроен.

Далее настроим к примеру 10 порт коммутатора для того чтобы мы могли попасть на него с помощью патч корда

interface GigabitEthernet 1/0/10

port link-type access

port access vlan 7

quit

для удобства доступа включим ssh на коммутаторе

ssh server enable

И сменим пароль юзера admin чтобы зайти через ssh

local-user admin

password simple PASSWORD

service-type ssh terminal telnet

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

192.7.0.244 255.255.255.0

LACP

Теперь перейдем к самому интересному — настройке lacp на портах коммутатора.  Что же такое LACP, приведу статью из Википедии:

Link Aggregation Control Protocol (LACP) — протокол, предназначенный для объединения нескольких физических каналов в один логический в сетях Ethernet. Агрегированные каналы LACP используются как для повышения пропускной способности, так и повышения отказоустойчивости. Использование LACP в некоторых случаях позволяет обнаружить повреждённый канал, который бы при использовании обычной статической агрегации обнаружен бы не был. Описывается стандартом IEEE 802.3ad.

Так вот в нашей статье мы рассматриваем подключение коммутаторов кольцом при котором один подключен в другой а последний в первый.

Итак приступим:

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

Для начала настроим агрегированный интерфейс br1 (link-aggregation group 1) в режиме LACP dynamic | Далее будет br2 это — (link-aggregation group 2)

interface br1

link-aggregation mode dynamic

quit

напомню для коммутаторов 1920 можно использовать range т.е. настроить несколько интерфейсов сразу, тогда как для 1910 вы будете настраивать нижеследующее но для каждого порта, итак возьмем два последних порта в этом коммутаторе которые пойдуте в два предпоследних порта 45 и 46 следующего по кольцу коммутатора:

interface range GigabitEthernet 1/0/47 to GigabitEthernet 1/0/48 | коротко это можно записать так  in ra g1/0/47 to g1/0/48

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

Все наши порты мы будем настраивать в trunk1:

port link-type trunk

port trunk permit vlan 2-8,10,15

undo port trunk permit vlan 1

port link-aggregation group 1

quit

Теперь обратно заходим в br1 и дописываем настройки нашего trunk:

interface br1

port trunk permit vlan 2-8,10,15

undo port trunk permit vlan 1

Теперь настроим br2 (link-aggregation group 2):

interface br2

link-aggregation mode dynamic

quit

Настроим теперь порты 45 и 46 для приема двух проводов с последнего коммутатора в кольце, настройки все те же самые, кроме link-agregation group

interface range GigabitEthernet 1/0/45 to GigabitEthernet 1/0/46 | коротко это можно записать так  in ra g1/0/45 to g1/0/46

port link-type trunk

port trunk permit vlan 2-8,10,15

undo port trunk permit vlan 1

port link-aggregation group 2

quit

Идем обратно в агрегат br2

interface br2

port trunk permit vlan 2-8,10,15

undo port trunk permit vlan 1

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

По аналогии проделываем все эти операции на всех коммутаторах в кольце, после чего получаем 2 gb\s между ними, два резервных провода на каждый коммутатор, и один резервный коммутатор в кольце.

Хочу упомянуть про STP.

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

Пример:

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

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

 

 

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

 

Магистральный порт или Trunk1 port — это канал типа «точка-точка» между коммутатором и другим сетевым устройством. Магистральные подключения служат для передачи трафика нескольких VLAN через один канал и обеспечивают им доступ ко всей сети. Магистральные порты необходимы для передачи трафика нескольких VLAN между устройствами при соединении двух коммутаторов, коммутатора и маршрутизатора или коммутатора и сетевого адаптера узла с поддержкой транкинга 802.1Q.

IPMI Tool настройка ipmi из Debian 7

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

 

 

 

Расскажу небольшую предысторию почему мне понадобилось использовать ipmitool в линуксе, внутри операционной системы. Закупили мы сервер на компанию, вот примерно вот такой:

Корпус Supermicro SC-825TQ-R740LPB — 1шт
Материнская плата: Supermicro X10SRi-F — 1шт
Охладитель процессора пас. SuperMicro SNK-P0048P — 1шт
Процессор: Intel CPU Xeon E5-2620v3 — 1шт
Жесткий диск: HDD Enterprise 3.5″ 2Tb SATA 7200 RPM — 4шт
Микросхема: 16GB 2133MHz DDR4 ECC Reg — 4шт
Кабель SAS / SATA — 2шт
Контроллер: Adaptec 8805 — 1шт
Устройство чтения и записи дисков: Slim DVD-RW. — 1шт
Комплект для установки: MCP-220-81502-0N — 1шт
Сетевая карта Intel I350T2 — 1шт

На этой платформе существует встроенный ipmi. Изначально я зашел в биос настроил себе ipmi по айпи адресу в локальной сети, тогда у нас еще не было разделений на вланы в корпоративной сети, ipmi быстро настроился я вернулся на своё рабочее место с печенюжкой и стаканом свежесваренного кофе. И начал устанавливать гипервизор на нем. После установки гипервизора на основном шлюзе компании я начал разграничивать всю локальную сеть по отдельным вланам, для IP телефонов, для гостевого WiFi, для серверов, для пользователей, для Management и т.д.. Ставил я тогда Proxmox 3. Соответственно разворачивал я его изначально просто в юзерском влане. После настройки онного и перепиливания интерфейсов управления в другой влан и соответственное переделывание портов свитча HP 1920-48G Switch (о котором я напишу еще одну статью) из access в trunk ipmi с радостью отвалился. В то время я этого еще не понимал. Проработав с ним некоторое время увидев свои плюсы и свои минусы я решил поставить вместо него VMware Esxi 6. Перенеся весь продакшен на другой сервак (старый дряхлый PC) я вновь начал настраивать этот Supermicro. Докупил для него SSD под корневую систему я полез в bios чтобы настроить ipmi, но не тут то было. IPMI упорно мне говорил что ни один кабель не подключен, я перепробовал все варианты с подключением его и в trunk и в access и запихивал его в различные виланы ничего не помогло. После установки ESXI 6, поработав с ним некоторое время я понял что бесплатного функционала мне недостаточно и я решил вернуться на Proxmox 3. Установив все обратно, перенеся все виртуальные машины и запустив продакшен, я вспомнил что есть замечательная приблуда IPMItool для Linux. недолго рыская в репозитории мне понадобились три пакета из репозитария Debian 7, и это:

ii  ipmitool                         1.8.11-5                      amd64        utility for IPMI control with kernel driver or LAN interface
ii  libopenipmi0                     2.0.16-1.3                    amd64        Intelligent Platform Management Interface — runtime
ii  openipmi                         2.0.16-1.3                    amd64        Intelligent Platform Management Interface (for servers)

После их установки необходимо добавить следующие модули для инициализации системой чипа IPMI

ipmi_devintf
ipmi_si

для постоянной загрузки я дописал их в /etc/modules, для временной можно воспользоваться командой

modprobe ipmi_devintf

modprobe ipmi_si

после этого выполнив команду

ipmitool lan print

вы сможете наблюдать текущие настройки вашего IPMI:

Set in Progress         : Set Complete
Auth Type Support       : NONE MD2 MD5 PASSWORD
Auth Type Enable        : Callback : MD2 MD5 PASSWORD
: User     : MD2 MD5 PASSWORD
: Operator : MD2 MD5 PASSWORD
: Admin    : MD2 MD5 PASSWORD
: OEM      : MD2 MD5 PASSWORD
IP Address Source       : Static Address
IP Address              : ************
Subnet Mask             : ************
MAC Address             : *************
SNMP Community String   : *****************
IP Header               : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Default Gateway IP      : *************
Default Gateway MAC     : 00:00:00:00:00:00
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
802.1q VLAN ID          : *
802.1q VLAN Priority    : 0
RMCP+ Cipher Suites     : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max   : XaaaXXaaaXXaaXX
:     X=Cipher Suite Unused
:     c=CALLBACK
:     u=USER
:     o=OPERATOR
:     a=ADMIN
:     O=OEM

 

Звездочками я закрыл данные о тестовой настройки своего IPMI.

соответственно изучив листинг команд ipmitool вы сможете настроить его по своему вкусу

#: ipmitool

Commands:
raw           Send a RAW IPMI request and print response
i2c           Send an I2C Master Write-Read command and print response
spd           Print SPD info from remote I2C device
lan           Configure LAN Channels
chassis       Get chassis status and set power state
power         Shortcut to chassis power commands
event         Send pre-defined events to MC
mc            Management Controller status and global enables
sdr           Print Sensor Data Repository entries and readings
sensor        Print detailed sensor information
fru           Print built-in FRU and scan SDR for FRU locators
gendev        Read/Write Device associated with Generic Device locators sdr
sel           Print System Event Log (SEL)
pef           Configure Platform Event Filtering (PEF)
sol           Configure and connect IPMIv2.0 Serial-over-LAN
tsol          Configure and connect with Tyan IPMIv1.5 Serial-over-LAN
isol          Configure IPMIv1.5 Serial-over-LAN
user          Configure Management Controller users
channel       Configure Management Controller channels
session       Print session information
sunoem        OEM Commands for Sun servers
kontronoem    OEM Commands for Kontron devices
picmg         Run a PICMG/ATCA extended cmd
fwum          Update IPMC using Kontron OEM Firmware Update Manager
firewall      Configure Firmware Firewall
shell         Launch interactive IPMI shell
exec          Run list of commands from file
set           Set runtime variable for shell and exec
hpm           Update HPM components using PICMG HPM.1 file
ekanalyzer    run FRU-Ekeying analyzer using FRU files

 

Надеюсь кому-то поможет моя статья.

Разработка NewWpThemes.com  |  шаблоны для wp