CentOS


The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Recently, we were trying to update a WordPress installation that was running under apache in a CentOS 7. When we would press the lovely blue button to update WordPress we would get the following error:

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Installation Failed

At first we thought it was an issue with the privileges on the folder, so we did the following steps to fix the issue:

Find which user is controlling apache server:

We executed the following command to get the name of the local user that was handling the apache web server:

ps -ef | grep apache;

From which, we got the following results:

apache 7289 8523 1 10:35 ? 00:00:03 /usr/sbin/httpd -DFOREGROUND
apache 7293 8523 0 10:35 ? 00:00:02 /usr/sbin/httpd -DFOREGROUND
apache 7316 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7317 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7335 8523 1 10:35 ? 00:00:03 /usr/sbin/httpd -DFOREGROUND
apache 7347 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7348 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7349 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7350 8523 0 10:35 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 7351 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
root 8071 7978 0 10:40 pts/1 00:00:00 grep --color=auto apache

The first column is the name of the user, so we found out that apache local user is the user executing the apache web server.

Repair all file and folder access rights:

After getting the above information we proceeded to update the access rights in our WordPress installation folder (/var/www/example.com)

find /var/www/example.com -type d -exec chmod 755 '{}' \;
find /var/www/example.com -type f -exec chmod 644 '{}' \;
chown -R apache:apache /var/www/example.com;

To our disappointment, nothing changed and we would still get the same error. Luckily enough we had another ace in our sleeve!

Checking the security context of each file and folder:

We executed the following command (ls -Z) to get the security context of the files and folders in the installation folder of WordPress:

ls -Z /var/www/example.com;

Where we got the following results:

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 api
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 favicon.ico
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 license.txt
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 readme.html
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 r-file.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wordfence-waf.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-activate.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-admin
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-blog-header.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-comments-post.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config-sample.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-cron.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-includes
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-links-opml.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-load.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-login.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-mail.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-settings.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-signup.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-trackback.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 xmlrpc.php

What we got from this result: all files and folders marked with the httpd_sys_content_t are not directly editable by the apache web server even though the user has the rights to do so as it is a security step by SELinux.

httpd_sys_content_t
Use this type for static web content, such as .html files used by a static website. Files labeled with this type are accessible (read only) to httpd and scripts executed by httpd. By default, files and directories labeled with this type cannot be written to or modified by httpd or other processes. Note that by default, files created in or copied into /var/www/html/ are labeled with the httpd_sys_content_t type.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_confined_services/sect-managing_confined_services-the_apache_http_server-types

The simple solution

We just changed the security context for the folders and files to httpd_sys_rw_content_t which allows apache web server to edit the files:

httpd_sys_rw_content_t
Files labeled with this type can be written to by scripts labeled with the httpd_sys_script_exec_t type, but cannot be modified by scripts labeled with any other type. You must use the httpd_sys_rw_content_t type to label files that will be read from and written to by scripts labeled with the httpd_sys_script_exec_t type.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_confined_services/sect-managing_confined_services-the_apache_http_server-types
chcon -R --type httpd_sys_rw_content_t /var/www/example.com;

After this command finished, we updated WordPress as normal!

(In case you want to change the security context back to the original just execute chcon with httpd_sys_content_t as parameter on the folders and files you want to operate as read-only).

Advertisements

How to temporarily open MySQL / MariaDB port on CentOS 7 firewall

Recently, we came across a CentOS 7 that was executing MariaDB (MySQL) server. The Database Administrators needed a way to open to the port and allow connections to the SQL server from outside the machine.
As they did not have a specific IP from which they would connect, we provided the following solution.

To temporarily open port 3306

firewall-cmd --add-port=3306/tcp;

To close the port 3306 (method A)

firewall-cmd --remove-port=3306/tcp;

or reload firewalld which will cause it to loose all changes that are not permanent (method B)

firewall-cmd  --reload;

firewalld (Dynamic Firewall Manager) tool provides a dynamically managed firewall. The tool enables network/firewall zones to define the trust level of network connections and/or interfaces. It has support both for IPv4 and IPv6 firewall settings. Also, it supports Ethernet bridges and allow you to separate between runtime and permanent configuration options. Finally, it supports an interface for services or applications to add firewall rules directly.


Building wireshark-2.4.2 on CentOS 7 (64bit)

Recently we were trying to compile WireShark from source on a CentOS 7 (64bit) with GTK3 disabled (./configure --disable-gtk3;).

As seen in the truncated logs below we got some errors.
To resolve them we had to install a few packages using yum.
Specifically, our solution involved the installation of the following:

sudo yum install libgcrypt-devel qt5-qttools-devel libpcap-devel -y;

Truncated logs:

...
checking for libgcrypt-config... no
checking for LIBGCRYPT - version >= 1.4.2... no
configure: error: libgcrypt not found; install libgcrypt-devel package for your system
libgcrypt-devel.i686 libgcrypt-devel.x86_64 
[[email protected] wireshark-2.4.2]$ sudo yum install libgcrypt-devel -y

checking for lrelease-qt5... no
checking for lrelease... no
configure: error: I couldn't find lrelease-qt5 or lrelease; make sure it's installed and in your path
[[email protected] wireshark-2.4.2]$ sudo yum install qt5-qttools-devel

checking whether to use libpcap for packet capture... yes
checking for pcap-config... no
checking for extraneous pcap header directories... not found
checking pcap.h usability... no
checking pcap.h presence... no
checking for pcap.h... no
configure: error: Header file pcap.h not found; if you installed libpcap
from source, did you also do "make install-incl", and if you installed a
binary package of libpcap, is there also a developer's package of libpcap,
and did you also install that package?
[[email protected] wireshark-2.4.2]$ sudo yum install libpcap-devel

[georg[email protected] wireshark-2.4.2]$ ./configure --disable-gtk3

 


CentOS 7: C++: static linking cannot find -lstdc++ -lm and -lc

Recently, we were trying to compile a C++ application with the following compilation command on a CentOS 7 64bit :

g++ -static -O2 -lm -Wall -Wno-unused-result -std=c++11 -DCS_ACADEMY -DONLINE_JUDGE 510152025.cpp -o 510152025;

unfortunately, we got the following errors:

 /usr/bin/ld: cannot find -lstdc++
 /usr/bin/ld: cannot find -lm
 /usr/bin/ld: cannot find -lc
 collect2: error: ld returned 1 exit status

To resolve the issues, we performed the following installations to install the static versions of the glibc and libstdc libraries:

sudo yum install glibc-static libstdc++-static -y;

 


CentOS 7: Setup a DHCP server and provide specific IP based on MAC address

Step 1: Install DHCP service

We installed the Dynamic host configuration protocol software (DHCP service) using the command:

yum install dhcp;

The dhcp package provides the ISC DHCP service and relay agent.

Step 2: Configure the DHCP service

Afterwards, we created the file /etc/dhcp/dhcpd.conf using the following content:

subnet 192.168.0.0 netmask 255.255.255.0 {
 option routers                  192.168.0.254;
 option subnet-mask              255.255.255.0;
 option domain-name              "bytefreaks.net";
 option domain-name-servers       192.168.0.1;
 option time-offset              -18000;     # Eastern Standard Time
 range 192.168.0.90 192.168.0.99;
}

host coolServer {
 hardware ethernet 0e:e0:4b:b4:28:82;
 fixed-address 192.168.0.80;
}

This configuration allowed us to provide a DHCP service to the network for the subdomain 192.168.0.x with the range [90,99].
Also, we statically defined the IP for our coolServer using a filter based on the MAC address of the machine.
If you do not want to provide any range, only static IPs, then comment out (#) the line that starts with the word range .

Step 3: Start DHCP service

systemctl start dhcpd.service;

Step 4: Check the status of DHCP service

systemctl status dhcpd.service;

It is a good idea to verify that there are no errors, so be sure to check the status of the service.
You can ignore the error that says “you did not define a subnet declaration for all devices” if you do not really need to do it.

Step 5: Permanently enable the DHCP service

systemctl enable dhcpd.service;

Additional:

Disable the DHCP service

systemctl disable dhcpd.service;

Stop the DHCP service

systemctl stop dhcpd.service;