Screenshot сайта с консоли Linux

Появилась задачка отслеживать как меняется дизайн сайта на протяжении недели с шагом в 3часа.
Можно конечно запускать wget по расписанию, но не сильно удобно смотреть потом 100500 файлов.
После поиска по просторам инета был найден простенький способ.
Для этого нам понадобится какой-то сервер (рабочая машина) на Linux.

Для захвата изображения будем использовать програмку CutyCapt

CutyCapt is a small cross-platform command-line utility to capture WebKit’s rendering of a web page into a variety of vector and bitmap formats, including SVG, PDF, PS, PNG, JPEG, TIFF, GIF, and BMP

В итоге мы получим картинку с сайтом отрендереном движком WebKit. Однако требуется Xserver для рендера.
Читать далее Screenshot сайта с консоли Linux

Обновление WP без доступа к FTP

Не всегда есть доступ к блогу на WordPress через фтп протокол, да и постоянно вводить пароль на фтп, который еле запоминаем тоже не прикольно
Для этих случаев WP может обновлятся через локально предоставленый доступ.
В файле wp-config.php нужно переопределить переменную, которая за сие безобразие отвечает. Делается это вот так:

define('FS_METHOD', 'direct');

Читать далее Обновление WP без доступа к FTP

«DELETE FROM users» — как застраховать себя от подобных неприятностей в MySQL

Скомуниздил описание интересной опции мускуля с Хабра:
Когда в очередной раз, пытаясь изменить пароль одного из пользователей или вручную поправить поле какой-нибудь одной записи, забываешь ввести WHERE, ты обеспечиваешь себе не только тонну кирпичей, но и незабываемый экспириенс по восстановлению бекапов.
Читать далее «DELETE FROM users» — как застраховать себя от подобных неприятностей в MySQL

OTRS: хранение заявок на ФС

OTRS
OTRS

По умолчанию все заявки в системе OTRS хранятся в БД, причем там же хранятся и вложения к заявкам, а это скриншоты, логи ошибок, програмки и т.д.
Когда заявок много, то база из-за этого может разростись на несколько Гб, что сказывается на скорости работы самого HelpDesk особенно когда строятся отчеты или производится поиск.
Для этого в самом OTRS предусмотрен вынос всех вложений и писем на файловую систему.
Прежде чем начинать перенос данных рекомендую сделать backup и проверить права на папку var/attachment и var вцелом. Владельцем должен быть пользователь otrs (согласно инструкции по установке)
Читать далее OTRS: хранение заявок на ФС

Статистика Exim в Cacti

Имея настроеную систему рисования графиков Cacti, захотелось еще и рисовать загруженость почтового сервера Exim
Для этого воспользуемся скриптами любезно выложеными на форуме Cacti, но немного поправив их
Для начала скажем демону snmp откуда брать статистику

cat /etc/snmp/snmpd.conf
.....
extend .1.3.6.1.4.1.8607.64 mx-stats /bin/cat /var/spool/exim/statistics

Теперь научим систему генерировать эту статистику каждые 3мин

crontab -l
*/3 * * * * /scripts/snmp/exim_stats.pl

Читать далее Статистика Exim в Cacti

Мониторинг с помощью Observium

Внешний вид Observium
Внешний вид Observium

Observium является PHP / MySQL системой мониторинга сети, ориентированной прежде всего на Cisco и Linux сети, но и включает поддержку широкого спектра сетевого оборудования и операционных систем.

Observium выросла из-за отсутствия простых в использовании NMSes. Она предназначена для обеспечения более нативного интерфейса управления. Разрабатан для быстрого сбора информации о устройствах и хранения истории изменений без ручного вмешательства.Есть режим autodiscovery.

Observium еще не предназначен для замены существующих Nagios/Cacti/Zabbix системы мониторинга, а в дополнение к нему с интуитивным представлением исторических и текущих показателей статистики, настройки визуализации и syslog захвата.
Бесплатно.
Читать далее Мониторинг с помощью Observium

Балансування навантаження з допомогою Nginx

Переклад статті Use Nginx for Proxy Services and Software Load Balancing

Серед додаткових особливостей nginx є можливість використання його як проксі (front end proxy) для передачі запитів на інші веб-сервери, Nginx також може виступати в якості Front end інтерфейсу для кластеру з серверів і навіть для балансування навантаження (load balancer).

Розглянемо наступні витримки конфігурації, які описують кластер appcluster:

Уривок файлу : nginx.conf

http {
  # [...]
 
  upstream appcluster {
     server lollipop.ducklington.net:8801;
     server lollipop.ducklington.net:8802;
     server lollipop.ducklington.net:8803;
     server lollipop.ducklington.net:8804;
     server simons.ducklington.net:8801;
     server simons.ducklington.net:8802;
     server simons.ducklington.net:8803;
     server simons.ducklington.net:8804;
     }
 
  # [...]
 
  server {
    listen 21.43.56.87:80;
    server_name ducklington.org www.ducklington.org;
 
    location / {
       proxy_pass  http://appcluster;
       }
    }
 
    # [...]
  }

У цьому прикладі ми описали просте балансування по принципу round-robin за допомогою директиви upstream.

Всередині цього блоку ми описали вісім серверів, кожен з яких працює на різних хостах і портах.
Конфігурація блоку upstream повинна бути разташована на початку блоку http конфігураційного файлу nginx.conf.

Сервери, що працюють на портах з 8801 по 8804 на хостах lollipop.ducklington.net і simons.ducklington.net отримають одинакову кількість запитів направлених в блок appcluster.

В блоці server Nginx налаштований для прослуховування запитів на певну IP-адресу і порт (наприклад, 21.43.56.87 і 80), і відповідати на запити до доменів ducklington.org і www.ducklington.org.

Усі запити про виділення ресурсів у цьому домені (наприклад, /) будуть передані у http://appcluster, який описаний в директиві upstream.
Читать далее Балансування навантаження з допомогою Nginx

Работа с Postgresql: настройка, масштабирование

Книга Работа с Postgresql: настройка, масштабирование является справочным пособием по настройке и масштабированию Postgresql. В книге иследуются вопросы по настройки производительности Postgresql, репликации и кластеризации. Изобилие реальных примеров позволит как начинающим, так и опытным разработчикам быстро разобратся с особенностями масштабирования Postgresql для своих приложений.
http://postgresql.leopard.in.ua/

ссылка на книгу если с сайта не грузится

postgresql

Правила Rewrite для поддержки ЧПУ на серверах под управлением Nginx для DLE

После перехода на с Apache на связку Nginx+spawn-cgi у меня некоректно запустились сайті на DLE.
Причем проблемы была именно в ссылках ЧПУ. Обычные ссылки newsid=xxx прекласно работали.
Решение проблемы
В конфиге Nginx вместо :

#                            if (!-e $request_filename) {
#                            rewrite ^(.+)$ /index.php?q=$1 last;

Вставляем такой код:

rewrite ^/page/(.*)$ /index.php?cstart=$1 last;
 
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)/page,([0-9]+),([0-9]+),(.*).html(/?)+$ /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&cstart=$5&news_name=$6 last;
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)/page,([0-9]+),(.*).html(/?)+$ /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&news_name=$5 last;
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)/print:page,([0-9]+),(.*).html(/?)+$ /engine/print.php?subaction=showfull&year=$1&month=$2&day=$3&news_page=$4&news_name=$5 last;
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)/(.*).html(/?)+$ /index.php?subaction=showfull&year=$1&month=$2&day=$3&news_name=$4 last;
 
rewrite ^/([^.]+)/page,([0-9]+),([0-9]+),([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$4&news_page=$2&cstart=$3 last;
rewrite ^/([^.]+)/page,([0-9]+),([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$3&news_page=$2 last;
rewrite ^/([^.]+)/print:page,([0-9]+),([0-9]+)-(.*).html(/?)+$ /engine/print.php?news_page=$2&newsid=$3 last;
rewrite ^/([^.]+)/([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$2 last;
 
rewrite ^/page,([0-9]+),([0-9]+),([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$3&news_page=$1&cstart=$2 last;
rewrite ^/page,([0-9]+),([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$2&news_page=$1 last;
rewrite ^/print:page,([0-9]+),([0-9]+)-(.*).html(/?)+$ /engine/print.php?news_page=$1&newsid=$2 last;
rewrite ^/([0-9]+)-(.*).html(/?)+$ /index.php?newsid=$1 last;
 
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)(/?)+$ /index.php?year=$1&month=$2&day=$3 last;
rewrite ^/([0-9]+)/([0-9]+)/([0-9]+)/page/([0-9]+)(/?)+$ /index.php?year=$1&month=$2&day=$3&cstart=$4 last;
rewrite ^/([0-9]+)/([0-9]+)(/?)+$ /index.php?year=$1&month=$2 last;
rewrite ^/([0-9]+)/([0-9]+)/page/([0-9]+)(/?)+$ /index.php?year=$1&month=$2&cstart=$3 last;
rewrite ^/([0-9]+)(/?)+$ /index.php?year=$1 last;
rewrite ^/([0-9]+)/page/([0-9]+)(/?)+$ /index.php?year=$1&cstart=$2 last;
rewrite ^/tags/([^/]*)(/?)+$ /index.php?do=tags&tag=$1 last;
rewrite ^/tags/([^/]*)/page/([0-9]+)(/?)+$ /index.php?do=tags&tag=$1&cstart=$2 last;
rewrite ^/user/([^/]*)/rss.xml$ /engine/rss.php?subaction=allnews&user=$1 last;
rewrite ^/user/([^/]*)(/?)+$ /index.php?subaction=userinfo&user=$1 last;
rewrite ^/user/([^/]*)/page/([0-9]+)(/?)+$ /index.php?subaction=userinfo&user=$1&cstart=$2 last;
rewrite ^/user/([^/]*)/news(/?)+$ /index.php?subaction=allnews&user=$1 last;
rewrite ^/user/([^/]*)/news/page/([0-9]+)(/?)+$ /index.php?subaction=allnews&user=$1&cstart=$2 last;
rewrite ^/user/([^/]*)/news/rss.xml(/?)+$ /engine/rss.php?subaction=allnews&user=$1 last;
rewrite ^/lastnews/(/?)+$ /index.php?do=lastnews last;
rewrite ^/lastnews/page/([0-9]+)(/?)+$ /index.php?do=lastnews&cstart=$1 last;
rewrite ^/catalog/([^/]*)(/?)+$ /index.php?catalog=$1 last;
rewrite ^/catalog/([^/]*)/page/([0-9]+)(/?)+$ /index.php?catalog=$1&cstart=$2 last;
rewrite ^/newposts(/?)+$ /index.php?subaction=newposts last;
rewrite ^/newposts/page/([0-9]+)(/?)+$ /index.php?subaction=newposts&cstart=$1 last;
rewrite ^/static/(.*).html(/?)+$ /index.php?do=static&page=$1 last;
rewrite ^/favorites(/?)+$ /index.php?do=favorites last;
rewrite ^/favorites/page/([0-9]+)(/?)+$ /index.php?do=favorites&cstart=$1 last;
 
rewrite ^/rules.html$ /index.php?do=rules last;
rewrite ^/statistics.html$ /index.php?do=stats last;
rewrite ^/addnews.html$ /index.php?do=addnews last;
rewrite ^/rss.xml$ /engine/rss.php last;
rewrite ^/sitemap.xml$ /uploads/sitemap.xml last;
 
rewrite ^/category/([^.]+)/(.*).html(/?)+$ /index.php?subaction=showfull&news_name=$2 last;
rewrite ^/category/([^.]+)/page/([0-9]+)(/?)+$ /index.php?do=cat&category=$1&cstart=$2 last;
rewrite ^/category/([^.]+)(/?)+$ /index.php?do=cat&category=$1 last;
 
if (!-d $request_filename) {
        rewrite ^/([^.]+)/page/([0-9]+)(/?)+$ /index.php?do=cat&category=$1&cstart=$2 last;
        rewrite ^/([^.]+)/?$ /index.php?do=cat&category=$1 last;
}
 
if (!-f $request_filename) {
        rewrite ^/([^<]+)/rss.xml$ /engine/rss.php?do=cat&category=$1 last;
        rewrite ^/page,([0-9]+),([^/]+).html$ /index.php?do=static&page=$2&news_page=$1 last;
        rewrite ^/print:([^/]+).html$ /engine/print.php?do=static&page=$1 last;
}
 
if (!-f $request_filename) {
        rewrite ^/([^/]+).html$ /index.php?do=static&page=$1 last;
}

Осваиваем Git

Никогда не пользовался системами контроля версий, так как мало что творю на языках программирования, а скрипты можно просто хранить в папочке.
Ну и вот решил попробовать хранить скрипты (и не только) в каком-то хранилище, но при этом упустить освоение SVN И CVS, а сразу приступить к Git’у , так как мы не исчем легких путей 🙂

Для начала создаем собственный репозиторий с проэктом, который будет находится не на локальной машине, а где-то в сети.
Пишу по мотивам статьи How to set up your own private Git server on Linux
Сервер и клиенты (в основном) работают под управлением Gentoo.
Итак приступим.
Для начала добавим свой публичный ключ на сервер

cd ~/.ssh
ssh-keygen -t rsa
scp ~/.ssh/id_rsa.pub 'user'@'server':.ssh/authorized_keys

Теперь мы можем зайти по SSH на наш сервер и установить Git:

ssh <server>
ACCEPT_KEYWORDS="~amd64" USE="bash-completion cvs subversion" emerge -av git
</server>

Теперь добавим пользователя

useradd -d /home/git -m -s /bin/bash git

Теперь вам нужно добавить свой публичный ключ для пользователя Git

mkdir /home/git/.ssh
cp ~/.ssh/authorized_keys /home/git/.ssh/
chown -R git:git /home/git/.ssh
chmod 700 !$
chmod 600 /home/git/.ssh/*

Читать далее Осваиваем Git