Tag: Web Server

Error “No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed” (SOLVED)

Debian and derivative distributions (Ubuntu, Linux Mint, Kali Linux, and many others) may experience a “FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed” error when migrating from PHP 8.1 to PHP 8.2.

Apache web server log

sudo tail /var/log/apache2/error.log

contains the following error messages:

[Sun Jan 29 03:05:45.213609 2023] [proxy:error] [pid 1313500] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:05:45.213763 2023] [proxy_fcgi:error] [pid 1313500] [client 127.0.0.1:58950] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:06:39.789031 2023] [proxy:error] [pid 1313496] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:06:39.789110 2023] [proxy_fcgi:error] [pid 1313496] [client 127.0.0.1:50024] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:06:41.336218 2023] [proxy:error] [pid 1313499] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:06:41.336297 2023] [proxy_fcgi:error] [pid 1313499] [client 127.0.0.1:50040] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:07:24.027400 2023] [proxy:error] [pid 1313497] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:07:24.027445 2023] [proxy_fcgi:error] [pid 1313497] [client 127.0.0.1:44688] AH01079: failed to make connection to backend: httpd-UDS
[Sun Jan 29 03:09:55.008467 2023] [proxy:error] [pid 1504919] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.1-fpm.sock (*:80) failed
[Sun Jan 29 03:09:55.008530 2023] [proxy_fcgi:error] [pid 1504919] [client 127.0.0.1:38382] AH01079: failed to make connection to backend: httpd-UDS

Sites and engines that use PHP, such as phpMyAdmin, give the following error:

503 Service Unavailable
Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.55 (Debian) Server at localhost Port 80

The essence of the problem is indicated in the web server logs – it is impossible to connect to the php8.1-fpm.sock socket. This is a fairly predictable problem when changing the PHP version, in this case from PHP 8.1 to PHP 8.2.

FPM (FastCGI Process Manager, FastCGI process manager) is an alternative implementation of PHP FastCGI with several additional features commonly used for high load sites.

To disable an outdated version of FPM, run the following commands:

sudo a2disconf php8.1-fpm
sudo systemctl restart apache2

At this point, engines and sites that don't use FPM should already be working fine.

If you are really using FPM and want to enable the new version, then run the following commands:

sudo a2enconf php8.2-fpm
sudo systemctl reload apache2
sudo systemctl restart apache2.service
sudo systemctl restart php8.2-fpm

How to reboot a server in DigitalOcean

DigitalOcean offers various cloud technologies for developers, but of all the variety of services, I use only VPS (virtual private server).

At the same time, due to the large number of cloud solutions, it is not intuitively clear how to perform such a simple action in DigitalOcean as rebooting the VPS.

The server can be restarted by connecting to it via SSH and executing the command

reboot

But if the server is frozen and SSH is not working, then you can force a reboot of the VPS from the DigitalOcean control panel.

How to restart a VPS in DigitalOcean

Go to the control panel and select Droplets from the menu, then select the server you want to restart.

Then select the “Power” tab.

On it you will see two possible actions:

  • Turn off Droplet – turn off the VPS
  • Power cycle – VPS reboot

That is, to restart the VPS, you need to press the “Power Cycle” button.

After that, wait until the reboot is completed.

What is the difference between Turn off Droplet and Power cycle

Turn off Droplet roughly corresponds to a power outage from your virtual private server. That is, the server stops working. At the same time, the server itself is saved, its IP and IPv6 addresses and other characteristics are saved.

You can turn your server back on at any time.

The “Turn off Droplet” feature is necessary if you want to make it unavailable, shut down your server for any reason.

Please note that turning off the server using the “Turn off Droplet” does not cancel the payment for it! You will still be charged for the plan for VPS in accordance with the selected server parameters!

If you want the server to no longer be charged, then you need to destroy it (that is, go to the “Destroy” section and perform the appropriate actions to delete the server). After deleting the server, it will be impossible to restore it!

The “Power cycle” is to turn off the power from the server, and then turn it on again, that is, this corresponds to a VPS reboot.

That is, you can restart the server by turning off the power in the Turn off Droplet, and then turning it back on manually, or by performing a Power cycle. However, these actions are not quite equivalent:

  • Turning off and on using the “Turn off Droplet” will mean an attempt to send a command to the server to turn off. If this fails, the power will be forcibly turned off. You can then restart the server manually. All of this takes longer overall, but is a bit safer.
  • Using “Power cycle” will turn the power off and back on without attempting to shut down the server safely. Power cycle takes less time (provided that your VPS is healthy and able to boot on its own).

DigitalOcean promo code

If you want to get a DigitalOcean promo code for testing VPS (or other cloud features) for free, then use this link.

You will be given $200, which you can use to create a VPS, among other things.

How to rename a table in phpMyAdmin and MySQL

How to rename a table in phpMyAdmin

Open the database and then navigate to the table you want to rename.

When the table is open, select the “Operations” menu item.

Locate the “Move table to (database.table)” section. Yes, renaming uses the same function as moving a table to another database.

Enter a new table name and click the “Go” button.

Now the table has been given a new name.

How to rename a table in MySQL

To connect to MySQL or MariaDB DBMS on localhost without a password, use the command:

mysql -u root

To connect to MySQL or MariaDB DBMS on localhost with a password, use the command:

mysql -u root -p

Note that you do not need to specify a password after the -p option – you will need to enter the password at the command prompt.

If you are connecting to a remote server, then you can also use the -h (or --host=NAME) option with the host name or IP address.

After connecting to MySQL/MariaDB you can use the following command:

RENAME TABLE `DATABASE`.`TABLE NAME` TO `DATABASE`.`NEW TABLE NAME`;

You can also choose which database to use and leave out the database name next to the table name:

USE `DATABASE`;
RENAME TABLE `TABLE NAME` TO `NEW TABLE NAME`;

An example of renaming a table in MySQL:

RENAME TABLE `test`.`OLD NAME` TO `test`.`NEW NAME`;

An example of renaming a table in MySQL with database preselection:

USE `test`;
RENAME TABLE `OLD NAME` TO `NEW NAME`;

To list tables, use the following SQL query:

SHOW TABLES;

phpMyAdmin error “Error: Undefined constant “SODIUM_CRYPTO_SECRETBOX_KEYBYTES”” (SOLVED)

On Arch Linux, when trying to use the phpMyAdmin 5.3 pre-release, I encountered an error:

Error: Undefined constant "SODIUM_CRYPTO_SECRETBOX_KEYBYTES"

Checking in Debian showed that there is no such problem with phpMyAdmin 5.3.

The reason for the error is that sodium support is not enabled.

How to enable sodium on Arch Linux (Manjaro, BlackArch)

To enable sodium support in Arch Linux and derivative distributions (Manjaro, BlackArch) follow these steps.

Install the php-sodium package:

sudo pacman -S php-sodium

Open the /etc/php/php.ini file:

sudo gedit /etc/php/php.ini

Find the line in it

;extension=sodium

and uncomment it to get:

extension=sodium

Restart the web server for the changes to take effect:

sudo systemctl restart httpd.service

This will enable sodium support and the error in phpMyAdmin 5.3 will disappear.

How to show all errors in PHP 8

How to display all errors in PHP 8

By default, PHP 8 disables showing errors, so if there is a problem while executing a PHP script, nothing will be displayed on the screen. If an error in the program occurred before the output of the HTML code, then you will see a white screen of the web browser.

Where is the error output configured in PHP

Error output is configured in:

  • script code
  • .htaccess file
  • in the PHP configuration file (for example, in php.ini)

The settings in the script code only affect the behavior of the program in which the settings are made.

The settings in the .htaccess file affect all scripts in that directory and subdirectories.

The settings in the php.ini configuration file affect all PHP scripts that are run unless their error output settings are overridden.

Remember that error reporting is very useful while writing and debugging code, but on production servers, error reporting should be turned off to prevent sensitive data from being leaked and making it harder for an attacker to hack the site.

Configuring error output in PHP script

To display all errors, add the following lines to the beginning of the script:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

These settings enable the output of all errors and warnings to the user's web browser.

Warnings about the use of deprecated constructs will be displayed.

Error output to the web server logs is configured separately.

Remember that if fatal errors occur, that is, when the script could not even run due to incorrect PHP syntax, then the rules specified in the php.ini or .htaccess file will be used to output errors. This is due to the fact that if the syntax is incorrect, the PHP interpreter does not understand the entire file, including the above directives. That is, if a semicolon or a curly brace is missing in the code, then errors will be displayed in accordance with the settings in the php.ini file.

Configuring PHP error output in .htaccess file

Enabling error output in the .htaccess file is done by the following directives:

php_flag display_startup_errors on
php_flag display_errors on

For them to work, the web server must have .htaccess files enabled.

Error output to the web server log is performed by the following directive:

php_value error_log logs/all_errors.log

Setting the output of all errors in the php.ini file

The php.ini file is the PHP configuration file.

PHP can use more than one configuration file during its operation.

Location of php.ini file:

  • In Debian and derivative distributions (Ubuntu, Linux Mint, Kali Linux and others), it depends on the PHP version, for example, for PHP 8.1 the path to the file is: /etc/php/8.1/apache2/php.ini
  • On Arch Linux and derivative distributions (Manjaro, BlackArch and others): /etc/php/php.ini

In the php.ini file you will find the following directives:

display_errors = Off
display_startup_errors = Off

To enable error reporting, replace them with:

display_errors = On
display_startup_errors = On

The default value of error_reporting is set to:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

This means that all errors are printed except for deprecation warnings and warnings caused by strict code checking.

To display all errors and warnings, set the following value:

error_reporting = E_ALL

Common Values:

  • E_ALL (Show all errors, warnings and notices including coding standards.)
  • E_ALL & ~E_NOTICE (Show all errors, except for notices)
  • E_ALL & ~E_NOTICE & ~E_STRICT (Show all errors, except for notices and coding standards warnings.)
  • E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR (Show only errors)

See the link for details: https://www.php.net/manual/errorfunc.constants.php

In order for the changes made in the php.ini file to take effect, a restart of the web server is required.

  • In Debian and derivative distributions (Ubuntu, Linux Mint, Kali Linux and others), this is done with the command:
sudo systemctl restart apache2.service
  • In Arch Linux and derivative distributions (Manjaro, BlackArch and others), this is done with the command:
sudo systemctl restart httpd.service

To check that the php.ini file settings are actually applied, create a file, for example, named info.php and copy into it:

<?php
phpinfo();

If you created the file in the root folder of the web server, in a web browser open http://localhost/info.php.

The following screenshot shows that error output is disabled in the php.ini file:

This screenshot shows that error output is enabled in the php.ini file:

Outputting errors to the web server log

Error output to the web server log is configured in the php.ini file.

The following directive is used for this:

log_errors = On

The location of the error file is configured in the web server configuration.

The “error_reporting('all');» и ошибка «Uncaught TypeError: error_reporting()”

When trying to use the following construct:

error_reporting('all');

You will encounter the Uncaught TypeError: error_reporting() error.

Full error log:

[Wed Jul 06 07:29:19.410966 2022] [php:error] [pid 14101] [client 127.0.0.1:58402] PHP Fatal error: Uncaught TypeError: error_reporting(): Argument #1 ($error_level) must be of type ?int, string given in /srv/http/suip/index.php:3\nStack trace:\n#0 /srv/http/suip/index.php(3): error_reporting('all')\n#1 {main}\n thrown in /srv/http/suip/index.php on line 3, referer: http://localhost/suip/

Instead of 'all' you need to provide a constant expressing the level of the error message. Valid values are provided on this page: https://www.php.net/manual/errorfunc.constants.php

The following entry is correct for PHP 8 and means to show all errors, notes, and recommendations:

error_reporting(E_ALL);

Apache window appears and immediately disappears (SOLVED)

When I click on httpd.exe, a black window flickers and then disappears

Apache (httpd) is a command line utility. Strictly speaking, this is a service that is designed to run in the background without a graphical interface. That is, Apache does not have a graphical interface in the form of a familiar window. Therefore, Windows users may feel that the program starts in an unusual way.

To run the program, you need to open a Windows Terminal window (or PowerShell). To do this, press the key combination Win+x, and select Windows Terminal (Admin):

Then you can proceed in two ways.

The first option: you can simply drag and drop the executable file into the command line window. The executable is httpd.exe.

The second option: on the command line, you can change the current working directory to the one where the Apache executable files are located. For example, my program is located in the C:\Apache24\bin\ folder, to change the current working folder, the cd command is used, after which the folder to which you want to go is indicated, in my case the command looks like this:

cd C:\Apache24\bin\

As you can see from the screenshot, the C:\Users\MiAl folder has been changed to C:\Apache24\bin\.

Now, to run the program, it is enough to type the name of the executable file indicating the current folder. The current folder is indicated by a dot (.), then you need to put a backslash, it turns out like this:

.\httpd.exe

Apache is a network service, that is, a program that uses a computer network for its work. Specifically, Apache listens for incoming connections on port 80 (opens a port). For this reason, the Windows Firewall asks whether to allow access to the Apache HTTP Server program, select “Allow access”.

Already at this stage, the web server is running and you can open the address http://localhost/ in a web browser

To stop the service, press Ctrl+c.

Typically, command-line utilities support various options that can be specified with a space after the executable file name.

Also, utilities usually have built-in help on available options, which can be displayed using the -h option or the --help option.

For example:

.\httpd.exe -h

In addition to command line options, many services are configured using configuration files, which are text files with a specific syntax. For Apache in Windows this is the C:\Apache24\conf\httpd.conf file.

To get a complete web server with all the necessary components, follow the steps from the guide “How to install Apache web server with PHP, MySQL and phpMyAdmin on Windows”.

“Failed - Network error” when exporting from phpMyAdmin (SOLVED)

phpMyAdmin allows ones to export databases and individual tables (as well as individual rows) in the web interface.

In the latest stable version of phpMyAdmin 5.1.3, users encountered a problem when exporting data from tables and databases to a file.

Regardless of the selected settings, instead of downloading the file, an error is shown:

Failed - Network error

This is what the error looks like in a web browser:

This bug has been fixed in phpMyAdmin 5.3, which is available as a snapshot version at the time of writing.

You can download phpMyAdmin 5.3 from the direct link: https://files.phpmyadmin.net/snapshots/phpMyAdmin-5.3+snapshot-all-languages.zip

Or go to the download page of the phpMyAdmin site and select the latest version there: https://www.phpmyadmin.net/downloads/

After unpacking phpMyAdmin in the web server folder, no additional configuration is required - the export of databases and tables works again.

phpMyAdmin error “Deprecation Notice in .\vendor\twig\twig\src\Loader\FilesystemLoader.php#40 realpath(): Passing null to parameter #1 ($path) of type string is deprecated” (SOLVED)

At the time of this writing, the latest release of phpMyAdmin (5.1) is not fully compatible with the latest PHP versions (8.1.1), so the program displays the following deprecated syntax notices:

Deprecation Notice in .\vendor\twig\twig\src\Loader\FilesystemLoader.php#40
 realpath(): Passing null to parameter #1 ($path) of type string is deprecated

Backtrace

.\vendor\twig\twig\src\Loader\FilesystemLoader.php#40: realpath(NULL)
.\libraries\classes\Template.php#57: Twig\Loader\FilesystemLoader->__construct(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\\\templates\\')
.\libraries\classes\Theme.php#101: PhpMyAdmin\Template->__construct()
.\libraries\classes\Theme.php#174: PhpMyAdmin\Theme->__construct()
.\libraries\classes\ThemeManager.php#307: PhpMyAdmin\Theme::load(
string './themes/metro',
string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\./themes/metro/',
)
.\libraries\classes\ThemeManager.php#79: PhpMyAdmin\ThemeManager->loadThemes()
.\libraries\classes\ThemeManager.php#121: PhpMyAdmin\ThemeManager->__construct()
.\libraries\classes\ThemeManager.php#385: PhpMyAdmin\ThemeManager::getInstance()
.\libraries\common.inc.php#240: PhpMyAdmin\ThemeManager::initializeTheme()
.\index.php#15: require_once(.\libraries\common.inc.php)
Deprecation Notice in .\vendor\twig\twig\src\Markup.php#35
 Return type of Twig\Markup::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

Backtrace

.\vendor\composer\ClassLoader.php#444: include(.\vendor\twig\twig\src\Markup.php)
.\vendor\composer\ClassLoader.php#322: Composer\Autoload\includeFile(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\vendor\\composer/../twig/twig/src/Markup.php')
.\tmp\twig\46\46f1bfbf4328d3d22fddffb9178fdeb9868d0740e4cc8b5bbd6f2fcfb8e4523e.php#59: Composer\Autoload\ClassLoader->loadClass(string 'Twig\\Markup')
.\vendor\twig\twig\src\Template.php#405: __TwigTemplate_034511bee5325c368ee003e3d97d6cb47c3e1c94ebb527bcf0b76ba7818d1ac6->doDisplay(
array,
array,
)
.\vendor\twig\twig\src\Template.php#378: Twig\Template->displayWithErrorHandling(
array,
array,
)
.\vendor\twig\twig\src\Template.php#390: Twig\Template->display(array)
.\vendor\twig\twig\src\TemplateWrapper.php#45: Twig\Template->render(
array,
array,
)
.\libraries\classes\Template.php#132: Twig\TemplateWrapper->render(array)
.\libraries\classes\Header.php#714: PhpMyAdmin\Template->render(
string 'javascript/variables',
array,
)
.\libraries\classes\Header.php#193: PhpMyAdmin\Header->getVariablesForJavaScript()
.\libraries\classes\Header.php#142: PhpMyAdmin\Header->addDefaultScripts()
.\libraries\classes\Response.php#184: PhpMyAdmin\Header->__construct()
.\libraries\classes\Response.php#215: PhpMyAdmin\Response->__construct()
.\libraries\classes\Plugins\Auth\AuthenticationCookie.php#102: PhpMyAdmin\Response::getInstance()
.\libraries\classes\Plugins\AuthenticationPlugin.php#275: PhpMyAdmin\Plugins\Auth\AuthenticationCookie->showLoginForm()
.\libraries\common.inc.php#263: PhpMyAdmin\Plugins\AuthenticationPlugin->authenticate()
.\index.php#15: require_once(.\libraries\common.inc.php)
Deprecation Notice in .\vendor\twig\twig\src\Markup.php#40
 Return type of Twig\Markup::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

Backtrace

.\vendor\composer\ClassLoader.php#444: include(.\vendor\twig\twig\src\Markup.php)
.\vendor\composer\ClassLoader.php#322: Composer\Autoload\includeFile(string 'C:\\Server\\data\\htdocs\\-phpmyadmin\\vendor\\composer/../twig/twig/src/Markup.php')
.\tmp\twig\46\46f1bfbf4328d3d22fddffb9178fdeb9868d0740e4cc8b5bbd6f2fcfb8e4523e.php#59: Composer\Autoload\ClassLoader->loadClass(string 'Twig\\Markup')
.\vendor\twig\twig\src\Template.php#405: __TwigTemplate_034511bee5325c368ee003e3d97d6cb47c3e1c94ebb527bcf0b76ba7818d1ac6->doDisplay(
array,
array,
)
.\vendor\twig\twig\src\Template.php#378: Twig\Template->displayWithErrorHandling(
array,
array,
)
.\vendor\twig\twig\src\Template.php#390: Twig\Template->display(array)
.\vendor\twig\twig\src\TemplateWrapper.php#45: Twig\Template->render(
array,
array,
)
.\libraries\classes\Template.php#132: Twig\TemplateWrapper->render(array)
.\libraries\classes\Header.php#714: PhpMyAdmin\Template->render(
string 'javascript/variables',
array,
)
.\libraries\classes\Header.php#193: PhpMyAdmin\Header->getVariablesForJavaScript()
.\libraries\classes\Header.php#142: PhpMyAdmin\Header->addDefaultScripts()
.\libraries\classes\Response.php#184: PhpMyAdmin\Header->__construct()
.\libraries\classes\Response.php#215: PhpMyAdmin\Response->__construct()
.\libraries\classes\Plugins\Auth\AuthenticationCookie.php#102: PhpMyAdmin\Response::getInstance()
.\libraries\classes\Plugins\AuthenticationPlugin.php#275: PhpMyAdmin\Plugins\Auth\AuthenticationCookie->showLoginForm()
.\libraries\common.inc.php#263: PhpMyAdmin\Plugins\AuthenticationPlugin->authenticate()
.\index.php#15: require_once(.\libraries\common.inc.php)

To stop these notifications, you just need to use phpMyAdmin version 5.2 or later. At the moment, this version can be downloaded from the link https://files.phpmyadmin.net/snapshots/phpMyAdmin-5.2+snapshot-all-languages.zip

How to protect my website from bots

In the article “How to block by Referer, User Agent, URL, query string, IP and their combinations in mod_rewrite” I showed how to block requests to a site that match several parameters at once – on the one hand, it is effective against bots, on the other – practically eliminates false positives, that is, when a regular user who is not related to bots.

It is not difficult to block bots, it is difficult to find their patterns that expose the request from the bot. There should have been another part in that article, in which I showed exactly how I assembled these patterns. I wrote it, took screenshots, but ultimately didn't add it to the article. Not because I am greedy, but I just thought that this was at odds with the topic of an article that was not the easiest one, and, in fact, very few people are interested in it.

But the day before yesterday, bots started an attack on my other site, I decided to take action against the bot… I forgot how I was collecting data)))) In general, so as not to invent commands every time, now they will be stored here)) You might find this useful too.

How to know that a site has become a target for bots

The first sign is a sharp and unreasonable increase in traffic. This was the reason to go to Yandex.Metrica statistics and check “Reports” → “Standard reports” → “Sources” → “Sources, summary”:

Yes, there is a sharp surge in direct visits, and today there are even more of them than traffic from search engines.

Let's look at Webivisor:

Short sessions from mobile devices, strange User Agents (includes very old devices), specific nature of the region/ISP. Yes, these are bots.

Identifying of IP addresses of the bots

Let's look at the command:

cat site.ru/logs/access_log | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | awk '{ print $1 }' | sort | uniq -c

In it:

  • cat site.ru/logs/access_log — read the web server log file
  • grep '"-"' — we filter requests, leaving only with an empty referrer
  • grep -E -i 'android|iPhone' — filter requests, leaving only mobile ones
  • grep -i -E -v 'google|yandex|petalbot' — remove requests from specified web crawlers
  • awk '{ print $1 }' — leave only the IP address (first field)
  • sort | uniq -c — sort and leave unique ones, display the quantity

In my opinion, everything is pretty obvious, all requests come from the same subnet 185.176.24.0/24.

But now is morning, there is still little data, let's check the log of the web server for yesterday:

zcat site.ru/logs/access_log.1 | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | awk '{ print $1 }' | sort | uniq -c

Yes, all bots came from the 185.176.24.0/24 network.

Basically, you can just block this entire subnet and end up there. But it is better to continue collecting data, then I will explain why.

Let's see which pages the bots are requesting:

cat site.ru/logs/access_log | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | grep '185.176.24' | awk '{ print $7 }' | sort | uniq -c

zcat site.ru/logs/access_log.1 | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | grep '185.176.24' | awk '{ print $7 }' | sort | uniq -c

These commands have new parts:

  • grep '185.176.24' — filter for requests from the attacker's network
  • awk '{ print $7 }' — the requested page in my server logs is the seventh column

The bot requests exactly 30 pages.

We return to the article “How to block by Referer, User Agent, URL, query string, IP and their combinations in mod_rewrite” and block the bot.

But in my case, I can get by with blocking the subnet.

In Apache 2.4:

<RequireAll>
	Require all granted
	Require not ip 185.176.24
</RequireAll>

In Apache 2.2:

Deny from 185.176.24

Keep your finger on the pulse

This is not the first influx of bots that I've been fighting, and you need to remember that the owner of bots changes the bot settings after your actions. For example, the previous time it all started with the following pattern:

  • bots requested 5 specific pages
  • all bots were with Android user agent
  • came from a specific set of mobile operator networks
  • empty referrer

After I blocked on these grounds, the owner of bots changed the behavior of the bots:

  • added URL (now 8 pages)
  • iPhone added as User-Agent
  • the number of subnets increased, but bots still came only from mobile operators

I blocked them too. After that, the bot engine added desktops to the user agents, but all other patterns remained the same, so I successfully blocked it.

After that, the bot owner did not change the behavior of the bots, and after some time (a week or two) the bots stopped trying to enter the site, I deleted the blocking rules.

For further analysis

The command for filtering requests from the specified subnet (185.176.240/24), which have a response code of 200 (that is, not blocked) – useful in case bots change the User Agent:

cat site.ru/logs/access_log | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | grep '185.176.24' | grep ' 200 ' | tail -n 10

A variant of the command for compiling a list of IP addresses given at the beginning of this article, but only requests with a response code 200 are taken into account in the command (those that we have already blocked are filtered out):

cat site.ru/logs/access_log | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | grep ' 200 ' | awk '{ print $1 }' | sort | uniq -c

Command for monitoring the latest requests specific to bots:

cat site.ru/logs/access_log | grep '"-"' | grep -E -i 'android|iPhone' | grep -i -E -v 'google|yandex|petalbot' | tail -n 10

How the influx of bots affects the site

This time, I reacted pretty quickly – a day after the attack started. But the last time bots walked around my site for a couple of weeks before I got tired of it. This did not have any impact on the position of the site in the search results.

Error “Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: mysqli, openssl” (SOLVED)

This post explains the causes of the error and how to fix it.

When self-installing the web server on Windows, for example, following the guide “How to install Apache web server with PHP, MySQL and phpMyAdmin on Windows”, when trying to open the phpMyAdmin address, an error may occur:

Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: mysqli, openssl

It occurs in the latest version of phpMyAdmin (for example, in 5.1.1) in the following cases:

1.

The following line is not added to the php.ini file:

extension_dir = "C:\Server\bin\PHP\ext\"

Open the php.ini file and double-check the value of the extension_dir directive. Depending on the folder where you are installing, you may have a different path instead of "C:\Server\bin\PHP\ext\". This value is correct if you install according to the instructions, the link to which is given above.

2.

The following line are commented in the php.ini file:

extension=mysqli
extension=openssl

Check your php.ini file to make sure these lines are uncommented.

3.

Your system for some reason does not use the settings from the php.ini file, for example, because the php.ini file is named incorrectly.

You can check this by running at the command line:

C:\Server\bin\PHP\php --ini

The output should include the path to the file C:\Server\bin\PHP\php.ini. If it is not, you may not have renamed the file to php.ini or named it php.ini.txt or something.

4.

All the settings in the php.ini file are correct, but the web server has not been restarted, which prevented the settings from being applied.

To restart the Apache web server, run the following command (you may have a different path to the executable file):

c:\Server\bin\Apache24\bin\httpd.exe -k restart

Alternatively, restart your computer.

Conclusion

You can think of more exotic reasons, for example, when copying the PHP executable files, the “ext” folder was not copied. But the essence is always the same: PHP is not configured to use the extensions mysqli, openssl – that is, exactly what the error says.

Loading...
X