Лесна настройка на GPRS връзка под Linux по Bluetooth

3 comments »

Edit: Blueman версия > 1.0 не изглежда по този начин и долното описание не е актуално.

Когато пътувам, нерядко ми се налага да използвам Интернет през мобилния си телефон. Настройката на такава връзка под Linux не е кой-знае каква философия. В контекста на постоянно менящите се архитектурни слоеве, особено в последно време свързани с безжичните мрежи, човек трябва постоянно да помни в кой конфигурационен файл какво се пишеше, какво трябва да се махне след последния драйвер ъпдейт и т.н. Особено неприятни започват да стават нещата, когато трябва да помогнеш на приятел отдалече – започва се едно мазане в конзолите, рестартиране на демони и прочие ексорсизми.

Скромното ми мнение е, че в Linux света нещата трябва да стават все по-лесно. По темата, за която пиша мрежата е пълна с HOWTOs и step-by-screen обяснения, които обаче можа да объркат начинаещите. Затова направо към проблема:

Стъпка 0: С какво разполагаме
Dell XPS 1330
Nokia E65
Ubuntu Intrepid Ibex 8.10, 64bit edition
Връзката между компютъра и телефона ще става по Bluetooth.
Нещата ще работят по подобен начин и с друг хардуер/ОС, просто инсталирайте пакетите и ги конфигурирайте по същата схема.

Стъпка 1: Инсталиране на допълнителни пакети и хранилища
Приемаме, че използвате Gnome среда. NetworkManager е аплет, чрез който управлявате мрежовите връзки. Версията му трябва да е поне 0.7 и ако използвате прясно Ubuntu или Fedora вече я имате. NetworkManager от тази си версия поддържа Mobile broadband, но за да се активира първо трябва да се конфигурира връзката между телефона и компютъра и то по такъв начин, че NM да я разпознава и използва.
За тази цел ще се наложи да инсталираме допълнително приложение, а именно BlueMan [http://blueman-project.org/] С негова помощ могат да се правят и други полезни неща, но нека се фокусираме над главното.
За Ubuntu можете да го инсталирате от PPA страницата на проекта:
https://edge.launchpad.net/~blueman/+archive/ppa
За Intrepid това става като изберете:
System -> Administration->Software sources-> таб Third-Party software -> Add…
И там добавите реда:
deb http://ppa.launchpad.net/blueman/ppa/ubuntu intrepid main
Добре е да добавите и публичния ключ на хранилището, за да може да се проверяват цифровите подписи на пакетите. Как става това вижте на PPA страницата.
Когато го добавите, презаредете хранилищата и използвайте любимия си пакетен инсталатор, за да инсталирате blueman. Към него ще ви предложи да се обновят няколко системни библиотеки, свързани с Bluetooth поддръжката – потвърдете ги.
На терминала това става така:
sudo apt-get update; sudo apt-get install blueman;

Стъпка 2: Конфигуриране
Ако всичко е минало успешно в Applications->Accessories трябва да се е появил Blueman Bluetooth Manager. Когато го стартирате ще видите Bluetooth устройствата, които сте свързвали към компютъра си. Ако все още не сте го направили с телефона си, включете Bluetooth услугата му, погледнете дали е visible, за да може да бъде открит и цъкнете на Inquiry. Следвайте въпросите и свържете двете устройства.
Когато приключите, изберете Edit -> Services. Тук ще видите активните и неактивните услуги, които ще използвате с през Bluetooth връзката ви. В колонката статус цъкнете срещу Serial, а ако искате да не се връщате постоянно на тази стъпка отбележете и Autostart. Продължете като цъкнете бутона Configure (най-в дясно). Тук разширете Add new serial port, в Host изберете вашия телефон, в Service – Dial-Up Networking. Цъкнете на Add Port и отбележете чекбокса „This is a GSM/GPRS/EDGE/3G dialup connection”. Потвърдете всичко.
Последно остана да конфигурирате и NetworkManager. Цъкнете върху него с десен бутон и изберете „Edit Connections…”, след това „Mobile Broadband” и „Add..”. Там изберете вашия мобилен доставчик и настройките за него автоматично ще се заредят.

Стъпка 3: Свързване
Връзката от тук нататък става като цъкнете на NetworkManager. В списъка трябва да се е появил нов раздел – Mobile broadband. Там трябва да е и новосъздадената ви връзка. Избирате я след няколко секунди сте в Интернет през мобилният си телефон.

CC инвазия

No comments »

Сутринта попаднах на Вени Марковски по “БиТиВи-ту нъ културътъ”. За друга тема беше отишъл, но не пропусна да спомене за публикуването сайтовете на Президента и прокуратурата под Creative Commons. Това събитие, разбира се, беше подобаващо отразено в блог пространството.

Случайно бях на компютъра и реших да разгледам. Направи ми впечатление, че избраните варианти (уклони?) на двете страници е различен: за президента е “Признание-Без производни произведения 2.5 България“, а прокуратурата “Признание 2.5 България“. Доколкото последния е по-малко рестриктивен, без да съм специалист по темата, считам, че е некоректен, тъй като дава възможност за разпрстранение на модифицирано съдържание от страницата с цитиране на источника.

Дори и нещата да не са така, отново прозира познатата схема в България: някой предлага нещо, евентуално след години някой се сеща за предложението и го прави формално, без да се задълбочава в значението на действието, с тайната надежда да спечели евтин PR. За реализацията на подобна идея трябва да има насочено разбиране към проблема и съответните формални санкции – ПМС-та, заповеди и т.н. Докато този тип неща се решават, като на маса се разберат едни хора и после единия издудне на системния администратор по телефона “…абе Пенчо, вземи тури едно […] отдолу на сайта…”, няма да видим светлинка в тунела :(

Wine&HMM4

1 comment »

Edit: регресията е отстранена в актуалните весии на wine

От време на време пускам някоя стара игра за разтоварване. Почти винаги на лаптопа ми има Heroes of Might and Magic IV. На български. Противно на разбиранията на старите геймъри и здравата логика :)

Та ситуацията е следната: dual boot visa 64 + ubuntu; под vista играта гърми със син екран (хех, следващото нещо, което ще trace-на ще е това, хубав DoS, не иска административни права. С потенциал за code execution ;).

С Wine играта си вървеше до версия 1.1.3, след което взе да гърми още в началото, при стартиране. Чинно отбелязах проблема в WineAppDB и закачих вече пуснатия бъг.

След ослушване и следвайки правилото “The fastest way to close your bug is to submit a patch” се порових из кода на wine. Порових с Пламен и стрелях в тъмното. Резултата може да се прочете в бъг тракера на wine, а компилиран за Ubuntu пакет може(х)те да дръпнете тук.

Да се отбележи, че *не* поощрявам свалянето и инсталирането на пакети от ляво и дясно, така, че пускайте на своя глава. Коментари и регресии – в бъга и тук.

Слушаме

No comments »

Тече кампаниятежка и с неясен край…

Моята гледна точка към ситуацията е проста – *всички* слушат. Това не е параноя, а реална ситуация.

За “ИТ” хората това са дадености – некриптирана парола не пращаш; към сайт, за който не знаеш как пази информацията за теб (демек, не е под твой контрол;) не пишеш истински данни и т.н. Дали те снифи (разбирай, подслушва) ДАНС, системния администратор, ъплинк доставчика, съседа (кракнал безжичната ти мрежа в къщи и ARP отровил XP-то ти) или просто някой те е гледал в ръцете и след това ти чете пощата – това е без значение.

Твоите съкровени тайни са вече извън твоя контрол.

Когато си в началото на жизнения път, нямаш толкова много тайни. Дори, повечето ти деяния могат да минат за “здрави/жестоки/изродски/яки (или както сега там_му_се_казва)”. Тогава желанието просто да се чуе за теб надделява.

Когато започнеш да осъзнаваш действията си във времето, рано или късно разбираш, че си грешил. Ако не си – или обществото е в застой, или самия ти си Иисус (не, Не си – пиша го за пълнота!)

Сигурен съм, че няма да обучим всички потребители. Те ще продължават да цъкат на ефтините часовници, рецептите за събуждане на “змея” и акциите на далавера.

Всеки, който не осъзнава необхдимостта да има възможност да сподели нещо наистина тайно, трябва индиректно да публикува.

Да има огромни екрани показващи всичко за всеки – освен това, за което *нарочно* е отказано като лично и неприкосновено.

За да се случи горното трябва и добра основа – истински закон, гарантиращ правата на мислещите създания.

Някои хора питат: какви са тези радетели за отворено общество, които искат да се затворят и да пазят тайни?

Накрая, това е бъдещето на всяка тайна – да излезе на яве. А тогава?

Oraclish

No comments »

select to_date(‘01.01.2008’, ‘DD.MM.YYYY’) + to_number(‘FF’, ‘XX’)
from dual
===
trunc(sysdate)

===

Another beer, please!

Без реклами 2

No comments »

Днес намерих малко свободно време и реализирах идеята на Явор – добавих възможност за изпращане на ваши адреси за българския лист [http://stanev.org/abp/] на AdblockPlus. За да прескоча СПАМ-а съм използвал чудесната reCaptcha, а има и елементарни проверки за повторение. Добавянето няма да става автоматично, а след преглед от моя страна.

Сигурно вече ви е направил впечатление аскетичния дизайн на страничката – ако някой иска да я направи по приятна за окото – да заповяда :)

Безплатен MSOffice от държавата

11 comments »

Ето ви една добра новина: вече можете да свалите MS Office съвсем безплатно от държавен сървър. Чудото се случва на страничката на Фонд “Условия на труд” към Министерството на труда и социалната политика. Попадайки там, първото, което трябва да направите е да се отърсите от натрапчивото чувство, че дизайнера е хрупал халюциногенки, които от своя страна са извратили представата му за цветове/разположение/използваемост и т.н. черни магии.

Ако вече не сте се отказали, продължете смело напред – погледнете сивата лента под картинката, разполагаща България на явно заслуженото място на дъното на Атлантика. Това всъщност е меню и трябва с мишката да посочите “Проекти и програми”. Тогава друго меню ще се свлече и от там избирате “Готови продукти”. Това, което търсите е третата връзка, Risk.rar (145MB). Това творение на програмисткият гений е Access приложение и за по-лесно в инсталационния пакет са добавили и MSOffice 97 Professional.

И така, граби народе! Докато има! Безнаказано! Дори и Linux потребителите (да ви е честит и новия 2.6.26 kernel) могат да се впуснат в приключението, с чаша вино в ръка ;)

Благодаря на Voland, който ми обърна внимание към далаверата.

Edit: е, то се е видяло: иранците ще ни оправят.

Onion routing и закона

5 comments »

The Onion Router (TOR) е свободна имплементация на технология, целяща да създаде инфраструктура за гарантиране на (псевдо)анонимност в мрежата. Това става като всеки участник в TOR става отделно звено, а връзката се насочва през произволни участници в мрежата. Комуникацията между TOR звената е криптирана, но при последното звено, така наречения exit node, се налага да се използва първоначалния протокол, за да се изгради връзката с търсения сървър. Ако не използвате криптиране от край-до-край, като примерно качите връзката на SSL обслужващия ви exit node може да прихване и подслуша комуникацията.
Всъщност, горното е отдавна известно и е подчертано още на първата страница на проекта. Комбиниране с възможността да се инжектира съдържание в обратния отговор (примерно web bug, който да ни се „обади”, когато пристигне при оригиналния клиент), нещата вече губят всякаква възможност за гарантиране на анонимност. Въпреки това, много хора не го разбират или просто не им пука толкова.
В средата на миналата година, шведски консултант по ИТ сигурност направи точно горното – инсталира на няколко машини TOR сървъри, пусна sniffer и зачака. След като само за няколко седмици успя да „налови” паролите за пощите на маса посолства, вдигна тежка олелия и го обявиха за хакер номер едно. После и го арестуваха.
За мен горния случай единствено показва колко малко се разбират проблемите на ИТ сигурността в горните организации. Ако правилно си спомням, много малко държави въобще използваха Интернет за преносен канал с мисиите зад граница (хм, няма да конкретизирам…). Та дори и нашата малка България се впусна в изграждането на сателитни мрежи – помните скандала със Соломон Паси преди време…
Както и да е. Преди 2-3 години аз също в името на опита и любопитството проверих какво се пренася. Тогава не излезе нищо неочаквано – пощи, порно страници, форуми.
Реших сега да опитам отново – наистина ли трафика е станал толкова „сериозен”? Инсталацията на опитната установката отне около 10 минути, след което отидох, разбира се, на бира.
Когато се завърнах, прегледах логовете. Само един бърз поглед показа, че играта с времето само е загрубяла – беше пълно с адреси към гнусна детска порнография.
Тук идват и резонните въпроси:
• Какво ще кажат нашите приятели от ГДБОП, ако от ISP-то ми слушат трафика? Тук историята се доближава до тази с торентите – както там не си изясниха технологията, така и тук вероятно ще имат заблуждения.
• Всъщност, прави ли ме инсталирането и конфигурирането на TOR сървър „Доставчик на далекосъобщителна услуга”? Не мисля, че закона може да се прочете така, но на практика аз в случая имам клиенти, за които си нямам и понятие кои са, но които обслужвам. Да не говорим, че и логовете, които евентуално ще пазя са абсолютно безсмислени.
• Защо, след като в ситуацията в момента е такава, МВР не пусне няколко TOR сървъра и не спре *източниците* на незаконното съдържание? Без значение дали са на територията на България или навън, варианти има. Не мисля, че кампании от типа „Натопи другарчето, ако го усетиш да прави нещо нередно” ще помогнат повече.
Проблемът такъв, какъвто генерализирано го виждам е, че за кой ли път законите (и то не само в България) изостават твърде много от процесите в истинския свят.
TOR и подобните системи не са заплаха. Има десетки и много по-големи бот-мрежи, създадени, за да обслужват единствено и само престъпни цели, от компютрите на нищо неподозиращи Windows потребители. От там се сипе SPAM, инициират се DDoS атаки, bruteforce-ват се услуги и какво ли още не.
Все си мисля, че трябва да направим нещо по въпроса. А вие?

Яхтаджии

No comments »

Моят приятел и колега Косьо, заедно с още трима капитани-разбойници поеха едно скромно начинание, за което искам да пиша накратко тук.
Първо се метнаха на самолет до Чикаго. Там са си харесали една спортна яхта, която към момента е изтеглена на сух док. На място ще натоварят лодката на камион и ще я откарат до океана – на има-няма 800 км. Там се пуска на вода и на платна, ще се приберат в България.
Интересното тук е, че това ще е най-младият екипаж, прекосил Атлантика с яхта. Отделно, Косьо пък ще е най-младия българин, свършил тази работа :)
През цялото време екипажът ще разполага със сателитен телефон, през който ще блогват какво им се случва по пътя и ще изпращат снимки. Очаква се и първото (доколкото ми е известно) използване на услуга от така нареченото електронно правителство от насред океана, но за това когато му дойде времето ;)
Ако ти е интересно, можеш да следиш събитията на живо на блога на проекта http://chicagoandback.org

HPN-SSH patch за Ubuntu 8.04 Hardy Heron HOWTO

5 comments »

В днешно време прехвърлянето на огромни обеми данни на далечни разстояния става все по-често занимание на системните администратори (Забележка: пряката ми работа не е свързана със системно администриране, възможно е някои изводи да са ми изкривени). Освен физическите ограничения на преносния канал, трябва да се вземе предвид и протокола за предаване на данни, както и особеностите на неговата имплементация.
Работейки на място, където боравим изключително с чувствителна информация ми се наложи да харесам решение, което да предоставя високо ниво на сигурност при комуникацията, както и производителност близка до оптималната за преносната среда.

Варианти тук, разбира се, не липсват. Аз исках да заложа на изпитани решения, които най-добре вече да са на въоръжение и които няма да усложнят допълнително плетеницата от връзки, технологии и външни компоненти, в която и без това сме затънали.

След известно разглеждане се спрях на SSHFS – отдалечена файлова система, използваща SCP за преносен протокол. Sshd имам на всяка машина, а се оказа, че и под Windows има shell extension-и, които директно mount-ват отдалечения ресурс.

Който е прехвърлял големи обеми данни със SCP е забелязал силното намаляване на производителността спрямо ширината на канала, както и лекото „насичане“ в комуникацията.

Мислейки си за 300-те GB компресиран бекъп на една от базите, която е с навика да расте с по 10 GB на ден, се зарових в търсене на проблема.

Такъв недостатък не би останал незабелязан и съответно вече имаше решение – High Performance Networking patch за OpenSSH.

Причините за деградиралата производителност са следните:

  • Статичен размер на I/O буфера в имплементацията на протокола.
    До версия 4.6p1 въпросният буфер е бил едва 64 KB, което е крайно недостатъчно и предизвиква ненужно фрагментиране на данните.. Всеки фрагмент от своя страна се криптира отделно и води до допълнителен overhead.
    В последната версия на OpenSSH 4.7p1 буфера е увеличен на 2 MB. Това дава добро увеличение на производителността, но все още има какво да се желае.
  • Имплементациите на използваните алгоритми за криптиране не са multithread.
    Това директно оказва влияние върху оптималното използване на процесорите. В днешно време сървърите разполагат с повече от един процесор, да не говорим за дву- и четири ядрените хардуерни решения.
  • Когато използваме собствени (или dedicated) канали, които може би имат и криптиране на по-долен слой или пък не пренасяме чувствителни данни, можем да използваме eNULL алгоритъм за криптиране, или иначе казано – без такова.

По решението на горните проблеми работи екип на Pittsburgh Supercomputing Center, който е реализирал patch за OpenSSH. По редица причини този patch все още не е станал част от официалната дистрибуция и се налага прилагането му на ръка.

Работейки с Ubuntu, реших първо да намеря прекомпилирани deb пакети, с които да експериментирам. За продукционна машина това не е добра идея, тъй като заедно с HPN patch-а може да ви нахулят и хубав излъскан троянски кон – но вие това си го знаете :)

След като не открих прекомпилиран пакет се заех да свърша работата сам. Както се досещате, гредата дойде от там, че както всяка уважаваща себе си дистрибуция, разработчиците на Debian/Ubuntu имаха свои собствени patch-ове, които решават един или друг проблем за интегрирането на OpenSSH. Прилагането на patch-a гръмна на 6 места, като две от тях бяха вече наложени от допълнителните patch-ове, а за останалите трябваше лека намеса на ръка. Няма да се впускам в подробности, защото те са конкретни за текущото състояние на двете кодови дървета и са тривиални за решение.

Ето накратко стъпките:

  1. Ако не сме прекомпилирали пакети до момента е добре да си дръпнем необходимите ни tool-ове:
    alex@dawn:~/openssh$ sudo apt-get install build-essential devscripts fakeroot
  2. Изтегляме необходимите ни dev пакети спрямо информацията за връзките в openssh:
    alex@dawn:~/openssh$ sudo apt-get build-dep openssh
  3. Изтегляме source пакета на openssh (в случая е openssh_4.7p1-5ubuntu1):
    alex@dawn:~/openssh$ apt-get source openssh
  4. Изтегляме двата HPN patch-а (в случая версия 13v1), включващи динамичното оразмеряване на I/O буфера, eNONE алгоритъма и multithreading имплементацията за брокера за криптиране:
    alex@dawn:~/openssh$ wget http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-dynwindow_noneswitch.diff.gz
    alex@dawn:~/openssh$ wget http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-CTR-threading.diff
  5. Влизаме в директорията със source кода и прилагаме двата patch-а:
    alex@dawn:~/openssh$ cd openssh-4.7p1
    alex@dawn:~/openssh$ zcat ../openssh4.7-dynwindow_noneswitch.diff.gz | patch
    alex@dawn:~/openssh$ cat ../openssh4.7-CTR-threading.diff | patch
    Първия би трябвало да изгърми тук-таме, втория трябва да се приложи безпроблемно. Тук трябва да се разходим из кода, като в генерираните .rej файлове има информация за това какво не е успяло да се приложи. Редактираме .h и .c файловете на ръка.
  6. Обновяваме changelog-а, където е важно да инкрементираме версията на пакета, за да не го намажем при по-късен upgrade:
    alex@dawn:~/openssh$ dch -i
  7. Компилираме source-а и изготвяме пакетите:
    alex@dawn:~/openssh$ dpkg-buildpackage -rfakeroot
    Ако всичко е минало добре, би трябвало да имате няколко .deb и .udeb пакета, тъй като в Debian OpenSSH е разделен на модули. Инсталирате първо клиента, след това сървъра така:
    alex@dawn:~/openssh$ sudo dpkg -i openssh-client_4.7p1-5ubuntu1alex-hpn13v1_i386.deb
    alex@dawn:~/openssh$ sudo dpkg -i openssh-server_4.7p1-5ubuntu1alex-hpn13v1_i386.deb
    Разбира се, имената на пакетите могат да варират според това какво сте написали на стъпка 6.

След рестартиране на sshd можете да направите малко експерименти. За да използвате patch-а не е необходимо и клиента на отсрещната машина да е да patch-нат – достатъчно е само сървъра да е подобрен.

При моите експерименти в 100 MBit локална мрежа установих два пъти повишаване на производителността. През Интернет(колкото и относително да е това, bgpeering) около 20%.

На финала, ако горните стъпки са ти се сторили сложни и времеемки, можете да използвате моите пакети:

openssh-server_47p1-5ubuntu1alex-hpn13v1_i386.deb (md5:774856d4167be8770203f7c1c8e9af80)

openssh-client_47p1-5ubuntu1alex-hpn13v1_i386.deb (md5:0e5499487010c1e18ca7832318aa87a1)

Отново не препоръчвам инсталирането им в продукционна среда – ако го направите сигурно много ми вярвате :)

Ще се радвам да споделите вашите наблюдения върху производителността с HPN-SSH patch-а.

Bonus info:

Прегледах и двете платени Windows имплементации за mount на sshfs като локално устройство:

  • SftpDrive – просто приложение, което прави точно това, което очакваме. Няма настройки за SSH протокола (алгоритми за криптиране, SCP и т.н.)
  • WebDrive – може да mount-ва Amazon S3, WebDav по SSL, SFTP/SCP, като поддържа подробната настройка на комуникационните параметри. За съжаление поне последната версия, която тествах бе доста бъглива. Има и допълнителен cache, който когато е включен се грижи за background трансфер на данните. Малко по-скъп е от горното приложение.
  • Мернах и решение с отворен код на SourceForge, което обаче беше докарано до под кривата круша и е дефакто неизползваемо.

Накратко, ако ви трябва прозрачна интеграция на sshfs под Windows, препоръчвам SftpDrive (да си помислят за комисионна в моя полза;)

Без реклами

3 comments »

След като около половин година използвах активно NoScript, най-после ми омръзна от постоянно изскачащите предупредителни съобщения и нефункциониращите страници, прекаляващи с употребата на JavaScript.

Всъщност това, което исках е добро филтриране на така досадните реклами. След кратко оглеждане се спрях на най-използваното разширение за това – AdBlock Plus.

Както се оказа, никой не си е поиграл за да състави общ списък за българските сайтове. В резултат, тук-там правилата от общия списък (EasyList) пропускат банери и шаренията успява да пробие.

За да запълня нишата, реших да съставя допълнителен списък, съдържащ сигнатури за българските страници. За да го попълня избрах случайна top100 българска класация за най-посещаваните сайтове и набързо филтрирах каквото шаваше.

Страницата на списъка е тук. Можете да го инсталирате от тук, а това е самия лист.

eGovernment & OpenSource

No comments »

Да пусна и моите 2 ст. по темата.

Преди ~5 години (началото на 2003 г.) бях делегат на годишната конференция на EEMA. Като сериозна и независима организация (основана през 1987), те създават работни групи по различни наболели проблеми. Тогава течеше усилен дебат по въпроса на отворения код и неговото използване в публичния сектор. Аз участвах в групата за eGovernment, където трябваше да изготвим позицията на организацията по темата.

По-долу може да се прочете материала, който им изпратих тогава (преведен на български, оригинала е на английски):

Някои бележки относно приложението на отворения код в публичния сектор

Въвличането на все повече хора в разработката на софтуер с отворен код води до появата на много нови мнения за това как даден продукт трябва да се развива, какви да са неговите възможности и пр. Особено важно е да се синтезира най-доброто, за да се постигне успех. За външния наблюдател тези процеси изглеждат анархистични и разнопосочни, което е определено странно и едновременно стряскащо за служителя от държавния сектор, търсещ оптималното решение. Всъщност, протичащите процеси са просто още един изглед на Демокрацията и това, което се случва е съвсем нормално за обществото, в което живеем. Такава среда е особено продуктивна и дружелюбна към всички нови технологии и налагащи се стандарти, като помага за тяхната интеграция и развитие по един изчистен и свободен начин – така, както обществото се отнася към въпроса за прозрачност и адекватност на държавните решения.

Една от основните задачи на Електронното правителство е да интегрира съществуващите системи в една обща информационна инфраструктура, използвайки технологи като Web Services, PKI и т.н. Една такава отворена инфраструктура ще помогне на малките играчи на софтуерния пазар да се включат в изграждането на нови и нови услуги по най-добрия начин и в мащаби, които могат да управляват. В същото време, в момента някои от най-големите компании се опитват да наложат затворени решения, само защото това е единствения начин да запазят пазарните си ниши и дивиденти.

Въпреки всичко, изглежда ветровете се променят. Университетите подготвят все повече млади специалисти, приемащи каузата на отворения код присърце, работейки по стотици свободни проекти. Те осъзнават, че това е най-ефективния начин да вникнат в дълбочината на базовите технологии. А това е от особено значение за разбирането на това как работят информационните системи около нас. Много от тези проекти с отворен код растат и намират своето комерсиално приложение.

Разполагащи с необходимия капацитет, много IT компании започват да инвестират в решения с отворен код. Основната причина за това е преработката на отворените решения по такъв начин, че те максимално да отговорят на възникналите специфични нужди – техни или на клиентите им. За много от тези компании успешните резултатите са налице, което значи, че това е един от правилните пътища за развитие. Някои от тях дори променят основно своя бизнес-модел, опитвайки се да максимизират успехите от работата с отворен код.

Предлаганите решения в eGovernment областта няма да бъдат изключение от общата тенденция. Свободата на избор на доставчици, технологии и разработки са основните фактори за внедряването на отворени решения в държавата.

The end.

Може би не е необходимо да пояснявам, че в тази леко закостеняла организация, доминирана и управлявана от големите корпорации, моите романтични брътвежи не намериха място в крайния доклад. Впоследствие, въпросния документ, изпратен надлежно в централата на ЕС в Брюксел, послужи за основа на стратегията за развитие на IT в Съюза.

Избори HOWTO

6 comments »

Измина повече от месец от местните избори. Въпреки това, все още в над 200 места продължават препирните кой, как и защо е станал общински съветник/кмет. Резонно е да се хвърлят и обвинения в най-странни и невинни посоки – просто за замътване на обстановката, защото, както знаем – в мътни води не знаеш какво ще хванеш.

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

Всичко започва сутринта в изборния ден. Събират се секционните избирателни комисии (СИК), разполагат бюлетините, отварят изборните секции и започват да чакат. Хората идват, гласуват и пускат пликовете с маркираните бюлетини.

Когато приключи гласуването, членовете на СИК се затварят, измъкват бюлетините от пликовете и ги разделят на купчинки по партии/кандидати. След това броят. Бройката на СИК членовете варира, обикновено от 9 до 13, винаги нечетна. Те се предлагат от различни политически партии, за да няма договаряне. Когато се скарат за бройките, сдобрят се, пак се скарат и накрая здравият разум победи (разберат/наговорят се), изготвят СИК протокола.

СИК протокола има две части – основна и разпределение. В основната се записват числа от типа – колко бюлетини получихме, колко хора дописахме в списъка, колко празни пликове намерихме и т.н. Разпределението се състои от бройката на гласовете по партии/кандидати. Когато го попълнят се подписват и го мъкнат в Общинската избирателна комисия (ОИК).

ОИК има за всяка община – 264 на брой в момента. Тук започва и компютърната обработка. Протокола от СИК-а се носи на оператор на компютър, който го набира под наблюдението на членове от общинската и секционната комисия. Те го гледат в ръцете и мрънкат, когато сбърка.  Отделно софтуера реализира и всички законови контроли – дали написаната бройка на действителните гласове отговаря на сумата на гласовете по партии/кандидати, броя на подписите дали съвпада и т.н. Накрая оператора разпечатва разписка, съдържаща числата от СИК протокола. Разписката се сравнява още веднъж визуално от членовете на ОИК и СИК, след което всички се подписват.

Подписаната разписка се носи на специално нарочен отговорник, който проверява налични ли са всички подписи и я потвърждава.

По време на въвеждането в ОИК, на регулярни интервали се изпращат потвърдените до момента СИК протоколи в Централната избирателна комисия (ЦИК). Това се прави за публикуване на данните в Интернет, както и за нуждите на оперативните справки. Всички данни се изпращат подписани с цифров сертификат за електронен подпис, без да се криптират. Това гарантира невъзможността за промяна/подмяна, както и прозрачността – който иска – да sniff-и.

Когато въвеждането в ОИК приключи се сумират резултатите, изпълняват се стъпките на математическия метод за изчисляване на пропорционалните резултати (сега Хеър-Ниймайър, преди – Д’Ондт) и се попълва ОИК протокол. Тогава става ясно кой е кмета, кои ще бъдат общински съветници и т.н.

След приключването на въвеждането, трима от членовете на ОИК се вдигат и мъкнат в ЦИК в София СИК протоколите, копие на локалната база данни (подписана с електронен подпис) и още някои допълнителни решения, записки и т.н.

В ЦИК се извършва повторно въвеждане (превъвеждане) на СИК протоколите. Специално се следи второто въвеждане да не става от едни и същи хора. Най-малкото, първоначално въвеждането става в съответната община, а след това в София. Физически достъпа до работните станции и сървърите в ЦИК се осигурява от Националната служба за охрана (НСО), които допускат единствено хора по списък, след предварителна проверка за чисто криминално минало.

Операторите в ЦИК превъвеждат всеки един СИК протокол още веднъж. Софтуера налага същите контроли, които са и в ОИК, като заедно с това и сравнява с първото въвеждане. Ако има каквито и да било несъответствия, оператора получава съобщение от общ характер, което не му специфицира къде точно е разликата, а го приканва просто да прегледа още веднъж всичко.

Когато превъвеждането на даден ОИК приключи, специално обучена група анализатори пуска справки, които показват точните места на несъответствията/техническите грешки. За всеки един проблем се разписва предложение за решение, базирано на оригиналния протокол.

Когато превъвеждането приключи, всички справки за несъответствия се предават на ЦИК за вземането на решение. Обикновено, това са написани с левия крак протоколи или операторски фантазии. Последното почти не се среща, защото всичко се регистрира и последствията са мълниеносни – от отрязване на парите по договора, до предаване на съответните органи. Добрата новина е, че хората вече се научиха и глупости не правят – главицата на всяко пиленце си му е мила :)

ЦИК се произнася и оповестява публично решение за грешките. Решението се въвежда в системата и се проверява дали води до промени в изборния резултат. Ако това се случи се сезира Върховният административен съд (ВАС) за касиране на изборите в съответното място.

Когато всичко приключи, се генерира и отпечатва изборният Бюлетин – на хартия и в електронен вид. Според вида избори, Бюлетина е от 300-400 страници до над 3500 (за сравнение, “Война и мир” е около 1300) за Местните избори.

SubVersion+PostgreSQL+GMailFS backup

No comments »

За един малък домашен проект ми се наложи да измисля бекъп решение за кодовото хранилище и базата данни. Хрумнаха ми два бързи варианта:

  • Закачам USB памет на щайгата и копирам там всекидневно експорти;
  • Регистрирам в Google потребител за електронната им поща и пускам там бекъп-а по gmailfs.

Разбира се, като всеки уважаващ себе си програмист, нямам резервни USB стърчишки, особено ако трябва да ги завирам в архаична щайга (Celeron 433 MHz / HDD 20GB / RAM 512 MB) за постоянно. Трябва да поясня, че в Wikipedia не препоръчват gmail да се използва за бекъп – имат навика да трият акаунта при прекомерно използване, а и не се знае кога ще сменят API-то и ще угаснат файловете там.

Подминавам предупреждението и давам смело напред. Първо да идентифицирам какво точно ми трябва:

  • Бекъп пространство – поща в gmail, към момента дават 2-3 GB, напълно достатъчно за случая;
  • Скрипт за експорт на кодовите хранилища, по възможност да проверява дали има нови версии и ако няма да прескача стъпката с бекъпа;
  • Скрипт за пълен експорт на PostgreSQL-а;
  • Възможност за добро компресиране и силно криптиране на файловете – използвах 7z, видя ми се подходящ за случая;
  • Пилешки познания по bash scripting (е нека и гурутата да се посмеят сега), обилно гарнирани с крушова водка. Последното е необходимо на автора за да си припомни bash-а, че рядко му се налага да злоупотребява с него…

След известно ръчкане настъпих и първите мотики:

  • Използвам Ubuntu Gutsy Gibbon, към момента е dev версия. gmailfs-а при опит да се mount-не ме наплюва с 400: Bad Request. Това очевидно идва от гугълските сървъри, където някой нещо реже с флекс. По най-грубия възможен начин решавам проблема така: след известно взиране в python кода откривам, че грешката е в libgmail. Отивам на страницата на библиотеката, завирам се в cvs-а, от където измъквам топла-топла последната версия, само на два дена, милата. Грозно намазвам старата библиотека, намираща се в /usr/share/pycentral/python-libgmail/site-packages с тайната надежда, че когато поддържащия ubuntu-джия, обнови пакета, ще имам по-нова версия, ако ли не поне същата.
    Разбира се, номера минава и вече имам достъп до gmail пощата.
  • gmailfs не се mount-на човешки (поне при мен), в резултат на което на нея не можах да използвам примерно mv

След още малко човъркане и двойно повече взиране в man страниците, изковах следните скриптчета:

svn_backup

#!/bin/bash
#Backup svn repos, alex [at] stanev.org
svnbase='/var/svn'
backup_target='/mnt/gmail'
svndump='/tmp/backup'
pass='archive_password'
wd=$PWD
cd $svnbase
for repo in $(ls -d */); do
repo=${repo%/}
svn info file://$svnbase/$repo > $svndump/$repo.curr
touch $svndump/$repo.last
if ! cmp -s $svndump/$repo.curr $svndump/$repo.last ; then
svnadmin dump -q $svnbase/$repo | 7z a -mx=9 -p$pass -si$repo $svndump/$repo.7z
if ! [[ -f $backup_target/$repo.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/$repo.7z -nt $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/$repo$ext
else
ext='.7z'
rm $backup_target/$repo$ext
fi
cp $svndump/$repo.7z $backup_target/$repo$ext
mv -f $svndump/$repo.curr $svndump/$repo.last
rm $svndump/$repo.7z
fi
done
cd $wd

pg_backup

#!/bin/bash
#Backup postgre db, alex [at] stanev.org
backup_target='/mnt/gmail'
pgdump='/tmp/backup'
pass='archive_password'
sudo -u postgres pg_dumpall | 7z a -mx=9 -p$pass -sipostgres $pgdump/postgres.7z
if ! [[ -f $backup_target/postgres.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/postgres.7z -nt $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/postgres$ext
else
ext='.7z'
rm $backup_target/postgres$ext
fi
cp $pgdump/postgres.7z $backup_target/postgres$ext
rm $pgdump/postgres.7z

Накратко, горните упражнения правят следното:

svn_backup обикаля всички хранилища и изтегля информация за HEAD revision. Ако има промени се прави копие към директорията за бекъп. Тъй като в случая с gmailfs използваме отдалечена файлова система, отсреща се пазят по две копия на един и същи файл. При качване на следващия винаги се изтрива по-стария. Това повишава мижавата вероятност са имаме поне един цял файл, ако връзката се разпадне в момента на предаване.

За pg_backup е аналогично, с разликата, че там бекъпа винаги се изпълнява, без да се правят по-специални проверки.

Настройте вашите пътища, сменете паролата и сте почти готови!

Остава двете скриптчета да се назначат за периодично изпълнение и да проследим първите бекъпи.

За накрая пожелавам на никой да не му се налага да си спасява работата. *Винаги* тествайте обратния процес на възстановяване – периодично се уверявайте, че задната вратичка е достатъчно широка, за да можете да се измъкнете, когато се подпали къщичката ;)

Смарткарти

No comments »

Преди малко драснах във вътрешния форум на компанията няколко реда за един колега, който искаше да подкара смарткартите ни под Linux. Реших, че може да свърши работа и на някой друг, затова го пускам тук:

Намерих малко време и направих един бърз експеримент със CCID четец и SetCOS смарткарти, които под windows вървят със SetWEB-а. Резултата е успешен.
Ето какво направих:

0) Хардуер
alex@si:~$ pcsc_scan
PC/SC device scanner
V 1.4.9 (c) 2001-2006, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.4.2
Scanning present readers
0: ACS ACR 38U-CCID 00 00

[snip]

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 9F 94 80 1F C3 00 68 11 44 05 01 46 49 53 45 31 C8 07 90 00 19
3B 9F .. 80 1F C3 00 68 1. 44 05 01 46 49 53 45 31 C8 .. 90 00 ..
Setec SetCOS 4.4.1

1) ОС
alex@si:~$ uname -a
Linux si 2.6.22-10-generic #1 SMP Wed Aug 22 07:42:05 GMT 2007 x86_64 GNU/Linux
alex@si:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION=”Ubuntu gutsy (development branch)”

2) Пакети
alex@si:~$ sudo aptitude install opensc libccid mozilla-opensc

Към тези пакети най-вероятно ще се задействат dependecies, необходимо е да се потвърдят.

3) Тест
Провери дали работи pcscd и пусни pcsc_scan
Трябва да се върне информация за четеца и картата, както и при вадене/пъхане да се прочита информация за текущата смарткарта.

4) Потребителски софтуер
Ако горните стъпки са ОК, вече разполагаш с работещ подпис под linux. Последно остава да се конфигурира потребителския софтуер. Той трябва да поддържа работа през PKCS#11 интерфейс, което си е стандартно отвсякъде.
Пример за Firefox/Thunderbird:
цъка се на Edit->Preferences->Advanced->Encryption->Security Devices
после Load и се оказва пътя към PKCS#11 библиотеката на openSC:
/usr/lib/opensc/opensc-pkcs11.so

Потвърждава се, инсталират се базовите сертификати на StampIt (незадължително) и това е – вече трябва да можеш да използваш смарткартата за клиентска оторизация.

Уговорки:
горното би трябвало да работи без промяна и на Debian. Въпреки, че съм използвал development версия на Ubuntu (утре излиза Tribe6, ще се пие бира!) +, че е 64 битова системата, вярвам, че ще работи и под други дистрибуции аналогично.

Изобщо, като цяло инсталацията си е stright forward процес, без допълнителни “врътки”.

Edit: пътят към opensc pkcs#11 библиотеката може да е различен във вапата дистрибуция. Например, под Ubuntu 8.10 e /usr/lib/opensc/opensc-pkcs11.so

Вътрешно

1 comment »

Петъка ми възложиха една рутинна, но необичайна за компанията ми задача – да инсталирам вътрешен форум. “Но от тези, с тредовете. Знаеш ли какво е ‘thread’?”

Хм, при нас е весело, както се пееше в един популярен шлагер.

От доста време се боря за такава комуникация – все пак имаме 3 сгради в София и още 27 клона из България. Друг е въпроса, че исках висшето ръководство да  узрее за една такава стъпка – нека първо решат какво искат да споделят, а тогава да им връчим мегафона.

Все пак, веднага ми дойде да бухна Joomla и да натреса към нея колкото допълнения ми дойдат на идея. Сега обаче, си мисля за едно просто уики с форум.

Въпроса е по-скоро идеологически и философски. От една страна CMS ще свърши работа, ако си имаме едно проактивно ръководство, което в целта си да натрупа повече средства за акционерите (това е правилната посока) тупа по рамото тружениците и ги напъстства в живота (one of us технология). Апропо, имаме си и “Фирмени комуникации”, та те може да родят нещо интересно. Дано не е след 9 месеца, че при стъпкване на главата може и да пометнат.

Другия вариант е да връчим силата на хората. Web 2.0 и подобни – уики + форум + фото галерия (да, ходим на паметни team buildings) и като за организация като нашата – анонимен достъп за редактиране.  Това ще работи, когато няма да има кой да се занимава с хората и те ще се самозадоволяват. Може би грубо, но поне няма да е публично, от това най-боли, чувал съм.

Трудното заглавие

No comments »

За един програмист винаги съществува проблема да именува създанието си. С времето това става все по-лесно, стига програмиста да загуби навиците си. Тогава първо измисляш заглавието, продаваш го, а след това започваш да го създаваш. Обикновено, нещата приключват с измислянето на алгоритъма, системата или оптимизацията на двете заедно или поотделно. Тогава вече работата става безинтересна и ако нямаш на кой да я захвърлиш, пиши я бегала.

Ако все пак си напреднал, чети надолу.

Хм, упорито си ти…

Тук няма универсална истина, дори и добър съвет.

Опитай пак!

Раздвижване

No comments »

Наскоро се случиха някои доста интересни неща с оръжията, които използвам на компютъра си. Първо, в момента upgrade-вам служебния лаптоп с прясната версия на Ubuntu – дистрибуцията, с която се залисвам в последно време.
Отгоре на всичко FireFox най-после стабилизираха 2.0, което, надявам се, ще подтикне творците на add-ons да си поогледат творенията и да синхронизират интерфейса им. Учудващо, но 3.0а1 също е доста стабилна и може да се използва за всекидневно сърфиране.
Не на последно място, бирата все още е хладна, а живота – хубав :)
Само избори да не се задаваха…

Около изборите

No comments »

Повечето ми приятели и познати като цяло са аполитични.
Винаги като наближат избори обаче тръгват приказките как някой “пипа” в софтуера, подменя гласове и какво ли още не. За по-голяма прозрачност ще публикувам някои от филмчетата за обучение на служителите, както и заснети регресивни тестове на системата в ЦИК. Зная, че това е недостатъчно и единствено отвореният код ще помогне да се успокоят духовете, но и това е едно добро начало.
Заредете се с flash-добавката + малко търпение и цъкнете тук.