Tux, as originally drawn by Larry Ewing

Image via Wikipedia

Днес мисля малко да по размишлявам върху това извращение на природата CentOS. Вдъхновен от наскоро излязлата CentOS 6-та версия имам какво и аз да кажа. Само по себе си тая глупост е разработка RedHat и е сървърен форк на тяхната Red Had Enterprise Linux. Използва rpm пакетния им менаджер (които е ужасно велик, да ама не).

Нека да започна с това което ме накара да започна да пиша и да размишлявам що за изрод е това CentOS и има ли почва в моите сървъри. Преди около седмица излезе верися 6 и реших да ъпдейтна настоящата ми 5.6 инсталация на VPS хостинга ни. Бях доста неприятно изненадан като видях, че не ми отчете пакети ъпдейт. Реших, че нещо аз бъркам и проверих в Интернет. Бях шокиран като видях препоръката на производителя е да се прави чиста инсталация и дистрибутививен ъпгрейд от 5.6 не е препоръчителен и се прави с кила черни магии и затова не е възможно по стандартен начин. Хммм доста интересен момент. 😆 И това се води enterprise дистрибуция, много интересно. Не виждам как може дори да се класира в тази категория освен, че производителя и сложил това гръмко наименование. Да приемем следните 2 сценария – единия е правим нов инстал другия е не правим.

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

2. Сценарии – Не правим дистрибутивен ъпгрейд системата си седи така докато се пускат кръпки по сигурноста. Докато в един момент не и се прекрати подръжката след известно време бива хакната заради пробойна в някоя от услугите които предлага, заради невъзможноста да си да осигурява диструбутивно надграждане. Крадат се данни или просто само се компроментира сървъра – отновно солени глоби или си губиш работата.

Доста интересно и двата сценария завършват доста неприятно за системния им администратор заради капитална греша в дизайна на дистрибуцията подбора и  мързела на компанията която я разработва за да не осигури съвместимост между пакетите. Докато от друга страна има не чак толкова enterprise дистрибуции които се надграждат тихо и кротко, без да носят гръмки имена. Имам Debian сървър които е от версия 3 надграден до актуаланта версия 6 в момента сиреч преживял е 3 големи надграждания като не е имало отказ до достъпа на услугите. По принцип единия от основните принцип на админа е – „Ако работи не се пипа“ но затова хората откриват дупки пускат кръпки затова излизат нови пакети да подобряват стабилността или да ускоряват производителността. В заключение освен мое лично мнение но и мнение на много мои приятели къде по добри админи от мен е CenOS не струва.

Enhanced by Zemanta

BackTrack 5 беше издаден на 10-ти май. За първи път се появи официална версия с Gnome вероятно натискът на обществото си каза думата 🙂 и поради точно си този факт реших да го инсталирам на моето EEE 1000H. Все пак Gnome ми е любимата графична среда 😉 . Пак както 4-та версия отново и настоящата е базирана на Ubuntu 10.04LTS. Което според мен не недостатък да речем все пак целевата група са ламави хахори 😀 . Както обикнове основен мрежови мениджър е wicd, които по принцип е доста приятен поне според мен е предпочитан ( когато ми е нужен 😉 ), но на eee-то ми прави бъг че не може да се закача към некриптирани безжични мрежи. Доста неприятно определено, с нормалния си мрежови менажер на Gnome този проблем отсъства. Вече ситуацията е ясна имам проблем имам и решението му.

Общо взето няма да наблягам на инсталцията и премахването а на основния подводен камък които ще се случи. Иначе предишните 2 операции по стандартния начин с apt-get или през synaptic  както ви е най комфортно. Така споменах за подводен камък и тои е следния заради съдържанието в /etc/network/interfaces network-manager-a не може да инициализира мрежовите ви адаптери. Необходимо е да за коментирате всичко излишно, включително настройките с IP адреси. След като изчистих съдържанието на моя се получи нещо такова

auto loe th0 wlan0
allow-hotplug wlan0
allow-hotplug eth0

По този начин се решава проблема с не работещия network manager.

Enhanced by Zemanta

Миналата неделя ми беше модулния изпит за втория ми семестър на Cisco академията върху Routing Protocols and Concepts. Общо взето за разлика от първия семестър този път съм доволен от резултата на изпита извадих 98% което ще рече от 50 въпроса 49 верни. Резултата не е чак толкова изненадващ понеже все пак разбирането на routing-a и протоколите около него е част от работата ми, вярно не съм работил с динамични routing протоколи като OSPF IS-IS или EIGRP но пък поне статичния routing и самите таблици са ми ясни както и самите мтрики в тях. Резултата както бях отбелязал и в предишния final exam не е определящ за сертифицирането но е вид надъхване за следващия семестър. С по голямо самочувствие да се заходи към материята.

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

Засега остава да се наслаждам на моя момент на малка слава (както каза една приятелка) 😀 все пак резултата не е от най ниските 😉

При мен интернета ми се рутира от домашно рутерче D-Link DIR-600 което на което съм инсталирал DD-WRT . Общо взето никак не лош маршрутизатор подържа относително добър максимум стабилна работа и N wi-fi стандарт. Отделно DD-WRT софтуера ми дава голяма свобода на настройки и вуду магии.

Зад него в локалната ми мрежа е сървъра на които се хоства скромния ми блог. Общо взето драмите се получават от факта, че когато се изпрати запитване към dns-a отговаря публичното ми IP на което съм направил forwarding към хоста на блог-а ми и когато заявката от вътрешната мрежа не е необходимо да се обръщам към публичния си адреса. Решението на проблема се оказа повече от елементарен трябва да се направи запис в /etc/hosts файлът в които да се посочи domain-a и IP адреса. Това става посредством следните 2 команди

echo '192.168.1.2 host.com' >> /etc/hosts
killall -HUP dnsmasq

Тях ги слагате като startup script в administration ->commands часта. След това си рестартирате рутера или дайте run на командата за да се изпълни и сте готови вече хоста коиот сте описали от вътрешната ви мрежа ще бъде видим с локалния ви адрес.

Вчера ми пристигна 1650mHa батерия за HTC Kaiser-a ми, което е с 300mHa повече от оригиналната 😎 . Понеже ползвам телефон които е non native Android се налга да се направят няколко магии за да отчита правилно батерията в %-ти. Единия по лесния вариант е ако ползвате стандартен kernel си го едитвате с Atools като задавате новата стойност за mHa на батерията флашвате с новото NBH и дерзаете. Другия вариант е да ползвате нестандартно ядро което не се поддава на atools обработка и да направите грозена кръпка на създалия се проблем.

Първо нека да разясним малко теория и след това да пристъпим към кръпката. Когато правите промени по ядрото си с atools вие правите фини настройки на система в /sys/module/ и след това според зависи за вашия хардуер. При мен важния файл който отговаря за настройката на батерията се намира в /sys/module/board_kaiser_battery/parameters/battery_capacity. В него се съдържа колко единици е количеството на вашата батерия и на база на цифрата вътре се изчислява на колко % е вашата батерия в момента. Казвам единици защото не се пише чисто число в mHa а се изчислява на база на формулата

mHa*1.6=единици

В моя случай това ще рече 1650*1,6=2640 единици, сиреч това ще ни е съдържанието на файлчето. Речено сторено набързо в конзолата си набивам едно


echo 2640 > /sys/module/board_kaiser_battery/parameters/battery_capacity

Така до тука нещата са кристално ясни какво трябва да се прави, къде и защо. Обаче тука идва и момента за малката подробност, файлът в /sys директорията си занулява съдържанието след всеки рестарт на телефона, което не е много оферта. Затова следващата стъпка е да го сложим горния ред init-a на нашия Android.

Тъй като несъм съм го сложил в init-аискам да изчакам няколко дни преди да го направя. Когато го набия в init-a ще драсна набързо едно дребно how to 🙂