Так как это ISP, то структура каталогов известна.
Если это нужно сделать для всех пользователей, тогда для каждой цепочки директорий и файловой внутри них, например, folder/subFolder, сделать просто:
chmod -R 0777 /var/www/*/data/www/*/folder/subFolder
Первая "*" - все пользователи, вторая "*" - все домены.
Если все немного сложнее - уточни задачу с примерами. Возможно надо что-то более конкретное написать с помощью find.
Что за ошибка возникает?
И в Debian до сих пор нигде не пофиксили ...
https://security-tracker.debian.org/tracker/CVE-2014-7169
Интересно в каком дистрибутиве патч выдадут раньше :)
Если диски идентичные, то можно dd.
Если нет - создайте аналогичную на новом сервере структуру разделов диска.
На обоих серверах загруженных в livecd примнотировать файловые системы и сделать rsync по сети.
И не забыть на целевом сервере установить загрузчик.
Для нешифрованного трафика можно топорно модулем string iptables вырезать пакеты:
iptables -A FORWARD -m string --algo bm --string "BitTorrent" -j DROP iptables -A FORWARD -m string --string "get_peers" --algo bm -j DROP iptables -A FORWARD -m string --string "announce_peer" --algo bm -j LOGDROP iptables -A FORWARD -m string --string "find_node" --algo bm -j LOGDROP iptables -A FORWARD -p udp -m string --algo bm --string "BitTorrent" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "BitTorrent protocol" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "peer_id=" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string ".torrent" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "announce.php?passkey=" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "torrent" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "announce" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "info_hash" -j DROP iptables -A FORWARD -p udp -m string --algo bm --string "tracker" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "BitTorrent" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "BitTorrent protocol" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "peer_id=" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string ".torrent" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "announce.php?passkey=" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "torrent" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "announce" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "info_hash" -j DROP iptables -I OUTPUT -p udp -m string --algo bm --string "tracker" -j DROP
В последнее время в пост-сноуэденовскую эпоху люди стали активно переходить на HTTPS, но сразу сталкивались с визуально заметным снижением скорости загрузки и общего отклика сайта. Однако, при грамотном подходе к настройке сервера можно значительно подтянуть скорость открытия страниц, чтобы это перестало доставлять дискомфорт (с такой задачей люди обращаются к нам).
Для ее решения в первую очередь мы подключаем SPDY.
SPDY - протокол прикладного уровня, разработанный Google-ом. Основной сутью протокола является снижение времени загрузки страниц за счет мультиплексирования передачи файлов, чтобы при этом требовалось по одному соединению на каждого клиента. По данным Google использование протокола позволяет сократить скорость загрузки страницы на 30% в зависимости от ее типа.
Наверстать лишние секунды помогает включение OCSP - протокол для проверки статуса сертификата. По умолчанию браузер обращается к регистратору, выдавшего SSL сертификат, для уточнения действенности сертификата, так как сам по себе он может быть и валидным, но на самом деле по какой-то причине отозванным центром сертификации. На это уходит некоторое время клиента. Задачу проверки валидности можно переложить на собственный веб-сервер, который с определенной периодичностью будет сам обращаться к центру сертификации за подписанным ответом, который затем будет выдаваться во время установки сессии с клиентом, исключая таким образом необходимость в самостоятельном запросе клиентом сведений о состоянии сертификата.
Самой накладной частью при работе с TLS/SSL является само инициирование соединения, поэтому уменьшить время отклика последующих запросов можно включив кэширование параметров сессии. В случае с SPDY это поможет уменьшить затраты при перезагрузке страницы, т.е. в ситуациях, когда после закрытого ранее соединение создается новое.
Также не забываем включать STS (Strict Transport Security) - специальный заголовок, заставляющий браузер самостоятельно делать запросы исключительно по HTTPS в течение заданного времени.
Немного о грустном. В nginx в версиях 0.5.6 - 1.7.4 выявлена проблема в работе с SSL кэшем, позволяющая повторно использовать закэшированные SSL сессии для проведения MITM атак. Проблема исправлена в версиях nginx 1.7.5 и 1.6.2. На данный момент пакет nginx в Debian wheezy является уязвимым, исправления выложены только в репозитории squeezy lts и sid.
Metal_Messiah, OpenVZ?
artful172, где смотрели объем свободного opcache?
Т.е, как я понимаю, у вас на удаленном сервере существуют разные пользователи, у каждого из которых свой публичный ключ в authorized_keys?
Если да, то можно просто дополнить директивку IdentityFile.
Вообще там доступны на ряду с %h, который вы уже использовали, следующие коды:
‘%d’ (local user's home directory)‘%u’ (local user name)‘%l’ (local host name)‘%h’ (remote host name)‘%r’ (remote user name)
Добавьте еще %r и будет счастье. Какое-нибудь:
IdentityFile ~/.ssh/ids/%h/%r/id_rsa
Ключ для vasya сервера 1.1.1.1 будет лежат в ~/.ssh/ids/1.1.1.1/vasya/id_rsa.
Можно и без дополнительной папки обойтись - это уже дело вкуса.
Поясните задачу. Где что?
