Linux за българи: Форуми

Здравейте,

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

В момента проблемите, които стоят са основно необходимостта от промяна на настройките на DNS сървърите на доставчиците в България. Имаме съгласието на две фирми, но всяка от тях обслужва няколко квартала в София, което е недостатъчно.

Идеята е този вид домейни да стартират сега, за да може пред 2008, когато ICANN стартират със същите домейни, да дадат .бг на нас, тъй като вече ще сме стартирали, а не на някоя американска фирма, която да се разпорежда и да слага цени, каквито иска. (В този ред на мисли е МНОГО ПОГРЕШНО собствеността на .bg да се прехвърли на Affilias, а собствениците на .info домейни с популярни сайтове може да останат много изненадани от догодина).

Идеалният вариант е да се сформира група от хора, с подкрепата на Интернет доставчиците и hosting компаниите и тази група да получи правата върху .бг след старта му в ICANN.

Цените можем да ги определим ние - компанията взима 5$ или 20% на домейн (което е повече). Първата година или първите 6
месеца могат да се дават безплатно, за да се привлекат клиенти.
Можем да си изберем освен .бг, и други TLD, които не се повтарят в Русия -
.биз, .инфо и т.н.
Можем да препродаваме от руснаците и .ком, .нет и .орг (но те вече са
определили цена от 20$ на година)

Въпреки, че те имат 4 главни DNS сървъра, от компанията предпочитат у нас да има 1 машина в slave режим.

Човекът от I-DNS, с който обсъждаме нещата смята, че капиталът, изискван от ICANN ще се събере от първите няколко
хиляди  продажби на .бг домейни, а такива ще има.
**********

Въпросът ми е бихте ли подкрепили подобна инициатива. Това може да стане по няколко начина:
* ако работите в Интернет доставчик, да се опитате да го убедите да направи промяната по DNS сървърите си.
* Да се включите в групата, която да поеме .бг при официалното му стартиране.

Освен с промяна по DNS, .бг домейните могат да се виждат с plugin (само за IE) или с прокси, което обслужва само заявките към .бг (контролирано от proxy.pac скрипт).

Подкрепям идеята !
Имам възможност да обсъдя идеята, и почти съм сигурен, че може фирмата в която работя да съдейства с ресурс.
Други ?

Принципно съм против идеята за IDN, но така или иначе ще се внедри рано или късно, така че май е без значение мнението ми, пък е и малко offtopic.

-- offtopic ---
можеш ли да споделиш как ще се изненадат .info притежателите защото аз съм един от тях и не ми се иска да съм неприятно изненадан. Ако искаш може и на лични.
-- offtopic ---

Благодаря на Тодор Петков, че ме насочи към тази тема, изпълнена с толкова "хумор".

Извинявам се, ама как хора, които понятие си нямат от DNS и пишат в този форум мега глупости по темата, имат наглостта да искат да бъдат регистър на ccTLD БГ.

Аз съм първият, който ще напише писмо до ICANN, защо не бива на тези хора да се дава подобно управление. И причината е до болка ясна и се нарича "АМАТЬОРСТВО".

С интерес прочетох това, което си написал Веселине [Колев], благодаря за наистина задълбочения анализ, но ... завърши зле.
Естествената реакция на всеки читател тук е да приеме, че причисляваш и него към "80% технически инвалиди и пълни идиоти", което е ... как да се изразя ... много грубо.
Много отдавна ученето и работата в СУ не е гаранция за елитарност, особено пък в знанията.

Сигурен съм, че въобще не те интересува мнението ми, но ако примеш един съвсем позитивен съвет, бих ти препоръчал да бъдеш малко по дипломатичен, малко по-скромен и не толкова самоуверен.
Това, което ти пиша е единствено във връзка с offtopic завършека на анализа ти. Иначе съм съгласен с написаното по-горе.

Поздрави!

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

П.П. Blue, ако не се лъжа, преди месец имаше една тема от тебе. Нещо не можеше да пуснеш DNS сървър и да разбереш от къде е опроблема. Много бързо стана администратор  

Бързо се уча.  

И затова поддържам един от сървърите на Cesidian Root.  

Сложих *** на момента, за да си скрия домашното IP.  

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

Според мен защото искат да се откъснат от ICANN. Това лошо ли е?

Цитат

А кой ги е проверил, кой ти е сертифицирал техниката, кой ти е сертифицирал специалистите, това някак си остава неясно. Защото аз лично на такива хора не мога да се доверя.

Най-много у нас да има един slave сървър на I-DNS. И щом смяташ, че не трябва да се докосвам до DNS, има кой да го пусне.  

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

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

Весо, съгласен съм с голяма част от твоята лекция и затова съм склонен да не се заяждам, честно

Има само един спорен момент, не че се заяждам де. ама как да се изразя...мисля че не е особено изяснен.

По-долният цитат имам предвид

Цитат

Това са две или повече машини (възли), които се виждат като една навън. Така, ако някой от възлите отпадне поради технически проблеми, другите поемат натоварването. За целта вътре в автономната система на кореновия сървър се използват динамични протоколи за маршрутизация, които да са "link state" или да се обвързани с работособността на процеса на DNS демона (щом процеса на демона спред да общува със сокета, се спира анонсирането на възела - ако всички възли са неналични, се спира BGP анонса). Ако се изпълнят тези условия, то услугата е на практика непрекъсваема поради локални технически проблеми. Подобна тестова структура беше градена в мрежата на СУ "Климент Охридски" с учебна цел.

Интересна идея за load-balancing на HA услуга. Предполагам имплементацията на link-state динамичния рутинг протокол, нека бъде OSPF, работи доста независимо от named демона, т.е падне ли по някаква причина DNS услугата, заявки идващи отвън ще продължават да бъдат прерутирани до fail-налия node, мм? Ок, да речем че някой напише някакъв скрипт и при падане на named това се отразява и на рутинга (локалната имплементация на динамичният рутинг протокол на всеки node е просто още един потенциален point of failure, но както и да е). Това поставя още няколко проблема, именно:

1) Как zone информацията ще бъде обща за всички машини зад loadbalancer-a във всеки един момент, т.е изисква се някаква консистентност на данните на всички машини. Да речем че проблема се решава с някакъв shared storage и подходящата файлова система (и определено не чрез NFS, поради ред причини).

2) Понятието "сокет" не е правилно използвано в контекста. При умиране на един процес, умират всички сокети асоцирани с него. Да не говорим че няма механизъм по който един процес да разбере друг процес "комуникира" ли през сокетите, които е създал. И това че bind създава един listening сокет не означава, че при всяка нова заявка отвън, accept() не създава по един нов сокет, как мислиш да наглеждаш по всеки един сокет какво минавало (да не говорим и че това са UDP sockets - SOCK_DGRAM - при което "състоянието" им е малко спорна материя)

3) Да речем ъпдейтваш една зона динамично, защото не е практично да променяш zone информацията по сървърите върху техния, както уточнихме, споределен storage, та после да ги рестартираш всичките за да захапят. Стигаме до още един забавен момент. Балансъра ще те реферира dynamic update заявката към един от сървърите и ще го ъпдейт-неш. Обаче това ще си важи за него, не и за останалите. С другите сървъри обаче какво ще правиш? Дори да пуснеш много заявки за ъпдейтване на зоната, как можеш да си сигурен че си ги ъпдейтнал всичките nodes, така че да не се случи при една заявка единия да ти отговори едно, при втора заявка другият да ти отговори друго?

Предполагам си мислил по въпроса, така че ще ми е интересно до какво решение си стигнал

Между другото не знам защо ви е трябвало да си правите такива занимавки в СУ - балансирането чрез някакъв динамичен рутинг протокол е как да кажа...глуповата идея. Най-малкото нямаш никаква сесийност, което прави този метод абсолютно непригоден за балансиране на уеб приложения. Представи си че така балансираш 5 webapp сървъра за един интернет магазин. На всеки 2-3 request ще ходиш на сървър, който няма грам идея за твоята сесия, да речем за това с какъв потребител си се лог-нал и какво има в shopping cart-a ти. И това е само един частен случай, има още сума ти issues свързани с това.

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

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

Мерси за изчерпателният отговор

А мога ли да намеря в Интернет резултата от този "експеримент" в СУ, много ми е интересен