21 ноября 2009 г.

Сервисы Google и Python

Наткнулся в журнале Хакер на статью про использование сервисов Гугла в Питоне. Мощная штука! :) Можно работать, например, с блоггером, почтой, таблицами, документами и т.д.

Начать нужно с Google Data Protocol - страницы протокола, который используется для работы с API гугловых сервисов. Там есть библиотечки для разных языков.

Хотя, это API какое-то странное и не очевидное... Вот простой пример, который печатает в консоль все посты дефолтного блога пользователя demalexx@gmail.com.
# -*- coding:utf-8 -*-

'''This script prints all blog posts from blogger.com'''

from gdata import service
import gdata
import atom

blogger_service = service.GDataService('demalexx@gmail.com', 'password')
blogger_service.source = ''
blogger_service.service = 'blogger'
blogger_service.account_type = 'GOOGLE'
blogger_service.server = 'www.blogger.com'
blogger_service.ProgrammaticLogin()

query = service.Query()
query.feed = '/feeds/default/blogs'
feed = blogger_service.Get(query.ToUri())

blog_id = feed.entry[0].GetSelfLink().href.split("/")[-1]

feed = blogger_service.GetFeed('/feeds/' + blog_id + '/posts/default')

print feed.title.text
for entry in feed.entry:
    print "\t" + entry.title.text.decode('utf-8')
Вывод:
D:\Projects\python\google>get_blogger_posts.py
race1
    Сервисы Google и Python
    PAP Affiliate и eAccelerator
    SSH - аутентификация ключом
...

20 ноября 2009 г.

PAP Affiliate и eAccelerator

На сайте стоит eAccelerator и потом я поставил PAP Affiliate. С самого начала этот пап работал очень медленно. Настолько медленно, что оставлял после себя процессы httpd, работающие по несколько часов и потребляющие все ресурсы процессора. Единственный выход был в перезагрузке Апача, но это спасало не надолго.

Интересна реакция саппорта. Они просили проверить настройки электропочты. Типа проблема в этом. Хотя письма как раз отправлялись. Попробовал я поменять эти настройки - в настроках PAP сделал отправку писем не функцией mail(), а используя SMTP сервер - ничего лучше не стало, конечно.

Как временная мера - установил лимит на выполнение скриптов из папки PAP в 30 секунд :)

В общем в итоге всё оказалось просто. PAP не работает с eAccelerator. Вот страница у них на сайте, где говорится что они знакомы с проблемой, и ничего не собираются с ней делать: http://support.qualityunit.com/knowledgebase/post-affiliate-pro/troubleshooting/eaccelerator-module-installed-at-server.html.

Что бы решить проблему нужно выключить eAccelerator для скриптов из папки PAP. Для этого я создал файл /var/www/vhosts/centurysupplements.com/conf/vhost.conf (конфиг Апача для виртуального хоста), и написал туда такой текст:
<Directory /var/www/vhosts/centurysupplements.com/httpdocs/affiliate>
    php_admin_value eaccelerator.enable 0
</Directory>
Т.е. выключить eAccelerator для папки /var/www/vhosts/centurysupplements.com/httpdocs/affiliate (там установлен PAP).

Теперь PAP просто летает, а eAccelerator работает для всего остального сайта.

PS. Удалил eAccelerator, заменил его APC. Он, говорят лучше, плюс от создателей PHP. И PAP с ним работает.

15 ноября 2009 г.

SSH - аутентификация ключом

Вот здесь хорошая документация, первоисточник - http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter8.html.

В SSH можно авторизоваться либо паролем, либо ключом. Авторизация ключом более секурная, но настраивается на 5 минут дольше авторизации паролем (которая просто уже есть) :) А ещё, используя авторизацию ключом, можно избавиться от ввода пароля, правда это будет уже не так секурно.

Суть в том, что генерируется пара ключей - приватный и публичный. Приватный ключ находится только у пользователя, и используется для шифрования сигнатуры (кража приватного ключа означает то же самое, что кража пароля). Расшифровать сигнатуру можно публичным ключом, который нужно поместить на сервер. При аутентицикации Putty генерирует сигнатуру, которая шифруется приватным ключом, и отправляет её серверу. Сервер, используя публичный ключ, расшифровывает сигнатуру и проверяет её. Т.е. авторизация пройдёт только в том случае, если сигнатура зашифрована приватным ключом пользователя. Это более секурно, потому что даже получив доступ к серверу, злоумышленник не узнает приватного ключа (который хранится у пользователя), в отличие от пароля (который хранится на сервере). Правда для этого очевидно нужно отключить авторизацию по паролю на сервере...

По-хорошему приватный ключ тоже следует зашифровать. Но тогда при каждм соединении по SSH нужно будет вводить пароль для рассшифровки приватного ключа. Если же приватный ключ не шифровать, и указать в Putty имя пользователя для входа - вводить пароли не нужно будет вообще. А только следить что бы приватный ключ никто не стырил :)

Для генерирования ключей нужно взять программку PuttyGen. С её помощью сгенерировать пару ключей. Публичный ключ нужно поместить в файл .ssh/authorized_keys2 в домашней папке на сервере. Каждая строка файла - отдельный публичный ключ. Приватный ключ нужно сохранить куда-то на компьютере.

В Putty во вкладке SSH->Auth нужно указать приватный ключ в поле Private key file for authentication. Что бы Putty автоматически использовала имя пользователя для входа, его нужно прописать в поле Auto-login username, во вкладке Connection->Data.

Готово. Теперь при соединении аутенификация будет происходить по ключу, не нужно вводить ни логин, ни пароль. Удобно :)

HeidiSQL через SSH

Оказывается, настроить HeidiSQL (фронтэнд к MySql) для работы с удалённой базой через SSH оказалось не просто, а очень просто :) На удивление такой вариант работает гораздо быстрее чем phpMyAdmin, и потребляет совсем немного трафика. А ещё это более производительный вариант - серверу не нужно обрабатывать множество http запросов от phpMyAdmin. В общем, теперь можно забыть phpMyAdmin как страшный сон, и очень удобно работать с локальными полноценными приложениями типа HeidiSQL и другими.

Итак, что бы это заработало, нужно настроить туннелирование в Putty и настроить соединение в HeidiSQL.

Настройка Putty

Во вкладке SSH->Tunnels нужно добавить новый туннель, где Source это локальный порт, который будет связан с портом на сервере (который слушает MySQL). Порт 3306 занят локальным MySQL, поэтому укажем порт 3307. Destination это имя хоста и порт MySQL на сервере (по-умолчанию 3306), указываем localhost:3306. Всё, теперь все запросы на локальный порт 3307 будут перенаправлены на порт 3306 на сервере.

Настройка HeidiSQL

Создаём новое соединение, указываем хост localhost, и порт 3307. Ещё нужно указать логин/пароль для доступа к базам. Готово.