Преди няколко дни излезе XAMPP 1.8.0 вчера след надграждане от версия 1.7.7 имах доста интересен проблем. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403

Access forbidden!


New XAMPP security concept:

Access to the requested object is only available from the local network.

This setting can be configured in the file „httpd-xampp.conf“.

Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. WTF ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Require all granted. О да еврика. Това е новия контролен механизъм който влезе в apache 2.4.x. С него се дава достъп или се отказва такъв на всички изискани, в общи линии се имитира Allow/Deny функционалността :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. След промените при мен изглежда така

<Directory „/opt/lampp/phpmyadmin“>
AllowOverride AuthConfig Limit
Order allow,deny
Allow from all
Require all granted
</Directory>

 

Вианги може да се пробва и друга дивоти, например да се преименува папката phpmyadmin на нещо други и да се направи alias към не. Но е по грозно и не особено смислено 🙂

p.s Питаха ме защо ползвам XAMPP а не чиста инсталация на всички компоненти както си ги е моя Debian родил – отговорът е много много прост – МЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉

Enhanced by Zemanta

A shell script wants your job

Днес докато работех видях че една от машините лагна много жестоко. Влизам в нея гледам един cron наблъскал адски много зомби процеси (грубо около 50-60). Нямаше как да ги убия всички с killall затова се наложи да направя малко по грамотно решение на проблема – да драсна едно елементарно bash скриптче което да намери и убие процесите. 50-тина PID-а не се пишат лесно на ръка :D. Скрипта го надрасках за минута и е свръх елементарен но все пак заслужава внимание 🙂

В основата му седи конвейера

ps ax | grep -v grep | grep process_name | awk '{print $1}')

Тука получаваме лист с всички PID-ове на процеса който трябва да килнем като изключваме grep от този списък. Вече като имаме списъка нещата стават лесни всичко се завърта в един for. Ето го и крайния резултат

#!/bin/bash

PR=$(ps ax | grep -v grep | grep process_name | awk '{print $1}')

for PID in $PR
do
echo "$PID will be killed"
kill -9 $PID
done

Може да се „тунингова“ като името се взима като аргумент след името на скрипта и по този начин се вика като изпълнимо binary. Обаче не е много добра практика да има много такива чести случаи 😀 Но никога не пречи да сме предпазени от всякакви шитни

Enhanced by Zemanta

Image representing MySQL as depicted in CrunchBase

Преди известно време бях писал за MySQL Full Text Search 🙂 Днес имах много интересно преживяване с една заявка. В общи линии заявката търси за резултати който липсват друга таблица. Един основне Select и един sub select в WHERE частта на заявката. В общи линии скелета и е

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

В общи линии елементарна заявка. Написах я за 30 сек пускам я и зацикли машината. След дълго и търпеливо чакане от моя страна или по точно ~43 сек . Ми се изплю резултат lol . Пффф лудница. Влизам в машината гледам процесора е нормално натоварен почти в idle състояние. Шок и ужас. Пускам пак заявката пак същия резултат. Fuck WTF. Пускам explain на заявката и всичко лъсна – второто поле secondTextField е само full text search без index, а там табличката е скромна от около 35к реда. Кой да чете – full text search не е индекс. Вече е ясен проблема набързо едно

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

И нещата си дойдоха на местата Query took 0.0005 sec 😀

Внимавайте как си слагате индексите от тях ви зависи маргинално скоростта на заявката.

p.s Като цяло аз съм си крив за горната ситуация не само защото липсва индекс ами защото не ползва full text search метода 😀

Enhanced by Zemanta

Преди няколко дни забелязах че мясото в / (root дяла) ми е намаляло кардинално. Прегледах набързо за някакви големи свали файлове но не открих нищо. WTF ??? След това започнах да търся директория с неочаквано по голям размер от очаквания  – такава се оказа home директорията ми. След още по кратко разглеждане на нещата се оказа че ~.Skype/ е директорията която ми яде от HDD-а. Една бърза la -lah веднага показа че най големите файлове ми са от вида chatmsg1024.dbb chatmsg512.dbb и прочие. В дейтали това е историята на вашия skype chat. Общо взето решението е да изтриете само тези файлове така ще се занули историята ви ако подържате таква но все пак искате да запазите историята си за прехвърляните документи да речем. Това става лесно с командата

$ rm -rf chat*

Следната команда изтрива всички файлове започващи с chat. Винаги съществува варианта да се забрани history log-a но при мен това не е решение.

В действителност тези файлове са изключително интересни понеже от тях доста лесно може да се разчете цялата skype история – с кой сте говорили какви файлове сте прехвърляли и какво сте си писали. Но това е тема за някое бъдещо писане.

ps Тези наблюдения са направени върху skype 2.2.35

Enhanced by Zemanta

Днес исках да си инсталирам една игра 😀 но ми трябваха малко Windows библиотеки. Реших да ги попълня с winetricks и когато стартирах скрипта получих следното ведро съобщение –


$ ./winetricks
 ------------------------------------------------------
 wineserver not found!
 ------------------------------------------------------

Доста забавна ситуация и същевременно крайно очевидна. Winetricks не намира wineserver binary файлът.  Общо взето нормално понеже ползвам x64 Debian Linux и пакетите който ползвам не са от официалния източник. Решението е елементарно в 2 стъпки

1. Намираме пътя на wineserver


$ locate wineserver
/usr/lib32/wine-unstable/wineserver
/usr/share/man/de.UTF-8/man1/wineserver.1.gz
/usr/share/man/fr.UTF-8/man1/wineserver.1.gz
/usr/share/man/man1/wineserver.1.gz

И създаваме символична врзка към /usr/local/bin/wineserver където въпросния скрипт търси файлът по подразбиране но в моя случай е /usr/lib32/wine-unstable/wineserver


#ln -s /usr/lib32/wine-unstable/wineserver /usr/local/bin/wineserver