by ·2 Comments
Packet Tracer

Image via Wikipedia

Днес ми се наложи да демонстрирам една симулация през Cisco Packet Tracer на машина на която не беше инсталиран. В общи линии малоумщината е, че стимулатора на Cisco е за x86 машини а при мен машината беше x64. При опит за инсталация умира с грозното съобщение

Attempting to install package now
dpkg: error processing PacketTracer-5.3_3.i386.deb (–install):
package architecture (i386) does not match system (amd64)
Errors were encountered while processing:
PacketTracer-5.3_3.i386.deb

Общо взето всичко е очевидно Debian-ския пакет не иска да се инсталира защото е за друга архитектура. От тук нататък проблема е ясен dpkg + форсирано инсталиране за да байпаснем грешката за различна платформа. Bin-ския файл на инсталатора реално е само разархивиращ се архив който се разархивира в /tmp/selfextract.XXXXX папка където XXXXX е произволен низ. В тази директория се намира .deb файлът на Packet Tracer-a. Инсталацията се извършва с командата

dpkg -i --force-all /tmp/selfextract.XXXXX/PacketTracer-5.3_3.i386.deb

Естествено с root права.

Related articles
Enhanced by Zemanta

by ·2 Comments
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 не струва.

Related articles
Enhanced by Zemanta

by ·2 Comments

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

#!/bin/bash -x
wget http://checkip.dyndns.org/ -O /tmp/ipaddr
IPADDR=$(cat /tmp/ipaddr | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>')
IPADDROLD=$(cat /tmp/ipaddr_old | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>')

if [ "$IPADDR" != "$IPADDROLD"  -a "$IPADDR" != "" ]
then
 sed -i "s/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/$IPADDR/" /etc/bind/neo2shyalien.eu
 /etc/init.d/bind9 restart
 echo "server localhost" > /tmp/nsupdate
 echo "zone neo2shyalien.eu" >> /tmp/nsupdate
 echo "update delete ns.neo2shyalien.eu. A" >> /tmp/nsupdate
 echo "update delete ns.neo2shyalien.eu. CNAME" >> /tmp/nsupdate
 echo "update add ns.neo2shyalien.eu. 38400 A $IPADDR" >> /tmp/nsupdate
 echo "update add *.neo2shyalien.eu. 38400 CNAME ns.neo2shyalien.eu." >> /tmp/nsupdate
 echo "show" >> /tmp/nsupdate
 echo "send" >> /tmp/nsupdate
 echo "" >> /tmp/nsupdate
 /usr/bin/nsupdate -k /etc/Kns.neo2shyalien.eu.+157+59417.private -d /tmp/nsupdate
 mv /tmp/ipaddr /tmp/ipaddr_old
fi

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

if [ "$IPADDR" != "$IPADDROLD"  -a "$IPADDR" != "" ]

Преди беше


if [ "$IPADDR" != "$IPADDROLD"]

Така самия ред прави следното взима 2-та IP адреса и ги сверява ако са еднакви пропуска ако са различни ъпдейтва. В предния вариант бях пропуснал много важна грешка поради някаква причина скрипта ми беше решил че имам IP = „“ (нищо) и пренаписало конфигурацията на bind-а ми с празно поле и при следващата смяна вече не може да пренапише правилно конфигурацията което води липса на връзка с nameservr-a. Малоумно нали 😉

by ·0 Comments

Днес phpmyadmin-a ми изтрещя без никаква видима причина с следната груба грешка

Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.

Общо взето проблема е елементарен променливата session.save path в php.ini фаила беше без стоиност. Мистиката се развърза като се сетих че направих упгреид на на php версията ми и тогава вероятно по невнимание съм замал старите настроики, а днес рестартирах сървъра, че беше почнал да пълни swap-a заради едно зомби 🙂

by ·0 Comments

Преди известно време ми се беше случило като се опитвах да си качвам фаилове на сървъра през sftp да не успея а предишния ден бях качвал. Днес един прител ми писа, че има същия проблем и се сетих, че исках да го опиша 😆 И така проблема супер кретенски декларация в /etc/ssh/sshd_config и по точно се налага да изтрием реда със съдържание

Subsystem sftp /usr/lib/openssh/sftp-server

И на негово място добавяме

Subsystem sftp internal-sftp

Рестартираме си ssh сървъра и всичко е на мястото си 🙂