Или “Как от файл пълен с бази данни да извадим точно тази, от която имаме нужда?”
Елементарно Уотсън 
sed -n '/^-- Current Database: `dbname`/,/^-- Current Database: `/p' AllDatabases.sql > mydb.sql
Заменете dbname с името на базата данни, която искате да извадите от архива и “магически” тя ще се озове във файла mydb.sql
1. Сваляме ioncube файловете, отговарящи на нашата конфигурация. Списък с файловете можете да намерите тук
wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz .
2. Разархивираме
tar -xvf ioncube_loaders_lin_x86-64.tar.gz
3. Така получената директория с име ioncube местим на по-подходящо място:
mv ioncube /usr/local/
4. Създаваме файл с описание за ioncibe extension-a
nano /etc/php5/conf.d/ioncube.ini
и в него пишем следният ред:
zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.3.so
5. Рестартираме Apache и сме готови
/etc/init.d/apache2 restart
Аз отивам, а вие?
Както пише на сайта, Leading Speakers Include:
$.fn.preload = function() { this.each(function(){ $('<img/>')[0].src = this; }); } $(['img1.jpg','img2.jpg','img3.jpg']).preload();
For simple JavaScript use:
function preload(arrayOfImages) { $(arrayOfImages).each(function(){ $('<img/>')[0].src = this; }); } preload([ 'img/1.jpg', 'img/2.png', 'img/3.gif' ]);
Елементарно Уотсън!
За целта използваме командата “pdfimages“, но първо трябва да инсталираме това:
apt-get install poppler-utils
Нека нашият PDF файл се казва test.pdf. За да изкараме картинките от него, използваме следната команда:
pdfimages -j test.pdf imgТова ще извади всички картинки от PDF файла като .jpg с префикс “img”. Пример: img-001.jpg, img-002.jpg
Как ми трябваше начин да разделя дългите номера на товарителниците за да са по-читаеми за хората… а всъщност е толкова лесно
Ако и вие искате да разделите дългите си цифри, използвайте str_split
Звучи като приказка, нали? Всъщност е реална история за това как трябваше да открия и да изтрия гаден “вирус” от един сървър.
При поредната проверка на пощата ми, чета писмо от datacenter-a, в който се намира една от машините ми. Там пишеше, че ако до няколко часа не разреша проблема с машината, тя ще бъде спряна. По-долу беше обяснено, че от нея има изключително много изходящи конекции, които flood-ят суича, към който е вързана машината.
И така, започна се…
В началото трябваше да намеря кой точно е процеса, предизвикващ въпросните конекции. Използвах ps auxw за да разгледам процесите, които в момента се изпълняваха на машината. На пръв поглед нямаше нищо необичайно – ftp, mysql, apache, ssh и още купчина други, с които няма да ви губя времето.
Но един от тях ми привлече вниманието, а именно /usr/local/apache2/bin/httpd. Нищо необичайно, нали? Всъщност проблема е, че моето apache се намира в друга директория… Ето и заподозреният
От тук нататък ще използвам прякорът “сивчо” за да не разкривам все пак за кой сайт става въпрос
Забелязах, че въпросният процес се изпълнява с потребител “сивчо“. Това означаваше точно две неща:
1. Машината ми не е root-ната. Тоест, мога да си я използвам без да е наложителна преинсталация.
2. Някой, някак е успял да хакне акаунта на “сивчо” – лесна парола или остарял РНР скрипт.
Първото ме успокои… пфу!
Започнах да разследвам “сивчо” и да видя какво е правил в последно време, но преди това заключих цялата му директория за всеки случай:
chmod 0 /home/сивчо
Използвах командата
find /home/сивчо/public_html -mtime -30 -o -ctime -30 -ls
за да разбера кои файлове е променял в последните 30 дни. Тук ударих на камък – няма нито 1 променен файл. Това означаваше, че скрипта не е писал по файлове, принадлежащи на “сивчо“… пълна мистерия…
Видях кой е Process ID на въпросния скрипт и отидох да го поразгледам. Нека кажем, че PID е 2012.
Влязох в директорията на процеса:
cd /proc/2012/
Исках да разбера, кой всъщност е файла, който се изпълнява зад този процес. А именно, на къде сочи exe файла. В случея – към root директорията “/“. Пак удрям на камък.
Исках да видя коя команда е използвана за да се стартира процеса, като погледа съдържанието на cmdline файла, но и той беше празен. Камък.
Погледнах в директорията fd, за да видя по кой файлове пише и чете процеса. Там имаше само сокети и apache error log файла. Това ме наведе на мисълта, че може би щях да мога да видя кои други файлове са се стартирали от потребител “сивчо” и евентуално да разбера точно в кой РНР файл е дупката за да я оправя или да предупредя клиента. Нямаше нищо. Погледнах и в лога на suPHP, но и там беше празно.
Отидох в /tmp/ директорията, която също се използваше от процеса. Там видях доста (десетина) скрити директории, принадлежащи на потребител “сивчо” и един странен .tgz файл, който при опит да разкомпресирам върна греша. Предположих, че това е самият “вирус”.
От тук нататък, изчерпан от идеи, реших да не се занимавам с ходене по следи от трохи, а просто да реша проблема. Убих процесите и изтрих скритите файлове и директории на “сивчо”. Това реши проблема, надявам се за постоянно. Все пак погледнах в /var/spool/cron/ да не би случайно там да има рестариращ процеса скрипт, но всичко беше наред.
Заключението ми е, че може би сам съм пренесал вируса от друг сървър при смяната на машините, която се случи преди известно време.
Заглавието може би не е много точно, но идеята е, че с тази команда можете да видите от всяко IP колко отворени connection-и (връзки) има в момента към вашият сървър:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Демонстрация:
blagomir@firefly:~$ netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 1 173.194.34.73 3 64.34.119.101
Цифрата е броя отворени конекции последвана от IP адреса.
Първа стъпка разбира се е да имате сертификат Копирайте файловете (.crt/.pem и .key) на вашата машина.
Редактираме nginx.conf, който ако сте инсталирали nginx от package management system се намира тук: /etc/nginx/nginx.conf
server { listen 443; ssl on; ssl_certificate /etc/ssl/certificate.crt; (или .pem) ssl_certificate_key /etc/ssl/certificate.key; server_name bgtechblog.com; location / { root /home/bgtechblog.com/root/; index index.html; } }
Последната стъпка е да рестартираме nginx за да приеме новите промени:
/etc/init.d/nginx restart
Лесно, нали?