Изпечатай

Освен което не би било лошо да се помисли и за pppoe, надеждна автентикация, подръжка на vlans (802.1q), spanning tree protocol, интеграция с quagga за динамичен рутинг, секюрити на цялата тая работа (естествено уеб сървъра няма да работи като root и трябва да се пише един демон който да обира нещата и да маже - оттам могат да се появят доста проблеми). Performance monitoring & testing също не е лоша идея - в крайна сметка ако машинката се наблъска с уеб сървър, PHP, mysql, pppoe сървър, разни cron jobs, голяма бройка iptables и tc правила, разни realtime статистики...при по-голямо натоварване машинката ще почне да се държи зле и ще се окаже bottleneck за цялата мрежа.

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

Също така би било интересно да се помисли и за high-availability (пускаме две такива машинки да речем и ако едната падне другата да върши работа), разни странни случаи като bonding връзки, странни WAN интерфейси и протоколи, QoS и т.н. Трябва да се търси баланс за най-добра производителност. WINS-подръжка също е добра идея.

Мисля че това всичкото е прекалено много работа дори за няколко човека.

Идеята е интересна, ако имате нужда от идеи или от някой некадърен писач на C (glibc/kernel) съм готов да хелп-вам. В интерес на истината преди време мислех да си правя нещо подобно (само че *БЕЗ* web интерфейс). Мога да хелп-вам и със security/performance тестване и доработване. Бих могъл да се захвана с писането на някакъв CLI интерфейс за тва нещо, web-based нещата нещо не ми допадат..

Ако сте заинтересувани, пишете на UIN 159768870 :-)

[VladSun]

@gat3way
Много добри предложения '>
Изводът според мен е един: трябва да са две машини - едната да е рутера (iptables, tc, ssh), а другата да е управляващата с всичките му PHP, mysql и т.н. По този начин може управляващата да стане рутера в случай на пропадане на heartbeat-a между тях.
Това сron-a съм го мислисл, но реализацията при мен си е със sudo.

В добавка към функционалността:

- генериране на conf-файла за dhcpd.

Ми не мисля че е необходимо да разделяме нещата така...по-добре нещо многофункционално, вече какви функции ще изпълнява си е въпрос на администрация. По скоро няколко версии - олекотена, стандартна и за глезени админчета примерно '>

Относно конфигурациите - не само на dhcpd а и на доста други userspace неща може да се мажат. С разни templates би било лесно.

Мисля че би било идейно в дъното на всичко да стои един текстов CLI интерфейс (readline, не curses). Както при цицко '> с тази разлика че ще бъде върху ssh, което само по себе си би било първото фундаментално предимство пред прехвалените черни кутийки. Поне повечето модерни процесори са по-бързи от мизерните им мотороли и няма да се измъчат особено с криптираната връзка '>

За жалост никога, ама никога няма да можем да бием по производителност техния хардуер. Дори на бързи машинки, дори с прекрасни мрежови карти, дори с pci-x...обаче можем да се постараем за гаврата да издъним някой друг buffer size в ядрото, въобще би било прекрасно да се постараем да гоним скорост и надеждност пред всички глезотии за администраторите, в крайна сметка няма нужда да правим клонинг на LRP и подобните дистрибуции...по-добре нещо по-уникално доколкото имаме възможности '>

Имам няколко идеи по отношение на ускоряването на всичко това - доста ненужни библиотеки и байнърита могат спокойно да си заминат, логване няма да има поне във вида в който сме свикнали (syslogd да маже по бавни дискови устройства), няма да има шел по принцип, ще има наш си /bin/login. В крайна сметка може да се получи нещо което се стартира бързо от флаш върху машина без дискови устройства, разни хубави заемки от цицко като организация на нещата и интерфейс (за да може дори  сертифицираните ******ци да се справят) и т.н.

Ако измислим и един удобен текстов формат на цялостната конфигурация на рутера и един engine дето да я превръща в каквито трябва конфигурации и да вика съответните байнърита...ехеее цена няма да има. Пак по подобие на цицко аеххех '>

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

Хммм това е моята "визия" за нещата де '>

[VladSun]

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

За мен ситуацията е следната:
1) основа - добър дизайн на базата-данни;
2) добро имплементиране на userspace приложенията;
3) добър (избор на) протокол за комуникация между първите две '>

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

По отношение на темплейтите - какво по-добро от SQL + PL '> Все пак и темплейта си е един PL, макар и доста орязан (което в определени случаи може да бъде и недостатък).

В момента съм се спрял на следното решение - система комуникираща с Mikrotik машина през SSH за достъп и трафик контрол.
Мотивите ми са следните - Mikrotik e с висока производителност по отношение на рутиране, достъп, шейпинг и т.н.; администраторската система отделена на отдалечена машина с базата данни позволява мащабируемост, модулност, независимост от мрежовото натоварване и не на последно място добър потребителски интерфейс.

ПС
@gat3way: Твоето предложение за dedicated Linux дистрибуция в много голяма степен съвпада с това, което са направили Mikrotik.

Хм, ако ти кажа тия микротик колко ме заинтригуваха днеска няма да повярваш...определено е доста, доста, доста интересен проект...ама платен, дееба, как може да продаваш масово модифицирани opensource решения, ужасяващо е това. Не съм някъв фанатик, ама това е гадно не знам ;(

Микротик рутерОС е нещо, което май ми дойде в повече...4/5 от идеите които имах за разработване *някой_ден_като_си_нямам_работа* са осъществени там.. което от една страна ме натъжава, но пък е нормално за интересните идеи някой вече да се е погрижил, хехе '>

Обаче все пак има някои *фундаментални* неща които се различават от това, което си мислех да направя, както и тяхната имплементация, която също на моменти ми се вижда малко  неразумна. На първо време мислех за нещо оупънсорс, а не платено. Мислех нещо, съвместимо с IOS CLI  синтаксиса...Микротик са поели по собствен път, в което няма нищо лошо, дано да се наложат '> Признавам, че са постигнали *ГОЛЯМ* напредък и им завиждам благородно. Обаче все пак пичовете разчитат на (бавни) дискови устройства и на странни решения като LinuxBIOS, прехвърляне на прекалено много функционалност в/у userspace, виждам че имат мерак да си разработват и пропрайътъри протоколи, което е нещо *МНОГО_ДРАЗНЕЩО_ПРИЙОМ_НА_ЛАЙНАРИТЕ_ОТ_ЦИЦКО!!!*  Личи си обаче, че това е нещо, върху което работят бройка девелопери и върши работа доволно добре, има си комерсиална организация, сайт, подръжка и т.н.. А това, че си имат и готови хардуерни решения ебаси, как да не им се радва човек...напомнят на coraid и на техните AoE решения, нещо, което радва като идея и е фрий, а и е прекрасна идея за евтин shared storage '> Напомнят също и донякъде за Juniper, не знам защо, сигурно защото и juniper и mikrotik се опитват да продават безплатни неща, пачнати и реформирани в удобен за малоумни админи вариант '>

Ебахти, как искам да беше opensource това чудо на микротик '> Щях да се пробвам да им се включа в проекта (бидейки некадърен програмист пишещ бъглив код, хехе)  '>

Обаче от друга страна това ми ускорява мераците да започна да си правя нещо подобно. Наистина, ще напиша някакъв базов framework, ще го документирам доколкото мога и ще го пусна на sourceforge. Когато евентуално (дай боже) му дойде времето, ще пусна една *реклама* тук...дано да се намерят хора, на които да им се разработва нещо подобно в свободното време, при това с отворен код и безплатно, мисля че от една безплатна оупънсорс алтернатива на цицко джаджите, вървяща при това на евтин хардуер, определено има смисъл...

БТВ гони ме изкушението да им платя на Микротик (доколкото помня $45) и да видя как са модифицирали разни готови решения за техните си цели...разни неща от quagga и netkit-base най-вече....

Иначе уважение към латвийците...заслужават го, но само да не беше платено, мамка им! Нямат право да го продават и да не му разпространяват сорс-а, просто не е честно '>((

Пак, може на повечето хора да им се стори глупаво, вероятно налудничаво, но наистина искам да си направя нещо подобно, отворено решение за "рутерна" ОС, която да има CLI интерфейс, подобен (съвместим с) на тоя на цицко, функционалност, осигурена от ядрото и няколко готови userspace решения (с корекции '>) , максимална стабилност/performance, НИКАКВА зависимост от бавни block devices с механика (освен ако не се налага от тях да се буут-ва,  swapping-a се чудя дали не може да си го спестя), подръжка на (доколкото идеята позволява) благинки като SNMP, remote syslogging, DNS caching, WINS, radius-базирана автентикация, ppp/pptp/pppoe client, надеждна примитивна трафик статистика  - независима от дискови устройства - някои хора знаят какво вади ifconfig за rx/tx bytes при 32-битови архитектури, хех, честитка на 4-тия гигабайт '> ), справки за CPU/memory утилицация, подръжка на широк спектър архитектури, протоколи и хардуер (inherited от възможностите на ядрото, хехе), възможно най-голямо приемливо  разчистване от ненужни байнърита, библиотеки, глупости в ядрото и т.н....

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

Иначе по отношение точно на този проект, който се дискутираше тук...той е уеб-базирана администрация на малко/средно ISP, моята цел не е точно това, но пък би било интересно да се интегрират и уеб-възможности, въпросът е обаче че един уеб-сървър и PHP би поставило на сериозни изпитания тази идиотска идея (голям image (може и да не се събере на USB drive), нуждата от mysql база - съответно някакъв block device който да се ползва от mysql съръра за съхранение на данните - не мога да си го позволя!, доста shared libraries, съответно по-малко свободна памет щото се mmap-ват библиотечките и файловете с някои по-малки таблици, доколкото знам - без swap, както аз си го мисля, може да стане грозно и т.н и т.н...)

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

И да не ме помислите за луд ся...изказвам си петъчните идеи, обаче съм съвсем сериозен '> Наистина никак не мисля че е лоша идея, което е странното, дори в нормалното  *работно* време ми се вижда доста добро хрумване...обаче няма да мога сам да се спрявя и всякаква помощ за бъдеще ще е много добре оценена, наистина. Очаквайте скоро more details '>

[VladSun]

В допълнение към твоя коментар за Микротик - в момента имам две машини за wireless комуникация. Всяка една е с Микротик, като всичко е инсталирано върху едно 64МБ Flash IDE '>
Няма механика ! '> ( като си помисля, колко пъти са ми забивали сърверите заради скапани хардове '> )

ПС: Още една добавка - една Linux Router OS, би трябвало да се почне от Linux from Scratch '>. А за това определно нямам време '>

[Hapkoc]

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

Принципно няма проблем да се хване кода на едно приложение и да се модифицира за собствени нужди, НО какво ще се случи при излизане на нова версия на съответния софтуер? Ок, ако в новата версия са сложени няколко дребни bugfix-а не е проблем, но при по сериозни промени (добавена нова функционалност, която налага промени по голяма част от кода) merge-ването на кода ще е доста тежка задача. Може да се окаже по-лесно да се реализира новата функционалност спрямо модифицирания код на приложението, което обаче изисква да имаш познанията, които имат и създателите на съотвения софтуер.

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


Другата ми забележка е относно Cisco-подобния CLI. Аз лично никак не одобрявам подобни решения. Създаването на такава система просто предоставя поредния интерфейс, с който администраторите трябва да се научат да работят. Няма значение колко интуитивен и лесен за научаване е направен, със сигурност ще си има особености, които трябва да се научат от съответния потребител, за да може да работи нормално със системата.


Както и да е, не съм аз човека (а и никой друг не е), който може да ти каже "недей да се захващаш с това". Ако си си наумил да го правиш - действай, само гледай да го почнеш скоро и да нахвърляш по-голяма част от нещата сравнително бързо, понеже от опит знам, че всеки проект се започва с голям ентусиазъм, но много често ентусиазма бързо бързо угасва и проекта малко по малко умира. :)

Поздрави.

Няма нищо лошо човек да има идеи. И аз имам много, ама наистина много. Моята цел е това което правя <опитвам се> е този "проект" да може да се ползва от хора, с по-малко опит /като мен/. "Нормален" човек като види конзола и направо му натръхва косата.  '>

Hapkoc ами наистина е доста обемно, дам '> Обаче може и да се навие някой да се включи...на sf.net да речем.

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

Значи на първо време мисля да се хвана да пиша един шит за командния ред, с libreadline, който съответно ще си има няколкото "режима" - потребителски, административен ("enable"), и config-mode със съответните там подрежими (конфигуриране на интерфейс/рутинг/етц/етц). Този шит мисля спокойно може да замени /bin/login  '>

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

Съвкупността от тези функции условно казано да речем ще се нарича  "engine" или "интерпретатор" или каквото там страшно име му дадем '>

Най-големият зор според мен ще бъде точно този engine, който хваща въведената CLI команда и маже темплейти по конфигурациите, вика съответните binaries, парсва им output-a и накрая връща на потребителя някакъв резултат.

Пример - да речем че съм в режим "конфигурация" и въвеждам команда за добавяне на нов статичен маршрут (ip route add x.x.x.x 255.255.255.0 y.y.y.y). Викам engine-a, parse-вам командния ред, съответно той е валиден=> превръщаме маската 255.255.255.0 в CIDR-такава (/24), викаме route add -net x.x.x.x/24 gw y.y.y.y и ако не върне грешка всичко е 6, ако върне - виждаме ква е грешката и изписваме каквото трябва.

Вероятно това "интерпретиране" на командния ред в някои случаи ще се окаже доста брутална задача с оглед просто на това, че при IOS нещата са организирани доста различно. Примерно като се стигне до access list-ите и тяхното превръщане в iptables правила ще настане огромно мазало и честно казано наистина нямам идея как ще се реши успешно проблема, което не му пречи да се пробвам де '> Дори нищо да не излезе ще се радвам че съм си блъскал главата '>

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

Лошото е че някои от тия неща трябва да се пипнат, за да им се подава удобно input-а или да върши в случая по-добра работа...примерно quagga, малко е тъпо да отварям tcp socket, да се автентицирам и да пращам командата по него, след като мога да речем през някъв pipe, прескачайки авторизацията,по-лесно е, по-бързо е и се избягват странни случки като примерно "филтрирах си 2604/tcp и сега мистериозно не мога да си настроя OSPF, wtf?!?"

Отделно (дай боже) някой ден всичко това е готово...ще трябва да има бая bug/security тестване, писане на някакъв там manual (ОТВРАТ!'> и т.н... та наистина тази цялата идея никак ама никак не е лесна за реализация.

Чудя се обаче наистина толкова ли е важно да се следва IOS синтаксиса при положение че това ОПРЕДЕЛЕНО ще доведе до доста усложнения...но пък в противен случай ще направя някакъв там интерфейс, който едва ли някой ще тръгне да изучава ей така щото си няма друга работа...абе не знам. В микротик гледам си имат собствен синтаксис, който са документирали доволно добре, имат си и някакъв уиндоуски клиент с който администрират тва животно...измислянето на някакъв такъв "административен" протокол и писането на уиндоуски клиент определено не ми е по силите '>

През web интерфейс иначе го няма този проблем...ама да пускам apache,php,mysql, колко мегабайта отгоре е това и колко ще товари железото, не е приемливо според мен...+което съм много скаран с прилично изглеждащите пхп-та '> PHP девелопер никога няма да излезе от мене (не че C ще излезе някога де '> )

[Hapkoc]

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

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

Другото ако идеята на уеба е през него да става конфигурирането на системата не виждам за какво точно ще ти трябва MySQL. CGI на Perl, sh или дори на C биха свършили работата, а може да се подбере сравнително лек HTTP сървър, не е казано че трябва да е Apache с 80 модула накачени.

Това е от мен засега.

[Hapkoc]

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

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

[smelkomar]

http://www.freesco.net/index.php
http://m0n0.ch/wall/
http://www.pfsense.com/index.php?id=1

Да не са тези проекти? Последният го ползвам и е много стабилно

[Hapkoc]

smelkomar, не само тези. Има още поне 10 дистрибуции на Linux и *BSD създадени с цел лесно инсталиране и конфигуриране на маршрутизатори.

perl/php - не, защото са много обемни. От perl не разбирам, обаче php e динамично линкнато със сума ти библиотеки, проблемът не е толкова че е бавно, а че взема много памет - съответно ще имаме по-малко свободна РАМ, както и по-голям image на "дистрибуцията". Shell scripts не дават достатъчно функционалност- като се стигне до парсване на стрингове ще се почне със sed/awk примерно и ше стане една мамма-миа. Сега да речем че се спра на варианта със cgis написани на C, веднага ми се набиват няколко проблема на очи:

- Сигурност. Уеб сървъра няма да работи като root. Всякакви опити скриптовете да работят с uid/euid=0 според мене са глупави и тъпи начинания поради ред причини. sh скриптове с sudo също не ми се вижда добра идея. Може да се избегне ако един демон, работещ като root  върви отзад и събира информацията подадена му от скриптовете и маже, обаче възниква проблема че трябва да е написан прекрасно - и най-малките там memory leaks след продължителна работа ще са кофти нещо. Ако вземе да segafault-не вероятно няма да има механизъм да го вдигнем отново - ще се налага рестарт '>

Другото което е че трафика не е криптиран и не знам да има тънък уебсървър с SSL подръжка. Това вече наистина е сериозен проблем според мен. Администрация през http и администрация през telnet са две еднакво-тъпи идеи според мене '>

- Трудно за реализиране: няма (и трябва аз да си ги реализирам) сесии, няма варианти наготово за ъплоудване на файлове (ако реша да му качвам готови конфигурации кво да правя?!?), трябва да се внимава за ред неща, които php ми дава наготово - разни memory limits, execution time limits, няма да е добре ако по някаква причина извикания скрипт не си приключи изпълнението като хората - ще си кисне процеса докато поради някаква причина там това се рестартира.
Генериране на прилични хтмл-и : не ми се отдава никак '>

- performance : дори с много лек уебсървър с CGI подръжка пак винаги ще бъде по-бавно.

Мисля има леко неразбиране, свързано с целите де...аз не искам да правя лесна-за-настройване "рутерна" дистрибуция, а такава, която е максимално бърза и стабилна и лесна за употреба от мрежари дето си нямат идея от линукс.

 "лесна-за-настройване-рутерна-дистрибуция" е малко странна идея - странно е как един човек дето си няма идея от tcp/ip, рутинг протоколи, NAT и т.н. ще тръгне да си прави рутер, хммм.

Наркос, ти обаче ме замисли за цицко и патентите им...не ми се вярва да са си патентовали CLI интерфейса, но знае ли човек.

Те в zebra/quagga доста го копират всъщност, но няма дела доколкото знам...еее там се настройват единствено разни шитни за динамично рутиране де... абе не знам..

[Hapkoc]

Под "лесна за настройване рутер дистрибуция" разбирам да може да се настрой от човек, който знае какво е IP адрес, DNS, default gateway и ping. Има варианти, в които такъв човек може без проблем да въведе нужните настройки през някакъв интерфейс, останалото да се свърши от системата. Имам предвид, да няма нужда човек да разбира от iptables, tc, да знае къде е resolv.conf и какво се пише вътре и т.н.

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

А на тебе вече какви са ти плановете и какво искаш да направиш ти си знаеш.