Блог переехал на http://blog.levsha.org.ua

Так как мне было влом следить за wordpress-ом (даже обновлять его), а всякие спамботы срали в него неимоверно, то я решил забить на сомостоятельное содержание своего блога и переехал на blogs.

Новый блог находится по адресу http://blog.levsha.org.ua .

Так как, возможно, часть из моей писанины в этом блоге кому-то еще интересна (и может быть даже есть неверноятное: где-то еще стоят ссылки сюда), я пока не сношу старый блог и Вы можете попасть на него по ссылке http://levsha.org.ua/wordpress/

Для начала нужно найти BD_ADDR телефона и прописать соответствующие записи /etc/bluetooth/hosts и в /etc/bluetooth/hcsecd.conf (детали тут: Cвязь между iPAQ и PC с FreeBSD 6.x по Bluetooth)
Далее прописываем в /etc/ppp/ppp.conf секцию такого стиля:


hypernet:
enable force-scripts
# You might want to change these
set authname
set authkey
set phone "*99#"
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 10 \"\" AT\
OK-AT-OK ATE1Q0 OK \ AT+CGDCONT=1,\\\"IP\\\",\\\"hyper.net\\\",\\\"0.0.0.0\\\",0,0 OK \
AT+CGATT=1 OK \\dATDT\\T TIMEOUT 40 CONNECT"
set logout "ABORT BUSY ABORT ERROR TIMEOUT 30 \ \"\" +++ATH OK-ATH-OK AT+CGATT=0 OK"
set login
set timeout 0
enable dns
resolv rewrite

set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
disable mppe

В зависимости от модели телефона и типа подлючения возможно нужно под себя изменить параметр в set phone и строку инициализации начиная с AT+CGDCONT . Насколько я знаю authname и authkey у всех операторов и телефонов пуст (ввиду того, что никакого ppp на gprs на самом деле нет, но есть только на участве между компом и телефоном), но если вдруг это не так то и для них нужно прописать соответствующие значения.
Для подключения запускать от рута команду
rfcomm_pppd -a e60 -c -C dun -l hypernet
Где вместо e60 подставить имя телефона из /etc/bluetooth/hosts , а вместо hypernet своё название секции из /etc/ppp/ppp.conf . Процес соединения можно наблюдать по /var/log/ppp.log , а факт соединения просто по появления пары адресов на tun интерфейсе

Простой пример для снятия по snmp счетчиков с ipfw (snmpd демон от net-snmp):
В /usr/local/etc/snmp/snmpd.conf добавляем строчку вида
pass_persist .1.3.6.1.4.200 /usr/local/etc/snmp/getfw
Файл /usr/local/etc/snmp/getfw :

#!/usr/bin/awk -f

/PING/ {
print "PONG"
fflush
next
}
/get/ {
getline
oid = $0
split(oid, s, "\.")
rule = s[8] + 0
cmd = "ipfw show " rule
if( ( cmd | getline) > 0 ){
print oid
print "Counter64"
print $3 % 4294967296
close( cmd );
fflush
next
}
print "NONE"
close( cmd );
fflush
next
}
/getnext/ {
getline
rpint "NONE"
fflush
next
}
{print "NONE" }

Соответственно опрашивать по OID .1.3.6.1.4.200.rulenum

Во такая красота:
$ host 217.199.210.50
50.210.199.217.in-addr.arpa domain name pointer CCXVII.CXCIX.CCX.L.quickline.ru.

Valentin Davydov в ru.unix комментирует что это

Защита от дурацкого бэкрезолвинга некоторых почтовиков.

ospfd от quagga на 7.0-CURRENT оказался не рабочим: наложились два изменения: с одной стороны во FreeBSD bms переписал кусок setsockopt, касающийся multicast ( http://www.freebsd.org.ua/cgi/cvsweb.cgi/src/sys/netinet/in_mcast.c?cvsroot=freebsd , Revision 1.1 ), с другой стороны в quagga начали вместо проверки “Линукс/не линукс” начали проверять наличие структуры ip_mreqn ( http://cvs.quagga.net/cgi-bin/viewcvs.cgi/quagga/lib/sockopt.c.diff?r1=1.20&r2=1.21 ). Структура ip_mreqn в CURRENT есть, вот только во FreeBSD, в отличие от Линукса, она не предназначена для использования с IP_ADD_MEMBERSHIP/IP_DROP_MEMBERSHIP , а только для IP_MULTICAST_IF . Собственно тут есть достаточно подробное объяснение: http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074478.html .
В результате по быстрому нарисовал патч, реализующий подключение/отключение к multicast группе, с помощью новых вызовов MCAST_JOIN_GROUP/MCAST_LEAVE_GROUP : http://levsha.org.ua/sockopt.c.diff . Патч достаточно грязный: он ломает работу на Linux, поэтому в таком виде явно не годится для внесения в quagga, максимом только патчем в порты. Вот теперь в раздумиях: напрячься и сделать нормальный патч для основного дерева исходников quagga (с проверкой наличия struct group_req на этапе configure ) или забить и кинуть существующий патч pr-ом в порты фряхи?

В своё время (во времена появления стабильного релиза пятой ветки FreeBSD) я решил отказаться от использоания PicoBSD для построения новых PC роутеров (PicoBSD фактически уже не поддерживалась, да и надоело выкашивать из сборочных скриптов не нужных в современности извратов).
Первая машинка, вышедшая из под операционного стола, была сделана просто из обычной FreeBSD 5.x с рабочей станции самодельным сборочным скриптом, который просто брал из рабочей системый нужные файлы. После этого нужно было еще немного пошаманить с созданием etc в памяти и копированием туда содержимого с флешки. Всё это безобразие жило на ide флешке размером в 32M и прожило до последнего времени, пока месяц назад машинка не была демонтирована с площадки за ненадобнотью.
Позже был обнаружен сборочный скрипт по имени tinybsd, идеология которого практически полностью совпадала с моим: взять из готовой системы нужные файлы, который и использовался до последнего времени.
Чуть попозже был так же обнаружен проект nanobsd, но не оценен и отброшен: из-за идеологии “соберем отдельно мир и ядро и выбросим оттуда не нужные вещи” система получалась ну очень уж полненькой: нужно было хотя бы 128M флешку, да и то не факт что хватило бы.
Но время идет, сейчас уже найти в продаже ide flash меньше 512M практически не реально. Кроме того несколько раз попадались упоминания что в nanobsd копирование etc в память реализовано штатно, да и идея с двумя рабочими разделами (и тем самым возможностью обновления одного раздела в то время когда у нас есть еще один, гарантировано рабочий) всё больше начинала нравится. В результате nanobsd на тестовом столе.
При ближнем рассмотрении nanobsd оказалась очень даже приятной вещью. Красиво решен момент с etc (штатными возможностями /etc/rc.diskless), возможность кастомизации в любых пределах собираемой системы через конфигурационный файл, реализация установки необходимых пекеджей в собираемый имидж, штатная возможность автоматического добавления любых файлов в собираемый имидж, создание /usr/local/etc как симлинка на /etc/local (что я раньше сам делал).
Так что в ближайшее время посмотрю как она в работе.

Клиенту сделали два канала (для увеличения пропускной способности и резервирования). Нашелся мммдак ((с) День Радио), который не принял письмо с диагнастоикой что hello не совпадает с обратным резолвом. Клиент спросил что нужно прописать, я сказал что нужно прописать лечение тому админу

Пришлось на днях заняться бумагомарательством: писать в документации пунктик на тему “почему PostgreSQL”. Вот что получилось

На сьогоднішній день для абсолютної більшості задач, що потребують систему управління базами даних (СУБД, в англомовній літературі DBMS), використовуються реляційні бази даних (РСУБД, в англомовній літературі RDBMS). Для виконання операцій над базою даних практично завжди використовується мова запитів SQL.
На сьогоднішній день серед РСУБД, ліцензія яких дозволяє їх вільне використання, популярні 3 основні розробки: MySQL ( http://www.mysql.com/ ) , PostgreSQL ( http://www.postgresql.org/ ) , та Firebird ( http://www.firebirdsql.org/ ).
СУБД Firebird являє собою розвиток відкритої частини вихідного коду СУБД InterBase компанії Borland (також деякий час відомої як Inprise). Розробка цієї СУБД як окремого продукту ведеться з 2000 року. СУБД досить потужна по своїм можливостям: практично повна підтримка стандрату ANSI SQL92 та часткова підтримка стандарту ANSI SQL99. Firebird поиширюється під власною ліцензією Initial Developer’s Public License, що являє собою модифікацію ліцензії Mozilla Public License. Ліцензя вимогає у випадку внесення змін у вихідні коди забезпечити безперешкодний доступ до модифікованого коду для всіх бажаючих. Через досить малий час розвитку Firebird зараз не набув великої популярності і використовується переважно розробниками, що раніше використовували InterBase.
СУБД MySQL це власний продукт групи розробників фірми MySQL AB, розроблений по мотивам популярної свого часу бази mSQL. Під час майже всієї історії розробки MySQL основна увага зверталась на якнайбільшу продуктивність цієї СУБД, часто за рахунок зменшення функціоналу. Тільки останнім часом розробники почали прикладати значних зусиль для розширення функціоналу. Таким чином на даний момент MySQL в значній мірі підтримує стандарт ANSI SQL92 та підтримує деякі пункти стандарту ANSI SQL99. В версіях MySQL 4.x та 5.x зроблено певні зміни для більшої підтримки ANSI SQL99 (вкладені запити, збережені процедури в дуже обмеженому виконанні). Деякі функції, реалізовані в MySQL, функціонально аналогічні певним пунктам стандарту ANSI SQL99, але реалізовані у власному діалекті мови SQL. MySQL поширюється під подвійною ліцензією: поширення у вихідних кодах регулюється ліцензією GPL (що вимагає надавати вільний доступ до модифікованого вихідного коду у випадку внесення змін), поширення в бінарному вигляді як частини власного продукту регулюється власною комерційною ліцензією.
СУБД PostgreSQL веде свою історію з СУБД Postgres, що мала власну мову побудови запитів. Пізніше в Postgres було реалізовано мову SQL, Postgres перейменовано в Postgres95, а ще пізніше в PostgreSQL. PostgreSQL являє собою об’єктно-реляційну систему управління базами даних (ОРСУБД, в англійскій літературі ORDBMS) – найпотужніший і найфункціональніший на даний момент клас СУБД. Об”єкто-реляційні СУБД включають в себе такі можливості, як розширення функціоналу за допомогою нових типів, введення нових операторів, наслідування таблиць, відображення таблиць та інше. На даний момент PostgreSQL практично повністю підтримує стандарт ANSI SQL92, більшу частину ANSI SQL99 та деякі можливості з найновішого стандарту ANSI SQL2003. Розробки по підвищенню швидкодії, які були розпочаті ще з версії 7.3, на даний момент (версії 8.0 та 8.1) дали результатом те, що Postgresql не поступається а в багатьох випадках і перевищує по швидкодії інші СУБД (особливо на складних запитах). PostgreSQL поширюється під власною дуже ліберальною ліцензією, що є модифікацією BSD ліцензії. Основною вимогою ліцензії є збереження поміток про авторство на вихідних кодах. Самі ж вихідні коди і бінарні продукти можна використовувати без обмежень для будь яких, в тому числі і для комерційних, цілей.
Таким чином зі всього списку доступних для вільного використання РСУБД найбільш підходить PostgreSQL завдяки найкращій підтримці стандартів ANSI SQL, найбільшому функціоналу, достатній швидкодії та ліберальній ліцензії.

Вдруг кому будет полезен для общего развития или для использования: /tinybsd/usr/local/etc/rc.d/netgraph
Скрипт реализует создание netgraph структуры для сбора и экспорта netflow статистики и маркировку входящего траффика tos пакетами.
Сбор netflow на интерфейсе идёт в обе стороны (таким образом например на роутере сбор необходимо делать только на внешних интерфейсах). Кстати как оказалось при этом всё-равно сохраняется информация о входящем и исходящем интерфейсе. Возможно создание нескольких netflow нод, каждая из которых будет собирать информацию с разных интерфейсов (сбор несколькими нодами информации с одного интерфейса пока не реализован).
Маркировка делается нодой ng_settos, исходники которой были когда-то найдены в просторах интернета. Допустимо делать маркировку как на интерфейсах, которые будут подключены к netflow, так и на не подключенных к netflow интерфейсах.
Скрипт ложить в /usr/local/etc/rc.d/ и включать строчкой
netgraph_enable=”YES”
Другие опции:
tos_ifaces=”vlan18:8 vlan22:8 vlan26:8″ # каким tos маркировать на каком интерфейсе
netflow_names=”netflow extif” # netflow ноды с какими именами создавать . По умолчанию создаётся только нода с именем netflow
netflow_ifaces=”vlan14 vlan300 vlan5 vlan6 vlan192″ # с каких интерфейсов снимать информацию ноде netflow
extif_ifaces=”vlan18 vlan22 vlan26″ # аналогично для ноды extif
netflow_bind=”10.0.0.1:3520″ # забиндиться ksocket ноде, используемой для экспорта данных с netflow, на этот адрес и порт. Это полезно дла избежания ситуации если у роутера динамический роутинг и в зависимости от него исходящие пакеты будут иметь разный src ip
extif_bind=”10.0.0.1:8787″ # аналогично для ноды extif
netflow_connect=”10.0.0.10:3520″ # куда слать flow с ноды netflow
extif_connect=”10.0.0.20:8787″ # аналогично для ноды extif

Вот, пусть будет на сайте мой pgp ключ

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.4 (FreeBSD)

mQGiBESrwQURBACHcyJ6Gebk3eXuenqfp2FbfIZwBAXjaI7XI8SwiaSqjW4Ju/lX
UjSwHjKowtNu7a10xUgRRvJdChhAqip634jWNyjSVHtRRttZ4uBQlbHmDuqMN1nr
9ZIfQmDrofanYjsjXnJL7qjJhyVgn019XqCbS5oQnlHNUhdzd7IwKOG5xwCgudOk
3T4KnSpjkDwvtAjGfxAVS3cD/2OruLyxQjieXWJHvtyGleH1VqE5PKYPKdr/2eF5
7NtWAXvSmNqs4W1oMLElMjKBxQS2WNkrAoV/NG8VrFnw+DxawrMoeTUCNaTLCQiu
koB/F8sXEBjPD9t93WL2oHpD9QIrPMJGQJfD0n4z8cxKFCSH+35NVXrhN2nH4Say
MfQlA/9HTV7QICq+XINfZ9veHnrX+nzdkVrOiZFvWAeXjHRo3LFmCG2Ww13slkJV
O4390wsOB//6FO9cQJ6B035XEd+fZp/hGS12ehxhthoGYuSe5kzNw7qyKAubTB3k
fSMCdRRLZ+08+ri6ctzx3rLrhAiwEx34W86EyYDVG4hdMSmeBrQxTXlrb2xhIER6
aGFtIChMRUZULVVBTklDKSA8bGV2c2hhQHRlcmFiaXQubmV0LnVhPohgBBMRAgAg
BQJEq8EFAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQK/9C8YCUdlINkQCf
VrnPH3xtiCb3ocml3NYc+ZQDAIkAmwVWBp7qytzruy8eJTVZ0owW83S2tClNeWtv
bGEgRHpoYW0gKEpJRCkgPGxldnNoYUBqYWJiZXIubmV0LnVhPohgBBMRAgAgBQJE
3dcHAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQK/9C8YCUdlLvPQCgpcWZ
8hvDDJFfLddqjaIYqwhY1nkAn1Nw39Dsco5lzI1Le1KlkoGceAKHtC5NeWtvbGEg
RHpoYW0gKHBlcnNvbmFsIG1haWwpIDxpQGxldnNoYS5vcmcudWE+iGAEExECACAF
AkSszuICGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAr/0LxgJR2UqlFAJ9D
EyqR+dMxc6uTM7aYtsfOMhcN3gCfVNJ3tZriHEv7N1+00CoziO1N7Ay5Ag0ERKvB
EBAIAK2sTF2+GxXBZw0VzJOSxepGRoF9JmhWR8zaDQGfLqDjBPLfSYX6sgOF7wOu
uiPg1/m3ObT1yohEV04yQ8OOliINL4YLkS80u6bLp1EXriNxNoCr770rIQshTUHd
Kb3KWVviwgteZHwcFJ7rWRbY7I73B4keGLqBt/Fs9ltxGCa8AuQaveI/LOT+09tX
XoNApbeVXJ3zTlW2n2kO0xfHND3FZx47vCumRtxwB5qVQ50qBK43h9bx5B4Hw/4E
/ACFbClMh7j7Z7J7xwsK8wh5CDxVj5ApvF/qJ3vlByl0v0YNpEJHQBGgy1Ftj12i
qy+R8jjGy4PxRq6EgeP9qSZuWDcABAsH/2657zT/4QSPq++VfxGlGKQX0ExTXuWH
peiTK+VoyzynRYCuexNnyd4XInP6WovlIr7TdIRz6yoc9CsDmUVFvCXe+EIBvLpg
aGcJzU7HMwq1iRD74PQ3WwNI4mPJOEZDtppBvb7U+rKZj03tF1jNrznEnee6AZH/
xyHTl/9IHqS0Ye3LlFaHgJVnGoBCUZZYpp4iwvMkRod1nHqhNIHU17K/4nE0wpRp
w5bSM1Q2MtBsadKdVVAPkDokXtRYVDexmiKoUDtYVrGAcntADC4VgFD/7HUw8w8q
T6h37VFP+lRU9aek9DStpFKdMy23Qv+/0cmfZ1qNz/8+Xv0L2444XXuISQQYEQIA
CQUCRKvBEAIbDAAKCRAr/0LxgJR2UqkAAJ9/KQoWK/QYD+FbOPioLweolagYTQCe
PXjx7evt+oTeuxfvcvDSWm81N2g=
=Zo/c
-----END PGP PUBLIC KEY BLOCK-----

PGP fingerprint: 2A0B 7423 51AF B19B 74D5 31CA 2BFF 42F1 8094 7652