Posts

Showing posts from December, 2009

Утилиты chiark

Анонс от Ian Jackson : chiark-tcl 1.0.0: cdb, adns, etc. for Tcl, plus journalling cdb Что есть в ленни: aptitude show libtcl-chiark-1 chiark-utils-bin chiark-scripts chiark-rwbuffer chiark-really chiark-backup Пакет chiark-really: Описание: really - a tool for gaining privilege (simple, realistic sudo) really is a program that allows certain users to become whatever user they like on request. It is a bit like sudo in that respect. However, really is simpler than sudo, and doesn't give the system administrator any false security promises. So really is less of a general security risk to the system. Unlike sudo it does not pretend that the called account can be any more secure than the calling account. so there is never a need for a password. If you wanted to restrict which commands and functions the called user can perform, use userv, not really or sudo. Also unlike sudo, really only works if the calling user is supposed to be equivalent to root. But, really can also be us

qmail в быту

Из вики qmail : qmail — MTA (агент доставки почты), который работает под Unix. Он был написан Daniel J. Bernstein как более безопасная замена для популярного MTA Sendmail. Аннотация от автора, очень формальный конспект, который можно мельком глянуть, все равно ничего мы оттуда не узнаем: qmail Бестселлер Life with qmail Написано "казенным" языком, что-то в духе "забивания гвоздя есть продукт соударения неподвижного гвоздя с движущимся орудием типа молоток". В общем, читать толку мало, ибо писать автор просто не умеет. См. ниже перевод "Жизнь с qmail" - один из немногих случаев, когда перевод лучше оригинала, читается легко, стиль написания на уровне статьи для популярного журнала. Очень кратко, но со вкусом: Qmail On Debian Бегло рассказано об установке в дебиане, удалении конфликтующих пакетов, настройке: Qmail Vpopmail Debian Wiki Для больших любителей извращений рассказано про связку с mysql, ну да ладно, простим автору. А вот это занимательное чтиво

stunnel в мирных целях

Как в песне поется: "А мне всегда чего-то не хватает..." Вот в stunnel не хватает передачи информации о клиентском сертификате в хидерах. Наподобии вот такого: Patch info for setenv_mf . Возможно, еще имеет смысл с OpenSSL его научить работать - тогда можно делать нормальное управление сертификатами (патчи есть, но не смотрел). Сейчас что-то как-то делается как описано по ссылкам Tips for doing client cert authentication и Using Certificates with Stunnel

Updated sqlite3-rdiff

Image
The new version of sqlite3-rdiff utility can produce really small signatures. See below test on 10 Mb database. The analyze mode will help you to select optimal parameters for your databases.

Pure-tcl sockets

Тесты fileevent socket-сервера на CoreQuad хосте для двух сценариев - возвращаемый документ 10 килобайт и 0,5 килобайт. Тестовый скрипт - немного модифицированный netserver.txt , возвращающий вместо эха http-заголовок 200 OK и простенькую html-страничку. Ради интереса попробовал tclhttpd (оригинальный, 2004-го года) и его реинкарнацию wub. Первый выдает 40 TPS, а второй - 8 TPS. Комментарии, как говорится, излишни. 10k responce $ openload -l 10 localhost:9999 200 URL: http://localhost:9999/ Clients: 200 Time Limit: 10 sec. MaTps 6301.00, Tps 6301.00, Resp Time 0.020, Err 0%, Count 6301 MaTps 6324.30, Tps 6534.00, Resp Time 0.020, Err 0%, Count 12835 MaTps 6416.87, Tps 7250.00, Resp Time 0.018, Err 0%, Count 20085 MaTps 6434.88, Tps 6597.00, Resp Time 0.023, Err 0%, Count 26682 MaTps 6469.59, Tps 6782.00, Resp Time 0.019, Err 0%, Count 33464 MaTps 6501.94, Tps 6793.00, Resp Time 0.019, Err 0%, Count 40257 MaTps 6535.44, Tps 6837.00, Resp Time 0.030, Err 0%, Count 4

AOL Server API

В далекие времена, когда API AOL Server нельзя было просто взять и загрузить в обычный тиклевый интерпретатор, жил-был вот такой проект: nstcl Исходники можно посмотреть в репозитории здесь . Начиная с версии 4.x, все намного проще: $ tclsh % load /usr/lib/aolserver4/lib/libnsd.so % join [lsort [info commands ns_*]] "\n" ns_addrbyhost ns_adp_abort ns_adp_append ns_adp_argc ns_adp_argv ns_adp_bind_args ns_adp_break ns_adp_close ns_adp_compress ns_adp_ctl ns_adp_debug ns_adp_dir ns_adp_dump ns_adp_eval ns_adp_exception ns_adp_flush ns_adp_ident ns_adp_include ns_adp_mime ns_adp_mimetype ns_adp_parse ns_adp_puts ns_adp_registeradp ns_adp_registerproc ns_adp_registerscript ns_adp_registertag ns_adp_return ns_adp_safeeval ns_adp_stats ns_adp_stream ns_adp_tell ns_adp_trunc ns_after ns_atclose ns_atexit ns_atshutdown ns_atsignal ns_cache ns_cache_flush ns_cache_keys ns_cache_names ns_cache_size ns_cache_stats ns_cancel ns_chan ns_charsets ns_checkurl ns_chmod ns_cond ns_config ns_

The small signature for sqlite3-rdiff

Depends: current test version of sqlite3-rdiff The sqlite3-rdiff utility produces a signature file of size about 10% of original database size. Yes, it's better than coping an entire database but it's not good enough for production use. So I wrote a new algorithm that can build the small signatures. The algorithm calculates checksums for set of rows and so with N rows in each set the signature size will be decreased by the factor of N! Of course the delta file size will be increased but only a little for most databases. My code uses a hack select rowid/N as rowid, sum(murmurhash('$unixepoch',$cols)) from ... group by rowid This solution is not good and may be used for testing only. This code will fail with N>16. $ time ./sqlite3-rdiff signature slave.db slave.db.signature signature slave.db slave.db.signature --table-name % --rows-per-hash 1 =7 system_config =160 center =7 role =1 macroregion =988 point =7 region =1841 user =2867166 document_status =25 c

sqlite3-rdiff: master-slave replication for SQLite

Link: http://mobigroup.ru/files/sqlite-ext/sqlite3-rdiff Depends: tcl 8.5, sqlite3, murmurhash SQLite extension I'm glad to annonce the sqlite3-diff utility for SQLite replication. Are used the ROWID value as unique key of row and murmurhash for build signatures for each row. It's enough for master-slave replication. The INTEGER PRIMARY KEY is not mandatory becouse sqlite3-rdiff may store the ROWID values. The signature and delta files are valid SQLite3 databases too. They can be dumped/restored, updated and analyzed by any SQLite3 client application. Hash collisions are resolved by using unique salt for each signature. So after first sync the theoretical frequency of collision (when any record is changed but the hash is same) is about 10^-9, after second sync - 10^-18, after N syncs - 10^-N*9. The salt is unix epoch time which is saved by using "PRAGMA user_version" in signature and delta databases. Note: the master-master replication is now unsupported becouse is

The SQLite History extension

The article is not completed! The History SQLite extension may be used for table history logging. This extension has been tested with SQLite versions 3.6.x running under Linux Debian. The code is public domain. Link: http://mobigroup.ru/files/sqlite-ext/history/ Suggests: ENV extension Usage There are anly 2 functions in the extension: history(table ,column) - add history logging support for the table [table] by key column [column]. unhistory(table) - drop history logging triggers for the table [table]. The history table is saved! Only triggers will be drops. The *_history table consists all fields of the [table] table without any checks or constraints and some additional fields: CREATE TABLE [table]_history( ... _date REAL, _action TEXT, _user TEXT, _host TEXT ); The _action field has action names where 'I' - insert, 'U' - update, 'D' - delete and '' - initial import. The index for common queries to history table is built autimati

О master-master репликации

Нежданно-негаданно встретилась ссылка на следующий проект: rubyrep - репликация для PostgreSQL и MySQL. Непосредственно реализацию не смотрел, а вот дизайн системы мне понравился. А вот насчет master-master режима есть разумное сомнение - разработчики предлагают некоторые алгоритмы разрешения конфликтов, но, по сути, если архитектура реплицируемой базы позволяет возникновение конфликтов, это проблема архитектуры, а отнюдь не репликатора. Вместо того, чтобы изменять одну и ту же таблицу на разных хостах, можно создать набор схем (schema) так, что каждый хост работает со своей схемой, тогда при репликации каждый хост будет мастером для "своей" схемы и слэйвом для "чужих". В эскулайте то же самое реализуется созданием набора баз данных (притом часть идентификаторов должны иметь или сквозную нумерацию, или быть уникальными uuid).

Трэйсер запросов в tclsqlite

В новом релизе 3.6.21 появилась возможность полноценной трассировки запросов (раньше значения забинденных переменных не выводились). Тест у меня для этой функции давно написан, его и привожу. Кстати, нюанс - функция трассировки имеет возможность отменить выполнение запроса, так что аудит запросов в эскулайт легко делается встроенными средствами. Замечу, что инструкции PRAGMA не выводятся. $ ./test_trace.tcl {DROP TABLE IF EXISTS events} {CREATE TABLE events (id INTEGER PRIMARY KEY,value INTEGER)} {SAVEPOINT _tcl_transaction} {insert into events (value) values (0)} {insert into events (value) values (1)} {insert into events (value) values (2)} {insert into events (value) values (3)} {insert into events (value) values (4)} {insert into events (value) values (5)} {insert into events (value) values (6)} {insert into events (value) values (7)} {insert into events (value) values (8)} {insert into events (value) values (9)} {insert into events (value) values ('value')} COMMIT {CREATE

Системы очередей для взаимодействия приложений

Собственно, идея состоит в реализации парадигмы вопрос-ответ. Очевидны два случаяя - ответ получаем сразу или когда-нибудь потом. Как пример, синхронная система - http, асинхронная - imap. Вики излагает более подробно, см. Message queue Есть продакшен реализации и стандарты, например, Red Hat Enterprise MRG Этот монстр реализует стандарт AMQP. Замечу, что спецификация стандарта содержит почти 300 страниц. В дебиане есть эрланг-реализация этого стандарта в пакете rabbitmq-server. Разработчики проекта RabbitMQ обещают надежность 9 девяток , что означает не более 3-х секунд недоступности системы в столетие, во что ни один здравомыслящий человек не поверит. К примеру, сто лет назад компьютеров еще не было, а через сто лет и таком проекте давно забудут. Так что мы обратимся к более адекватным идеям и реализацим. Вот реализация попроще и без гарантии доставки сообщения: Gearman Иллюстрации красивые и понятные, а вот архитектура системы подкачала: вместо стандартизированного проток

MurmurHash 2.0 for SQLite

Нашел довольно удачную реализацию хэш-функции: MurmurHash 2.0 Кстати, немного теории: Hash Functions Приведенный ниже вариант функции нужен для вычисления хэша сразу всех (или некоторых) полей записи, таким образом, можно вычислить хэши всех записей для целей репликации, хранения истории изменений (версионности) и других. Также можно использовать как компактный индекс на больших таблицах, где обычный многоколоночный индекс непримением по соображениям производительности. Sqlite3 murmurhash extension

SQLite Virtual Tables

Решил провести экспедицию в пучины иинтернет в поисках идей. А искать собираюсь различные виртуальные таблицы для SQLite. Virtual Table в SQLite - это такая штука, которая обеспечивает доступ к любым внешним или внутренним данным с помощью стандартного SQL, подробнее см. по ссылке: The Virtual Table Mechanism Of SQLite Если мы заглянем в вики-страничку на офсайте http://www.sqlite.org/cvstrac/wiki?p=VirtualTables то в самом низу увидим некую приписку о существовании модуля для создания виртуальных таблиц на языке perl. Несложно найти и пример: SQLite::VirtualTable::Pivot Что ж, начало положено, идем дальше. Следующая реализация, судя по описанию, весьма функциональна, но является частью большого проекта - libferris: Libferris and SQLite--A Powerful Combination, Part 1 Libferris and SQLite--A Powerful Combination, Part 2 Libferris and SQLite--A Powerful Combination, Part 3 Обещан доступ к xml-файлам, структуре файлов и каталогов (и их свойствам), к базам PostgreSQL, и многим другим хран

Тестирование PostgreSQL 8.3 на больших таблицах: 40М записей и ограничение ОЗУ

Продолжение статьи Тестирование PostgreSQL 8.3 на больших таблицах: денормализация (40М записей) . В предыдущих заметках мы выполняли некоторые типичные выборки из таблиц с десятками миллионов записей в разных версиях PostgreSQL. Пожалуй, такие таблицы и в самом деле можно назвать большими. Но можно ли назвать нашу тестовую БД большой? Разумеется, нет. Нельзя потому, что вся наша БД умещалась не только в ОЗУ сервера, но даже и в буфере памяти PostgreSQL (shared memory). Да, объемы памяти растут, но растут и массивы информации, которые мы хотим обрабатывать, потому для работы с действительно большими БД мы должны быть готовы к тому, что Бд будет значительно больше, чем объем доступной памяти. Для того, чтобы получить удобные для сравнения результаты, мы воспользуемся той же тестовой БД, но объем памяти на запрос и для кэша уменьшим вдесятеро и теперь наша таблица вдесятеро превышает размер кэша постгреса. Для того, чтобы обнспечить работу с "горячим" кэшем (когда нужные данные

Тестирование PostgreSQL 8.3 на больших таблицах: 40М записей

Продолжение статьи Тестирование PostgreSQL 8.3 на больших таблицах: денормализация (10М записей) . Параметры сервера и PostgreSQL те же. Нормализованная таблица без справочников (40M записей) select count(*) from tmp_facts7 where a1=2 and a2=2 and a3=2 and a4=2; count ------- 391 (1 row) explain analyze select * from tmp_facts7 where a1=2 and a2=2 and a3=2 and a4=2; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on tmp_facts7 (cost=102820.61..123140.53 rows=307 width=16) (actual time=1240.778..1250.728 rows=391 loops=1) Recheck Cond: ((a4 = 2) AND (a3 = 2) AND (a2 = 2)) Filter: (a1 = 2) -> BitmapAnd (cost=102820.61..102820.61 rows=5832 width=0) (actual time=1238.241..1238.241 rows=0 loops=1) -> Bitmap Index Scan on tmp_facts7_a4_idx (cost=0.00..34273.29 ro

Тестирование PostgreSQL 8.3 на больших таблицах: 10М записей

Продолжение статьи Тестирование PostgreSQL 8.1 на больших таблицах: денормализация Как один из вариантов оптимизации скорости выборки может быть использована денормализация таблиц. Продолжим работать с тем же тестовым распределением, но теперь в таблице фактов заменим числовые ключи на строковые значения, соответствующие значениям из справочников. Для генерации тестового распределения использована приведенная ниже функция, создающая строки из символа "0", повторенного случайное число раз от нуля до заданного аргументом значения. Для вычисления времени выполнения запроса на этот раз использую команду explain analyze, хотя имхо она дает заниженное значение времени. Количество возвращаемых строк также можно увидеть в выводе названной команды, но из соображений удобства привожу и результат запроса на получение числа строк. Параметры сервера: Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz MemTotal: 8310900 kB Параметры сервера PostgreSQL: shared_buffers = 1600MB work_mem = 1