На зметку пара элементарных скриптов для резерного копирования веб проекта – форума, сайта, и т.д. и т.п.

Резервируем базу. Создаем файл:

#touch /etc/periodic/daily/340.websqlbkp.sh

В файл пишем:

#!/bin/sh

bkpdir=/home/bkp/sql
curdate=`date +%Y-%m-%d`

mysqldump -u root -pmypass --databases web-base > ${bkpdir}/web-base-$curdate.sql

Пароль без пробела сразу за атрибутом -p. Делаем файл исполняемым. Создаём директории куда будут складываться бэкапы.

Теперь пака с файликами проекта:

#touch /etc/periodic/daily/350.bkpwebdir.sh

В файле:

#!/bin/sh

bkpdir=/home/bkp/web
curdate=`date +%Y-%m-%d`

tar czf $bkpdir/bkp-$curdate.tar.gz /usr/local/www/apache22/data/mydir

Получим файлики с именами содержащими дату создания. Не забываем периодически старые бэкапы удалять.

Небольшие заметки для себя о настройке мини АТС Panasonic TEB-308. Станция небольшая, в моём случае вообще устанавливалась в частном доме – один транк, несколько внутрнних линий. Задача – настроить ограничения по внутренним линиям (COS), заставить работать с обычной телефонной линией (CO) в тоне. Ставим Maintanance Console, драйвера, подключаемся. Пароль по дефолту: 1234.
Продолжить чтение →

Чтобы не забыть и скопипастить. Видео с ютуба в All Video Reloaded на джумле публикуем так:

{youtube width="465" height="420"}9d5fGFUVlnfs0{/youtube}

Себе на память – как управлять запуском служб в Linux, в частности в CentOS. Есть команда chkconfig. Делаем:

chkconfig --list radvd
radvd           0:off   1:off   2:off   3:off   4:off   5:off   6:off

Видим уровни запуска и состояние, в нашем случае radvd отключен на всех уровнях.
Делаем:

#chkconfig radvd on
# chkconfig --list radvd
radvd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

Видим состояние служб изменилось. Теперь при старте системы на данных уровнях служба запустится автоматически.

В процессе настройки DHCPv6 на CentOS получил ошибку:

Warning: dhcp6s listening on ALL interfaces

И не работающий dhcpv6:

#service dhcp6s start
dhcp6s: Warning: dhcp6s listening on ALL interfaces
Starting dhcp6s:                                           [  OK  ]
# service dhcp6s status
dhcp6s dead but subsys locked

Всё оказалось просто – в файле /etc/sysconfig/dhcp6s обязательно прописываем интерфейс на котором слушаем:

DHCP6SIF=eth0
DHCP6SARGS=

PS: Никак не могу привыкнуть к тому что в CentOS конфиги размазаны по нескольким файлам. Во FreeBSD всё как-то более логично…

Столкнулся с невозможностью заменить сертификаты на хосте введённом в кластер vSphere.
Делаем generate-certificates.sh, смотрим что сертификаты изменились:

#cd /etc/vmware/ssl
/etc/vmware/ssl # ls -l
-rw-r--r-T    1 root     root               1058 Apr 18 12:11 rui.crt
-rw-r--r-T    1 root     root                891 Apr 18 12:11 rui.key

Перезагружаемся и …видим что сертификаты старые.

Оказалость в ESXi есть скрипт (auto-backup.sh) который каждый час бэкапит определённые файлы (в частности с установленным стики бит и др.) и помещает их в архив /bootbank/state.tgz. Во время старта файлики из архива извлекаются и раскладываются по директориям, восстанавливая состояние машины.

Столкнулся с проблемой – в браузере Chrome плагин видео плеера для Joomla! AllVideos Reloaded отображает несоответствие версии установленного flash плеера.
Оказалось проблема появляется только если теги плеера AllVideos Reloaded заключены в контйнер <p>, например, если вы вставили плеер в контент и выровняли его посередине.
Решение – либо убрать из разметки обрамляющие теги <p> либо добавить внутрь дивы:

<p><div>{mov width="465" height="420" screenmode="default" usefullscreen="true"
 showdigits="false" wmode="opaque"}Sample{/mov}</div></p>

По умолчанию при установке ESXi генерит самоподписанные сертификаты и при соединении с хостом мы получаем предложение установить сертификат и ошибку при подключении в CLI:

#connect-viserver servername.com

WARNING: There were one or more problems with the server certificate: 
* The X509 chain could not be built up to the root certificate. 
The certificate's CN name does not match the passed value. 

Продолжить чтение →

Странная задача, но иногда возникает – изменить имя отправителя уведомлений от Nagios. Обычно уведомления приходят с адреса вида user@host, то есть, обычно nagios@servername.com
Чтобы изменить имя отправителя уведомления Nagios вносим изменения в определения notify-host-by-email, notify-service-by-email и подобные. В конец строки добавляем

-- -f your@address.com

Получаем что-то вроде такого:

/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ -- -f your@address.com

Теперь в поле «от кого» будет заданный вами адрес.

Для того чтобы гибко управлять порядком проверок Nagios, есть возможность определять зависимости между проверками. Для чего это нужно? Например, мы мониторим состояние служб и хостов за пределами нашей сети, nagios работает на машине во внутренней сети и маршрутизируемого адреса не имеет. Теперь представим ситуацию когда наш шлюз упал и nagios пытается провести прверку удалённого хоста. Проверка звершается ошибкой, хост помечается как DOWN и, после того как сеть восстановлена администратор получает уведомление о том что внешний сервер якобы упал.
Вот для того чтобы этого не происходило (помимо грамотного планирования топологии проверок) есть взможность определить зависимости проверок внешних хостов от состояния шлюза (в нашй ситуации).
Продолжить чтение →

При попытке подключиться к чужому серваку по VPN получал ошибку в логах принимающего сервера:

CTRL: PTY read or GRE write failed (pty,gre)=(6,7)

То есть проблема с фаерволлом на моём шлюзе, который не пускает правильно gre.
Лечится добавлением трёх правил в ipfw:

${fwcmd} allow tcp from any to me 1723 in
${fwcmd} allow tcp from me 1723 to any out
${fwcmd} allow gre from any to any

PS: Осталось проверить как будет работать mpd5, котоый работает на этом же шлюзе, через который я шёл на чужой впн…

Скругленные углы – штука популярная но многие не хотят заморачиваться с методом горной вершины и другими способами для которых нужно готовить файлы иображений и писать сложные каскады и конструкции из <div>.

1. Качаем NiftyCube.zip (в сети легко находится поиском)
2. Распаковываем (внутри примеры стили и скрипты)
3. Заливаем niftyCorners.css в папку css вашего темплейта
4. Заливаем niftycube.js в папку js вашего темплейта
5. Правим index.php шаблона:

Добавляем каскад:

<link rel="stylesheet" href="<?php echo $this->baseurl;?>/templates/<?php echo $this->template ?>/css/niftyCorners.css" type="text/css" />

Добавляем скрипт:

<script type="text/javascript" src="<?php echo $this->baseurl;?>/templates/<?php echo $this->template ?>/js/niftycube.js"></script>

Применяем скрипт к нужному модулю (это может быть id, класс, селектор и т.д.). Здесь мы применяем скрипт к модулю (в свойствах модуля у нас определение индивидуального стиля -anekdot).
Этот пример скругляет нижние углы, большим радиусом.

<script type="text/javascript">
window.onload=function(){
Nifty("div.moduletable-anekdot","bottom big");
}
</script>

Повторюсь: всё что перечислено выше (каскад, скрипт, вызов скрипта) – добавляем в index.php шаблона.

Важно чтобы у модуля был задан бэкграунд цветом, без него естественно никаких границ с основным фоном не будет.
Чтобы ничего не торчало – как обычно пользуемся margin и padding.

Столкнулся с проблемой форматрования даты в Joomla! на машине с FreeBSD при переходе на 5 ветку php:

Warning .... function.strftime was not found on this server

Решается добалением описания timezone в php.ini и перезапуском сервера.

date.timezone = "Europe/Moscow"

Ну и про подавление ошибок php не забываем:

error_reporting = E_NONE

Периодически получали ошибку Service Check Timed Out при проверке Вин машины через NRPE (NSClient++). На хосте выполнялся скрипт проверки, выполнялся в течение, примерно 2-3 минут.

В логах примерно такое:

SERVICE ALERT: TASK;name_of_the_task;CRITICAL;HARD;3;(Service Check Timed Out)

Пытались изменить время проверки ключом -t:

$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 600

Результата не было. С настройками NSClient++ особо не игрались, но на проверяемой машине висели процессы в состоянии FIN_WAIT.

В результате наткнулся в сети на описание переменной в конфиге nagios:

Format: service_check_timeout=seconds
Example: service_check_timeout=60

This is the maximum number of seconds that Nagios will allow service checks to run. If checks exceed this limit, they are killed and a CRITICAL state is returned. A timeout error will also be logged.

There is often widespread confusion as to what this option really does. It is meant to be used as a last ditch mechanism to kill off plugins which are misbehaving and not exiting in a timely manner. It should be set to something high (like 60 seconds or more), so that each service check normally finishes executing within this time limit. If a service check runs longer than this limit, Nagios will kill it off thinking it is a runaway processes.

Увеличиваем значение переменной для решения проблемы с таймаутом.

Понадобилось настроить VPN для доступа к ресурсам локальной сетки (файлсервер, rdp, vnc и т.д). Шлюз работает на FreeBSD. Начал смотреть что есть, а есть немало: poptop, mpd5, openVPN, vtun и т.д.

Особых требований у нас нет – настроить клиента под виндой и подключившись к шлюзу получить айпи из диапазона внутренней сети и получить доступ к локальным ресурсам.

Продолжить чтение →