Кстати, мне, как владельцу аккаунта на twitter, на почту пришло письмо с информацией об обновлениях – настоящий трактат:

P.S.: Если у вас есть twitter-аккаунт – присоединяйтесь

Подробнее о S.M.A.R.T. вы можете посмотреть на википедии, я заострю внимание на ПО для Linux, как одной из наиболее популярных серверных ОС.

Для чтения данных S.M.A.R.T. в Linux (и, кстати, в BSD тоже) предусмотрен набор инструментов под названием smartmontools. В Ubuntu он доступен из стандартных репозиториев. Устанавливаем:

# aptitude install smartmontools

После установки необходимо узнать, доступен ли SMART на интересующем устройстве. Допустим, это /dev/sda:

# smartctl -i /dev/sda

Параметр -i выводит информацию по указанному вслед за ним устройству. В этой информации можно узнать, поддерживает ли S.M.A.R.T. устройство, и если да, то также можно узнать, включен S.M.A.R.T. или нет:

Для управления работой S.M.A.R.T. можно делать так:

# smartctl -s on /dev/sda

для включения, и

# smartctl -s off /dev/sda

для выключения.

Для вывода полной информации по устройству можно скомандовать так:

# smartctl -a /dev/sda

На выходе я получил много-много статистики по своему жесткому диску:

На самом деле её гораздо больше, я просто показал скриншот с самой “злободневной” информацией – эти значения могут дать вам представление о том, когда может сдохнуть жесткий диск. Однако, следует помнить о том, что выход некоторых значений за рамки заводских не всегда означает, что винту капец – единичные сбои случаются и с вполне исправным оборудованием. Так что рекомендую почитать поподробнее про саму технологию S.M.A.R.T. На деле, -a – параметр, который эквивалентен набору “-H -i -c -A -l error -l selftest -l selective” для ATA-дисков, и “-H -i -A -l error -l selftest” для SCSI-дисков (взято из man). Параметр -H выдает текущий статус устройства, составленный на основе различных тестов. -i – уже известный параметр, выдающий информацию об устройстве. -c – выдает только основные атрибуты S.M.A.R.T. – разные производители могут добавлять или убирать какие-либо атрибуты в S.M.A.R.T. -A – выдает информацию по специфическим для производителя атрибутам S.M.A.R.T. -l – выдает информацию из логов различных тестов. Для этого параметра необходимо указать значение – лог какого теста выводить.

Утилита smartctl хороша еще и тем, что при её помощи можно прогонять тесты жестких дисков. Однако, тут есть ограничение – единовременно можно прогонять только один тест. Для немедленного запуска теста есть параметр -t, после которого необходимо указать значение, характеризующее тест. Возможные значения – offline; short; long; conveyance; select,<START_LBA> – <END_LBA>; select,<START_LBA>+<SIZE>. Все виды тестов могут быть проведены при штатной работе устройства. Однако, и тут есть оговорки, и, поскольку ответственность за функционирование устройств и целостность хранящихся на них данных лежит только на вас, настоятельно рекомендую почитать man smartctl перед запуском тестов. Последние два теста (select – SMART Selective Self Test – тестирование определенного количества логических блоков устройства) принимают параметры – <START_LBA>, <END_LBA>, <SIZE>: соответственно адрес логического блока, с которого начинать, адрес логического блока, на котором заканчивать, количество блоков, которое тестировать. Использовать, например, так:

# smartctl -t offline -t select,0-100 /dev/sda

В этой команде я указал утилите прогнать offline-тест и selective-тест с нулевого по 100-й блоки. Разумеется, они будут прогнаны последовательно.

Если вы сталкиваетесь с ситуацией, когда находитесь на расстоянии от сервера или терминала, в котором можно посмотреть результаты тестов S.M.A.R.T., можно настроить уведомление об ошибках тестов по электронной почте. Это можно настроить при помощи файла smartd.conf . Подробнее о том, как это сделать, читайте man smartd.conf . Вкратце ситуация обстоит так – необходимо в этом конфиге создать правило, в соответствии с которым, по расписанию, будет запускаться определенный набор тестов и, в случае возникновения ошибок, на указанный e-mail будет отправляться сообщение.

Вот пример.

Открываю /etc/smartd.conf, пишу там (предположу, что у меня SCSI-диск):

/dev/sda -d scsi -m somemail@example.com -a -s L/../../1/02

Что здесь что: -d – тип диска (ata,scsi и т.д., подробнее в man smartd.conf), -m – отправка сообщения с ошибками по директивам -H, -l, -f, -C, -O . Эти директивы означают различные проверки, кое-что я уже описывал выше в абзаце про smartctl (они аналогичны), кое-что вы можете прочесть в man. -m использует стандартную утилиту mail для отправки письма, таким образом можно указать в качестве получателя root@localhost, и тогда письмо будет отправлено на учетную запись администратора, его можно будет посмотреть при помощи той же утилиты mail. -a – включает вышеописанные директивы в тест. И последнее – -s – параметр, при помощи которого можно указать конкретный тест для прогона в конкретное время. В качестве значения этот параметр принимает регулярку, общая структура ее такова – T/MM/DD/d/HH , где T – тип теста (в моем случае – L – Long self-test), MM – месяц (значения от 1 до 12, если цифра у числа меньше 10, перед ней ставится 0, иначе глюки неизбежны), DD – день (1 – 31, правила те же, что и для месяца), d – день недели (1 – 7, где 1 – понедельник, 7 – воскресенье), HH – час (1 – 24, правила те же, что и для месяца). Я написал на месте месяца и дня точки – это своего рода эквивалент ‘*’ в crontab-файле. Что получилось: я поставил правило проводить тест Long self-test каждый понедельник в два часа ночи на SCSI-диске /dev/sda с отправкой сообщения на e-mail somemail@example.com в случае возникновения ошибок после проведения теста. Добавлю также, что -m позволяет отправлять сообщение на несколько адресов – их необходимо указывать через запятую. -m отправляет сообщение единожды (по умолчанию так настроено). В случае, если требуется задать правила отправки сообщений, используется параметр -M . в качестве значений принимает once, daily, diminishing, test, exec. Это, соответственно, однажды (по умолчанию), ежедневно, дополнительные сообщения (интервал в 1, 2, 4 и т. д. дня с момента обнаружения ошибки), немедленная отправка тестового сообщения на указанный ящик для проверки, указание пути к исполняемому файлу утилиты отправки почтовых сообщений (например, exec /bin/mail).

Вернусь к настройке. После конфигурирования smartd.conf открываю /etc/default/smartmontools и раскомментирую (комментарий #) строку

#start_smartd=yes

Делаю в консоли

# /etc/init.d/smartmontools start

Все, smartd запущен. Подчеркну, что все действия производятся из под root (я явно указал # перед текстом с командами для этого), чтобы не пришлось каждый раз набивать sudo перед командой, можно написать так:

$ sudo -i

Или, если у вас не установлена утилита sudo, но есть утилита su, вот так:

$ su

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

Вот и все. Удачного вам мониторинга и количества бэдов, стремящегося к нулю

Для этой процедуры мне понадобился архив с WordPress 3 и много чего от старой сборки. Во-первых, я взял облегченную версию ru_RU.mo, которую положил в /wp-content/languages. Во-вторых, конфиг wp-config.php с настройками. В-третьих, тема блога, которую я перенес на то же самое место, только уже в новой сборке – /wp-content/themes. В-четвертых, плагины. Все плагины у меня были обновлены, и я их перенес на их законное место в новый движок – /wp-content/plugins. Скомпоновав всё это дело в одну кучку, я поставил его выгружаться на сервер и пошел пить чаёк .
Изначально я предполагал, что могут возникнуть проблемы с совместимостью плагинов и готовился к тому, что что-то не будет работать после переноса. Однако, все прошло очень гладко и просто – WP подхватил настройки и базу и корректно отобразил мой блог. Когда же я обратился к админке WP, то получил вот такое сообщение:

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

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

Итак, я начну эту рубрику с моего тезки Олега Маркарьяна. Олег ведет блог “Блогоника – город блоггеров”, в котором он рассказывает о новостях в блогосфере, о SEO и многих других интересных вещах, порой не связанных с блогосферой. В общем, очень интересный и разносторонний (как и его хозяин ) ресурс – рекомендую к прочтению.

В Python для работы с ssh используется модуль paramiko. Документацию по модулю вы можете почитать тут, ну а я покажу вам пару основных моментов, от которых вы оттолкнетесь и дальше уже будете применять то, что вам необходимо.

Paramiko присутствует в стандартных репозиториях Ubuntu и Debian, и установить его можно очень даже легко:

# apt-get install python-paramiko

Теперь, когда модуль установлен, приступим к программированию)). Для работы с SSH в модуле предусмотрен класс – SSHClient. С него все и начинается:

#!/usr/bin/env python
import paramiko
ssh=paramiko.SSHClient()

Я создал объект ssh класса SSHClient, и теперь могу устанавливать соединение. Модуль позволяет авторизоваться как при помощи пары “имя пользователя – пароль”, так и при помощи ключа. Во втором случае, конечно же, нужно иметь “при себе” этот самый ключ.

Разумеется, на разных серверах SSH настроен по разному. Важно знать, что существует 3 варианта авторизации – по имени пользователя и паролю, ключом и гибридный. По умолчанию, скажем, на Debian-based дистрибутивах включен последний вариант. Осмелюсь предположить, что это наиболее популярный вариант настроек. Что он из себя представляет? Когда вы подключаетесь к серверу по SSH, он, перед запросом логина и пароля, предлагает вам принять ключ, чтобы, позже, вы, выгрузив в директорию с ключами на сервере свой ключ, могли авторизоваться именно по ключу. Что получает пользователь? Он получает удобный диалог, на утвердительный ответ которого SSH-клиент скопирует к себе ключики сервера сам. Что получает программист? Весьма неудобную ситуацию – дело в том, что по умолчанию SSHClient настроен так, чтобы не соединяться с сервером, если у клиента нет ключа. Даже если логин и пароль правильны. Это приводит к тому, что SSHClient сбрасывает соединение, и авторизоваться не получается. К счастью, на такие случаи в Paramiko предусмотрено удобное решение:

ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

Ежели вам охота вернуть все обратно, можете просто не прописывать этот метод. Явно политика по умолчанию устанавливается так:

ssh.set_missing_host_key_policy(paramiko.RejectPolicy())

Объект создан и настроен, теперь можно и подключиться:

ssh.connect("<сервер>",username="<имя пользователя>",password="<пароль>")

Необходимо указать свои сервер, имя пользователя и пароль. В качестве сервера можно указать IP-адрес или доменное имя, по которому резолвится ваш сервер.

После успешного соединения есть два варианта работы с сервером – продолжать работать по SSH и выполнять консольные команды сервера или переключиться в режим SFTP и использовать приемы SFTP для работы с файлами. Какой метод предпочтительнее – дело ваше. Посмотрим оба варианта.

Вариант номер один – SFTP. Для переключения в этот режим используем такую конструкцию:

ftp=ssh.open_sftp()

И далее работа с сервером осуществляется по SFTP. В качестве примера приведу пару команд по навигации по директориям сервера и управлению файлами:

fileList=ftp.listdir()
ftp.chdir("/var/log")
currentDir = ftp.getcwd()
ftp.get("sql.log","mysql.log")
ftp.put("sql.log","mysql.log")
ftp.unlink("mysql.log")
ftp.mkdir("test")
ftp.rmdir("test")

В первой строке я получил список файлов. Метод listdir() возвращает кортеж, с которым я могу работать как обычно.

Во второй строке я осуществил переход в директорию /var/log. Таким образом можно перемещаться по директориям на сервере.

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

Для скачивания файла использется метод get() – строка четвертая. В качестве первого параметра задается имя локального файла (куда скачивать), в качестве второго – что скачивать. Можно указывать абсолютные пути.

Для выгрузки файла на сервер используется метод put() – параметры аналогично get(). Стоит отметить, что ни get(), ни put() не принимают в качестве входных параметров маски (например, “*.php”).

Удалить файл можно при помощи метода unlink(). Параметр задается также, как и у get() и put().

Для создания директории можно использовать метод mkdir(), а для удаления – rmdir().

Вообще, если вы имели ранее дело с sftp/ftp, то, думаю, вы заметили похожесть в названиях методов и команд протоколов FTP/SFTP. Так что трудно не будет, а нюансы всегда можно найти в документации к paramiko.

Вариант номер два – работа с сервером по SSH. Работа с сервером не через SFTP, а через SSH отличается прежде всего тем, что можно выполнять консольные команды. Для выполнения команд по SSH служит метод exec_command(). Ниже пример (я продублировал соединение с сервером для наглядности):

#!/usr/bin/env python
import paramiko
ssh=paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect("<сервер>",username="<имя пользователя>",password="<пароль>")
stdin, stdout, stderr = ssh.exec_command("cat /var/log/syslog")

Данный метод примечателен тем, что при выполнении команды необходимо обрабатывать три возвращаемых канала – это содержимое стандартного ввода, стандартного вывода и стандартного вывода ошибок. Например, результат выполнения вышеописанной команды, если он будет успешен, будет содержаться в stdout. Ко всем трём возвращаемым каналам можно обратиться как к файлу и, например, считать оттуда всё, что необходимо. Для получения результата выполнения всё той же команды выше (результатом будет содержимое файла), я могу просто считать его построчно из stdout:

result = stdout.read.splitlines()

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

Усложним немного. Допустим, мне понадобилось перезагрузить сервер. Команда перезагрузки доступна только для root (/sbin/reboot). Для выполнения команд, доступных только root, от обычного пользователя, можно воспользоваться утилитой sudo. Я исхожу из того, что на сервере установлена и настроена sudo, и моя учетная запись может выполнять эту утилиту (является т.н. sudoer’ом):

stdin, stdout, stderr = ssh.exec_command("sudo reboot")
stdin.write("<пароль пользователя>\n")
stdin.flush()

Мои действия:

1. выполняю команду “sudo reboot”
2. в результате выполнения мне нужно ввести пароль пользователя (настройки по умолчанию для sudo – пароль вашего пользователя). Для этого я пишу в stdin, как в обычный файл, свой пароль вместе с переносом строки, и отправляю содержимое stdin серверу.

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

Это основные моменты работы с ssh в Python, для более подробной информации вы всегда можете обратиться к документации, ссылку на которую я дал в начале статьи. Удачи!

Я использую Firefox при разработке web-приложений по нескольким причинам:

1. это один из самых популярных браузеров;
2. наличие плагинов, которые добавляют такие функции, которых нет в других браузерах.

Итак, первый и, пожалуй, самый нужный для веб-разработчика плагин – Firebug. С его помощью можно удобно инспектировать HTML-код страницы, CSS-стили, отлаживать JavaScript. Если вы имеете дело с AJAX – для вас этот плагин просто “must-have”. Да, бесспорно, существуют аналогичные средства для разработчиков во всех современных браузерах, но они не дотягивают до функционала Firebug. Это первый плагин, который я устанавливаю после новой установки Firefox.

Следующая группа плагинов так или иначе связана с работой с HTTP-заголовками. Их просмотр может понадобится при анализе работы web-сервера.

Удобнее всего мне просматривать HTTP-заголовки при помощи плагина Live HTTP Headers. Когда плагин запущен, он, при загрузке какой либо страницы или фоновой передаче браузером данных, пишет в свое текстовое поле все переданные и полученные HTTP-заголовки. Если вы анализируете заголовки для одной страницы, лучше не производить работу в других вкладках или плагинах, работающих с сетью, иначе будет каша)).

Для редактирования HTTP-заголовков я обычно использую Tamper Data. Думаю, это наиболее удобный из целой “плеяды” подобных плагинов. Этот плагин также позволяет просматривать HTTP-заголовки и может это делать по команде.

Следующий плагин – Modify Headers – позволяет составлять HTTP-заголовки вручную. Плагин, будучи запущенным, отсылает составленные заголовки при обращении к какому-либо серверу при помощи Firefox.

И, напоследок, еще один плагин для работы с HTTP-заголовками – Poster. Плагин также позволяет составлять HTTP-заголовки и отправлять их какому-либо сайту. Особенность его заключается в том, что он не зависит от вкладок Firefox, т. е. у него есть свой интерфейс для получения результатов (простенький) и своя адресная строка, что может дать некоторую гибкость в работе. Штукенция весьма навороченная, хотя я чаще пользуюсь именно Tamper Data.

А какими плагинами/утилитами, помогающими при разработке web-приложений, пользуетесь вы?

Итак, я выбрал небольшой список социальных сервисов, вот они:

• Мой Мир mail.ru;
• Facebook;
• Delicious;
• Digg;
• FriendFeed;
• Google Buzz;
• Twitter;
• Mister-Wong;
• Reddit;
• MySpace;
• Orkut;
• Slashdot;
• Technorati;
• StumbleUpon.

Далее я нашел подходящие иконки для отображения на страницах блога. Мне очень приглянулись иконки этого товарища, за них ему спасибо. Самое скучное было дальше – поиск GET-запросов к сервисам для добавления постов. Оказывается, аналогичное проделал и Глобатор, за что ему тоже спасибо – некоторые запросы перекочевали ко мне именно из его статьи .

Итак, код:

Пара нюансов.
Во-первых, необходимо поменять пути к вашим иконкам.
Во-вторых, размер ваших иконок может быть другим, поэтому вам может понадобиться изменить параметры width=”32″ height=”32″ в теге IMG или вовсе убрать их. В последнем случае иконки будут отрисовываться со своим натуральным разрешением.
Этот код необходимо прописать в файле “index.php” и/или “single.php” вашей темы после строки:

<?php the_content(''); ?>

Первый файл отвечает за вывод информации на главную страницу (где, как правило, отображаются подряд несколько постов), а второй – за вывод отдельного поста – когда вы посещаете страницу, содержащую один пост. Например, эту . Можно сделать и покрасивее – сохранить приведенный выше html-код в отдельный файл и назвать его как-нибудь с расширением .php, например “services.php”. Далее, этот файл кладется в директорию с темой (можно и в любое другое место), и в вышеуказанных файлах после

<?php the_content(''); ?>

пишем

<?php include("path/to/services.php"); ?>

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

А вот что стало:

По-моему, неплохо . К тому же, оно теперь и грузится быстрее

Появится такое окошко:

Необходимо перейти по ссылке “задать настройки сайта блога“. Тут-то мы и найдем желаемое:

Далее я привожу настройки для WordPress. Если у вас standalone-блог, выбираете “Мой собственный или указанный мною сервер“. WordPress поддерживает постинг через MovableType API, выбираем его. Заполняем URL, логин и пароль пользователя, от которого будем писать статьи. Жмем кнопочку “Проверить”, чтобы узнать, работает выбранный API, и сохраняем настройки. Единственная проблема заключается в том, что публиковать на данный момент можно документы, созданные старым редактором Google Docs, в котором нет отображения документа, как на листе, дополнительных опций форматирования и прочих функций нового редактора. Таким образом, если вы публикуете некоторые документы (неважно куда – даже просто как html-страничку), вам перед их созданием придется переводить Google Docs в старый режим работы:

Для публикации вам необходимо отметить документ флажком и в меню “Дополнительные действия” выбрать пункт “Публикация” (все точно так же, как на первом снимке). Появится окошко, где вы можете кликнуть по кнопке “Поместить в блог” для публикации на блоге:

Вам необходимо будет перед публикацией определить стили документа, т.к. Google Docs выгружает документ со стилями, либо почистить от стилей исходный код документа (меню Изменить-> Изменить HTML). Может возникнуть также ситуация, когда пост будет опубликован без названия. Скорее всего в таком случае после публикации понадобится дополнительное изменение поста в редакторе WP. Думаю, что это косяки Google Docs, а не Movabletype API, т.к. через него мне уже доводилось писать пост с мобильника, и все было в порядке. Также отмечу то, что Google Docs не позволяет сохранять документ как черновик WP, нет возможности указать категории поста и тэги. Если у вас есть несколько документов, названных одинаково, и вы публикуете один из них, то, несмотря на выделение только одного документа, будут опубликованы все документы с этим названием

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