by ·0 Comments

От известно време бях забелязал че е спрял да ми работи gnome shell weather extension-a ми. В общи линии мрънкаше че не бил актуална версия за моята версия на Gnome Shell. Странно защото го обнових като ми се обнови версията на gnome shell. След това го зарязах, защото не  е болка за умира и още по малко имам време да се ровя в такива дребни грешки. Но днес прецених че е крайно време да прекратя това и да си оправя чудесията. Обнових git tree-a до последна версия, инсталирах на ново – никаква промяна. WTF. След това му ударих един make uninstall и се появи нещо шокиращо, добавката все още беше деактивирана като не обновена, а я бях деинсталирал. Общо взето в този момент предположих че го има инсталиран и в някоя друга папка за extensions и затова прави сечено. От тук нататък нещата се развиват в следния сценарии. Намиране на името на добавката, намиране на добавката и премахване. Взимането на имената на инсталиранете добавки в gnome shell ства със следната команда


gsettings get org.gnome.shell enabled-extensions

От чиито изход разбрах, че имам активирана добавка с името [email protected]. Забавно. Приятното е в случая това е името на папката на добавката и лесно може да се локира местоположението и с командата


find / -name '[email protected]'

Тук нещата вече станаха лесни. От изхода на find-a разбрах, че го има в 2 папаки. Един бърз rm -rf на 2-те папаки и всичко си дойде на местата. Една бърза инсталация на добавката и рестарт на gnome shell.

Enhanced by Zemanta

by ·0 Comments

Преди няколко дни излезе 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

by ·0 Comments

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

by ·0 Comments

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

by ·0 Comments

Преди няколко дни забелязах че мясото в / (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