I had a CentOS 7 system running WordPress and received the warning: WordPress has detected that your site is running on an insecure version of PHP.  The system was running PHP 5.6 which is end of life, so here are the steps I used to upgrade to the latest version recommended by WordPress at the time of this posting (PHP 7.3).

1. If not already installed:

   sudo yum install epel-release

2. Add the IUS repository that maintains updated PHP packages.
   More information can be found at the following site including these commands:
   https://ius.ioFor CentOS 7

   yum install \
   https://repo.ius.io/ius-release-el7.rpm \
   https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

   For CentOS 6

   yum install \
   https://repo.ius.io/ius-release-el6.rpm \
   https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

   Note: if you get Error: Nothing to do when  using the above commends it means you may already  have the repository installed and is safe to ignore.

3. Since we are using IUS repository we will use the replace plugin
   More information about this plugin for reference:
   https://github.com/iuscommunity/yum-plugin-replace

   yum install yum-plugin-replace

4.  The next step depends on your specific configuration. If you are on a stock CentOS 7 install you can use

   yum replace --replace-with php73-common php

   Note: if you receive Error: Package ‘php’ is not installed then you are not on a stock install and you must replace php with the specific version you have installed. Inspect the output of the command:

   yum list installed | grep php

   Then perform the yum replace command using the package name you have installed. For example:

   yum replace --replace-with php73-common php56u

   Note: if you receive WARNING: Unable to resolve all providers it probably means identical replacements for all php extensions could not be found which is typical. Press y to continue.

5. This server was running Apache so it needs to be restarted for the new PHP to take effect:

   apachectl restart

6. At this point the WordPress installation was broken: There has been a critical error on your website.   Setting WordPress into debug mode revealed the following Fatal error: Uncaught Error: Call to undefined function json_encode() … /wp-includes/functions.php:3820 To resolve it, install the json extension:

   yum install php73-json

7. Then restart Apache again

   apachectl restart

8. Now WordPress should be functional again and no longer reporting an out of date version of PHP.

Attempting to backup a Windows Server 2012 R2 Server with the Veeam Agent freshly installed and Backup and Replication server version 9.5 (also 10). The administrator credentials for the source server had been added to the destination server (Backup and Replication) and a backup job with type Windows Agent Backup was created. When running the job it would fail with error: Processing ServerName Error: Failed to connect to x.x.x.x:11731

The reason is because the source Windows Server was not properly added to the infrastructure of the destination Backup and Replication server. Checking the Programs and Features installed on the source Windows Server, only Veeam Agent for Microsoft Windows was listed. The Veeam Installer service was missing, which is triggered to install by the destination Backup and Replication server.

To resolve it, from Backup and Replication server navigate to Physical Infrastructure, Manually Added. Then perform a Rescan. Once complete you should see a confirmation that the Backup agent is installed on the source Server. Checking Programs and Features of the source Windows Server 2012 R2, the Veeam Installer Service should now be listed as installed.  The backup job on the destination server can now be restarted and should complete without the  previous failed to connect error.

Update 09-May-2020: The original script didn’t really work so I have commented it out.
Update 11-May-2020: Added method to search by Volume Name.
Update 23-Mar-2023: This also works for TrueNAS
Update 18-Aug-2025: Readded note 2 and link to official documentation

There are several reasons you may want to have ESXi rescan iSCSI at boot. For this example a FreeNAS guest VM was running an iSCSI target and sharing it back to the ESXi host. ESXi was then using it as a datastore with other VMs on it that also needed to be autostart. The trick is to start the FreeNAS guest and give it enough time to boot before letting ESXi proceed to the autostart step.

For troubleshooting, the script uses logger to send text to /var/log/syslog.log of the host.

This script should be added to the following file in ESXi (using vi) so that it is preserved by ESXi upon reboot:

/etc/rc.local.d/local.sh

Note 1: the last line of this file should be preserved (exit 0).

Note 2: This script will not be run when UEFI secure boot is enabled.

More information can be found on Broadcom’s support site:

https://knowledge.broadcom.com/external/article/324525/modifying-the-rclocal-or-localsh-file-in.html

#Establish our timer
count=0

#Power on the guest VM with the specified Vmid
#use the command vim-cmd vmsvc/getallvms to find which Vmid to use
vim-cmd vmsvc/power.on 1

#Now continuously rescan for the iSCSI device until it is found
#or the maximum time of 10 minutes is reached.
#This command will search all Logical Devices for one that has "Vendor_Name" in the Display Name (e.g., FreeNAS)
while ! esxcfg-scsidevs -c | grep -q 'Vendor_Name'

#Alternatively if you have multiple iSCSI targets that share the same Display Name
#(iSCSI Vendor) then you may want to instead search by Volume Name.
#This method allows you to single out a specific server since Volume Name is user configurable.
#The command below will search for the volume name 'Your_custom_volume_name' and that Mounted status is true.
#while ! esxcli storage filesystem list | grep -q "Your_custom_volume_name.*true"
do
    #print some debugging info to the syslog
    logger "local.sh: Forcing rescan since iSCSI target is not yet available..."
    
    #Rescan SCSI HBAs to search for new Devices, remove DEAD paths and update path state. 
    #This operation will also run an claim operation equivalent to the claimrule run command and a filesystem rescan.
    esxcli storage core adapter rescan --all

    #Now wait (in seconds) before checking again
    sleep 30

    #Increase the timer
    count=`expr $count + 30`

    #Check if maximum time has been reached (in seconds)
    if [ $count -ge 600 ]
    then
       logger "local.sh: Aborting, maximum time reached while searching for iSCSI target."
       break
    fi
done

logger "local.sh: Search time for iSCSI target was" $count "seconds."

#-------------- Old script is below, do not use

#Adjust the delay in seconds as needed to allow time for NAS to boot up fully
#sleep 300

#Enable iSCSI Initiator and rescan for iSCSI specific LUNs.
#esxcfg-swiscsi -e
#esxcfg-swiscsi -s

#Search for new VMFS datastores. If a new datastore has been detected, it is mounted in /vmfs/volumes/
#vmkfstools -V

#another delay just to be sure
#sleep 10

#Run the ESXi autostart script again to start all VMs that are on the datastore
#sh /usr/sbin/vmware-autostart.sh start