Ежемесячные архивы: Февраль 2009

OpenSuSe 11.1: Самый глючный дистрибутив всех времен и народов

Posted on by

OpenSuSe Logo

Не так давно я обновлял систему с OpenSuSe 11.0, как обычно, запустив обновление. После него отказались работать X, mplayer не показывал фильмы в fullscreen mode и творилось много неприятного. В связи с чем было принято решение снести все нафиг и поставить OpenSuSe 11.1, ведь в прошлый раз все произошло безболезненно.

Однако, проблемы начались сразу после установки. KDE4 оказался зело глючный, по крайней мере в без напильника многое работать не стало. Например, kget отказывался скачивать поставленные в очередь файлы, akregator рушился при добавлении RSS лент в ридер.

В связи с чем я и переставил систему на SuSe 11.1 с KDE 3.5. Но на этом мои злоключения не закончились. Хроническая болезнь всех видеокарт ATI продолжается вместе с любым дистрибутивом линукса. Каждая инсталляция превращается в головную боль, поскольку система с упорством маньяка ставит глюкавый драйвер radeonhd, вместо родного ATI-шного fglrx.

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

Но это все лирика. Установка драйверов старым добрым способом, описанным для SuSe 10.3, не дала желаемый результат. Драйвер встал, но 3D ускорение работало из рук вон плохо.
Симптомы были такие:

> glxinfo | grep direct
direct rendering: Yes

glxgears показывал порядка 300 кадров в секунду (что для карты с ускорителем и для маленького окошка слишком мало).

fgl_glxgears не запускался, рушился с вот такой ошибкой:
X Error of failed request: GLXUnsupportedPrivateRequest

Лечится просто, надо в .bashrc дописать вот такую строчку:
export LD_LIBRARY_PATH=/usr/X11R6/lib:$LD_LIBRARY_PATH
и перелогиниться после этого.

Сразу заработал fgl_glxgears и Quake3, и жизнь снова стала прекрасна и замечательна… казалось бы.

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

В файле /etc/X11/xinit/xinitrc.common надо закомментировать строчки 103 и 104:

xdpyinfo | grep -q “X.Org version: 6.9.0″ || \
setxkbmap -print | xkbcomp – $DISPLAY

Это сильно облегчит жизнь при настройке клавиатуры через Sax2, официально зарегистрированный баг SuSe 11.1: https://bugzilla.novell.com/show_bug.cgi?id=432627

Ну и еще одна серьезная пакость была в этом дистрибутиве, после установки SuSe 11.1 перестал работать звук. Эти товарищи включили кривой набор пакетов ALSA, в результате чего и звук пропал. Лечится обновлением драйверов до последней версии:

zypper ar http://download.opensuse.org/repositories/multimedia:/audio/openSUSE_11.1/ multimedia

zypper install alsa alsa-utils alsa-tools alsa-firmware libasound2

zypper rr multimedia

далее в зависимости от ядра, выполняются следующие команды:

zypper ar http://download.opensuse.org/repositories/multimedia:/audio:/KMP/openSUSE_11.1/ multimedia

zypper install alsa-driver-kmp-default

zypper rr multimedia

(для ядра kernel 2.6.27.7_9.1-1.1-default i386 or x86_64 GNU/Linux (openSUSE-11.1)

или

zypper ar http://download.opensuse.org/repositories/multimedia:/audio:/KMP/openSUSE_11.1/ multimedia

zypper install alsa-driver-kmp-pae

zypper rr multimedia

(для ядра с kernel 2.6.27.7_9.1-1.1-pae i386 GNU/Linux (openSUSE-11.1)

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

И снова о прокси

Posted on by

Я уже писал о том, как превратить VDS в прокси SOCKS5, но этот способ не всегда удобен. С одной стороны, никакого софта ставить не надо; но с другой стороны, перед использованием proxy обязательно соединяться по ssh с VDS. И в случае, если у VDS есть несколько IP адресов на одной сетевой карте, то использовать сможете только один из них.

Для полноценного использования своего VDS в качестве прокси-сервера можно использовать 3proxy, который легко собирается на VDS

Если вы собираетесь использовать этот прокси с каких-то фиксированных IP адресов, мой конфиг вам в помощь:


#!/usr/local/bin/3proxy
nserver 1.2.3.4
nserver 1.2.3.5
timeouts 1 5 30 60 180 1800 15 60
daemon
log /usr/local/etc/3proxy/logs/3proxy.log D
logformat "L%d-%m-%Y %H:%M:%S %z %N.%p %E %U %C:%c %R:%r %O %I %h %T"
archiver gz /bin/gzip %F
rotate 3
chroot /usr/local/jail
setgid 65535
setuid 65535

auth iponly
flush
allow * 11.12.13.14 * *
proxy -i1.2.7.9 -e1.2.7.10 -p8089 -n -a

auth iponly
flush
allow * 11.12.13.14 * *
proxy -i1.2.7.9 -e1.2.7.9 -p8090 -n -a

В этом примере демон 3proxy будет слушать порты 8089 и 8090 на айпишнике 1.2.7.9. Использовать получившийся анонимный http прокси можно только с IP адреса 11.12.13.14. На официальном сайте есть толковый мануал на русском, с примерами. Важно только не забыть поставить запуск прокси при перезагрузке VDS, например, в rc.local прописать вот такую строчку:

nohup /usr/local/bin/3proxy /usr/local/etc/3proxy.cfg >/dev/null 2>/dev/null &


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

Опубликовано в рубриках: Linux, proxy

Прикручиваем Paypal для оплаты

Posted on by

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

Сделать кнопку «Buy now» совсем не сложно, это простейшая форма вот такого вида:













Когда пользователь произведет оплату, он будет перенаправлен на URL, указанный в параметре return. После этого Пейпал сам отправит уведомление о поступившем платеже на notify_url, только эти данные подлежат тщательной проверке, поскольку любому злоумышленнику не составит особого труда сформировать POST-запрос на notify_url. Поэтому полученные данные надо перезапросить у paypal еще раз, добавив к запросу параметр cmd со значением _notify-validate. И если paypal подтвердит совершенный платеж, транзакцию можно считать завершенной.

Для сторонних разработчиков Paypal предусмотрел специальный сервис Paypal Sandbox, который позволяет тестировать весь процесс приема платежей, с одним небольшим ограничением. В paypal sandbox не работает IPN (Instant Payment Notification), когда уведомление о платеже отправляется на notify_url. Для отладки скриптов по обработке IPN в песочнице сделали отдельный инструмент Instant Payment Notification (IPN) simulator.