Мартин Петров Blog

Днес един от клиентите се оплака, че антивирусната му NOD съообщавала, че някакъв клиент 1.2.3.4 му правил "харески атаки". Разгледах го този пич и какво да видя пича заразен с Flicker- едно червейче което ползва MS08-67. или port 445. Червейчето придобива shell access (прави каквото си пожеле или каквито са му инструкциите) до машината ви т.е. Внимавайте . Това е стара пролука от миналата година(за първи път е съобщена преди доста повече време, но няма значение), но явно все още има хора които не си ъпдейтват машините.(btw ограничил съм на повечето клиенти 445,135,139 и други, но на тези клиенти не бях и веднага проблеми ех съдба ).

За хората с Windows XP да си ъпдейтнат машината: WindowsXP-KB958644-x86-ENU и ако искат да си пуснат защитните стени  (Важно да си ги конфигурират правилно) да блокират портове: 135,139,445

Извод: Ако клиентите Ви не полазват Sharing services слагайте ключа на врати с номера: 445,139,135 .

Днес проверявам статистиката за мрежовото натоварване и направо щях да падна . Доиде моментът в които ще активирам mod_deflate (модул на Apache за компресиране на съдържанието). Междо другото интересен факт е, че почти всички големи сайтове в България и по Света ползват mod_deflate.
След като го активирах за 30 секунди (Благодарности на Hipo) сега резултата е следния:

http://www.kakvo.org is gzipped
Original Size: 15 KB
Gzipped Size: 4 KB
Data Savings: 73.33%

На този етап ще пожертвам използваните процесорна мощ и памет за по- бързо зареждане на kakvo.org от потребителите и спестяване на мрежов трафик.

Пълната и кратка статия се намира в kakvo.org-> ЛИНК

Днес случайно видях статистиката от tyxo на един сайт ТУК и като натиснах на "По дни" или ТУК и познайте изплю грешцица: "Warning: Division by zero in /www/tyxo.bg/www/root/stat/byday.module.do on line 28" ..
По принцип това съобщение се появява когато се дели на 0 или на нищо,  а в случая явно защото за всички изведени дни посещенията и всички резултати са нули.  Според мен tyxo трябва да си оправят грешката понеже не всеки има по нула посещения на ден.
Шеговит извод: Ако използвате tyxo като броят, старайте се да имате повече от едно посещение на ден за да не виждате това:
Warning: Division by zero in /www/tyxo.bg/www/root/stat/byday.module.do on line 28
Warning: Division by zero in /www/tyxo.bg/www/root/stat/byday.module.do on line 29
Warning: Division by zero in /www/tyxo.bg/www/root/stat/byday.module.do on line 28
Warning: Division by zero in /www/tyxo.bg/www/root/stat/byday.module.do on line 29

PS: Нямам никакви лоши намерения към tyxo, а просто се шегувам. На всеки може да се случи да пропусне да го фиксне това. Човешко е. Имайте търпение предполагам, ще го оправят скоро.

Днес ми се случи една интересна случка с PuTTY 0.60 която за първи път видях преди няколко години.

На една от машините ми се наложи да спра единия интерфейс т.е. може би щеше да ми се наложи и затова се бях приготвил като на най- близката машина на windows отворих putty и просто си приготвих "ifconfig ethX down", но него изпълних. Не го изпълних защото идеята беше бързо да го сваля ако се наложи… Не се наложи и затворих putty, след което веднага получих съобщение че интерфейса е паднал. Проблема беше че, когато напишете някаква команда в PuTTY без да я изпълните и след това затворите PuTTY тази команда се изпълнява.

Пример: Отворете PuTTY и напишете 'echo "dzak" > /tmp/puttydzak.txt' и сега затворете PuTTY от Close. След това влезте отново в машината и ще видите, че /tmp/puttydzak.txt е там

Извод: Преди да затворите PuTTY (говоря за Close) изтрийте командата ако има такава и след това го затворете другия вариант е "exit" .

За да изтеглите PuTTY, моля натиснете ТУК за да бъдете пренасочени към официалния сайт на PuTTY за download- ТУК

Днес на моя началник в компанията в която работя му се наложи да копира файл 6 GB на флашка 8 GB обаче не успя . Като ми каза се сетих, че файловете системи най- вероятни са различни т.е.  на флашките по подразбиране е FAT32, а на неговата система- Windows XP най- често хората слагат NTFS. Разцъках и видях, че на флашката може да се променя файловата система. Промених я и всичко се оправи. Единственото неудобствно е, че сега когато се извършва някакво действие с флашката трябва да бъде премахната ръчно чрез "safely remove hardware", а не както преди да става напълно автоматично (слагаш, вадиш и това е ) .
Забелязах, че на български не видях добро обяснение на проблема и неговото решение и реших да напиша една малка публикация с доста снимки (снимките са от google.bg). Публикацията може да бъде намерена в kakvo.org: http://www.kakvo.org/statia/4/flashka-s-fajlova-sistema-ntfs

Надявам се статията да бъде полезна

Вчера посещенията на kakvo.org  надхвърлиха 11 000 и машината клекна. Клекна до толкова, че mysqld и apache2 заеха 100% и дори не можеш да се логнеш в машината нормално, а след известно време(20 сек.). За целта първата и най- основна част от решаването на този проблем е оптимизирането на mysql и apache2. След няколко огледа и мъки в натоварената машина забелязах, че полетата за "превод от" и "превод на" са тип "text" и не са индекси. В този случай когато се търси конкретен превод със заявка "… where превод от='търсен превод' " отнема 1.2 сек. и сериозно натоварва машината. Мислех 100 часа и реших да добавя едно поле "превод_md5" char(32) в което да пиша md5 на "превод от" и което ще бъде index. По този начин когато се търси превод не се изпълнява старата заявка където се търси самият превод, а новата в която се търси md5 на превода. Благодарение на уникалните и индексирани md5 хешове на таблицата, заявките се оптимизираха до заветните 00.00 сек. за изпълнение, а употребата на MySQL падна до 10%. Сега машината е във война с племето на Apache, но пък за сметка на това е в съюз със ордена на MySQL. Започвам да мисля още 100 часа как да подобря дипломатическите отношения на машината с племето на Apache.

Наложи ми се днес да оптимизирам една машинка, че доста се понатовари. Ето примерни стойности:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
StartServers 10
MinSpareServers 10
MaxSpareServers 15
MaxClients 200
MaxRequestsPerChild 1000

С новите стойности от 20% cpu падна на 3%.

Днес реших да прехвърля една база от MyISAM в InnoDB и при прехвърляното получих следната грешка:
mysql> alter table pcdict_words ENGINE = InnoDB;
ERROR 1214 (HY000): The used table type doesn't support FULLTEXT indexes

Това се получава защото в таблицата имам няколко индекса "Fulltext". Преди да прехвърлим
към InnoDB трябва да видим които са Fulltext индексите и да ги премахнем. За да видим индексите се изпълнява
следната команда:
mysql> SHOW CREATE TABLE pcdict_words\G
*************************** 1. row ***************************
Table: pcdict_words
Create Table: CREATE TABLE `pcdict_words` (
…
FULLTEXT KEY `worde` (`a`),
FULLTEXT KEY `description` (`d`),
…
) ENGINE=MyISAM AUTO_INCREMENT=3217 DEFAULT CHARSET=cp1251
1 row in set (0.00 sec)

Сега ще премахнем двата индекса Fulltext със следните команди:
alter table pcdict_words drop index `word`;
alter table pcdict_words drop index `description`;

Сега отново конвертираме от MyIsam към InnoDB :
mysql> alter table pcdict_words ENGINE = InnoDB;
Query OK, 3203 rows affected (0.54 sec)
Records: 3203  Duplicates: 0  Warnings: 0

Voila