Category Archives: sadmin

sadmin

Спиране на fork bomb

Ето един пример как да спрете потенциална fork бомба

Редактиране на /etc/security/limits.conf :

vi /etc/security/limits.conf

ribok hard nproc 300
@mishka hard nproc 50
@buba soft nproc 100
@dhstudio hard nproc 200

След като се редактира и записа файла ще пуснем бомбата в bash (Bourne Again SHell):

:(){ :|:& };:

Ако всичко е наред реално няма да се случи нищо лошо 🙂 , но ако не е машината ще се overload и дори има вероятност да не е възможна ssh връзка.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Проблем с mod_deflate и IE

Здравейте. За компресиране в apache 2, използвам Mod_deflate. Всичко си работеше нормално (доста месеци) докато един приятел(Ангел Марев)  не ми репортна за странна грешка в сайт които разработва на машината . Проблема беше в това, че като отвориш страницата под IE понякога(след няколко обновявания(f5,ctrl +f5)) ти извежда празна страница или страница с кодирана информация (като да отвориш rar през apache без mime). Отначало си помислих, че е от страницата която прави, но той се занимава от много време с това и едвали щеше да е от това проблема. В момента пиша един проект на които се случват същите "странни неща". В този проект използвам FCKEDITOR и проблема е , че веднъж ми го зарежда, веднъж не ми го зарежда. Тогава реших да махна mod_deflate и да пробвам да видя дали няма да се оправи. Е оправи се. Тъй като бях направил mod_deflate по подразбиране да се зарежда за всички виртуални хостове, сега го направих по подразбиране да не се зарежда, а да се зарежда индивидуално за всеки виртуален хост. Така се реши проблема със сайта на моя приятел и моя проект които пиша в момента.

PS: С Firefox и Опера всичко е наред. Правилата които съм добавил в mod_deflate смятам, че също са правилни, но може да се пипнат още малко.Byt the way решение беше също да не архивирам js файлове(това беше решението за моя проект), но реших да не прилагам лесното решение,а всичко да си разделено за всеки vhost.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Downgrade na Debian 4.0

Днес на една машина се наложи да направя downgrade и реших да напиша малка публикация.

Случвало ли ви се е да инсталирате пакети от testing или Unstable които да ви оплескат системата. В някои случай е възможно и друго решение, но в този случай ще предложа друго решение а именно, downgradе(даунгрейд) до stable.  …

Цялата статия може да бъде прочетена тук: kakvo.org- Интернет речник

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Компилиране на ffmpeg и vlc

Написах една малка публикация за компилиране на ffmpeg и vlc под Debian 4.0. Публикацията може да бъде намерена в сайта на какво.орг (раздел "статии") или ТУК
Надявам се, статията да бъде полезна. Успех!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

www.kakvo.org-голямо мрежово натоварване

Днес проверявам статистиката за мрежовото натоварване и направо щях да падна :). Доиде моментът в които ще активирам 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-> ЛИНК

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Изпълнение на команда при затваряне на PuTTY 0.60

Днес ми се случи една интересна случка с 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- ТУК

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Оптимизиране на mysql таблицата на kakvo.org

Вчера посещенията на 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.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Кратък стих :) за оптимизиране на apache2

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

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

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Конвертиране на mysql таблица от MyISAM към InnoDB

Днес реших да прехвърля една база от 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 🙂

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

Suhosin и максимален брой $_POST променливи

Днес ми се наложи в една html форма да сложа 500 $_POST променливи(input полета и форма с method='post')  и да ги събмитна(изпратя|submit). Обаче когато ги изпратя не се случваше нищо. Странно. Започнах да изследвам проблема и установих, че ако $_POST променливите(input полетата) са 199 ги изпраща към Apache и си работи напълно коректно, обаче когато са повече от 199 не иска да ги изпрати. След 168 часа(шегувам се) се сетих, че имам инсталиран Suhosin и от него може да се ограничава именно броя на $_POST променливите. Редактирах конфигурационния файл на suhosin (или php.ini зависи как е конфигурирано)  да пуска 2000 $_POST променливи и всичко се нареди както перфектно нареждане на Рубик.

/etc/php5/apache2/conf.d/suhosin.ini
# configuration for php suhosin module
extension=suhosin.so
suhosin.post.max_vars = 2000
suhosin.request.max_vars = 2000

cat interesno.php
<?php
$max_input=198; //Работи със стойностите по подразбиране в Suhosin
#$max_input=298; //Работи с НОВИТЕ стойности  в Suhosin
if (!($_POST['submit']))
{
echo "<form action=" method='post'>";
for ($i=0;$i<=$max_input;$i++) { echo "<input type='text' value='$i' name='dhstudio$i'><br>"; };
echo "<input type='submit' name='submit' value='ribka'></form>";
}
else
{
foreach ( $_POST as $key => $value ) {  print $key . " " . "=" . " " . $value;  print "<br>"; }
};
?>
Хей за хората които не ползват Suhosin или ползват най- обикновен Apache(нямам впредвид буквално най- обикновен) с php няма да го имат този проблем т.е. могат да добавят много голям брой $_POST заявки.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)