Использующим готовые хостинг панельки на своих серверах (plesk, cpanel и др.) думаю данный пост будет мало интересен, т.к. слежение за лог-файлами входит в функционал по-умолчанию.
А вот любителям поднять виртуальный хост в ручную, настроить сервера думаю стоит обратить внимание.
Настроив всё необходимое, лично я как то упустил из виду лог-файлы, которые довольно быстро начали «кушать» дисковое пространство на сервере.
Для правки ситуации я решил воспользоваться утилитой logrotate (штатная newsyslog не умеет работать по маске). Читать полностью »

ReTweet

В принципе информация в сети на эту тему присутствует — вот например статейка Как перенести сайт.
Всё бы ничего — вроде доходчиво написано и понятно, но в моём случае на старом сайте висит онлайн магазин с довольно неплохой посещаемостью (трафик в районе 1.5к уников)
Одновременно давать работать двум сайтам нельзя — «поплывут» базы, отрубать старую на сутки — потеря покупателей сказывающаяся на выручке.

Собственно, при правильно сформулированной задаче решение приходит само — уменьшение 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

Смотрю моя мини-заметочка Find — поиск измененных/созданных файлов принесла пользу моим читателям, собственно в рамках этих полезных минизаметках, ещё полезная nix команда, которой мне довольно часто приходит пользоваться:

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

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

ReTweet

На nix- системах есть очень выгодная команда, для поиска созданных и измененных файлов за последние N дней

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

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

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

ReTweet

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

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

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

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

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

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

ReTweet