User

find /var/www/ -type f -exec mv {} {}_renamed \;

find-рекурсивный поиск от заданного каталога и ниже
/var/www- где искать, если в текущем каталоге то можно заменить на .
-type f - только файлы
-exec выполнить с найденным
mv переместить
{} то что найдено в данном случае имя файла
\; - просто закончит команду.
Проверить можно так, вместо переименовывания вы получите просто принт самих команд.

find /var/www/ -type f -exec echo {} {}_renamed \;


Отметить решенным, спасибо кэп.

Кто вам сказал, что удаляется все? Можно спокойно обновляться

Мне кажется, Вы занимаетесь ерундой, прости Господи.

Почему.

Парадигма Panic Button - это не шифрование, а уничтожение, причем уничтожение очевидно необратимое (например подача на диск импульса, который стирает всю информацию нафиг). После очевидного даже для самых тупых людей (я правильно понимаю, что Вы метите в модель нарушителя государство? Менты - они далеко не всегда умные, а те, которых пошлют ткнуть Вас лицем в пол - будут из таких :) ) уничтожения устройства даже для них будет очевидно, что терморектальный криптоанализ к Вам применять бесполезно - хотя лице могут немного перекосить - от расстройства :)
Если же данные зашифрованы, то есть существует пусть теоретическая, но ненулевая возможность их восстановления, то (в зависимости от ценности и нужности данных конечно же) к Вам просто применят терморектальный криптоанализ. Единственный способ применить тут парадигму Panic Button - это немедленно умереть на месте :)

Это спорный вопрос. Имеет смысл проверять по таблице самых популярных паролей (серверная валидация) и отказывать, если пароль оттуда.
Ни в коем случае не проверяйте сложность пароля фактом наличия в нём символов из определённых групп. Нужно просто считать энтропию пароля в битах и задать пороговую допустимую энтропию.
К примеру, если у пользоватля длинный пароль из 30 символов, ему совершенно необязательно добавлять символы разного регистра, цифры и всякие запятые, они практически не повлияют на сложность, зато могут повлиять на способность пользователя как следует запомнить свой пароль (где там какая цифра, куда дефис и где именно скобки...)

Итак,

1. накладывать оганичения нужно только на энтропию пароля, остальное пойдёт только во вред.
   
2. ограничения должны нести рекомендаельный характер, имеет смысл сделать два порога энтропии. Совсем слабые пароли не допускать, средние допускать с предупреждением. Пусть пользователь осознаёт сложность пароля и сам соотносит ее с рисками злонамеренного подбора. Порог энтропии можно проверять на клиенте, базу популярных паролей придётся чекать на сервере.
   
3. как следует солите пароли и не храните их в открытом ввиде. Это правило следовало бы вынести на первое место, но это не рейтинг мер, а просто важные замечания. Соль для каждого пароля можно хранить рядом с хешем пароля через разделитель, рядом же можно указать и название алгоритма хеширования.
   
4. сложность пароля - не панацея. Нужно делать эффективную систему распознавания попыток подбора пароля. Если сильно ограничить скорость подбора пароля то пароль можно делать простым. Пример тому - пинкоды на вашей банковской карте. У вас всего три попытки неправильного ввода на сутки, ошибочные попытки на следующий день вовсе окирпичат вашу карточку. Не бывает простых решений. Нужно понимать также, что пароли могут брутфорситься не с целью подбора, а с целью блокирования входа законного владельца аккаунта.
   
5. Не забывайте про двухфакторную авторизацию. Это важно.
   
6. Обновляйте сессию пользователя при штатной работе в аккаунте. Не вынуждайте каждый раз вводить пароль по несольку раз на день. Этим, к примеру, постоянно грешит алиэкспресс. Но у них многое ерез задницу.
   
7. Не делайте нестандартных форм авторизации, важно, чтобы ваша форма нормально работала с основными стандартными менеджерами паролей. Если пользователь пользуется менеджерами паролей, то это его осознанный выбор, он может быть вполне обоснован. Это гораздо лучше, чем пароль на стикере, прилепленый к монитору.
   
8. Если делаете API, не требуйте использования в нём паролей. Сделайте нормальный менеджмент ключей, не заставляйте светить пользовательские пароли в открытом виде в скриптах и исходниках. Не все, пока еще, грамотно работают с секретами.
   

Это потому что в вашей системе по умолчанию установлен Python 2.7.
Вы-то поставили третью версию, но вторую он не заменяет (вы даже не указали, как скрипт запускаете) - вот потому второму Python не нравится print(), потому что во второй print это оператор, а в третьем оператор print был заменён функцией print().

Python2:
print "Дважды два: ", 2*2
Python3
print("Дважды два: ", 2*2)

Зачем стрелять себе в ногу, если они все отзывы отдают json'ном? Вот простой код:

import requests
import json

import requests
headers = {
    'content-type': 'application/json',
}

data = '''{"filter":{"rated":"Any",
					"orderBy":"WithRates",
					"tag":"",
					"reviewObjectId":276,
					"reviewObjectType":"banks",
					"page":"1",
					"pageSize":20,
					"locationRoute":"",
					"regionId":"",
					"logoTypeUrl":"banks"
					}}'''

response = requests.post('https://www.sravni.ru/provider/reviews/list',data=data,headers=headers)

reviews = json.loads(response.text)

total = reviews['total']

print(f'Всего отзывов: {total}')

for review in reviews['items']:
	title = review['title']
	text = review['text']
	print(f'{title} - {text}')

Так как всего отзывов 8718, а на каждой странице по 20 отзывов - получаем 436 страниц. Меняем параметр page в запросе от 1 до 436 и получаем все отзывы в удобном виде.
Структура json:

В списке lines модифицируйте нужную строку lines[i] и сохраните lines обратно в файл. Для сохранения файл нужно будет открыть в режиме записи. Вообще, конечно, для таких задач лучше использобвать БД. Посмотрите в сторону работы хотя бы с SQLite3, там всё просто.

юзай xargs

echo -n /etc/AlterPro/apps_{sys,map,ctrl,port}.conf | xargs -d" " -n1 -I NAME appman -f NAME standby unregister --sys-id 3

https://regex101.com/r/nV9ZLS/1
^[^\s()-]*$
Первая "крышка" означает, что это начало строки. Последний "доллар" означает конец строки.
Между ними любое (0 или более символов) из множества, описанного в квадратны скобках.
В квадратных скобках крышка означает, что множество инвертировано. То есть допускаются любые символы, кроме перечисленных.
То есть, данное множество представляет собой НЕ: пробел, скобки и минус, но любые другие символы.

500 строк в секунду - это не мощно и, вероятно, даже не DDoS. Если адрес один, то просто закройте ему доступ брандмауэром, а если адреса разные, то настройте лимит запросов в Nginx.

nginx.conf

http {
    ...
    limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=30r/s;
    ...
}

some_site.conf

server {
    ...
    location / {
        ...
        limit_req zone=reqlimit burst=10 nodelay;
    }
}

После этого запросы с одного ip-адреса начиная с 31-го в секунду будут отбрасываться.

Как вишенку на торт, можно добавить ещё фильтр для fail2ban:

nginx-req-limit.conf

[Definition]

failregex = limiting requests, excess: .* by zone .*, client: <HOST>
ignoreregex =

и правило в jail.local

[nginx-req-limit]
enabled = true
port = http,https
filter = nginx-req-limit
logpath = /var/www/*/*/logs/error.log # Здесь укажите свой путь к логам виртуального хоста
findtime = 600
maxretry = 10
bantime = 7200

После этого адреса DoS'еров будут автоматически блокироваться брандмауэром на два часа. Что разгрузит Nginx от обработки паразитного трафика.