Инсталлируем из портов
cd /usr/ports/sysutils/logrotate/
make install clean

Далее работаем тут
cd /usr/local/etc/
создадим папку в которую будем кидать конфиги виртуальных хостов
md ./logrotate.d
создадим конфигурационный файл
logrotate.conf
с одной лишь строчкой
include /usr/local/etc/logrotate.d

всё — далее при создании хоста будем кидать сюда файлик с индивидуальными настройками для этого хоста (это может делать и скриптик по шаблону)
/..../domain.ru/logs/*.log { #работаем по маске, т.к. тут логи и апача, и нгникса и фтп и т.д.
nomail #не отправляем на почту содержимое логов
size 16M #обрабатывать лог файл только при достижении 16 мегабайт
missingok # при отсутствии лога не формировать ошибку
rotate 10 # храним последние 10 архивов
compress # сжимаем логи
notifempty # не обрабатываем пустые
create 640 arh wheel # создаем с такими правами
dateext # в названии архивного файла ставить дату архивации
noolddir
}

далее я создал сценарий с запуском самого logrotate и обновлением демонов работающих с лог-файлами и поместил его в крон с запуском 1 раз в сутки ночью.

всё

ReTweet

Собственно, при правильно сформулированной задаче решение приходит само — уменьшение TTL в настройках DNS зоны.

Я поставил 3600 — час (было сутки — 86400).
Передёрнул бинд.
#killall -HUP named
#/etc/rc.d/named reload

Подожду сутки, пока новые настройки не подействуют — и в бой.
Как пройдёт — отпишу.
Кстати в статейке ещё один важный момент опущен — при переезде на старом серваке желательно отрубить возможность изменения данных (либо потом придётся их как то перетягивать — а это уже «головняк»)

P.S.
меняя что-то в кроне — не забываем передёргивать
/etc/rc.d/cron restart
или
killall −1 cron

ReTweet

Время от времени возникает задача рекурсивной смены сразу всех файлов (только файлов! либо только папок).

изменяет только файлы
find . -type f -exec chmod 644 {} \;

изменяет только папки
find . -type d -exec chmod 755 {} \;

изменяет только файлы
find . -type f -exec chown www:www {} \;

изменяет только папки
find . -type d -exec chmod www:www {} \;

запускать в текущей папке
вместо точки можно вписать абсолютный путь

chgrp аналогично ...

P.S. Ещё вариант
find /catalog -type d -print | xargs chmod 755
find /catalog -type f -print | xargs chmod 644

ReTweet

Чистка логов, темпов и изучение размера директорий проектов результат дали слабенький.

А вот замер папки /var/db/  расставил все точки над «и»  — более 50% винта оказалось именно там, а конкретнее в корне /var/db/mysql в виде файлов mysql-bin.000000 mysql-bin.000001 mysql-bin.000002 и т.д. каждый весом по гигабайту.

Это — бинарные лог файлы для организации репликации СУБД. (чего у меня не планировалось)

Решение — убить файлы и отключить эту опцию.

Правильно это сделать так:

1.  В конфиге мускуля комментируем строку  (у меня FreeBSD — конфиг тут /etc/my.cnf
log-bin=mysql-bin

2. И с правами рута в mysql выполняем
RESET MASTER;


Вуаля!
Так оно и побыстрее шевелиться должно.

P.S.
лучший браузер для ipad

ReTweet

sort -u файл1 файл2 ... файлN -o файлРезультат

на входе N текстовых файлов
на выходе результирующий файлик с отсортированным массивом строк, уже без дублей

ReTweet

find /.../*.php -mtime −1

поищет не впаяли ли в ваше отсутствие в php файлы за последний день бэкдорчик

P.S.
Сегодня таким методом вычисляли как один нехороший чел напакостил на сайте.

ReTweet

Наверное этот микро-пост нужно было написать ещё лет 5 тому назад, когда я первый дедик брал ...

Итак — после анализа логов на серваке зашевелились волосы от ужаса — постоянные попытки взлома по ssh,  по ftp дрюкают — даже пару раз DDOS из за FTP ложил сервер ... в общем мало приятного.

И всё это на фоне предыдущих моих статей по защите сайта от взлома

• Защита сайта от взлома. Продолжение. Июнь 20th, 2010 (17)
• Защита сайта от взлома Июнь 7th, 2010 (18)

Сначала пробовал настройками ProFTPD ограничить ftp доступ ... но всё же пришел к выводу обязательно врубать фаервол и ограничивать доступ по конкретным айпишникам, либо подсеткам именно на уровне фаервола (так и быстрее и более функционально — защищаем и ssh и др.)  И это первое с чего нужно начать строить оборону сервера!

Дома приплатил за белый статический IP, на работе они уже были — собственно других мест выхода в сеть у меня больше и нету. У коллег под серверу такая же история — соответственно кому давать доступ а кого отрубать — понятно, осталось дело за малым  — врубить и настроить фаервол ...

Не являясь гуру в FreeBSD (именно она рулит на моём дедике) начал разборки с местными фаерволами и тут свершилось одно из давних моих опасений — для статического включения фаервола необходимо было пересобрать ядро.

Перекомпиляция ядра системы — для меня уже давненько звучит ну очень страшно и даже понимая, что сделать это придётся рано или поздно — всё сдвигал сроки, заменяя какими то другими делами, пока не припёрло.

В итоге всё оказалось не так сложно и не так страшно — и ... что удивительно получилось с первого раза — как перекомпиляция ядра, так и настройка фаервола (единственный косяк — ещё на стадии «знакомства» с ipfd — это я динамически подгрузил модуль ipfw  kldload ipfw в режиме политики по умолчанию запрещено всё всем

Кстати пересборка ядра не только дала мне необходимую опцию — фаервол, которая уже сразу не хило разгрузила сервак избавлением от обработки левых поползновений ! Но так же плюс ко всему данная операция значительно разгрузило всю систему от ненужных драйверов и опций. Так изначально моё ядро GENERIC amd64  тянуло аж на 208 мб — после оптимизации осталось всего 33 ! Так что пересборку ядра смело можно включать в цикл заметок по вычислению и снижению нагрузки на сервер

Ну и как ведётся в правильных статьях — используемая литература, а именно материал, помогший мне в сием действе:

1. FreeBSD в качестве сервера доступа. 3 части.
2. Пересборка ядра FreeBSD
3. IPFW HOWTO

В постовой сегодня у меня одна кандидатура — Раскручиваем блог вместе от seokursi.info

ReTweet