Продолжаем «полировать» Alfresco…

Статистика посещений моего блога показывает, что наиболее читаемыми являются мои записки про Alfresco. По этому, продолжаю описывать свою эпопею по установке и настройке этой EMS. Собственно, установив Alfresco и запуская его, я продолжал читать файл протокола alfresco.log. И нашел в своем вот такие строки:

11:27:21,879 ERROR [org.alfresco.util.exec.RuntimeExecBootstrapBean] Bootstrap command failed:
Execution result:
   os:         Linux
   command:    "soffice" "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager" "-env:UserInstallation=file://oouser" -nologo -headless -nofirststartwizard -nocrashrep -norestore
   succeeded:  false
   exit code:  2
   out:

   err:        Cannot run program ""soffice"": java.io.IOException: error=2, No such file or directory

То бишь, хоть и старался я, и угадывал, какой же путь к Open Office указать при установке, все это, увы, оказалось безрезультатно! Как видно из приведенного фрагмента лога — «Файл не найден» — утверждает программа! Чтож, будем искать! Первым направлением «поисков» было традиционное слово — «пути». Дело происходило отнюдь не вчера, и некоторые детали я уже и не помню. Но, по моему, все таки именно я, следуя совету уж не помню из какого форума, создал в «стандартной» папке /usr/bin т.н. «жесткую ссылку» на программу soffice. А может быть и не я, а сама процедура установки Open Office. Одним словом, не помешает проверить ее наличие, и если там ссылки нет, то создать ее командой:

ln -s /opt/openoffice.org3/program/soffice /usr/bin/soffice

После этого проблем с запуском Open Office (в том числе и из консоли) нет — где бы ни был, кто бы не запускал — Open Office стартует на ура. Перезапускаю Alfresco, смотрю в лог — сообщение об ошибке осталось — «программа не найдена». Ну что за беда! Смущали меня лишь кавычки вокруг имени программы (soffice) — их почему-то было аж по паре с каждой из сторон. Поиск по форуму Alfresco подтвердил — мои сомнения были не напрасны. Как оказалось, это баг в файле, запускающем Open Office из Alfresco. Итак, идем в папку /opt/Alfresco/tomcat/shared/classes/alfresco/extension/bootstrap, находим в ней файл openoffice-startup-context.xml и смотрим его содержимое. Точнее, ту его часть, которая определяет значение «openOfficeStartupCommand». Вот так она выглядит в «родном» виде из архива:


   <bean id="openOfficeStartupCommand" class="org.alfresco.util.exec.RuntimeExec">
<property name="commandMap">
<map>
<entry key=".*">
<value><![CDATA["soffice" "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager" "-env:UserInstallation=file://oouser" -nologo -headless -nofirststartwizard -nocrashrep -norestore]]></value>
</entry>
</map>
</property>

Сама команда, запускающая Open Office, приведена в строке, начинающейся с «<value><![CDATA[…» (и т.д.). И именно в ней присутствуют эти самые кавычки. Я их в приведенном выше фрагменте файла для наглядности выделил красным. Вот именно эти кавычки и нужно убрать! ВНИМАНИЕ! Строка длинная, поэтому, просмотрите ее всю — в ней нужно убрать ТРИ ПАРЫ кавычек! Удаляем их все раз и навсегда! И, сохранивши файл openoffice-startup-context.xml, перезапускаем Alfresco. И вот, после выполнения данных изменений фрагмент моего лога стал выглядеть таким образом:


18:47:15,115 WARN  [org.alfresco.util.OpenOfficeConnectionTester] An initial OpenOffice connection could not be established.
18:47:15,636 INFO  . . .
18:47:15,637 WARN  . . .
18:47:15,651 INFO  . . .
18:47:17,312 WARN  . . .
18:48:32,384 INFO  [org.alfresco.util.OpenOfficeConnectionTester] The OpenOffice connection was re-established.

Как мы видим в последней строке цитаты, «соединение с Open Office восстановлено». То еть, все ОК!…

Putty — вход в консоль Linux из Windows

Когда я только начинал возиться со своим «сервером»,  то настроил доступ к его графическому рабочему столу при помощи NX. Описано это мной на вот этой странице. Но зачастую для решения «управленческих» задач нет нужды запускать «тяжеловесный» графический десктоп, а достаточно всего-лишь «легкой» и быстрой консоли. В случае с Linux-ом все просто — там ssh-клиент присутствует. Но периодически возникает нужда войти в «сервер» из под Windows. Для этой цели лично я пользуюсь программой PuTTY. Причина моего выбора проста — программа бесплатная, кроме того, она легко устанавливается и также легко настраивается.

Итак, для начала идем на домашнюю страницу программы и качаем инсталятор программы. (Если приведенные мной ссылки устарели, просто «Google-им» по-быстренькому). Устанавливаем. Думаю, тут не возникнет никаких трудностей.

Запускаем PuTTY (обычно это — «Пуск» -> «Программы» -> «PuTTY» -> «PuTTY»).  И видим вот такое окно настройки и запуска PuTTY:

putty_main
Рис. 1 Окно настройки и запуска PuTTY

Чтобы, как говорится, ну совсем уж «по-быстрому»», достаточно всего лишь в поле «Host name (or IP adress)» ввести, как нас и просят, либо имя, либо IP-адрес компьютера, к которому мы будем подключаться и затем щелкнуть кнопку «Open«. В принципе, стоило бы сначала еще подредактировать пару настроек, ну да ладно, мы ведь очень торопимся. К настройкам мы еще вернемся позже, а пока… Если Вы подключаетесь к выбранному компьютеру в первый раз, то получите вот такое сообщение:

putty_host_key
Рис. 2 Запрос на запись ключа удаленного компьютера

Суть его в том, что Вам предлагают убедиться — а к тому ли удаленному компьютеру Вы подключаетесь, и если «да», то сохранить его ключ, чтобы избежать подобного вопроса в будущем. Вы можете сохранить ключ (ответ «Да»), не сохранять ключ (ответ «Нет») и прервать соединение (кнопка «Отмена»). Кстати, такой же самый вопрос Вы получите снова, если попытаетесь обратится к тому же удаленному компьютеру, но уже с использованием другого имени (например, раньше Вы подключались к нему по IP-адресу и сохранили ключ, а теперь пытаетесь подключиться по имени компьютера).

Чтобы продолжить подключение к удаленному компьютеру, жмем «Да». (Можно выбрать и «Нет», но тогда при следующем подключении Вам придется снова отвечать на вопрос о ключе). В любом случае запустится окно консоли, и Вам будет предложено осуществить вход в систему в (скажем так) «ручном» режиме:

ptty_login1
Рис. 3 Процесс входа с вводом имени пользователя и пароля с клавиатуры

Как видно на приведенном выше рисунке, при «ручном» входе первым делом Вы должны указать пользователя, от имени которого подключаетесь к удаленному компьютеру. Затем следует запрос пароля. Если введенные Вами имя и пароль приняты компьютером, то выводится информация о дате и времени предыдущего входа данного пользователя в систему, после чего появляется приглашение — Вы в консоли удаленного компьютера. Можно рулить!..

На что при этом стоит обратить еще внимание, так это на настройку SSH-демона на «принимающей стороне» (в Linux-сервере).  У него может быть запрещена авторизация (вход) по паролю. Вкратце я об этом упоминал тут (параметр «PasswordAuthentication» и его два возможных значения — «yes» и «no»). В случае, если авторизация по паролю запрещена, подключиться так, как только что было описано выше, не получится. В этом случае нужно настраивать доступ по ключу (об этом ниже).

«Нарулившись», вводим комманду «exit» — консоль закрывается, соединение с удаленным компьютером разрывается.

Теперь вернемся к той «парочке настроек», о которой я упоминал выше. Чтобы убедиться в необходимости одной из них, достаточно просто запустить Midnight Commander, или же найти файлы с кирилицей в именах. «Кракозябры»!!! Дело в том, что в подавляющем большинстве дистрибутивов Linux используется кодировка UTF-8, в то время, как в PuTTY по умолчанию включена KOI8-U. Поэтому, если не менять кодировку, то будут проблемы как с отображением кирилицы, так и с отображением псевдографики. Выглядеть это будет примерно так:

putty_wrong_locale
Рис. 4 "бНОПНЯ", обусловленная неправильной настройкой кодировки, а также, вызов контекстного меню PuTTY

Поправить настройку локали можно «по-быстрому», даже не выходя из консоли. Нужно лишь мышью «щелкнуть» в левом верхнем углу окна PuTTY. Появится выпадающее меню (как показано на рис. 4 выше). В меню нужно выбрать пункт «Change Settings«.  Появится то же самое окно настройки и запуска PuTTY, которое мы наблюдали в самом начале (см. рис. 1). В данном меню сначала нужно в левой колонке выбрать пункт «Translation«, затем в правой чвасти меню в выпадающем списке выбрать кодировку UTF-8, и потом внизу справа нажать кнопку «Apply» (как показано на рис. 5 ниже).

putty_tranlation
Рис. 5 Выбор локали (кодировки)

Внимание! Уже отображенные в окне консоли «кракозябры» после смены кодировки таковыми и останутся. Изменения будут видны лишь после перерисовки экрана (например, нажатия Ctrl+R в Midnight Commander)…

Вторая настройка не является критической. Лично я обчно её настраиваю для себя т.к. уже подслеповат. Это возможность выбрать вид и размер шрифта, используемого в консоли PuTTY. Для этого в окне настройки в левой колонке выбираем пункт «Appearance» (см. рис. 6):

putty_font_change
Рис. 6 Изменение шрифта

В правой части меню при этом появится раздел «Font setting». В нем выбираем кнопку «Change«. Откроется окно выбора шрифта, стандартное для многих приложений Windows. В нем выбираем и шрифт, и его размер, как говорится, «по вкусу», и затем жмем кнопку «ОК». Вернувшись в окно настройки,  нажимаем кнопку «Apply»  внизу справа. Изменение этой настройки меняет вид шрифта в окне консоли сразу же.

Недостаток изменения настроек «по быстрому» лишь один — указанные нами значения действуют только на время текущего сеанса и сбрасываются после его закрытия. Согласитесь, неудобно каждый раз работу начинать с того, что настраивать кодировки, шрифты, и т.д. и т.п. По этому, PuTTY позволяет создать сессию (сеанс) и сохранить все настройки в ней. Чтобы создать и сохранить новый сеанс, если сессия у Вас уже запущена, сначала завершите ее командой «exit«. Затем, по-новой запустите PuTTY («Пуск» -> «Программы» -> «PuTTY» -> «PuTTY»).  Мы снова видим окно настройки и запуска PuTTY. Но вместо того, чтобы просто вводить адрес и жать «Open«, мы выполним следующее:

putty_save_session
Рис. 7 Сохранение сессии
  1. Вводим имя или IP-адрес удаленного компьютера.
  2. Проверяем номер порта к которому подключаемся. В большистве случаев SSH-демон Linux-компьютеров настроен ожидать подключения именно на 22-иу порту. Но иногда администраторы меняют номер порта в целях безопасности или по иным причинам. Если у удаленного компьютера, к которому Вы планируете подключаться,  SSH-демон настроен на прослушивание порта с другим номером, то введите в это поле правильное значение.
  3. Проверяем, что подключаемся по протоколу SSH. (Вообще, программа PuTTY позволяет подключаться к различным службам).
  4. Вводим имя сессии. (Это имя Вы придумываете сами — как хотите, так и называйте).
  5. Нажимаем кнопку «Save«.

Все! Сессия сохранена. После этого можно настроить кодировку и шрифт, как показано выше (рис. 5 и 6). Выполнив изменения, возвращаемся в закладку «Session» и снова нажимаем кнопку «Save«. До изменения любых параметров убедитесь в том, что имя сессии присутствует в поле, на которое указвает указатель №4 на рис. 7. Если там пусто, то сначала нужно выбрать  имя своей сессии в списке начинающмся с пункта «Default settings» и шелкнуть кнопку «Load» справа.  Лишь после этого имеет смысл менять и сохранять настройки сессии…

Впоследствии, когда сессия создана, ей присвоено имя, и все настройки выполнены и сохранены, то для того, чтобы запустить сеанс, достаточно будет лишь дважды щелкнуть на имени сессии в списке (пониже  «Default settings»), а затем — все как на рис. 3 выше — логин, пароль… И еще — Вы можете сохранить не одну сессию, а столько, сколько Вам понадобится (если есть необходимость подключаться к разным компьютерам).

На этом можно было бы и поставить точку. Если бы не лень! О чем это я? Да о том, что лично мне лень каждый раз при старте сессии вводить имя пользователя и пароль! А что, можно и не вводить? Да, можно! По крайней мере, вручную… SSH-демон допускает автоматическую аутентификацию по ключу вместо пароля, а PuTTY предоставляет возможность указать имя пользователя, используемое при входе в удаленный компьютер. В итоге — вот так выглядит процедура входа в автоматическом режиме:

putty_login_auto
Рис. 8 Вход в автоматическом режиме

Как мы видим на приведенном рисунке, при авторизации программа сама подставляет имя пользователя «dmitry», а вместо пароля используется публичный ключ «rsa-key-20090211». Таким образом, мое вмешательство в процесс подключения к серверу минимизировано и по сути сведено к двойному щелчку мышью по имени выбранного сеанса. Для такого лентяя как я — в самый раз. Но, и для злоумышленника, который захочет взломать Ваш сервер — это тоже прекрасный подарок! По этому, настройку такого подключения стоит осуществлять лишь на тех компьютерах, про которые Вы уверены, что ими никто другой не пользуется, и не сможет использовать эту дыру в безопасности для доступа к Вашему серверу.

Начать стоит с генерации ключей. Для этой цели в комплекте с PuTTY поставляется программа PuTTYgen. Ее назначение — как раз генерировать эти самые файлы ключей. На компьютере, с которого планируем подключатся к серверу, запускаем PuTTYgen: «Пуск» -> «Программы» -> «PuTTY» -> «PuTTYgen»

PuTTYgen - генерация SSH ключа
Рис.9 программа PuTTYgen - генератор SSH ключей

И в программе этой выполняем следующие действия:

  1. Нажимаем кнопку «Generate«. После нажатия начинаем хаотично перемещать мышку по столу. При этом идет генерация ключа. Ход процесса показывает растущая слева напараво полоса индикации.
  2. После того, как ключ сгенерирован (пропадат индикатор прогресса, а вместо него появляются данные о ключе как на рис.9), жмем кнопку «Save public key«, чтобы соохранить файл т.н. «публичного» ключа. Назовем его, например, id_rsa.pub.
  3. Затем нажмем кнопку «Save private key«, чтобы сохранить файл т.н. «приватного» ключа. Назовем его, например, id_rsa.ppk.

Порядок сохранения ключей (кого первым, кого последним) — неважен. Важно лишь не забыть, куда мы их сохранили. Ключи эти парные. Приватный ключ хранится на компьютере, с которого осуществляется доступ. А публичный должен быть импортирован на сервер в специальный файл SSH-ключей того пользователя, от имени которого мы будем впоследствии подключаться. Для этого файл  id_rsa.pub нужно скопировть на сервер (дискетой, флешкой, почтой, ftp — как Вам будет удобно). А затем его нужно импортировать в файл ключей сервера, которй хранится у каждого пользователя в его «домашней» папке в подпапке .ssh и называется authorized_keys. Для этого нужно выполнить команду:

ssh-keygen -i -f id_rsa.pub >> $HOME/.ssh/authorized_keys

ВНИМАНИЕ!

  1. Команда эта должна выполняться уже в консоли сервера, к которому мы впоследствии будем подключаться по ключу. Поэтому, чтобы ее выполнить, сначала нужно войти в консоль сервера в «ручном» режиме, введя имя пользователся и пароль на клавиатуре.
  2. Команда должна выполнятться из той самой директории (папки), в которую был скопирован файл id_rsa.pub. В противном случае в команде нужно будет указать полный путь к файлу ключа.
  3. Команду необхдимо выполнять от имени того пользователя, который впоследствии будет осуществлять подключение к серверу.

Теперь сервер готов к авторизации данного пользователя по ключу. Осталось лишь настроить PuTTY на использование этого самого ключа. Для этого в окне настройки в левой колонке выбираем пункт «SSH», а в нем подпункт «Auth». В правой половине открывшегося окна жмем  кнопку «Browse» и указываем месторасположение второго файла ключа — id_rsa.ppk. (см. рис. 10 ниже)

Выбор файла ключа
Рис. 10 Настройка PuTTY на использование файла приватного ключа.

Теперь при соединении с сервером PuTTY будет использовать указанный файл ключа вместо пароля. Ну и последнее, что осталось сделать, это указать PuTTY какое имя пользователя подставлять при подключении к серверу. Для этого в окне настройки в левой колонке выбираем пункт «Data«, а в правой половине окна в поле «Auto-login username» вводим имя пользователя (как показано на рис. 11 ниже).

putty_user
Рис. 11 Ввод имени пользователя для автоматического входа в систему

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

Почитать подробнее про SSH, а также настройку этой службы на сервере можно по ссылкам:

  1. http://www.opennet.ru/base/sec/ssh_intro.txt.html
  2. http://baybox.narod.ru/linux/putty.html
  3. http://www.pentarh.com/wp/2008/07/21/ssh-public-key-authentication/

А если все-таки чуток GUI ?..

Иногда все-таки вознкает необходимость запустить программу с графическим интерфейсом. Одну-одинешеньку, а не весь десктоп. В случае, когда мы с одного компьютера, работающего под управлением Linux, подключаемся по SSH к другому компьютеру, также работающему под управлением Linux, с этим нет никаких проблем. Дело в двух нюансах. Первый — само построение сервера графической подсистемы X-Window, позволяющее сформировать «каартинку» одним Х-сервером, переслать его, например, по сети на другой и воспроизвести уже там. Второй нюанс — SSH-демон поддерживает X-форвардинг (параметр, вкючается в файле настроек sshd). С SSH для Windows мы разобрались выше. Но вот при запуске какой-нибудь GUI-программы в сессии PuTTY мы получаем ообщение о том, что Х-сервер не найден. И это верно — в Windows нет никакого Х-сервера. Надо бы «организовать присутствие»! И в этом нам может помочь еще одна программа — Xming. Сайт проекта — тут, почитать можно (на английском) — тут. Идем, качаем, устанавливаем.

Запускаем Xlaunch («Пуск» -> «Программы» -> «Xming» -> «Xlaunch»). Эта программа настраивает Xming. Настраиваем (в принципе, там все вполне понятно). Единственный нюанс — это раскладки клаватуры. Их параметры задаются дополнительными опциями в одном из окон конфигурирования. Подробнее можно прочесть например тут (ну или же в документации 😉 )…  После настройки запускаем Xming («Пуск» -> «Программы» -> «Xming» -> «Xming»). Единственное, что видим при этом — добавившуюся в трей возле часов иконку программы («сервер» все-таки)…

Теперь нужно настроить X-форвардинг в PuTTY. Для этого запускамем окно кофигурирования PuTTY (если SSH-сеанс был уже запущен, из него обязательно нужно выйти).  В окне Session выбираем и загружаем (кнопкой «Load«) свою сессию. Потом в левой колонке выбираем пункт «X11» (Connection -> SSH -> X11) и там ставим галочку «Enable X11 forwarding» (см. рис. 12 ниже):

putty_x_forvard
Рис. 12. Включение в PuTTY форвардинга X-Window

После этого сохраняем параметры и запускаем сеанс по-новой. В консоли запускаем какую-нибудь программу, имеющую графический интерфейс. Например, если на Linux-компьютере используется графический десктоп KDE, то можно попробовать запустить Konqueror. Вводим с командной строке «konqueror», немножко ждем и наблюдаем:

putty_x_window
Рис. 13 GUI-приложение (Konqueror), запущенное из консоли PuTTY на графический десктоп Windows

Вот и все…

Еще чуток о кракозябрах…

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

Вопрос скорее относится к рюшечкам, т.к. все функции работают. Есть несколько серверов на SuSE от 9.3 до 10.3 и при работе с ними через Putty при запуске Yast в консольном режиме, вместо псевдографики рисуются буквы (приходится вглядываться, где поле кончается для ввода текста и т.п.). Причем, если запустить mc, то вся псевдографика отображается корректно. Попробовал с одного сервака зайти на другой через ssh — все также отображается корректно, поэтому сделал вывод, что это заморочки либо Putty, либо самого Yast. (Translation в Putty выставлена корректно, русский текст и ввод с клавиатуры — ок)

Решил и я проверить свою Mandriva на это дело. Запустил из Windows коноль в PuTTy, а Xming при этом не запустил. После этого в консоли запустил mcc (Mandriva Control Center — Центр управления Mandriva). Дело в том, что когда нет возможности запустить Центр управления Mandriva в чисто графическом виде (нет «принимающего» X-сервера), он стартует в псевдографике. Оказалось, что и у меня тоже «с буковками вместо границ». Вот так:

wrong_borders_of_mcc
Рис. 14 - Неверное отображение границ в псевдографике

В указанной теме форума присутствовал и вариант решения проблемы:

Это глюк Putty.
Идём в terminal -> Keyboard -> The Function keys and keypads ставим Linux
Идём в Connection -> Data, в графе Terminal-type string пишем linux

Попробовал — действительно границы нарисовало как надо. Однако быстро обнаружились два нюанса. Первый — некорректная работа половины функциональных клавиш. Исправилось простым возвращением значения «xterm» (как собственно и было изначально) для параметра «Keyboard » — «The Function keys and keypads». А вот второй нюанс мое естество так и не смогло «принять»! Дело в том, что совсем по другому стала использоваться мышь. Этот факт я не вынес, и решил, что пусть лучше уж «границы из буковок», но мышь пусть работает «так как было». Поэтому, вернул я назад «xterm» и в параметре «Terminal-type» тоже, созранил настройки и работаю дальше. Хотя, может стоило бы почитать help к программе…

«Полируем» Alfresco дальше…

В корневом каталоге своей установки Alfresco в процессе своей работы создает файлы протоколов (логи). Изначально создаваемый файл носит имя alfresco.log. Впоследствии, при создании нового протокола, старый файл не удаляется, а к его имени просто добавляется дата, и выглядит это примерно так — alfresco.log.2009-01-26. Таким образом, лог с датой в имени — это старый лог. А саммый «свежий» лог — это всегда файл alfresco.log. А на кой он нам нужен? Так для ловли блох, однако! Ну или, проще говоря, — для поиска ошибок. Вот, взял я и почитал лог своей Alfresco. Не зря, т.к. нашел в нем следующие строки:

11:27:12,572 ERROR [org.alfresco.repo.content.transform.swf.PDFToSWFContentTransformer] Failed to start SWF2PDF transformer:
Execution result:
   os:         Linux
   command:    pdf2swf -V
   succeeded:  false
   exit code:  1
   out:
   err:        Cannot run program "pdf2swf": java.io.IOException: error=2, No such file or directory

Что это значит? Да ничего особенного, просто Alfresco не смогла запустить программу pdf2swf. И причину указала — «нет такого файла или каталога». «Не нашла», «не запустила» — не порядок, однако! Чтож, будем наводить красоту, будем искать!..

Пару минут общения со «всемирным» поисковиком, показали, что во-первых, pdf2swf является частью пакета swftools. А во-вторых, что сайт, на котором можно скачать пакет, следующий — http://www.swftools.org/. Быстрый взгляд в «родной» набор пакетов моей Mandriva, показал, что там такого не числится. Чтож, качаем tar.gz-архив с указанного сайта, распаковываем и устанавливаем. Все стандартно,  Сначала команда:

./configure

(Естаственно, от имени root-а). Просмотр вывода ее результатов (да, иногда и такое бывает полезно) показал такие строки:

checking for missing libraries...  ungif gif_lib.h
***************************************************
* The following headers/libraries are missing:  ungif gif_lib.h
* Disabling gif2swf tool...
***************************************************

Хорошо-ли, плохо-ли, но ведь снова «не порядок»! Идем искать дальше. Сообщение об отсутствующей библиотеке пропало лишь после того, как я командой

urpmi libungif4-devel

установил пакет libungif4-devel-4.1.4-3mdv2008.0.i586.rpm. Чтож, возвращаемся к установке swftools. Повторяем комманду «./configure«, затем — «make» и напоследок — «make install«. Установили! Перезапускаем Alfresco, смотрим в лог — ура, нет больше такого сообщения об ошибке! Хорошо! Но, «пришла беда откуда не ждали». Точнее, данное сообщение об ошибке вновь появилось в логе после очередной перезаггрузки компьютера. Проблема была в путях. Исправилась созданием символьной ссылки командой:

ln -s /usr/local/bin/pdf2swf /usr/bin/pdf2swf

После этогго данная ошибка пропала навсегда…

«Рихтуем» StatPress (плагин для WordPress)

Некоторое время тому назал подключил я  к своему блогу плагин StatPress. Интересная штука, собирающая самую различную статистику о посещениях моего блога. Однако, после очередного обновления просмотр этой статистики начал добавлять вот такие ошибки в лог моего apache:

[Tue Feb 01 14:18:10 2009] [error] [client 192.168.1.1] File does not exist: /var/www/html/wp-content, referer: http://dmitrykhn.homedns.org/wp/wp-admin/admin.php?page=statpress/statpress.php

Судя по логу, программа не может найти папку /var/www/html/wp-content, что в моем случае и не удивительно. Дело в том, что WordPress у меня установлен не в корневой папке apache, а в дополнительной папке wp. Поэтому, мне пришлось в корневую папку добавить символьшую ссылку на реальное расположение папки wp-content при помощи команды:

ln -s /var/www/html/wp/wp-content /var/www/html/wp-content

Проблема ушла…

Ну «Secure», так «secure» (часть 3 — fail2ban охраняет apache)

В прошлых моих записях с заголовком «Ну «Secure», так «secure» я защищался от попыток постороннего входа в мой «сервер» по ssh. Но, это ведь не единственный порт моего «сервера», который открыт наружу. Раз уж у меня установлен веб-сайт, то доступ к нему извне, естественно, тоже есть. И вот теперь заглянем-ка в файл протокола ошибок apache (/var/log/httpd/error_log):

[Sat Jan 31 12:05:49 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/bin
[Sat Jan 31 12:05:50 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/mail
[Sat Jan 31 12:05:52 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/webmail
[Sat Jan 31 12:05:53 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/roundcube
[Sat Jan 31 12:05:58 2009] [error] [client 89.18.176.83] File does not exist: /var/www/html/rc

Насколько я понимаю, данные строки лога показывают, что «некто» пытается найти в моем сервере «нечто». Не знаю, можете называть это паранойей, но мне это очень не нравится! А вдруг найдет? Или вот еще, к примеру, строка из лога:

[Mon Jan 26 22:19:46 2009] [error] [client 213.21.37.175] script '/var/www/html/azenv.php' not found or unable to stat

Может это самый лучший и самый полезный в мире скрипт, а может быть и нет. Как по мне, так лучше не надо!

Итак, решено — будем защищаться. fail2ban у меня уже установлен — ssh защищает. Но это далеко не единственная возможность программы. Просто по умолчанию сразу после установки в ней включен единственный фильтр — sshd.conf. Вернемся к сути программы fail2ban. Она постоянно анализирует файлы протоколов работы служб компьютера, пытаясь найти в них сообщения об ошибках, соответствующие установленным шаблонам. Если условие совпадает, программа выполняет указанное действие. Условия-шаблоны прописываются в файлах фильтров, расположенных в папке /etc/fail2ban/filter.d. Возможные действия представлены файлами, находящимися в папке /etc/fail2ban/action.d. Управление «включением» и «выключением» фильтров, а также выбор последующих «действий» осуществляется в файле настроек /etc/fail2ban/jail.conf. Борьбу за безопасность apache я начал с поиска подходящего фильтра в папке /etc/fail2ban/filter.d. На первый взгляд мне подошел файл фильтра apache-noscript.conf. Его я поначалу и задействовал (об этом ниже). Однако, впоследствии, сопоставляя файл протокола ошибок apache и файл протокола работы fail2ban, я заметил, что далеко не все сообщения об ошибках приводят к бану вызвавших их посетителей. Утверждать, что программа не работает, было бы неправдой — на часть ошибок она все-таки реагировала. Следовательно, «что-то не то» с шаблонами. Отличным подспорьем в «разборках» с шаблонами является программа fail2ban-regex, устанавливаемая на компьютер вместе с fail2ban. Программа позволяет проанализировать указанный лог (или просто текстовую строку) на предмет нахождения соответствий шаблону из файла фильтра (или просто текстовой строке). Именно этим я и занялся. Взял лог, взял фильтр и «скормил» их програмке — ввел в консоли команду:

fail2ban-regex /var/log/httpd/error_log apache-noscript.conf

Первый ответ, о том, что найдено аж 10 совпадений меня очень развеселил.  «Невооруженным глазом» было видно, что в логе их гораздо больше… И начал я подбирать шаблон, попутно проверяя его эффективность все той же приведенной выше командой. Число совпадений росло, сначала три сотни, потом больше тысячи, финальный результат был равен 1706. Я решил, что пока хватит, а дальше посмотрим. Теперь о произведенных мной изменениях. Изначально в файле фильтра apache-noscript.conf строка шаблона сообщения об ошибке выглядела так:

failregex = [[]client <HOST>[]] (File does not exist|script not found or unable to stat): .*(\.php|\.asp|\.exe|\.pl)

Результат, который в конце концов устроил лично меня, выглядит так:

failregex = [[]client <HOST>[]] (File does not exist|Invalid URI in request|.* not found or unable to stat)

В чем суть моих изменений? Во первых, оригинальная строка шаблона предполагает, что в логе сообщение об ошибке должно содержать что-либо из «.php», «.asp», «.exe» или «.pl». Если же в строке такого нет, шаблон не срабатывает. Но даже в той «нарезке» лога apache, что я привел выше мы видим, что нет там никаких «.php», «.asp», «.exe» или «.pl». Следовательно фильтр не сработает. По этому, окончание шаблона — (\.php|\.asp|\.exe|\.pl) — я попросту выкинул.

Ну и во вторых, та часть шаблона, которая вылавливает неправильные скрипты. В оригинале она хочет, чтобы в логе был такой текст «script not found or unable to stat» (одним непрерывным куском!!!). Но, посмотрев в свои логи я увидел, что зачастую там текст отформатирован иначе, например так: «script ‘/var/www/html/pt.php’ not found or unable to stat». Следовательно этот фильтр тоже не срабатывал бы. Пришлось его заменить на «.* not found or unable to stat«. В данном случае «.*» обозначает «любой текст». После этого фильтр начал срабатывать на сообщения об ошибках о запуске несуществующих скриптов.

 

Ну и вкратце о том, как я подключал фильтр. В файле настроек /etc/fail2ban/jail.conf я нашел раздел:

[apache-shorewall]

enabled  = false
filter   = apache-noscript
action   = shorewall
           sendmail[name=Postfix, dest=you@mail.com]
logpath  = /var/log/apache2/error_log

И изменил его следующим образом:

[apache-shorewall]

enabled  = true
filter   = apache-noscript
action   = shorewall
           mail-whois[name=Apache, dest=dmitry@my-svr]
logpath  = /var/log/httpd/error_log
maxretry = 2

Таким образом я:

  • включил (enabled = true)…
  • выбранный фильтр (filter = apache-noscript)…
  • на анализ файла протокола (logpath = /var/log/httpd/error_log)…
  • и при возникновении 2 ошибок (maxretry = 2)…
  • доступ блокируется при помощи файервола (action = shorewall).

Вот и все…

P.S.
Не вышло «все», однако… 21 марта с одного IP такой «вал валил», что я решил предпринять что-то. И нашел еще один фильтр — apache-overflows.conf, который вроде как очень подходил моим потребностям. Судите сами, вот кусок лога apache:

[Sat Mar 21 17:19:35 2009] [error] [client 221.223.93.132] Invalid method in request \xf0\xaf\xa0_\x98\x1b\x9fi\xe2\x84\xca\xc8\xca\xfa\xabA\xb4f\xe0+\xf3\x96>S\x90\x90\xc1D\x80\xc2\x11\xe17\xcc\x91\x97
[Sat Mar 21 17:20:04 2009] [error] [client 221.223.93.132] Invalid URI in request \xfb%\xd2\ba\xf5\x84\x9c'\x0c\xbc\xf4|\xffu\x10?\xf2\x96\xee\xda\x9d\xe9\x9f\xb0\x15\xc9\xe9nd
[Sat Mar 21 17:20:43 2009] [error] [client 221.223.93.132] request failed: error reading the headers

А вот (но, правда, уже немножко подкорректированный мной) фильтр:

# Notes.:  Regexp to catch Apache overflow attempts.
# Values:  TEXT
#
failregex = [[]client []] (Invalid method in request|Invalid URI in request|request failed: URI too long|request failed: error reading the headers|erroneous characters after protocol string).*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Пришлось и его включать. С поправкой на тот факт, что мне показалось, что это была именно атака, рубить доступ я решил с первой же попытки. Для этого в файл /etc/fail2ban/jail.conf я добавил следующие строки:

[apache-overflow]
enabled	= true
filter	= apache-overflows
action	= shorewall
logpath	= /var/log/httpd/error_log
maxretry = 1

После этого перезапустил fail2ban командой:

fail2ban-client reload

И вот теперь сижу и жду новых поводов для добавления новых фильтров…

Еще про fail2ban