вторник, 13 января 2009 г.

Автоматизация резервного копирования в Linux

Автоматизация резервного копирования в Linux

Никаких отговорок: безопасное распределенное сетевое резервное копирование своими руками

developerWorks

Уровень сложности: средний

Карлос Юстиниано, архитектор программного обеспечения, Ecuity Inc.

13.01.2009

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

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

Простая схема резервного копирования

Чтобы упростить освоение материала, в данной статье используется пошаговый подход.

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


Листинг 1. Shell-скрипт arc
   #!/bin/sh     tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1     exit $?

Скрипт arc принимает в качестве параметра путь к файлу или каталогу, после чего создает архивный файл, имя которого содержит текущую дату. Например, для архивирования каталога beoserver скрипту arc необходимо передать путь к нему, после чего будет сформирован сжатый архив, имеющий имя приблизительно следующего вида: beoserver.20040321-014844.tgz

Упорядочить архивные файлы поможет включение в их имена даты и времени с помощью команды date. Дата имеет следующий формат: год, месяц, день, час, минуты, секунды - секунды, вероятно, в нашем случае уже лишние. О параметрах команды date можно узнать из ее руководства, просмотреть которое можно командой man date. Кроме того, в листинге 1 мы используем параметр -v (verbose, подробно) команды tar. Команда tar, запущенная с данным параметром, отображает имена всех архивируемых файлов. Если этого не требуется, параметр -v можно убрать.


Листинг 2. Архивирование каталога beoserver
   $ ls     arc  beoserver     $ ./arc beoserver     beoserver/     beoserver/bookl.dat     beoserver/beoserver_ab_off     beoserver/beoserver_ab_on     $ ls     arc  beoserver  beoserver.20040321-014844.tgz



В начало


Сложные схемы резервного копирования

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

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


Рисунок 1. Распределенная сеть
Рисунок 1. Распределенная сеть

Резервные копии файлов, находящихся на Сервере №1 и Сервере №2, будут безопасным образом передаваться во внешнее хранилище; весь процесс распределенного резервного копирования будет выполняться полностью автоматически на регулярной основе. Мы воспользуемся стандартным набором инструментов, в который входят программы из пакета Open Secure Shell (OpenSSH), ленточный архиватор (tar) и служба планирования задач cron. В общем виде наш план заключается в использовании cron для планирования задач резервного копирования, реализованных с помощью shell-скриптов и ленточного архиватора tar. Защищенная оболочка (ssh) будет обеспечивать шифрование трафика и аутентификацию пользователей, а программа защищенного копирования (scp) - автоматизацию передачи файлов. Предварительно рекомендую ознакомиться с руководствами по использованию всех перечисленных инструментов.



В начало


Защищенный удаленный доступ с использованием открытых/закрытых ключей

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

На каждом компьютере, задействованном в процессе резервного копирования, должна быть запущена служба защищенной оболочки OpenSSH (sshd). Используемый службой порт 22 должен быть открыт для данных машин на всех промежуточных сетевых экранах. Если вы работаете с удаленными серверами, велика вероятность, что вы делаете это с помощью защищенной оболочки.

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

Для начала проверим, установлен ли пакет OpenSSH, и выясним номер его версии. На момент написания этой статьи последним выпуском OpenSSH была версия 3.8, увидевшая свет 24 февраля 2004 г. Рекомендуется использовать наиболее свежий и стабильный выпуск, по крайней мере более поздний, чем версия 2.x. Для получения подробной информации о уязвимостях, обнаруженных в ранних версиях OpenSSH, посетите страницу OpenSSH Security (ссылка приведена ниже в разделе Ресурсы). В настоящий момент OpenSSH является вполне стабильной программой, не имеющей уязвимостей, обнаруженных в других SSH-инструментах.

Для отображения версии программы выполните команду ssh с параметром V (прописная буква):

$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

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

Нашим первым шагом будет вход на сервер внешнего хранилища под учетной записью, которая будет иметь доступ к серверам 1 и 2 (рисунок 1).

$ ssh accountname@somedomain.com

После входа на сервер внешнего хранилища создайте пару из открытого и секретного ключей, запустив программу ssh-keygen с параметром -t dsa. Параметр -t является обязательным и используется для указания типа ключа шифрования, который требуется сгенерировать. Мы воспользуемся алгоритмом Digital Signature Algorithm (DSA), позволяющим применять новый протокол SSH2. Дополнительную информацию по данному вопросу можно получить, ознакомившись с руководством к программе ssh-keygen.

После запуска ssh-keygen вам будет предложено указать каталог, в котором будут созданы файлы ssh-ключей, после чего будет запрошен пароль. Если на вопрос о каталоге для сохранения ключей ответить простым нажатием Enter, программа создаст скрытый каталог .ssh (если он не был создан ранее), в котором будут находиться два файла, содержащие открытый и секретный ключи.

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


Листинг 3. Старайтесь выбрать хорошую парольную фразу
   [offsite]:$ ssh-keygen -t dsa     Generating public/private dsa key pair.     Enter file in which to save the key (/home/accountname/.ssh/id_dsa):     Enter passphrase (empty for no passphrase): (enter passphrase)     Enter same passphrase again: (enter passphrase)     Your identification has been saved in /home/accountname/.ssh/id_dsa.     Your public key has been saved in /home/accountname/.ssh/id_dsa.pub.     The key fingerprint is:     7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite

Поскольку каталог .ssh, создаваемый ssh-keygen, является скрытым, чтобы его увидеть, необходимо выполнить команду ls с параметром -a.

[offsite]$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Перейдите в скрытый каталог .ssh и выведите его содержимое:

[offsite]$ cd .ssh
[offsite]$ ls -lrt
id_dsa id_dsa.pub

Видно, что в скрытом каталоге .ssh находятся файлы секретного (id_dsa) и открытого (id_dsa.pub) ключей. Просмотреть содержимое этих файлов можно с помощью текстового редактора, например, vi или emacs, или воспользовавшись командами less или cat. При просмотре содержимого файлов вы увидите, что оно состоит из алфавитно-цифровых символов кодировки base64.

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


Листинг 4. Установка открытых ключей на удаленные серверы
   [offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub     accountname@server1.com's password: (enter password, not new passphrase!)     id_dsa.pub 100% |*****************************| 614 00:00     [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub     accountname@server2.com's password: (enter password, not new     passphrase!)     id_dsa.pub 100% |*****************************| 614 00:00

После установки новых открытых ключей мы сможем заходить на каждый из серверов, используя парольную фразу, указанную при создании открытого и секретного ключей. А пока войдите на каждый из серверов и добавьте содержимое файла offsite.pub в конец файла authorized_keys, находящегося в каталоге .ssh. Это можно сделать с помощью текстового редактора или команды cat:


Листинг 5. Добавление offsite.pub к списку авторизованных ключей
   [offsite]$ ssh accountname@server1.com     accountname@server1.com's password: (enter password, not new     passphrase!)     [server1]$ cat offsite.pub >> ./ssh/authorized_keys

На следующем шаге мы примем дополнительные меры безопасности. Сначала мы изменим права доступа к .ssh таким образом, чтобы доступ к данному каталогу на чтение, запись и выполнение имел только его владелец. Затем мы убедимся, что доступ к файлу authorized_keys имеет только его владелец. И наконец, мы удалим за ненадобностью ранее загруженный файл открытого ключа offsite.pub. Очень важно правильно назначить права доступа, поскольку сервер OpenSSH может отказать в использовании ключей, для файлов которых заданы небезопасные права доступа.


Листинг 6. Изменение прав доступа командой chmod
   [server1]$ chmod 700 .ssh     [server1]$ chmod 600 ./ssh/authorized_keys     [server1]$ rm offsite.pub     [server1]$ exit

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

[offsite]$ ssh -v accountname@server1.com

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



В начало


Автоматизация доступа к компьютеру с помощью ssh-агента

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

Давайте взглянем на программу ssh-agent поближе. Ssh-agent выводит команды:


Листинг 7. ssh-agent в действии
   [offsite]$ ssh-agent     SSH_AUTH_SOCK=/tmp/ssh-XX1O24LS/agent.14179; export SSH_AUTH_SOCK;    SSH_AGENT_PID=14180; export SSH_AGENT_PID;     echo Agent pid 14180;

Мы можем указать оболочке выполнять команды, выводимые программой ssh-agent, с помощью встроенной команды eval:

[offsite]$ eval `ssh-agent`
Agent pid 14198

Команда eval вычисляет (выполняет) команды, генерируемые программой ssh-agent. Убедитесь, что используются именно обратные (`), а не одинарные кавычки! Команда eval `ssh-agent` возвращает идентификатор процесса агента. Незаметно для нас были экспортированы переменные оболочки SSH_AUTH_SOCK и SSH_AGENT_PID. Их значения можно просмотреть путем вывода в консоль следующей командой:

[offsite]$ echo $SSH_AUTH_SOCK
/tmp/ssh-XX7bhIwq/agent.14197

Переменная $SSH_AUTH_SOCK (сокращение от SSH Authentication Socket) содержит путь к локальному сокету, предназначенному для связи приложений с программой ssh-agent. Чтобы убедиться в том, что переменные SSH_AUTH_SOCK и SSH_AGENT_PID всегда заданы, добавьте команду eval `ssh-agent` в файл ~/.bash_profile.

После этого ssh-agent становится фоновым процессом, увидеть который можно с помощью команд top и ps.

Теперь мы можем организовать с его помощью совместный доступ к парольной фразе. Для того, чтобы это сделать, нам потребуется программа ssh-add, добавляющая (отправляющая) парольную фразу программе ssh-agent.


Листинг 8. Использование ssh-add для входа на сервер без лишних трудностей
   [offsite]$ ssh-add     Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)     Identity added: /home/accountname/.ssh/id_dsa     (/home/accountname/.ssh/id_dsa)

Теперь при получении доступа к server1 парольная фраза запрашиваться не будет:

[offsite]$ ssh accountname@server1.com
[server1]$ exit

Если приведенный пример кажется вам неубедительным, попробуйте выгрузить (kill -9) процесс ssh-agent и повторно подключиться к server1. В этом случае вы заметите, что server1 запросит парольную фразу секретного ключа, хранящегося в файле id_dsa, который находится в каталоге .ssh.

[offsite]$ kill -9 $SSH_AGENT_PID
[offsite]$ ssh accountname@server1.com
Enter passphrase for key '/home/accountname/.ssh/id_dsa':



В начало


Упрощенный доступ к ключам с помощью скрипта keychain

К данному моменту мы узнали, как работают некоторые программы пакета OpenSSH (ssh, scp, ssh-agent и ssh-add), а также создали и установили секретный и открытый ключи для того, чтобы обеспечить безопасный автоматический процесс входа на сервер. Вы, вероятно, уже поняли, что большую часть работы по настройке требуется выполнить только единожды. Например, процесс создания и установки ключей, а также настройка запуска ssh-agent из .bash_profile выполняются только один раз для каждого сервера. Это хорошо.

Плохо то, что программа ssh-add должна запускаться каждый раз, когда мы входим на сервер внешнего хранилища и, помимо этого, в том, что обеспечение совместимости программы ssh-agent с планировщиком с, который потребуется нам для организации резервного копирования, требует дополнительных усилий. Причина неспособности cron взаимодействовать с ssh-agent заключается в том, что задачи cron выполняются как дочерние процессы планировщика и поэтому не получают копию переменной $SSH_AUTH_SOCK.

К счастью, данная проблема имеет решение, позволяющее не только снять ограничения, связанные с использованием ssh-agent и ssh-add, но и использовать cron для автоматизации всех видов задач, требующих безопасного беспарольного доступа к удаленным машинам. В своем цикле OpenSSH key management (ссылка приведена в разделе Ресурсы), состоящем из трех статей, опубликованных developerWorks в 2001 году, Дэниел Роббинс (Daniel Robbins) представил скрипт keychain, представляющий собой интерфейс к программам ssh-agent и ssh-add, облегчающий процесс беспарольного доступа. Со временем был сделан ряд улучшений данного скрипта, который теперь поддерживается Ароном Гриффисом (Aron Griffis). Последний выпуск, датированный 17 июня 2004 г., имеет номер 2.3.2-1.

Текст скрипта keychain слишком велик для того, чтобы его можно было привести в данной статье, поскольку он, как и любой качественно написанный скрипт, включает большое количество проверок возникновения ошибок, подробную документацию и внушительный объем кроссплатформенного кода. Несмотря на обширные возможности, скрипт keychain можно быстро загрузить с web-сайта проекта (ссылка приведена в разделе Resources).

Работать со скриптом, после того как вы его загрузите и установите, очень просто. Просто зайдите на каждый из серверов и добавьте следующие две строки в конец файлов .bash_profile:

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

Когда вы зайдете на серверы в следующий раз, keychain запросит парольную фразу. При последующих входах, однако, ввод парольной фразы не будет запрашиваться до момента перезагрузки сервера. И, что самое главное, задачи cron смогут осуществлять безопасный доступ к удаленным машинам без ввода пароля. Теперь наше решение совмещает преимущества повышенной безопасности и простоты использования.


Листинг 9. Инициализация keychain на каждом сервере
   KeyChain 2.3.2; http://www.gentoo.org/projects/keychain    Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the GPL    * Initializing /home/accountname/.keychain/localhost.localdomain-sh     file...     * Initializing /home/accountname/.keychain/localhost.localdomain-csh     file...     * Starting ssh-agent     * Adding 1 key(s)...     Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)



В начало


Автоматизация процесса резервного копирования

Нашей следующей задачей является написание скриптов, выполняющих операции, необходимые для резервного копирования. Целью работы данных скриптов будет создание полной резервной копии баз данных, находящихся на серверах server1 и server2. На каждом из серверов в рассматриваемом примере установлена СУБД MySQL. Соответственно для экспорта нескольких таблиц в виде SQL-скрипта мы будем использовать утилиту mysqldump, работающую в командной строке.


Листинг 10. Скрипт dbbackup.sh для сервера 1
   #!/bin/sh    # переходим в каталог backup_agent, в котором хранятся файлы данных.    cd /home/backup_agent     # экспортируем таблицы баз данных с помощью утилиты mysqldump    mysqldump -u sitedb -pG0oDP@sswrd --add-drop-table sitedb --    tables tbl_ccode tbl_machine tbl_session tbl_stats > userdb.sql     # архивируем и сжимаем файлы tar czf userdb.tgz userdb.sql

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

[server1]:$ chmod +x dbbackup.sh

Разместив копии файла dbbackup.sh на серверах 1 и 2, мы возвращаемся на сервер внешнего хранилища, где создаем скрипт, выполняющий их перед запуском процесса удаленного копирования сжатых архивов (.tgz).


Листинг 11. Скрипт backup_remote_servers.sh для размещения на сервере внешнего хранилища
   #!/bin/sh    # используем ssh для удаленного выполнения скрипта dbbackup.sh на сервере 1    /usr/bin/ssh backup_agent@server1.com "/home/backup_agent/dbbackup.sh"     # используем scp для безопасного копирования созданного архивного файла userdb.tgz     # с сервера 1.  Обратите внимание на использование команды date     для формирования временной отметки     # при размещении файла на сервере внешнего хранилища.     /usr/bin/scp backup_agent@server1.com:/home/backup_agent/userdb.tgz /    home/backups/userdb-$(date +%Y%m%d-%H%M%S).tgz     # выполняем скрипт dbbackup.sh на сервере 2     /usr/bin/ssh backup_agent@server2.com     "/home/backup_agent/dbbackup.sh"      # используем scp для копирования transdb.tgz на сервер внешнего хранилища.     /usr/bin/scp backup_agent@server2.com:/home/backup_agent/transdb.tgz /    home/backups/transdb-$(date +%Y%m%d-%H%M%S).tgz

Скрипт backup_remote_servers.sh использует ssh для удаленного выполнения скриптов на серверах. Поскольку доступ, организованный нами, не требует ввода пароля, программа ssh может удаленно выполнять команды на серверах 1 и 2 с сервера внешнего хранилища. Благодаря keychain процесс аутентификации происходит полностью автоматически.



В начало


Планирование задач

Наша следующая и последняя задача заключается в планировании выполнения скрипта backup_remote_servers.sh на сервере внешнего хранилища. Для этого мы добавим в конфигурационный файл планировщика cron две новые записи, согласно которым скрипт резервного копирования будет запускаться дважды в день - в 3:34 и в 20:34. Чтобы добавить записи, запустите на сервере внешнего хранилища программу crontab с параметром -e.

[offsite]:$ crontab -e

Программа crontab запустит используемый по умолчанию текстовый редактор, указанный в переменных среды VISUAL или EDITOR. Теперь введите две новые записи, после чего сохраните и закройте файл.


Листинг 12. Записи crontab на сервере внешнего хранилища
   34 3 * * * /home/backups/remote_db_backup.sh     34 20 * * * /home/backups/remote_db_backup.sh

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


Листинг 13. Формат записи crontab
   +---- минута     | +----- час     | | +------ день     | | | +------ месяц     | | | | +---- день недели     | | | | | +-- команда, подлежащая выполнению     | | | | | |    34 3 * * * /home/backups/remote_db_backup.sh



В начало


Верификация резервных копий

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

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



В начало


Дополнительные меры обеспечения информационной безопасности

Для повышения уровня информационной безопасности можно установить и настроить на каждом сервере систему обнаружения вторжений (Intrusion Detection System, IDS), например, Snort. Система обнаружения вторжений предназначена для оповещения о попытках взлома системы, происходящих в данный момент или имевших место недавно. Наличие такой системы позволит наращивать уровень информационной безопасности за счет применения таких технологий как цифровая подпись и шифрование резервных копий.

Архивные файлы можно защитить с помощью распространенных инструментов с открытым исходным кодом, например GNU Privacy Guard (GnuPG), OpenSSL и ncrypt, однако, применять их без дополнительного уровня защиты, предоставляемого системой обнаружения вторжений, не рекомендуется (ссылки на дополнительную информацию по Snort приведены в разделе Ресурсы).



В начало


Заключение

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



Ресурсы

  • Примите участие в обсуждении материала на форуме.

  • Оригинал статьи Automate backups on Linux (EN) (developerWorks, июль 2004 г., обновлено: июль 2008 г).

  • На официальном сайте OpenSSH и странице OpenSSH Security вы найдете файлы для загрузки, документацию и много другой информации.

  • Прочтите замечательный цикл из трех статей, написанный Дэниелом Роббинсом для IBM developerWorks "OpenSSH Key Management" (EN) (developerWorks, 2001) и загрузите написанное им приложение keychain.

  • Тем, кто хочет узнать больше о SSH, Карлос рекомендует книгу издательства O'Reilly SSH, The Secure Shell: The Definitive Guide (EN) (O'Reilly & Associates, 2001 г.).

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

  • Архивные файлы резервных копий можно подписывать и шифровать с помощью скриптов, использующих GNU Privacy Guard (GnuPG), OpenSSL и ncrypt.

  • Любителей Perl должны заинтересовать статьи Теда Златанова (Ted Zlatanov) "Automating UNIX system administration with Perl" (EN) (developerWorks, 2001 г.), "Intro to cfengine for system administration" (EN) (developerWorks, 2002 г.), and "Application configuration with Perl" (EN) (developerWorks, 2000 г.).

  • Статья "Windows-to-Linux roadmap: Part 8. Backup and recovery" (EN) (developerWorks, 2003 г.), опубликованная на сайте developerWorks, содержит советы по выбору стратегии резервного копирования.

  • IBM Tivoli Storage Manager для Linux (EN) позволяет автоматизировать и обеспечить проведение по расписанию надежного резервного копирования, архивирования и централизованного управления данными на рабочих станциях и серверах, работающих под управлением Linux. Кроме того, линейка продуктов Tivoli включает инструменты для управления пользователями, управления доступом, мониторинга сети и многого другого, предлагая при этом унифицированную среду и интерфейс.

  • Узнайте больше о решениях Tivoli в разделе сайта IBM developerWorks, посвященном Tivoli.

  • В разделе сайта developerWorks, посвященном Linux, можно найти другие материалы для Linux-разработчиков.

  • В магазине технической литературы есть книги на эту и другие темы.(EN)

  • Разрабатывайте и тестируйте ваши приложения для Linux с помощью новейших инструментов и ПО промежуточного слоя, предлагаемых IBM по подписке developerWorks (EN): вы получаете такое программное обеспечение IBM как WebSphere, DB2, Lotus, Rational и Tivoli вместе с лицензией, дающей право пользования им в течение 12 месяцев - все это за меньшие деньги, чем вы предполагаете.

  • Загрузите бесплатные ознакомительные версии отдельных продуктов подписки developerWorks, предназначенных для Linux, включая WebSphere Studio Site Developer, WebSphere SDK for Web services, WebSphere Application Server, DB2 Universal Database Personal Developers Edition, Tivoli Access Manager и Lotus Domino Server, в разделе сайта developerWorksSpeed-start your Linux app (EN). Чтобы начать работу еще быстрее, ознакомьтесь с обучающими статьями и материалами технической поддержки по продуктам.(EN)


Об авторе


Карлос Юстиниано - архитектор программного обеспечения в компании Ecuity, Inc. В круг его интересов входят коммуникации и распределенные вычисления. Карлос сотрудничает с рядом технических журналов в качестве автора. Кроме того, он является основателем и архитектором Linux-проекта ChessBrain, основанного на распределенных вычислениях и вошедшего в 2005 г. в Книгу рекордов Гиннесса.

Комментариев нет: