iptables при среднем и большом количестве правил (например, блокировок) начинает тормозить. ipset даже при большом количестве адресов для блокировки работает быстро.
Поэтому лучше использовать не чисто iptables, а iptables+ipset,
И кстати обратите внимание, что в Ipset есть возможность добавлять адреса в базу на какой-то временной промежуток. Например Вы можете добавить IP адрес на месяц. Месяц он будет блокироваться, а потом удалиться из базы. И еще ipset (про iptable не помню) при перезагрузке правила и адреса, введенные из командной строки сбрасывает. Поэтому, если Вы хотите, чтобы после перезагрузки правила сохранялись, нужно об этом позаботится. Это решаемо. Как это сделать, почитайте в интернете.
Как вы на test.example.com обращаетесь? Через http или через https? Это две большие разницы. Дополнительно посмотрите какой редирект происходит 301 или какой-то другой. Для этого в браузере в хроме, например, нажмите F12, выберите вкладку, которая загрузку сетевых элементов отображает и перезагрузите страницу. Там информация по редиректу будет видна.
И еще может быть вариант такой, что все работает правильно, а редирект делает браузер "по старой памяти". Например фаерфокс может запоминать (кэшировать) 301 редирект и даже при изменении настроек на сервере продолжать в течение некоторого времени сразу делать редирект, не обращась к серверу. Т.е. фаерфокc понимает, что 301 редирект означает - страница переехала постоянно, и поэтому при повторном обращении старого адреса может какое-то время сразу грузить новый. У меня так было. Я тоже с настройками редиректа на сервере игрался. Сначала был 301 редирект, я это протестировал фаерфоксом, потом 301 редирект я на сервере отключил, а ферфокс продолжал все равно открывать страницу с 301 редиректом. При этом другие браузеры на том же компьютере (хром) и другие устройства (например мобильник) уже не переходили по 301 редиректу. Кстати хром в отличии от фаерфокса к серверу обращается при каждом запросе и 301 редирект не "кэширует"
Сергей: Если у Вас VPS и в идеале хотите найти программу типа Яндекс.Диска, то может быть Вам для начала попробовать настроить яндекс.Диск через WebDAV на Вашем VPS сервере? Яндекс.Диск можно настроить не на любом VPS. Возможность установки зависит от наличия Fuse в ядре операционной системы или от возможности его установить. На одном VPS хостинге у меня не получилось настроить яндекс.диск из-за того, что провайдер заблокировал изменения ядра ОС. На другом более продвинутом хостинге я установил Яндекс.Диск.
Если Вы установите Яндекс.Диск, то вряд ли на него захотите выкладывать рабочий сайт, потому что яндекс.диск может размонтироваться в какой-то момент. Но Вы можете на VPS сервере синхронизировать рабочую папку сайта с подмонтированной папкой яндекс.диска. Например с помощью rsync. Rsync синхронизирует очень быстро. Такую синхронизацию можно добавить в crontab и запускать автоматически с необходимой Вам частотой.
1. Заказчик может привлечь какого-то программиста, который что-то изменит в коде сайта.
2. Иногда встречаются взломы сайта и в одну из дальних никому не нужных директорий заливают шел или какой-нибудь вирус.
3. В редких случаях я сам не имея доступа к рабочей машине, могу что-то поправить прямо на продакшене.
Мне удобно, что имея GIT на продакшене я могу отследить любые измениния файлов проекта, которые по-другому очень трудно найти. А также удобно, что если кто-то (я или представитель заказчика) сделают полезные изменения на продакшене, я легко могу их закомитить и получить последнюю версию проекта на любой машине для разработки.
А операционная система разве сама не кэширует часто запрашиваемые файлы при наличии свободной памяти?
У меня на старом VPS хостинге в операционной системе Debian 5/6 даже при наличии свободной памяти кэширования файлов не было. Вероятно, это хостер из жадности запретил каширование, чтобы память не занимали с его точки зрения мусором. А поскольку память скорее всего старый хостер продавал больше, чем ее было физически на сервере, он был заинтересован, в том чтобы VPS сервера потребляли, как можно меньше памяти.
А на новом VPS хостинге стоит операционная система Debian 7/8. Так там прямо из коробки без дополнительных настроек включено кэширование любых файлов, к которым обращается операционная система, в том числе и файлов статики сайта. К примеру при 8Гигах памяти, в то время, как 2 гига при низкой загрузке занимают все запущенные программы, 5.5 гигов занимает кэш.
Для себя я решил, что нет смысла дополнительно кэшировать файлы статики итп. Во-первых в зависимости от реализации дополнительного кэширования статики, можно уменьшить количество свободной памяти, жестко выделив ее только под кэш. Во-вторых получается двойное кэширование, что теоретически может даже замедлить операции с файлами. В третьих приходится самому решать, какие файлы размещать в кэше. А при автоматическом кэшировании операционной системой, в кэше оказываются самые востребованные файлы, размер кэша ограничен только свободной памятью, а в случаях, когда системной памяти не хватает под запущенные процессы, размер кэша автоматически сокращается, вплоть до нулевых значений.
Поэтому, если у Вас в операционной системе кэш не выключен, то может быть и без дополнительных настроек в nginx все будет работать нормально.
В debian, например, можно посмотреть есть кэширование или нет командой "free" - данные в столбце cached.
Спасибо большое.
Сходу не получилось сделать цвет меню такой же, как в окошке с кодами, в котором применена цветовая схема Solarized. Количество тем в меню Appearance отличается от количества в меню Colors &Fonts. Но цвета меню меняются и я понял, в какую сторону копать.
Dmitrii Solovev: У меня нет желания ставить операционную системы только ради эксперимента. Хотя консоль у нас работает одинаково, меня это устраивает.
У Вас реально есть команды на русском языке, которые Вы вводите в консоли? (Именно команды, а не параметры команд).
Если таких реальных команд нет, то лечить ответ на команды опечатки "фыва/олдж/рпе" итп, это нерациональная трата времени.
Попробую пофантазировать... Если это не особенность, а именно ошибка Weezy и ее уже нет в следующей версии - Jessie, то возможно, что эту ошибку уже исправили или скоро исправят, но исправление находится в экспериментальных пакетах, которые по-умолчанию не ставятся при обновлении.
silentvick Большое человеческое спасибо! Сразу не ответил, потому что нужно время, чтобы все проверить. Сейчас проверил - добавление полей и таблиц в БД - все работает. Плагины для миграции в моем случае не использовались. Спасибо!
andrey69rus: Я так и хотел бы сделать (в одном месте, а потом юзать if $isBot.... ), но вот как это сделать я не знаю. Поэтому пока остановился на варианте, когда в каждом модуле своя проверка. Конечно, это не самый красивый вариант, но рабочий. Здесь уже вопрос из плоскости, как определить бота, переходит в другую плоскость - как создавать на лету и использовать глобальные переменные в symfony. Поскольку быстрого решения не нашел, решил использовать тот вариант, который предложили.
Такую проверку делать в каждом модуле или можно ее как-то в одном месте сделать, а потом результатом в любых модулях пользоваться?
Если проверку делать в каждом модуле отдельно, то потом при необходимости внести изменения в код (например, добавить еще одного бота в список), придется в куче мест правки одинаковые делать.
И по производительности тоже вопрос. Если при формировании одной страницы одинаковая проверка будет производиться несколько раз (отдельно в каждом модуле), то это вероятно лишние затраты.
Руслан Квашнин: Спасибо, что откликнулись. Я не успел прочитать Ваш ответ до удаления. У меня действительно Symfony 1.2, но Ваш ответ мог бы пригодиться кому-то со схожей задачей при использовании symfony более свежих версий.
Спасибо за совет.
С монтированием получилось. Поскольку все примонтированные директории сбрасываются при перезагрузке сервера, прописал в файл /etc/init.d/mysql в секции start:
mount --bind /run/mysqld /var/www/site1/mod-tmp/mysqld
и на всякий случай в секцию stop:
umount /var/www/site1/mod-tmp/mysqld
Хотя про размонтирование я не уверен, нужно ли оно.
Теперь при загрузке/перезапуске mysql сервиса директория с сокетом mysql монтируется внутри пользовательских chroot окружений.
Чтобы php-fpm использовал сокет внутри своего chroot, прописал в настройках пула php путь уже с учетом chroot:
php_admin_value[mysql.default_socket] = /mod-tmp/mysqld/mysqld.sock
Все работает, но осталось это дело немного затюнинговать.
1. Подскажите, какие права и владелец должны быть установлены на папку .../mod-tmp/mysqld
2. С точки зрения безопасности нормально монтировать папку с сокетом mysql внутрь пользовательского окружения? Поскольку сокет - это файл, не сможет ли пользователь одного сайта удалить файл сокета и тем самым отключить доступ к Mysql вообще на всех сайтах, соседствующих на сервере?
Поэтому лучше использовать не чисто iptables, а iptables+ipset,
И кстати обратите внимание, что в Ipset есть возможность добавлять адреса в базу на какой-то временной промежуток. Например Вы можете добавить IP адрес на месяц. Месяц он будет блокироваться, а потом удалиться из базы. И еще ipset (про iptable не помню) при перезагрузке правила и адреса, введенные из командной строки сбрасывает. Поэтому, если Вы хотите, чтобы после перезагрузки правила сохранялись, нужно об этом позаботится. Это решаемо. Как это сделать, почитайте в интернете.