How To Ensure WordPress Auto Updates Work on Self-Hosted Linux Machine

Share on LinkedIn

I’ve been meaning to get this posted for some time now. It could prove useful to someone hosting their own WordPress site on a self-hosted Linux machine.

When you are logged into the admin console of your WordPress site, you will get notifications of needed updates. You may also want to upload new themes from time-to-time.

When you go to perform the Automatic Update, it will work without issue so as long as your permissions are setup properly on your apache web server.

If you find yourself running into this issue, ssh into the backend of your apache web server and follow these simple steps:

1. Set ownership of /var/www/html and make changes recursive

chown -R apache:apache /var/www/html

2. Ensure the apache user/group can write to /var/www/html and make changes recursive

chmod -R 0775 /var/www/html

3. Restart apache

service httpd restart

Once you made those changes to the backend, try to run the update(s) again from the admin portal. You should be all good to go from there.

Open LDAP Server TCP Ports on Linux 6.5

What ports should be open in iptables to allow LDAP traffic on your linux server?

Ports 389 and 636

There are a couple ways of doing this.

1. Install nano

yum install nano

2. Edit iptables

nano /etc/sysconfig/iptables

3. These rules work in CentOS version 6.5

-A INPUT -p tcp -m tcp --dport 389 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 636 -j ACCEPT

4. Press Ctrl+X to exit, “Y” to save, and Enter

5. Start or restart iptables depending on its current state

service iptables start

Or

servcie iptables restart
redhat

How To Change MTU Size In CentOS and Linux

I ran into an issue with LDAP replication failing for some our remote sites in South Africa. After some troubleshooting, it looks like the local ISP is restricting MTU. In order to resolve the dropped packet issues and make LDAP replication possible, we had to change the MTU on our local servers sending the packets.

This has to be done at the source, not just at the router/firewall. I’ve read that it’s best if they do match however. For instance, if you set the MTU to 1300 on the ethernet port, set the MTU to 1300 on the firewall. If you set the MTU at the firewall to 1300 and not the source, packet loss will still occur.

I did some basic troubleshooting to find the issue using a ping variation:
ping mydomain.com -f -l 1472

Pinging mydomain.com [172.16.61.1] with 1472 bytes of data:

Reply from 10.0.10.1:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 172.16.61.1:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

 

Solution: Permanently change MTU size on VM (my ping test gave me good results with 1300)

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Output:
DEVICE=eth0
TYPE=Ethernet
UUID=76a8c659-2a7e-459f-abf2-e81230a2ece5
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
#HWADDR=06:74:8A:00:17:D9 # Commented by Clonezilla
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME=”System eth0″

add a setting
MTU=”1300″

Esc
:wq!

Restart network service
service network restart

Verify change took
vi /etc/sysconfig/network-scripts/ifcfg-eth0

Output:
DEVICE=eth0
TYPE=Ethernet
UUID=76a8c659-2a7e-459f-abf2-e81230a2ece5
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
#HWADDR=06:74:8A:00:17:D9 # Commented by Clonezilla
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
MTU=”1300″
IPV6INIT=no
NAME=”System eth0″

After trying ping again, I received a good ping

 

 

After re-initializing my LDAP replication, it started and completed with no problem.

Using chattr CMD To Protect Documents

The form of the chattr command is:

chattr [-RVf] [-+=AacDdijsSu] [-v version] files…
-R is to recurse all subdirectories
+i is to set the immutable bit to prevent even root from erasing or changing the contents of a file.
-i is to unset the immutable bit
The form of the chflags command is:

chflags [-R [-H | -L | -P] flags file …
-H If the -R option is specified, symbolic links on the command line are followed. (Symbolic links encountered in the tree traversal are not followed.)
-L If the -R option is specified, all symbolic links are followed.
-P If the -R option is specified, no symbolic links are followed. This is the default.
-R Change the file flags for the file hierarchies rooted in the files instead of just the files themselves.
Attributes (chattr)[edit]
Some attributes include:

append only (a)
don’t update atime (A)
compressed (c)
no Copy-on-write (C) [2]
no dump (d)
synchronous directory updates (D)
immutable (i)
data journaling (j)
secure deletion (s)
synchronous updates (S)
no tail-merging (t)
top of directory hierarchy (T)
undeletable (u)

I’m using it to keep the /etc/resolv.conf file from changing after a restart
chattr +i /etc/resolv.conf

To enable changes, run
chattr -i /etc/resolv.conf