Windows XP: FireFox и аппаратное ускорение

Допустим, есть компьютер под управлением Windows XP с графической системой Intel Q45/Q43 Express на борту, и есть браузер Mozilla FireFox, в котором галочка "Use hardware acceleration when available" вроде как стоит. При этом информация "about:support" показывает "GPU Accelerated Windows: 0/1 Basic". А хочется 1/1.

Помогло следующее:

1) Обновил драйверы видео до последней версии

2) В настройках браузера (about:config) поставил две опции:
gfx.direct2d.force-enabled=true
layers.acceleration.force-enabled=true

3) Перезапустил FireFox.

Источники:
Force Enable Hardware Acceleration in Firefox
Blocklisting/Blocked Graphics Drivers

Slackware: dot и graphviz

Начитался тут баша и открыл для себя язык описания графов по имени dot. Соответственно, возникло непреодолимое желание этот самый dot пощупать. Решил взгромоздить на свой Slackware некий софт graphviz v2.38, собрав его из исходников. Дальше начались чудеса.

Во-первых, заглючила команда make, вывалившись с сообщением error: 'tsrm_ls' undeclared. Решение нашлось, но, по-моему, на китайском языке. К счастью, буквы, которые надо вводить в компьютер, остались английскими, так что сориентироваться можно. В общем, надо отредактировать файл tclpkg/gv/gv_php_init.c, добавив в пару функций по строчке:

static size_t gv_string_writer (GVJ_t *job, const char *s, size_t len)
{
    TSRMLS_FETCH(); // <- добавили
    return PHPWRITE(s, len);
}
 
static size_t gv_channel_writer (GVJ_t *job, const char *s, size_t len)
{
    TSRMLS_FETCH(); // <- добавили
    return PHPWRITE(s, len);
}

На этом приключение не закончилось. Впервые на моей памяти заглючила также команда make install. На этот раз ошибка выглядела примерно так: fatal error: QtGui/qwidget.h: No such file or directory. Оказывается, требуется поправить файл /cmd/gvedit/Makefile: найти там строку примерно такого вида:

INCPATH       = -I/usr/lib64/qt/mkspecs/linux-g++ -I. -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include/QtGui -I/usr/lib64/qt/include -I../../lib/gvc -I../../lib/common -I../../lib/pathplan -I../../lib/cgraph -I../../lib/cdt -I../.. -I.

и вымарать из неё пару опций:

INCPATH       = -I/usr/lib64/qt/mkspecs/linux-g++ -I. -I/usr/lib64/qt/include -I../../lib/gvc -I../../lib/common -I../../lib/pathplan -I../../lib/cgraph -I../../lib/cdt -I../.. -I.

После этого всё, наконец, установилось.

Штука оказалась довольно прикольной. Например, можно создать вот такой текстовый файл sample.gv:

digraph myFirstGraph {
    edge [color=blue]
    a;
    b [shape=box label="Ку-ку"];
    c;
    d;
    a -> b [label="некая связь"];
    subgraph g1 {
        edge [dir=none]
        b -> c;
        b -> d;
    }
}

натравить на него команду:

dot -Tpng -osample.png sample.gv

и получить симпатичную картинку:

Ну не чудо ли!

Slackware: загадочный VirtualBox

Сегодня как-то нехорошо себя повёл VirtualBox. При попытке запустить виртуальную машину командой:

virtualbox --startvm WinXP

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

ICE default IO error handler doing an exit(), pid = 12345, errno = 32

Проверка диска при помощи fsck ничего интересного не дала.
Почему-то помогла очистка папки ~/VirtualBox VMs/WinXP/Logs

Linux: PostgreSQL 9.x и сертификаты

Захотелось тут, чтобы определенный пользователь при авторизации в СУБД был избавлен от необходимости ввода пароля. Можно было бы указать, что соединения от имени этого пользователя - доверенные, но я почему-то предпочёл другой путь: авторизацию с использованием сертификата. Наверно, в последнее время слишком часто приходилось иметь с этими штуками дело, вот и решил пойти проторенной дорожкой.

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

1) адрес или имя сервера баз данных, по которому будет стучаться клиент, например, myserver

2) имя системного пользователя, который пытается авторизоваться, например, sysUser

3) имя пользователя базы данных, под которым пытается авторизоваться системный пользователь, например, pgUser

При этом затрагиваются следующие каталоги и файлы конфигурации:

1) На стороне сервера: файлы postgresql.conf, pg_hba.conf и pg_ident.conf. Эти файлы в зависимости от сборки могут располагаться в разных местах. Например, на дебиане они обнаружились в каталоге /etc/postgresql, а на слакваре при установке из исходных кодов обосновались в рабочем каталоге /usr/local/pgsql/data

2) На стороне клиента: каталог ~/.postgresql/, в который должна быть положена пара ключ-сертификат, использующаяся для проверки подлинности пользователя.

Итак, настраиваем все эти сертификаты. Так как я - по натуре нищеброд, то сертификаты у меня будут самоподписанные, а создавать их буду бесплатной утилитой openssl.

Сначала генерируем корневой сертификат, которым будем подписывать сертификаты сервера и клиента:

# генерируем приватный ключ
openssl genrsa -out root.key 1024

# создаем самоподписанный корневой сертификат
openssl req -new -x509 -days 1826 -key root.key -out root.crt

При этом будут заданы всякие вопросы, от ответов, я так понял, мало что зависит.

Затем при помощи этого корневого сертификата создаем сертификат сервера:

# генерируем приватный ключ
openssl genrsa -out server.key 1024

# создаем запрос сертификата
# тут надо внимательно отнестись к заполнению полей:
# в поле Common Name (CN) надо указать адрес или имя сервера баз данных
# (например, myserver)
openssl req -new -utf8 -key server.key -out server.csr

# из запроса создаём сертификат сервера, подписанный корневым сертификатом
openssl x509 -req -days 730 -in server.csr -CA root.crt -CAkey root.key -out server.crt

У нас получилось три ценных файла: root.crt, server.key, server.crt. Их нужно запихнуть в рабочий каталог postgresql (тот самый что-то-там/data, в котором при установке СУБД делалась команда initdb). При этом на файл server.key налагаются суровые ограничения по безопасности: он должен иметь владельцем пользователя, под которым работает СУБД, и уровень доступа -rw-------.

Теперь сгенерируем сертификат для клиента:

# генерируем приватный ключ
openssl genrsa -out postgresql.key 1024

# создаем запрос сертификата
# тут тоже надо внимательно отнестись к заполнению полей:
# в поле Common Name (CN) следует указать имя системного пользователя,
# для которого создаётся сертификат
# (например, sysUser)
openssl req -new -utf8 -key postgresql.key -out postgresql.csr

# из запроса создаём сертификат клиента, подписанный корневым сертификатом
openssl x509 -req -days 730 -in postgresql.csr -CA root.crt -CAkey root.key -out postgresql.crt -CAcreateserial

После этой процедуры два файла, postgresql.key и postgresql.crt, закидываем клиенту в папку ~/.postgresql/ и у файла postgresql.key опять-таки выставляем правильного владельца и права -rw-------.

Стоит отметить, что содержимое получившихся сертификатов, в частности, заполнение поля CN можно всегда посмотреть командой:

openssl x509 -in postgresql.crt -text -noout -nameopt oneline,-esc_msb,utf8

Так или иначе, осталось написать правильные настройки сервера баз данных:

1) в файле postgresql.conf проверяем, что включена опция ssl = on

2) прописываем в pg_hba.conf строку:

#TYPE    DATABASE  USER    ADDRESS   METHOD
hostssl  all       pgUser  myserver  cert clientcert=1 map=myMap

Тут мы указали, что соединение должно быть защищено ssl, для авторизации следует использовать сертификат клиента и при сопоставлении системного имени и имени пользователя баз данных будет использоваться запись с меткой myMap из файла pg_ident.conf

3) в файле pg_ident.conf прописываем строку:

#MAPNAME  SYSTEM-USERNAME  PG-USERNAME
myMap     sysUser          pgUser

На самом деле, как я понял, этот файл содержит довольно простую информацию: какому системному пользователю под каким именем СУБД разрешается подключаться к серверу. То есть, если пользователю позволено подключаться под разными именами, pg_ident.conf будет выглядеть так:

#MAPNAME  SYSTEM-USERNAME  PG-USERNAME
myMap     sysUser          pgUser1
myMap     sysUser          pgUser2

4) перезапускаем сервер PostgreSQL.

Процесс авторизации по этой схеме выглядит, насколько я понял, так:

1) Устанавливается защищенное соединение при помощи сертификатов server.key + server.crt

2) От клиента сервер получает сертификат postgresql.crt, из которого выясняет системное имя пользователя. Имя пользователя базы данных, под которым хочет зайти системный пользователь, указывается явно в строке подключения.

3) По имени пользователя базы данных, имени сервера и режиму соединения (hostssl) определяется строка в файле pg_hba.conf, из которой выясняется имя метки в файле pg_ident.conf.

4) По метке в файле pg_ident.conf устанавливается, может ли данный системный пользователь авторизоваться в СУБД под данным пользователем баз данных.

Вообще говоря, требование размещения клиентских сертификатов в каталоге ~/.postgresql/ не является таким уж обязательным. Просто их там по умолчанию ищет библиотека libpq. В произвольных же скриптах можно указывать явно, какие файлы использовать в качестве пары ключ-сертификат. Вот, например, скрипт на Python-е:

import psycopg2

connString = "host=myserver"             + \
             " user=pgUser"              + \
             " dbname=postgres"          + \
             " sslcert=./postgresql.crt" + \
             " sslkey=./postgresql.key"

conn = psycopg2.connect(connString)

eToken: создать сертификат при помощи openssl

Дано:

1) USB-ключ eToken PRO (JAVA).
2) Операционная система Windows XP с установленным в ней eToken PKI Client-ом.
3) Операционная система Slackware 14.1
4) Центр сертификации Microsoft Active Directory Certificate Services со своим веб-интерфейсом.
5) Некий веб-ресурс, который умеет общаться по https с использованием сертификатов, выданных центром сертификации из п.4.

Требуется:

1) Получить сертификат в центре сертификации
2) Записать полученный сертификат на eToken
3) Подключиться к требуемому веб-ресурсу из-под Windows XP с использованием браузера Internet Explorer.

Решение:

Вообще-то, можно было бы воспользоваться веб-интерфейсом центра сертификации. Но есть маленькая проблема: этот центр с некоторых пор перестал воспринимать Windows XP.

Выглядит это так. Если попытаться при помощи IE8 сделать запрос сертификата через задачу "Advanced certificate request", центр сертификации присылает HTTP-ответ, в котором Content-length указано примеро 90кб, а реальная длина ~30кб, причем невооруженным глазом видно, что ответ оборван посередине какого-то vb-скрипта. Не знаю, с чем это связано, тем более, что если подменять User-agent браузера на другие варианты (например, при помощи чудесной утилиты UAPick), то HTTP-ответы формируются нормально.

Можно было бы при помощи подмены User-agent бы притвориться, скажем, IE9+Win7, но этот вариант не подходит: в современных системах работа с сертификатами на стороне клиента реализуется при помощи CertEnroll API, а в Windows XP для этой цели использовалось XEnroll API. Соответственно, если центр сертификации считает клиента работающим под новой ОС, он отправляет ему скрипты, которые выполняются с ошибками.

Остается один вариант: создать запрос на сертификат при помощи чего-нибудь стороннего, а потом, скажем, через FireFox его отправить в центр сертификации, благо, тот для "неподходящих" браузеров предлагает соответствующий интерфейс.

К счастью, под рукой оказался линукс с его openssl. Схема работы такова:

1. Генерируем 1024-битный ключ (eToken на ключи с большей длиной у меня почему-то ругается):

openssl genrsa -out 0000.key 1024

2. При помощи полученного ключа 0000.key делаем запрос сертификата:

openssl req -new -utf8 -config my.conf -key 0000.key -out 0000.csr

Тут обратим внимание на две опции: -utf8 позволяет заполнять поля запроса русскими буквами, а -config my.conf позволяет в файле my.conf выполнить "тонкую настройку", в частности, у меня этот файл выглядит так:

[req]
default_bits           = 1024
distinguished_name     = req_distinguished_name
req_extensions         = req_ext

[req_distinguished_name]
countryName                    = Country Name (2 letter code)
countryName_default            = RU
countryName_min                = 2
countryName_max                = 2

organizationalUnitName         = Organizational Unit Name (eg, section)

commonName                     = Common Name (eg, YOUR name)
commonName_max                 = 64

[req_ext]
extendedKeyUsage = clientAuth

3. Далее открываем получившийся файл 0000.csr в блокноте и копируем его содержимое в соответствующее поле ввода на веб-странице центра сертификации. Этот центр его переваривает и выдаёт сертификат, скажем, 0000.cer

4. Ключ 0000.key и сертификат 0000.cer сливаем в один файл 0000.p12:

openssl pkcs12 -export -out 0000.p12 -inkey 0000.key -in 0000.cer

и закидываем этот файл на eToken - там в PKI-клиенте есть команда "Импорт сертификата".

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

Литература:
http://www.websense.com/support/article/kbarticle/How-to-use-OpenSSL-and-Microsoft-Certification-Authority
https://www.openssl.org/docs/manmaster/apps/x509v3_config.html

Slackware: iptables и правила со множеством сетей

Возникла тут одна небольшая проблема. Пусть есть у нас некий линуксовый сервер, который служит шлюзом между тремя сетями, и в котором в iptables прописано много забавных маршрутов. Две сети - локальные, скажем, 10.0.0.0/8 и 192.168.0.0/16, воткнутые каждая в свою сетевую карточку, и третья - Интернет за NAT c внешним адресом X.X.X.X. И нужно какому-нибудь конкретному локальному адресу, например, 10.Y.Y.Y, дать доступ к ресурсам обеих локальных сетей и в то же время пустить в Интернет.

Было бы прекрасно, если бы можно было в параметрах iptables перечислить несколько подсетей, например, так:

iptables -A POSTROUTING -t nat -s 10.Y.Y.Y -d !10.0.0.0/8,!192.168.0.0/16 --to-source X.X.X.X

но, к сожалению, этот вариант у меня не сработал: iptables не позволил указать несколько подсетей таким образом и заругался на синтаксис.

Насколько я понял, в этом случае решением является следующее: создать отдельную цепочку правил, в которой последовательно проверить назначения пакета:

# создаем цепочку правил
iptables -N MYCHAIN -t nat
iptables -A MYCHAIN -t nat -d 10.0.0.0/8     -j RETURN
iptables -A MYCHAIN -t nat -d 192.168.0.0/16 -j RETURN
iptables -A MYCHAIN -t nat                   -j SNAT --to-source X.X.X.X

# используем цепочку правил
iptables -A POSTROUTING -t nat -s 10.Y.Y.Y -j MYCHAIN

WinXP + IE8 + Javascript

Если в браузере Internet Explorer 8 под WindowsXP не работает Javascript (от слова "вообще"), то иногда помогает команда:

regsvr32 c:\windows\system32\jscript.dll

А если не работает VBScript, то команда:

regsvr32 c:\windows\system32\vbscript.dll