Дмитрий Яковенко

Для начала ты должен понимать, зачем вообще нужно виртуальное окружение.
Каждое приложение как правило разворачивается в изолированной среде. Туда устанавливаются только те зависимости, которые нужны для работы этого приложения (Как правило, зависимости указываются в requirements.txt/pyproject.toml и т.д.).
При разработке тебе ничто не мешает вообще не использовать виртуальное окружение, но рано или поздно ты столкнешься с проблемой несовместимости библиотек на разных проектах.
Поэтому хорошей практикой является использование отдельного виртуального окружения для каждого проекта.
При локальном запуске ты выбираешь какой именно интерпретатор python использовать (оригинальный, установленный в системе или виртуальный). Ты просто указываешь путь к нужному тебе интерпретатору в своей среде программирования или при запуске через терминал вызываешь интерпретатор по указанному пути (если не активировано виртуальное окружение).

Весь этот спич вот к чему: ты можешь хранить виртуальные окружения где угодно.
Хорошими практиками являются:

- хранение виртуального окружения в корневой папке проекта (venv/. venv). !Обязательно добавлять эту папку в . gitignore!
-создать папку для виртуальных окружений и хранить все виртуальные окружения в ней

<?php
$mysecret = 'supersecret';

Минимальный совет из "PHP Правильный путь" звучит как храните свои конфиги хотя бы в виде php файлов.
Предположим, что мы сохранили такой скрипт в корне www.
При правильной настройке сервера посетитель увидит пустой экран по урлу //your.site/script.php
так как в нашем файле нет команд вывода.
В первой строке полный синтаксис, в варианте "<?" может случиться ситуация показа исходного текста, если сшорт таги отключены. И остается риск того, что php отвалиться и будет показываться исходный код.

Обще принятой практикой сейчас считается подход, когда все исходные файлы лежат выше диретории www рут.
В самой директории только один скрипт точки входа (index.php)

Ваши пароли скорее утекут по другой причине, чем из-за того, что к скрипту обратяться на прямую.

Вы используете eval c данными от пользователя или на сайте можно загружать через форму файлы.
На шаред хостинге ошиблись с разделением прав для ftp.

У Вас используются системы контроля версий кода и конфиги не добавлены в игнорируемые.

- Разница 1: Почти, sudo -i также меняет HOME на /root, и читает логин скрипты root юзера.
- Разница 2: Верно, действия с sudo -i и sudo -s логгируются в журналах юзера, а sudo su - нет.
- Разница 3: Верно, sudo позволяет настраивать ограничения для команд через sudo -i и sudo -s, но не для sudo su (так как sudo su переключает юзера в root).

Еще не понял разницу между
sudo su
sudo su -

- sudo su - переключает юзера на root, но окружение при этом не является полным root окружением.
- sudo su - - эмулирует полный вход юзера root (login shell). Будут прочитаны все файлы конфигурации, которые обычно читаются при входе root (profile, .bash_profile, .bashrc и что-то там еще). Насколько я понимаю, это то, что нужно Вам при работе от имени юзера root.

И где можно смотреть логи пользаков при использовании sudo -i, sudo -s?

Viewing and monitoring log files, можно еще заюзать journalctl.

Настрой что-нибудь.

Поставь на линуксе веб сервер. Прикрути к нему php и mysql, поставь wordpress, убедись что все работает. Вот уже что-то есть. Сделай бэкап всего, поломай и восстанови из бэкапа.

Подними мониторинг, который будет что-нибудь мониторить, свободное место, нагрузку на CPU.

Настрой уведомления от твоего мониторинга на почту или в телеграм.

Ну вот уже для начала что-то будет.
Потом можно будет почитать как єто все делается другими инструментами. Или все тоже самое но в докере.

Зависит от вашего сеоплана, от него и надо толкаться
Тостер один из самых грешных примеров так как он был и в директории основного сайта и на отдельном домене и теперь на субдомене, это называется горе от ума, тостеру понятное дело только плохо и до какого нибудь стековерфлоу ему надо набрать популярность в тысячи раз

Помогли решить так

add_filter( 'woocommerce_get_price_html', 'product_price_free_zero_empty', 100, 2 );

function product_price_free_zero_empty( $price, $product ){
if ( '' === $product->get_price() || 0 == $product->get_price() ) {
    $price = '<span class="woocommerce-Price-amount amount">Цену уточняйте</span>';
}
return $price;
}

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

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

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

Не создаётся. Но при изменении первичного индекса таблица полностью пересоздаётся с новым физическим порядком записей.

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

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

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

В системном журнале безопасности (Security Log) смотрим события 4624 (успешная аутентификация - An account was successfully logged on) или 4625 (ошибка аутентификации - An account failed to log on) с LogonType=10.
В описании события имя пользователя - в поле Account Name, имя компьютера - в Workstation Name, IP-адрес - в Source Network Address

GeoIP ngx_http_geoip_module

1. Nginx должен включать модуль ngx_http_geoip_module.
2. Качаем БД GeoLite2 Country.
3. Пример конфига (nginx.conf), с отправкой всех из Индии в 403 лес:

http {
    geoip_country /path/to/GeoLite2-Country.mmdb;
    map $geoip_country_code $allowed_country {
        default yes;
        IN no; # banned india
    }
}

server {
    if ($allowed_country = no) {
        return 403;
    }
}

Классика говорит, что НЕТ!
Сети НЕ ДОЛЖНЫ ПЕРЕСЕКАТЬСЯ!

"Костыли" при определенных условиях возможны, вроде proxy arp, проброса портов и.т.д.
Но они имеют свои ограничения и условия применимости.

Самое правильное одну из сетей перекинуть в другой диапазон, например
192.168.1-255.0/24
Если так уж принципиально 192.168.0.xxx
Можно одну сеть сделать
192.168.0.0/25 (адреса 1-126)
вторую
192.168.0.128/25 (адреса 129-254)
Если в каждой сети менее 120-ти хостов,
и маршруты 192.168.0.0/24 указать в VPN.

Учитывая отсутствие возможности изменения второй сети и жесткое условие сохранения адрессации -- нормального решения НЕТ!
Узел 192.168.0.12 в сети 1 НИКОГДА не сможет связаться (по IP) с узлом 192.168.0.12 в другой сети.
Вот СОВСЕМ!
(Проброс портов не считаем, это несколько иное условие).