Если нужна проверка через переменную - тогда и её добавляйте в форму <input type="hidden" name="ed" value="edit">, а в условии не забудьте поменять $_GET на $_POST.
Хотя логичнее поменять условие на: if (!empty($_POST['id'])) {.
Ещё один момент, ваш код совершенно не защищён от вредоносных SQL-иньекций.
Открывайте вторую консоль в MySQL, и при повисании командой SHOW PROCESSLIST; смотрите, какие процессы чего делают. Может что-нибудь увидите...
Но скорее всего идет перестройка индекса. Можно перед всасыванием дампа сделать ALTER TABLE __tbl_name__ DISABLE KEYS;, конечно заменив __tbl_name__ на своё название заполняемой таблицы. Тогда индексы не будут перестраиваться, вплоть до выполнения команды ALTER TABLE __tbl_name__ ENABLE KEYS;. И вот после этого база задуууууумается...
Ещё вариант - в тексте дампа ищите последнюю попадающую в таблицу запись, а точнее какие запросы идут после этой записи. Может там какая-нибудь ошибка, глюк или некорректная комманда?
Эта ошибка сообщает вам, что систему inotify (слежение за изменениями файла) использовать не получается (упёрлись в лимит), будет использоваться периодическая проверка файла.
Самое простое решение - тупо игнорировать ошибку.
Ну так просто сотрите в строке extension=php_pdo_mysql.so это самое php_, и будет вам желанный результат. А PHP должен сам разобраться, какая именно версия из найденных 3-х ему доступна, и её загрузить. Если не загрузит - значит недоступна ни одна, и нужно этот модуль устанавливать.
Ну всё правильно, раз нет такого файла - то и не будет он подключаться как extension в PHP.
А вот прочитали-бы мой предыдуший ответ в этой ветке, осознали-бы его - глядишь и решилась-бы проблема.
Тогда копайте, что именно передаётся на сайт при curl-запросе (доступно через curl_getinfo($ch, CURLINFO_HEADER_OUT) после выставления curl_setopt($ch, CURLINFO_HEADER_OUT, true);). И сравнивайте с правильным запросом.
Для проверки - обратитесь к какой-нибудь ещё странице сайта (GET /index.php например), и если запрос не приведёт к ошибке "устаревшая сессия" - значит не работает именно этот POST-запрос за AJAX-данными...
Ищите не файл php_pdo_mysql.so, а pdo_mysql.so.
Можно искать командой find /usr/lib/php/ -name pdo_mysql.so.
И в /etc/php.ini он уже должен быть вписан.
Подключите провод в сетевую карту enp5s0 (которая для Internet), сделайте ifup enp5s0 (если он сам атоматически не поднялся, проверять через ifconfig enp5s0, искать "state UP"), и потом пробуйте ping 8.8.8.8.
iptables никто и никогда и не адаптировал под fail2ban, он появился гораздо раньше.
Это скорее fail2ban заточен на использование iptables, потому что его возможности как раз подходят для задач fail2ban, вот тютелька-в-тютельку...
Значит не отрабатывает сама команда блокировки. Как правило используется iptables, ну или firewall типа ufw в случае Ubuntu. Копайте в эту сторону, в логах должны быть сообщения, в том числе и об ошибках...
Мда, всё выглядит очень чудесато.
Вот как так, прямой коннект - есть, а в браузерах - нет?
А может блокировка происходит при обращении к новому https-ному адресу, который в telnet уже не откроешь.
Можно попытаться процедить весь браузер-трафик через Wireshark или MITMProxy, может они что-то вскроют.
А может это срабатывает защита CloudFlare, блокирует вашу подсеть, потому что с неё был какой-нибудь вредный трафик? Но тогда бы и физического коннекта не было бы, я так думаю...
Ну вот, коннект физически проходит, HTTP-сервер вам отвечает, и на другой адрес (https://help.keenetic.com/hc) перенаправление даёт. И совершенно непонятно, почему не хочет работать на одном компьютере, плюс на втором компьютере, да ещё и на мобильнике... Может везде прокси используется, который и блокирует?
Попробуйте открыть сайт в браузере по IP-адресу: https://104.18.248.37/. Браузер конечно будет ругаться, что сертификат не соответствует, выдан на *.zendesk.com, а у вас коннект по IP - ну то есть полное несовпадение, но нам-то только проверить...
А вот если ругаться будет не на подозрительный сертификат, а на отсутствие коннекта - значит кто-то или что-то блокирует и по IP. А кто или что - я уже не скажу, потому что не знаю. Собственно кроме блокировки в proxy - и идей-то нет... Физически ж ведь коннект - проходит, а утройства - разные!
Значит сделайте echo "=={$_POST['id']}==";, что бы увидеть, что запрос на сервер передается.
А если между "==" и "==" ничего нет - стало быть getDB() вызывается с пустым postId.