Я нажал на единственную кнопку на странице, и база быстро обновилась, 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 можно хоть сейчас, особенно если вас не останавливает его ограниченный функционал

RewriteEngine On

RewriteRule ^(.*)$ http://site.com/$1 [L,R=301]
Redirect 301 /another-site/ http://another-site.com/
Redirect 301 /another-site http://another-site.com/

При помощи данных строк мы добились редиректа на доменное имя another-site.com при обращении по URL site.com/another-site и site.com/another-site/ (это разные URL, подробнее читайте про стандарт URI), попутно отдавая в заголовке HTTP код статуса 301 – Moved permanently. Второй строкой я заодно добился того, чтобы при обращении к www.site.com пользователя перенаправляло на site.com. Далее мы избавляемся от ненужного редиректа с подключенного домена на домен третьего уровня. Для этого в директории, к которой подключен наш домен (в данном примере это another-site), в файле .htaccess пишем такое (предполагается, что ваш сайт another-site.com является алиасом к another-site-com.site.com):

RewriteEngine On

RewriteCond %{HTTP_HOST} ^another-site-com.site.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.another-site-com.site.com$

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

Следующий нюанс, с которым я столкнулся при переносе сайта – права доступа. Несмотря на то, что tar сохраняет права доступа при архивировании файлов, после распаковки я получил не те права доступа, какие ожидал. Сервер не отдавал такие вещи, как, например, картинки и css-стили из-за отсутствия прав на чтение файлов. Возможно, это связано с настройками umask файловой системы. Ну да не важно. Я просто, в консоли, находясь в директории сайта, набрал:

$ find . -type d -exec chmod 755 {} \;
$ find . -type f -exec chmod 644 {} \;

тем самым выставив права на файлы – 644, на папки – 755.
Ну а далее все как по установке WordPress – выставил 777 на wp-content/cache и wp-content/uploads.
После всего проделанного я ринулся было использовать сайт в штатном режиме, но тут же наткнулся на проблему памяти. Как известно, современные версии WordPress кушают до 32 МБ оперативной памяти (PHP). Причем эта цифра имеет место при обычном режиме работы. Во время использования админки WP “хавает” (а по другому и не выразишься) гораздо больше. Стандартно на Bluehost установлена настройка PHP max_memory=32M. Это означает, что если php-скрипт начинает сжирать память больше установленного, апач роняет выполнение скрипта, и результата работы мы не видим. Очевидно, что для нормальной работы WP необходимо увеличить максимальное количество памяти, которое может потребить скрипт. Для этого на bluehost необходимо сделать пару действий:
1. в cPanel я нашел раздел “Программное обеспечение и службы”, в котором перешел по ссылке “PHP Config”. Далее выставил настройки, как на скриншоте:

Подробнее об этих настройках можно почитать на страничках, ссылки на которые размещены там же. В разделе “Install default php.ini” я нажал кнопку “Install php.ini master file”. После этого действия типовой php.ini появился в моей домашней директории с именем php.ini.default.
2. Я его переименовал в php.ini и отредактировал строку:

max_memory=64M

64 мегабайт хватило для того, чтобы запустить админку . Кстати, количество требующейся для WP памяти будет тем больше, чем больше у вас установлено плагинов.
Ну и напоследок отмечу, что, в дополнение ко всем телодвижениям с настройкой, мне пришлось лезть в настройки WP и менять путь к директории с загрузками – он был прописан как абсолютный, от корня. Разумеется, структура директорий серверов majordomo отличается от структуры директорий серверов bluehost.
Вот, в принципе, и всё. Конечно, существуют некоторые неудобства в работе с данным хостером, но сейчас он меня более чем устраивает своими возможностями. Кстати, главная страница моего блога стала грузиться чуть быстрее – это плюс. Ну а по поводу стабильности доступа к сайту еще предстоит поговорить – блог работает на bluehost только неделю.

Шифрование через PGP/GPG в Linux работает, что называется, “из коробки”. Я уже привык пользоваться им для шифрования сообщений Jabber. Но в Windows такой полезной вещи нет. Для того, чтобы получить ее, необходимо скачать GnuPG. Также, хорошим подспорьем в управлении ключами будет что-то вроде GnuPG Shell, в виду того, что GnuPG – набор консольных команд для управления ключами. GnuPG Shell должен сильно упростить работу с ними.

После установки GnuPG необходимо внести изменения в параметры Windows. А именно, необходимо добавить в переменную PATH путь к GnuPG. Такие программы, как, например, Psi, ищут gpg в директориях, указанных в этой переменной. Для изменения PATH надо перейти в “Свойства” системы (правый клик по “Мой компьютер” -> “Свойства” или “Панель управления”->”Система”) и нажать на кнопку “Переменные среды”:

Появится окошко, в котором, в разделе “Системные переменные” находим переменную PATH и жмем на кнопку “Изменить”:

Если значение переменной PATH не оканчивается на “;”, дописываем его туда, а также дописываем путь к директории с установленным GnuPG:

Жмем на “ОК”. Далее необходимо импортировать ключ. В GnuPG Shell есть список серверов, на которые вы можете экспортировать свои ключи,  с них же вы можете их и импортировать. Также вы можете воспользоваться экспортом в файл ключа для экспорта, и импортом ключа из файла для импорта. После импорта ключа остается только задействовать его в той программе, в которой вы хотите шифровать. В моем случае меня интересовал jabber, а точнее, клиентом для него – Psi. Именно этим клиентом я пользуюсь в Windows. Для использования ключа вам необходимо в свойствах учетной записи jabber назначить ключ:

Список ваших ключей будет отображаться в окошке ниже:

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