11/02/2010

Fedora 14 Lauglin release

Днес, 16:00, точно както обещаха от отбора на Fedora - Fedora 14 с кодово име Lauglin вече е достъпна за сваляне. Минути по-късно същата беше достъпна и за актуализиране от предишни версии, чрез preupgrade.


Честито на всички фенове!

10/21/2010

Ufomammut - (2010) Eve

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

Да, дами и господа, това са UFOmammut, които изобщо не си поплюват и са готови да ви объркат представите. Тука не става въпрос за някоя лигава брит поп бандичка, която се чуди как да направи новият си албум да не изглежда същият като предният, а за мощен катаклизмичен рок, който ще ви откъсне от реалността и ще ви засили към най-близката пропаст, ако се отпуснете достатъчно и не сте нащрек.

Ако сте от тези тип хора, които харесват такива екстремности и мразят брит поп шит глупости, това е албума за вас. Инжойн дъ факин фъз!

10/13/2010

Synchronizing in progress.

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

9/29/2010

За лошите практики - общи мисли

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

Но кой е точно правилният метод, ако една от основните философии на Linux системите е точно пълната свобода на действие?

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

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

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

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

Точно поради тази причина използвам Fedora, защото по принцип дериватите на Red Hat Linux винаги са държали страшно много на концепцията и мисленето в дългосрочен план.

За да не съм напълно голословен, ето един пример, за тея които биха ме разбрали:

# echo 1 >> /proc/sys/net/ipv4/ip_forward

След това тази команда се записва в някой системен файл, който се стартира със инициализацията, като например /etc/rc.local.

Ще оставя на читателя да разбере как се прави това по правилният начин. И това не е Red Hat или Fedora начина, а по принцип важи за всички модерни Linux системи.

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

9/24/2010

OpenVPN в кратки стъпки [3]

Нека продължим с конфигурацията на клиентската машина за нашият OpenVPN.

Първо копираме един от примерните конфигурационни файлове в директорията /etc/openvpn така:

# cp /usr/share/doc/openvpn-*/sample-config-files/roadwarrior-client.conf /etc/openvpn/client.conf

След това редактираме файла, като след remote тука:

remote [my server hostname or IP address]

записваме публичният IP адрес на сървъра ни. Имайте предвид, че ако на сървъра работи iptables, ще трябва да разрешите входящи връзки по порт 1194/udp, за да имате успешна комуникация. Във Fedora 13, firewall-а е пуснат по подразбиране и по-надолу ще обясня как да добавим тези правила, за да може всичко да е наред.

Може, разбира се, накрая на конфигурационният файл да добавим опцията:

log-append /var/log/openvpn

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

Преди да стартираме сървъра за да изградим VPN връзката, трябва да заредим модула за tun интерфейса, който ще използваме.

Това става чрез:

# modprobe tun



Но тъй като, това ще важи само докато не рестартираме системата, е нужно да добавим следното в директорията /etc/modprobe.d/

# touch /etc/modprobe.d/tun.conf
# echo "alias tun tun" > /etc/modprobe.d/tun.conf



Това е начина, по който модерни Линукс системи като Fedora използват за управление на модулите, които да се зареждат при стартиране. Писането на команди по разни скриптове, които се стартират с инициализацията на операционната система е проява на ниска техническа култура и не се препоръчва.

Така, време е да добавим openvpn в стандартните runlevel-и, за да може да се инициализира със стартирането на системата. Това във Fedora става с познатата ни вече команда chkconfig:

# chkconfig --levels openvpn on

Сега е време да пуснем нашият OpenVPN клиент и да проследим дали всичко е наред.

# service openvpn start

Във списъчният файл (ако сме задали такъв във конфигурацията, ако не всички системни съобщения отиват в /var/log/messages) трябва да видим нещо от рода:

Fri Sep 24 11:46:13 2010 us=542777 TUN/TAP device tun0 opened
Fri Sep 24 11:46:13 2010 us=542802 TUN/TAP TX queue length set to 100
Fri Sep 24 11:46:13 2010 us=542837 /sbin/ip link set dev tun0 up mtu 1500
Fri Sep 24 11:46:13 2010 us=543851 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Fri Sep 24 11:46:13 2010 us=547866 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Fri Sep 24 11:46:13 2010 us=548549 /sbin/ip route add 172.16.0.0/12 via 10.8.0.5
Fri Sep 24 11:46:13 2010 us=549134 Initialization Sequence Completed


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

$ ping 10.8.0.1

би трябвало да получим ICMP отговор от сървъра ни.


PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=2.12 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=1.78 ms
64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=1.84 ms


Ето и какво трябва да направите, ако искате да разрешите порт 1194/udp, за да може да получавате входящи връзки. Първо трябва да решим къде ще добавим това правило в цялата firewall таблица. Разбира се, веригата която ни трябва е INPUT, тъй като няма да правим никаква машрутизация на тези пакети. Най-добре, според мен, е в тази верига това да се случи преди всички Reject правила, за да може да избегнем конфликти. Естествено, ако вашият сървър е конфигуриран първо да филтрира всичко и после да приема определни пакети, правилото трябва да е под филтриращите такива.

В най-общ случай това трябва да работи винаги:

# iptables --insert INPUT 1 --match state --state NEW --match udp --protocol udp --dport 1194 --jump ACCEPT

След като изпълни тази команда и проверим дали всичко вече работи е необходимо да запишем тези правила за да се изпълняват при инициализацияата на firewall-а. Това в модерни Линукс системи като Fedora се прави чрез:

# service iptables save

Което записва промените във файла /etc/sysconfig/iptables, от където се зареждат при стартиране. Имайте предвид, че ръчното редактиране на този файл не се препоръчва и вероятно ще доведе до грешки.

Повече информация за OpenVPN, може да намерите тук:

http://openvpn.net/

9/19/2010

OpenVPN в кратки стъпки [2]

Нека продължим историята за OpenVPN връзката, от предишният пост.

Като цяло конфигурацията на OpenVPN сървъра е елементарна и доста праволинейна. На първо време трябва да изберем дали искаме routing или bridging метод за връзка между системите във VPN-а.

Разликите може да прочетете тук.

Аз избрах routing, защотo е по-гъвкав от колкото Ethernet bridging.

Така, първо нека преместим един от примерните конфигурационни файлове в директорията /etc/openvpn/. Това става така:

# cp /usr/share/doc/openvpn-2.1.1/sample-config-files/roadwarrior-server.conf /etc/openvpn/server.conf

След това отваряме файла /etc/openvpn/server.conf с любимията си текстов редактор (трябва да сте root за да може да записвате промените).

Първият ред показва порта, на който OpenVPN сървъра ще чака заявка, за осъществяване на комуникация. Вторият ред показва какъв вид връзка ще използваме (това не е много интуитивно, но ако сте прочели FAQ-то по-горе, ще разберете че за Routing използваме tun, а за Bridging използваме tap). По-надолу следват конфигурацията на ключовете, и пътищата до тях. Тук трябва да променим пътя до директорията с ключове, която направихме в първата част на това howto. Ето пример:

tls-server
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/lateralus.crt
key /etc/openvpn/easy-rsa/keys/lateralus.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

Малко по-надолу указваме режима да е сървър, оказваме IP адресите, които сървъра ще използва за крайни точки (тези адреси, не трябва да съществуват в мрежата, за да не стават конфликти) , също така и адресите, които да се раздават на клиентите, в нашият случай оставяме комуникационна четворка за всеки един от тях.

По-интересна е опцията push, чрез която може да окажете какви routing пътища трябва да се добавят към статичната routing таблица на клиентите. Например, ако имаме частна мрежа 172.16.0.0/12, която клиентите в VPN-а искате да достъпват е нужно да направим следният push към тях

# Push any routes the client needs to get in
# to the local network.
push "route 172.16.0.0 255.240.0.0"

По този начин, след като клиента се е удостоверил пред сървъра, последният му изпраща заявка за модифициране на routing таблицата му. Понеже това рядко ще работи out-of-the-box, може да се наложи модифициране на firewall-а на системата (iptables), което ще покажа как се случва по-надолу.

По-надолу в примерният файл има още push заявки за DHCP към клиенти с операционна система Windows. Тъй като не използвам Windows, в този пример, тези опции съм ги коментирал. Всичко останало съм го оставил така както си е, само съм добавил най-накрая на файла:

log-append /var/log/openvpn

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

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

# chkconfig --levels openvpn on

Това в системи базирани на Red Hat (като Fedora, CentOS и т.н.) ще добави openvpn в runlevel 2,3,4,5, което с прости думи обяснено означава, че сървъра ще се пуска при инициализация на системата.

Сега е време да стартираме сървъра. Това може да стане или чрез рестарт на цялата система (което не се препоръчва разбира се) или по-лесният вариант е:

# service openvpn start

Ако всичко е наред, би трябвало сървъра да се инициализира, като това може да се проследи в log файла /var/log/openvpn, ако сме указали тази опция в конфигурацията.

Другият вариант, който може да използваме за debugging е да стартираме


# openvpn --verb --config /etc/openvpn/server.conf

Като това ще изпълни openvpn и ще изведе инициализиращите съобщения директно в терминала.

9/14/2010

OpenVPN в кратки стъпки [1]

Вчера реших да си направя VPN между работната ми машина и тази в къщи. За целта избрах OpenVPN, защото подръжката му е прекрасна и Fedora го препоръчват. Ето в няколко стъпки как се конфигурира този страхотен софтуер.

1. Инсталираме openvpn пакета. В стандартната дистрибуция на Fedora 13 това става така:
# yum install openvpn
2. Създаваме директория, където ще се пазят инструментите за създаване на ключове и променливите.
# mkdir ~/easy-rsa
# mkdir ~/easy-rsa/keys

3. Копираме инструментите и някои стандартни файлове в директорията, която създадохме:
# cp /usr/share/openvpn/easy-rsa/2.0/* ~/easy-rsa
4. На този етап е хубаво да отворим файла vars за да променим аргументите на:
# cd ~/easy-rsa/
# cat vars

export KEY_COUNTRY=""
export KEY_PROVINCE=""
export KEY_CITY=""
export KEY_ORG=""
export KEY_EMAIL=""

/намират се най-долу на примерният файл/
5. Задаваме vars на обвивката за изпълнение:
# source vars
6. Почистваме за всеки случай:
# ./clean-all

=============================================

Така сме готови да създадем PKI (Public Key Infrastructure), която се състои от:

* отделен сертификат (публичен ключ) за сървъра и за всеки един клиент по отделно.
* главен Certificate Authority (CA) сертификат и ключ, с който се подписват всички други сертификати за сървъра и клиентите.

OpenVPN подържа двупосочна автентикаци, което означава че сървъра трябва да удостовери сертификата на клиента, както и клиента трябва да удостовери същото за сървъра.

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

Как да генерираме тези сертификати и ключове?

1. Влизаме в директорията, където преместихме инструментите по-горе
# cd ~/easy-rsa
След това изпълняваме скрипта, който ще генерира Certificate Authority (CA) сертификат:
# ./build-ca
Ще ви бъдат зададени, няколко въпроса. Хубаво е да отбележим, че този скрипт взима аргументите на променливите от файла vars, който променихме по-горе, като единственото по-различно е Common Name, което трябва да въведем сами. При мен използвах: lateralus

Country Name (2 letter code) [BG]:
State or Province Name (full name) [SF]:
Locality Name (eg, city) [SOFIA]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []: lateralus
Email Address [me@myhost.mydomain]:


2. След това трябва да създадем сертификат и ключ за сървъра. За целта изпълняваме:

# ./build-key-server server

( На мястото на аргумента 'server' може да поставим каквото си поискаме ).
Повечето неща, може да ги пропусне, защото са по подразбиране. Единственото, което трябва да въведем сами е Common Name. Две функции, ще изискат потвърждение "Sign the certificate? [y/n]" и "1 out of 1 certificate requests certified, commit? [y/n]". Естествено потвърждаваме!

3. Следва да създадем сертификати и ключове за клиентите. Например за клиента homebox изпълняваме:

# ./build-key homebox

Ще ви бъдат зададени познатите въпроси, след което ще се генерират сертификат и ключ. Това трябва да се изпълни за всеки един клиент по-отделно като трябва да внимаваме да няма клиенти със едно и също име.

4. Генериране на Diffie-Hellman параметрите:

# ./build-dh

Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................


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

7/24/2010

София, иууу!

София...

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

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

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

7/11/2010

Sun is shining

Велико! В Поморие отново времето е спряло, изпивам промишлени количества бира и изпушвам много цигари, но вкуса тука е друг, погледа е друг, цветовете са други. Като паралелна реалност, до която се докосваш само ако имаш усещането за това. Независимо колко странно е за някои хора всичко това. Поморие е неустоимо място за всички!

Един вид институция, но необвързваща с нищо друго, освен с любов! Приказка! Обичам!

6/28/2010

28.06.2010 г.

Може би след близо седмица облачно време, най-после краят на тази смърт настъпи. Днес видях слънце, което е страхотно! Надявам се в Сряда да е хубаво времето, за да може евентуално да хванем стопа за Поморие.


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

Но на фона на това, се случиха някои неща, които ми пълнят сърцето и ми слагат голяма усмивка на лицето. Какво по-хубаво от това. :-)

6/20/2010

Fedora 13 Installation success

На 25.05.2010 Fedora Project пуснаха последният release на чудесната си операционна система, базирана на Linux ядро - Fedora 13 Goddard. Посветена на Robert H. Goddard, човека направил първата ракета с гориво в течно състояние, която е била успешно изстреляна на 16.03.1924 г.

Fedora е една от водещите свободни операционни системи, базирани на Linux ядрото. Дори няма да е грешно да кажем, че това е най-свободната Linux дистрибуция, заради ясната си политика при приемането на пакети в основните си хранилища. В стандардна инсталация на Fedora няма да намерите подръжка на MP3, например, за разлика от Ubuntu, които подържат хранилище с тези не-свободни формати и пакети. В Fedora такова хранилище не съществува, а подръжката на такива пакети се прави third-party хранилища, като rpmfusion например. Така стои въпроса и с собствените драйвери за nVIDIA карти и още редица други софтуерни пакети с неясни лицензи.

По-надолу следват мойте премеждия при инсталацията на Fedora 13. Още не съм правил upgrade от F12 до F13, но обмислям скоро да го направя на домашната ми машина и след това на сървърите, които подържам.

Конфигурацията на машината, на която инсталирах Fedora 13 с KDE за графична среда е следната:

CPU: Intel Core 2 Duo E6300 @ 2.80GHz
MB: ASUS P5QPL-AM
RAM: 4GB Kingston Hyper X 800MHz ( 2x2Gb)
VGA: Intel Integrated Graphics GM4500 *
HDD: 500GB Seagate

След стартирането на boot механизма от Live CD-то, на което си бях сложил Fedora 13 x86 KDE release-a. Веднага бях посрещнат от познатият но вече леко променен boot screen на Fedora.

От менюто избрах Boot, другият вариант е просто да изчакаш 10-те секунди и системата автоматично се инициализира чрез тази опция. След известно време и звука на стъргане от CD–ROM устройството след малко се оказах в основният работен плот на KDE средата с симпатичната иконка Install on hard drive. След натискането на тази иконка инсталацията е повече от елементарна и стандартна - уточняването на часова зона, разпределение на хард диска и смяна на root паролата, след което всичко отнема между 5 и 10 минути според зависи от скороста на CD-ROM устройството и бързината на компютъра ви като цяло. При мен за щастие инсталацията мина без никакви проблеми и след около 15 минути имах напълно работеща система. След още 5 имах пълна подръжка на 3D ускорение, без грам собствен софтуер на компютъра ми и без инсталация на никакви драйвери, последният стабилен release на Линукс ядрото, пълна актуализация на системата до деня на инсталацията, последната версия на Mozilla Firefox, Тhunderbird, Amarok и всички останали малки tool-чета, които ми трябват за да мога да работя пълноценно.

Аз съм повече от доволен от последният release на Fedora. Актуализацията на NetworkManager-а под KDE ми направи доста добра изненада. Всъщност тази актуализация е от онези малки неща, които ти харесват, че ги има дори и да не ги ползваш. Аз не ползвам NetworkManager-а, но да видя че се обръща внимание на подръжката му в може би най-добрата графична среда за работа в Линукс - KDE, означава че хората, които организират Fedora мислят в перспектива и доста повече за user-friendly изживяването при работата с свободната операционна система.

* Инсталацията на друга машина с NVIDIA карта от 8-ма серия 'гърми' малко след стартирането на Live диска. За да се прескочи този момента трябва драйвера nouveau (който в момента изпълнява ролята на свободен драйвер с 3D оптимизация и е драйвера по подразбиране за Fedora, когато става въпрос за системи с NVIDIA графични ускорители) трябва да се забрани и системата да се вкара в single user mode. Но за това друг път.

3/11/2010

How to read a difficult book

In reading a difficult book for the first time, read the book through without stopping. Pay attention to what you can understand, and don't be stopped by what you can't immediately grasp on this way. Read the book through undeterred by the paragraphs, footnotes, arguments, and references that escape you. If you stop at any of these stumbling blocks, if you let yourself get stalled, you are lost. In most cases you won't be able to puzzle the thing out by sticking to it. You have a better chance of understanding it on a second reading, but that requires you to read the book through for the first time.

- Mortimer J. Adler, How to Read a Difficult Book

1/11/2010

Distant voice...


David Gilmour - On an Island

Слабост! Трудно е да се опише, когато толкова любим глас произведе толкова истински албум. Незнам какво да напиша повече от едно благодаря! Пробвайте, може да ви хареса :)

1/03/2010

03.01.09

Няма нищо, нищо по-хубаво от това да завършиш деня с Pink Floyd - Dark side of the moon. Помни човече - НИЩО!