When trying to perform a File Backup job using Veeam Backup and Replication (specifically version 10.0.0.4461) it would randomly fail with An unexpected network error occurred. This backup job was configured to backup a local NFS File Share to a local SMB (CIFS) backup repository. Repeating the job would result in another failure but differing amounts of data being transferred each time.  After the failure, the job report listed items such as NasMaster.ExecuteBackupProcessor and boost::filesystem::status:.

It continued to fail even after setting the Backup I/O control of the NFS File Share to the lowest impact value. To resolve it the backup repository was switched from SMB/CIFS to NFS.  After this change the Backup I/O control setting was also reset back to the default (middle) value.  This solution likely indicates a problem with the destination (backup repository), so if you need to keep it as SMB/CIFS then you can try adjusting the Load Control settings of the repository (right click Properties menu -> Repository). For example try reducing the maximum number of concurrent tasks. If it fails with just 1 task then you may also need to try limiting the data rate.

If you forgot the login credentials for the web account, here is how to perform the reset.

1. Access the VM appliance console
2. Stop the PowerChute service

   /etc/init.d/PowerChute stop

3. Edit the configuration file

   vi /opt/APC/PowerChute/group1/pcnsconfig.ini

4.  In the [NetworkManagementCard] section of the INI file, add the following lines with your desired values:
   username= new user name
   password= new password
5. Save and close
6. Restart the PowerChute service

   /etc/init.d/PowerChute start

A CyberPower CP1500AVRLCD unit originally came with two batteries, B.B. Battery HR1234W with dimensions 6.00 x 2.60 x 3.70 in. (LxWxH).  If you replaced them and forgot how to wire them back up, you can refer to the below diagram:

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.

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.

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: the last line of this file should be preserved (exit 0).

#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

BuddyPress @mentions were working perfectly within WordPress posts and comments however not in bbPress.

This is one solution to get @mention user lookups and an email notification when used in a topic or thread reply.  However a notification is not logged within BuddyPress.

First create or modify the following file in your WordPress install
/wp-content/plugins/bp-custom.php

Sources:

bp-custom.php

https://gist.github.com/imath/5a3c4ac645ec765863f2

<?php
function custom_bbpress_maybe_load_mentions_scripts(
$retval = false ) {
if ( function_exists( 'bbpress' ) && is_bbpress() ) {
$retval = true;
}
return $retval;
}
add_filter( 'bp_activity_maybe_load_mentions_scripts', 'custom_bbpress_maybe_load_mentions_scripts' );

Then you will need to install the bbPress Toolkit plugin for WordPress.

Once activated navigate to Tools -> bbP Toolkit in WordPress Dashboard. Then choose Extras at the top and confirm mentions are enabled.

A second option is to use the bbp Mentions Suggest plugin available at this website:

bbp Mentions Suggest

These are the minimum steps I needed to get WordPress running on Ubuntu Server 18.04. It is based on the below guide at the time of this writing:

How to install WordPress

1. During the install and setup of Ubuntu Server 18.04, the only option I chose beyond the defaults was to install Open SSH server but is not required depending on your needs.
2. sudo apt install apache2
3. Optional: if you want SSL support
   sudo a2enmod ssl
4. sudo apt install mysql-server
5. Set up a MySQL user and database for WordPress to use by using the debian-sys-maint user:

   sudo cat /etc/mysql/debian.cnf

   mysql -u debian-sys-maint -p(copy/paste the password from the previous cat output)

   CREATE USER 'username'@'localhost' IDENTIFIED BY 'password'; CREATE DATABASE your_dbname DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; GRANT ALL PRIVILEGES ON your_dbname.* TO 'username'@'localhost'; FLUSH PRIVILEGES; quit;

6. sudo apt install php libapache2-mod-php php-mysql php-gd php-xml php-mbstring
7. By default apache will look at /var/www/html location for your WordPress install, but you can modify it with these steps
   sudo nano /etc/apache2/sites-enabled/000-default.conf
   in this example we will change DocumentRoot line to be /var/www/wordpress
8. Optional: if you want SSL support add this entire block<VirtualHost *:443>
   ServerAdmin [email protected]
   DocumentRoot /var/www/wordpress
   SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
   SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
   </VirtualHost>
9. cd /var/www
10. sudo curl -O https://wordpress.org/latest.tar.gz
11. sudo tar xfvz latest.tar.gz
12. sudo cp wordpress/wp-config-sample.php wordpress/wp-config.php
13. sudo nano wordpress/wp-config.php
14. Modify database_name_here, username_here, password_here
15. sudo chown -R www-data:www-data /var/www/wordpress
16. Allow .htaccess permissions in Apache2 (otherwise changing the Permalinks settings in WordPress will result in 404 errors, as well as plugins that rely on subfolders to serve content).sudo nano /etc/apache2/apache2.conf
    Find the section where Directory parameters are specified and add the following block:
    <Directory /var/www/wordpress/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
    </Directory>sudo a2enmod rewrite
17. If you need to adjust maximum upload filesize and post size for PHP it is found in /etc/php/7.2/apache2/php.ini
    Then change upload_max_filesize and post_max_size
18. sudo systemctl restart apache2
19. Done

Specific setup was Windows Server 2012 R2 and UniFi Controller 5.12.35.   The issue was that suddenly neither internal connections (LAN/private) nor external WAN (public/WAN) connections  could access the controller.  If Windows Firewall is enabled, the UniFi controller needs two apps allowed: UniFi DB Server and Java.

UniFi DB Server default location is
C:\Users\xxxx\Ubiquiti UniFi\bin\mongod.exe
where xxxx is the username

Java (32-bit) default location is
C:\Program Files (x86)\Java\jrex.x.x.x_xxx\bin\java.exe
where jrex.x.x.x_xxx is the folder name. This folder path changes depending on the version number of Java Runtime Environment installed.

The root cause was that Java was updated on the system but a new rule was not automatically created for it in Windows firewall. Upon inspection there were several rules for Java already present in the firewall but none were for the most recent version.

To check, navigate to Control Panel – Windows Firewall then choose the option for Allow an app or feature through Windows Firewall.

Find Java and then click the Details button. Here you can check if the path to java.exe matches the version that is installed.  You can manually add the new version by using the Allow another app button.

Once allowed check to see if the controller can be accessed again.

These are the steps to crossflash a Dell 0WFN6R (SAS9341-8i) to an LSI 9300-8i. At the time of this guide the latest firmware available is P16.

All files needed for this guide can be downloaded here. The firmware and BIOS files were sourced directly from Broadcom’s website (Installer_P16_for_UEFI.zip and 9300_8i_Package_P16_IR_IT_FW_BIOS_for_MSDOS_Windows.zip specifically).

For UEFI method you will use sas3flash.efi.  You can perform this same procedure with BIOS method by instead using sas3flsh.exe. However if in BIOS mode you receive ERROR: Failed to initialize PAL. Exiting Program, then you must switch to the UEFI method.

1. Make a record of the Assembly number and SAS Address from the stickers on the back of the card
2. Create your bootable USB disk with Rufus, formatted as FreeDOS.  Extract the files from this guide to the root of the drive.
3. Place jumper on TP12 located on the front rear of the card near the two SAS ports. Otherwise you will receive the error: No Avago SAS Adapters found! Limited Command Set Available! when trying to use SAS3Flash.
4. Boot from the USB disk either UEFI or BIOS. For BIOS method substitute sas3flsh.exe for sas3flash.efi in all steps below.
5. Navigate to the SAS3Flash binary on the USB drive
6. Confirm the the 9341 card is detected:

   sas3flash.efi -list

7. Perform preliminary flash of the firmware:

   sas3flash.efi -noreset -f SAS9300_8i_IT.bin

8. Once you receive a confirmation that the flash was successful, power off the system and remove the jumper. Reinstall the card and boot off the USB drive.
9. Wipe the card :

   sas3flash.efi -o -e 6

10. Flash the firmware:

    sas3flash.efi -f SAS9300_8i_IT.bin

11. At this point you can stop if you don’t want any BIOS on the card.  It is needed if you want to boot from a drive attached to the card.
12. Flash the BIOS:

    sas3flash.efi -b mptsas3.rom

13. Flash the UEFI rom:

    sas3flash.efi -b mpt3x64.rom

14. Program the SAS address (don’t include hyphens as they will be added automatically): Note – you can perform this later at any time.

    sas3flsh.exe -o -sasadd XXXXXXX

15. Program the board assembly (you DO need to include hyphens with this):
    Note – you can perform this later at any time.

    sas3flsh.exe -o -assem XXXXXXX

16. Verify your results:

    sas3flash.efi -list

17. You should see your SAS address, firmware version 16.00.10.00,  BIOS version 08.37.00.00, UEFI BSD Version 18.00.00.00 and your board assembly.  Crossflashing is now complete.