Reborn

Disclaimer: Описаните техники в този документ могат да ви помогнат но не е задължително да са напълно вярни и изчерпателни. Не поемам отговорност за каквито и да било реални или нереални, вреди, ползи, пропуски, паднали къщи или каквото и да е произтичащи от ползването или неползването на този документ.

История

• 25.01.2007 – Първа версия

Тук ще се постарая да опиша по какъв начин съм настроил система състояща се от Trac и SVN която използвам за управление на проекти.

Идеята
Тъй като се занимавам с много и най-вече различни проекти, стана ясно че имам мужда от система за управление на проекти. И докато това ми се търкаляше в главата реших че ще е добре ако може да се използва за множество проекти с множество хора. Почна се търсенето, като минах през dotProject, TikiWiki, Mantis и някои други. Но просто някак си не ми допадаха. В крайна сметка се спрях на Trac и SVN.

Мотивацията
Избрах комбинацията Trac + SVN по следните причини

• Свикнал съм със SVN пък макар и от конзола
• Trac се разработва относително активно
• Вече имах инсталиран Python заради част от системата ми
• В самия Trac има вградено wiki което ще се ползва за описанието на проектите и документацията
• Има билетчета за проблеми
• Куп други дреболии

След всичко казано Trac се оказа едно добро решение.

Желязото
Машината на която работи всичко това е следната

Debian Unstable
600 Mhz CPU
256 MB Ram
20G HDD

Върху нея работят доста услуги: mysql, apache, exim, routing/shaping/nat, dns, dhcp, ntp, ftp, shell, samba (в режим на Master Browser) и други.

Като цяло доста слабичка машинка по днешни стандарти, но полезна и гледана с любоФ

Необходим Софтуер
За да може системата да работи като хората ни трябва следният софтуер

• Trac
• subversion
• libneon
• Python
• pysqlite
• python-subversion-bindings
• mod_python
• clearsilver
• xinetd
• други дреболии

Като цяло най-лесно е ако си имате дебиан. Ако е такъв случая процедурата е пределно проста

apt-get install trac libapache2-mod-python xinetd

И започва веселбата :)

Допълнително към Python сме инсталирали python-setuptools, tracwebadmin, tracaccountmanager.

Разположение на файловете
Тъй като ще има няколко проекта, ще отделим специално място за цялата система. Препоръчително е да е на отделен дял.
При мен се спрях на директорията /home/projects която има следната структура

/home/projects/
/home/projects/trac
/home/projects/trac/project1
/home/projects/trac/project2
... ... ...
/home/projects/svn
/home/projects/svn/project1
/home/projects/svn/project2
... ... ...

Възможно е Trac и SVN инстанциите да се намират в директориите на проектите но така се усложнява млко конфигурацията

Същинското изпълнение
Създайте си директорната структура която ще ви е удобна:

mkdir -p /home/projects/{trac,svn}

Създайте си съответните проекти (това става с trac-admin)

trac-admin /home/projects/trac/project1 initenv

Ще ви бъдат зададени няколко въпроса и по точно: Име на проекта, База данни (sqlite е добър избор), тип на хранилището за код, къде се намира самото хранилище.
Ограничение е че хранилището на код трябва задължително да е на същата машина (не се поддържат отдалечени), но това може лесно да се заобиколи с помощта на nfs

Създайте съответните хранилища за код (svnadmin)

svnadmin create /home/projects/svn/project11
Променете правата на така създадените директории съответно на потребителя като който вървят Trac системата и svn сървъра
1chown -R www-data:www-data /home/projects/trac/project1
chown -R svnserv:svnserv /home/projects/svn/project1

Използваме www-data тъй като под този потребител работи Apache сървъра. Потребителя svnserv сме създали предварително като за домашна директория сме му задали /home/projects/svn

След като имаме вече създадени проектите време е да можем да ги покажем в браузър (иначе са безполезни).
Trac може да работи като самостоятелен демон (tracd), като CGI процес (trac.cgi, trac.fcgi) или в контекста на Apache (което сме и избрали) с помощта на mod_python.

В конфигурацията на Apache добавяме

LoadModule python_module modules/mod_python.so
# или го разрешаваме с помощта на дистрибуцията си
 
<location /projects>
    # с какво ще обработваме съдържанието
    SetHandler mod_python
    # точно с какво (trac)
    PythonHandler trac.web.modpython_frontend
    # коя информация точно ще сервираме
    PythonOption TracEnvParentDir /home/projects/trac
    # от какво ще генерираме индекса (не е задължителен)
    PythonOption TracEnvIndexTemplate /home/projects/trac/listing.cs
    # debug mode ON
    PythonDebug on
</location>

Рестартираме сървъра и проверяваме. Трябва да се вижда нещо подобно на следната картинка

Ако ли пък не … почвайте да гледате в логовете какво пише.

Следва да пуснем svn сървър. Това се прави с помощта на svnserve. В случая съм избрал да го стартирам през xinetd понеже няма да е толкова натоварен. За по голяма сигурност ще работи като отделен потребител (svnserv)

Конфигурацията на xinetd е следната

service subversion
{
        # слушаме само на IPv4 адрес
        flags = IPv4
        # услугата НЕ е спряна
        disable = no
        # потребител и група
        user = svnserv
        group = svnserv
        # максимален брой инстанции
        instances = 5
        # be nice :)
        nice = 15
        # кой точно е сървърът
        server = /usr/bin/svnserve
        # аргументи за стартирането му
        server_args = --inetd --root /home/projects/svn
        # обичайните работи (логване, типаж ...)
        log_on_success = PID HOST DURATION
        log_on_failure = HOST ATTEMPT
        wait = no
        socket_type = stream
}

Тествайте със svn клиент дали работи.

Подсигуряване и подобряване на Услугите
След като имаме работещи услуги време е да помислим за тяхното подсигуряване. А именно ето какво ще направим:

За Trac системите

• Премахване на анонимният достъп (изцяло). За тази цел ще ни се наложи да използваме trac-admin. Възможно е да се реализира през web интерфейс но все пак трябва да се знае как се прави на ръка.

  # влизаме в интерактивен режим
        trac-admin /projects/trac/project1
        # привилегиите се управляват посредством командата permission
        Trac [/home/projects/trac/project1]> permission help
        permission list [user]
                -- List permission rules
  
        permission add <user> <action> [action] [...]
                -- Add a new permission rule
  
        permission remove <user> <action> [action] [...]
                -- Remove permission rule
        # това е просто за запознаване
        # следва същинското премахване
        Trac [/home/projects/trac/project1]> permission remove anonymous *

  Вече анонимните потребители нямат никакви права.

• добавяне на нов административен потребител с пълни права. Това се прави за да имаме по лесен контрол.

  Trac [/home/projects/trac/project1]> permission add user1 TRAC_ADMIN, MILESTONE_DELETE ....
        # всички възможни привилегии

  Така добавеният потребител user1 ефективно получава пълен и абсолютен контрол.

• активиране на администраторският панел - тази процедура се извършва чрез редакция на кконфигурационният файл conf/trac.ini в директорията на нашият проект. За да активираме администраторският интерфейс е необходимо да разрешим използването на компонентите които са ни нужни а именно да добавим

  [components]
  webadmin.* = enabled

• включване на подобрен процес на влизане в системата - по начало процеса на влизане в Trac не е особенно красив нито пък удобен, затова и ще бъде подменен от разширението TracAccountManager. То има зависимост от TracWebAdmin който вече е активиран. За да можем да ползваме подобреният процес трябва първо да изключим вграденият във trac и да активираме новият. Това става отново с редакция на trac.ini

  [components]
  acct_mgr.admin.accountmanageradminpage = enabled
  acct_mgr.api.accountmanager = enabled
  acct_mgr.htfile.abstractpasswordfilestore = enabled
  acct_mgr.htfile.htdigeststore = disabled
  acct_mgr.htfile.htpasswdstore = enabled
  acct_mgr.http.httpauthstore = disabled
  acct_mgr.web_ui.accountmodule = enabled
  acct_mgr.web_ui.loginmodule = enabled
  trac.web.auth.loginmodule = disabled
  
  [account-manager]
  password_file = /home/projects/trac/users
  password_store = HtPasswdStore

  Какво точно прави всяка опция е добре обяснено в документацията (линковете са в края)
  Сега е необходимо да рестартираме web сървъра за да влезнат в сила нашите промени.

За svn сървъра:

Забраняване на всякакъв достъп за неауторизирани потребители

Това се изпълнява като се редактират конфигурациите на svn сървъра. Те се намират в директорията в която е нашето хранилище на код. Модифицираме ги по следният начин:

conf/svnserve.conf

### This file controls the configuration of the svnserve daemon
### Visit http://subversion.tigris.org/ for more information.

[general]
# никакъв достъп за анонимните
anon-access = none
password-db = passwd
authz-db = authz
realm = Project 1

conf/authz

### This file is an example authorization file for svnserve.
### Its format is identical to that of mod_authz_svn authorization
### files.

[groups]

# за кой път иде реч (правата се унаследяват)
[/]
# правата на потребител (четене и писане)
user1 = rw
# правата на всички останали (пълна нула)
* =

conf/passwd

### This file is an example password file for svnserve.

[users]
user1 = password

Заключение
След като сме си свършили всичката работа следва да рестартираме за един последен път apache и xinetd и да започнем да си ползваме системата. За подробности за работата с нея … във връзките

Връзки
Trac
mod_python
Apache
Subversion
TracWebAdmin
TracAccountManager

Това е шестата част от серия от статии в които ще обясня как да създадем перфектният SOHO рутер. Държа да отбележа че това е моята идея за рутер със всичките и предимства и недостатъци.

Серията се състои от следните статии:

• Общи насоки, идеи, нужни услуги и размисли – тук ще се постарая аргументирано да обоснова защо съм избрал този комплект от софтуер и услуги
• Инсталация на базовата система - ще опиша методът по който ще инсталираме и минимизираме нашата система
• Конфигуриране на DNS и DHCP услугите – тук ще опиша обосновано конфигурациите които смятам за оптимални
• Конфигуриране на рутирането – като цяло тук е сърцето на нашият рутер. Ще предложа някои трикове за улесняване на живота, както и насоки към по-специфични задачи
• Конфигуриране на елементарна система за наблюдение и статистика
• Разширяване възможностите на нашият рутер – ще опиша някои дреболии които могат да направят живота ни много по лесен, удобен и приятен

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

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

Защо ни трябва прокси
Прокси сървърът представлява система която кешира заявки. Тоеск ако клиент А изиска файл file.html нашият сървър ще съхрани за определено време отговорът в своят кеш и при последваща заявка за този файл от друг клиент Б файлът ще бъде подаден от кеша, а не от интернет. По този начин постигаме спестяване на трафик, ускоряване, контрол. С малко повече труд може да се реализира антивирус, антиспам, филтрация на реклами, контрол на трафика и др. Най-популярното решение за прокси сървър е squid.

Проста конфигурация на squid
Ще дадем една много елементарна конфигурация при която всичко работи, но няма никакви защити от към използване. Конфигурацията е без коментарите от файла поради причината че целият файл е около 40К.

# на кой порт да слушаме и дали да ауторизираме (не)
http_port 9999 no-connection-auth
# на кой порт да си говорим с други проксита (няма да си говорим)
icp_port 0
# ако някой от тези стрингове се среща в URL - не кеширай
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
# workaround за буг в апачето
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
# максимална големина на обект в рам областта
maximum_object_size_in_memory 48 KB
# колко рам да заделим за кеширане
cache_mem 24 MB
# директория за кеш файлове (прочетете конфигурацията във файла, много полезна е)
cache_dir aufs /var/spool/squid 500 16 256
# логовете ...
access_log /var/log/squid/access.log squid
# малко анонимизация ... максимална всъщност)
client_netmask 0.0.0.0
# юзер за ftp сесии
ftp_user IEUser@
hosts_file /etc/hosts
# стандартни параметри за проверка по някои протоколи
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern .               0       20%     4320
# малко ACL-и. Почти всички са стандартни
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443          # https
acl SSL_ports port 563          # snews
acl SSL_ports port 873          # rsync
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 631         # cups
acl Safe_ports port 873         # rsync
acl Safe_ports port 901         # SWAT
acl Jabber_ports port 5222 5223	#Jabber
acl purge method PURGE
acl CONNECT method CONNECT
# това вече сме ние
acl clientnetwork src 10.42.3.0/255.255.255.0
# след като имаме ACL-и време е да почнем да раздаваме достъп
http_access allow manager localhost
http_access allow manager home
http_access deny manager
http_access allow purge localhost
http_access allow CONNECT Jabber_ports
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
# ДАААА пуснахме го :)
http_access allow clientnetwork
http_access allow localhost
# Всичко което не е разрешено ... под ножа
http_access deny all
http_reply_access allow all
icp_access allow all
cache_mgr root
cache_effective_group proxy
# нека да скрием версията при грешки
httpd_suppress_version_string on
# и да не издаваме че има прокси по пътя
via off
forwarded_for off
cachemgr_passwd parola all
buffered_logs on
short_icon_urls on
coredump_dir /var/spool/squid
# нека да се опитаме да сме умни и да вземаме по няколко странички на куп
pipeline_prefetch on

Както се вижда това отново е една много проста конфигурация, която се различава съвсем малко от стандартната. Променили сме стандартният порт на който слуша сървърът ни, добавили сме настройка за in-memory кешът, увеличили сме малко дисковият кеш и сме скрили малко факта че има прокси. Сега остава да го направим сървърът ни прозрачен. Тоест да няма нужда клиентите да се настройват. Това се постига посредством пренасочване на изходящите заявки към определен порт. Да предположим че искаме да пренасочваме целият http трафик но не и https трафика и ftp трафика. Като допълнителен бонус знаем че част от клиентите посещават сайтове които не са на 80ти порт ами на 81,88,8800,8080. Също така доста сайтове предпочитат да имат два web сървъра, първият на порт 80 който сервира страниците и втори обикновенно на порт 81 който сервира картинки само.
Цялата задача се реализира по следният начин (използваме конвенциите от Четвърта част)

$IPT -t nat -A PREROUTING -i $INT_IF -m multiport --dports 21,80,81,88,8800,8080 -j REDIRECT --to-port 9999

Съответно порт 9999 е отворен поне за вътрешният интерфейс.

Темата с delay_pools също е интересна тъй като с нея може да се реализира прост шейпър. И за всеобща радост е много добре обяснена в конфигурационният файл.

Просто ограничаване на трафик
Понякога клиентите на рутера са малко нагли и теглят ужасно много. Ако нямаме познанията или желанието да реализираме някакъв вид шейпър, можем да направим временно решение посредством iptables. Решението се базира на идеята че ако линията е претоварена мрежовият стек се опитва да намали трафика. Обикновенно претоварена линия се открива когато започнат да се губят пакети. И за да изглежда реално пакетите трябва да се губят що годе случайно. Това се постига посредством модула към iptables RANDOM. Този модул е в patch-o-matic-ng base. Правилото изглежда по следният начин.

$IPT -t nat -A FORWARD -i $INT_IF -s < client_IP > -m RANDOM --average 5% -j DROP

Методът изобщо не е красив и понякога само натоварва допълнително линията. Ако ползваме голям процент обаче (над 30%) обикновенно клиентите се усещат и просто си спират свалящите се работи.

Малко по-подробни статистики
Ако статистиките от mrtg не са ви достатъчни може да използвате ipaudit-web. Като цяло е доста добър софтуер, вади прилични статистики, но за съжаление е малко натоварващ.

За момента това са работите за които се сещам. Всеки който иска нека публикува и своите дребни трикове в коментарите. Ще се постарая да ги интегрирам.

Сървър за точно време
Това е едно удобство за клиентската мрежа което може да осигури стабилност на определен тип приложния. Най-вече тези които зависят от точното врем. Освен тях от точно време може да се възползва всеки който иска. Сървърът се реализира посредством пакета ntpd и конфигурацията му е доста семпла и проста

# /etc/ntp.conf, configuration for ntpd
# къде да пазим нашето отместване. Специфична настройка необходима за работа на сървъра
driftfile /var/lib/ntp/ntp.drift
# къде да съхраняваме статистиките
statsdir /var/log/ntp
# какви статистики искаме и точно с какви опции
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to more than 300 low-stratum NTP servers.
# Your server will pick a different set every time it starts up.
#  *** Please consider joining the pool! ***
#  *** <http ://www.pool.ntp.org/join.html> ***
# да научим нашият сървър къде да пита за точно време
server 0.bg.pool.ntp.org iburst
server 1.bg.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server pool.ntp.org iburst

Както виждате настройката е пределно проста. Единственото което си струва да се отбележи е че обявяваме времето на всеослушание. Никой не гарантира че то ще бъде използвано, но нека да го има. Ако имаме желание може да уведомим нашите клиенти къде могат да открият нашият сървър за време посредством следните редове в конфигурацията на нашият dhcp сървър (dhcpd):

option time-servers 10.99.3.1;
option ntp-servers 10.99.3.1;

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