When sending alerts from MegaRAID Storage Manager (MSM) fails, even though the SMTP-server configuration is correct and the network access is permitted, it might be due to what I believe is a bug in MSM.

I've seen this issue in servers with multiple NICs/servers having changes made to the pNICs after configuring MSM.

In short, the configuration utility does not bind to the correct IP-address/NIC when saving the configuration. This setting is nowhere to be seen in MSM, which is why it took me hours to figure out. To check and potentially fix the issue, do the following:

1) Open MSM and navigate to Tools > Monitor Configure Alerts

2) Make sure the settings for the SMTP-server are correct

3) Click Save Backup, store the file monitorconfig.xml on the Desktop and click "OK" to close the Configure Alerts-window

4) Edit monitorconfig.xml with Notepad or another text-editor

5) Find the <nic>-tag in the file and set it to the IP-address of the interface that should be used to access the SMTP-server

Example, see last line:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<monitor-config>
<actions>
<popup/>
<email>
<nic>10.106.22.40</nic>
...

6) Save the file and return to MSM

7) Navigate to Tools > Monitor Configure Alerts

8) Click Load Backup, then Yes, select monitorconfig.xml and click OK

9) Navigate to Tools > Monitor Configure Alerts and test again

Note: The dialog may display "The test email could not be sent. Check the mail server settings and try again." - ignore this and check if the email is delivered within a few minutes.

I don't know the mechanism MSM uses for verifying the email is sent - more often than not, the error displays but the email is delivered anyway.

Versions tested: 16.05.04.01, 17.05.00.02, 17.05.01.03

Valheim beta is regularly updated, this goes for both server and client. The client is usually updated automatically via Steeam, however the dedicated server is not. When the versions mismatch, ie: the server is behind; clients can no longer connect to the server.

Updating the server to the latest beta is easy, yet manual. I've written a few scripts to take care of this process. It could be improved in many ways, but it works so why bother.

Note: This procedure requires steamcmd

1) Create a start-script for Valheim, mine is called valheim.sh and is placed with the binary:

#!/bin/sh
export templdpath=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./linux64:$LD_LIBRARY_PATH
export SteamAppID=892970
echo "Starting server PRESS CTRL-C to exit"
./valheim_server.x86_64 -name "valheim" -port 12345 -nographics -batchmode -world "worldname>" -password "password" -public 1
export LD_LIBRARY_PATH=$templdpath

2) Start a screen named valheim by running screen -S valheim

3) Run valheim.sh to start the dedicated server and detach from the screen

4) Create a new script called valheim_nightly_update.sh with the following content:

#!/bin/bash
VALSCREEN=valheim
echo "Sending Control+C to $VALSCREEN"
screen -S $VALSCREEN -X stuff $'�03'
echo "Sleeping 10 seconds, let Valheim server shut down..."
sleep 10
echo "Sleep done"
echo "Running update check and install..."
/bin/bash /home/aners/valheim/InstallUpdate.sh
echo "Update check and install complete, sleeping 5 seconds"
sleep 5
echo "Starting Valheim-server"
screen -S valheim -X stuff 'sh /home/aners/valheim/valheim.sh'`echo -ne '�15'`

5) Create a crontab for the script with a runtime of your chosing

Mine looks like this:

# m h  dom mon dow   command
0 5 * * * /bin/bash /home/aners/valheim_nightly_update.sh

Every morning, my Valheim server is stopped, updated and restarted.

First use the storcli binary to identify failed drives on each controller (sure, multiple instances of grep could be improved with regex)

./storcli /cALL/eALL/sALL show all|grep Failure|grep -vi predict

   Example output:

Status = Failure
/c0/e1/s5  Failure    46 -

  Start locating the failed drive:

./storcli /c0/e1/s5 start locate

  Example output:

CLI Version = 007.1017.0000.0000 May 10, 2019
Operating system = VMkernel 6.7.0
Controller = 0
Status = Success
Description = Start Drive Locate Succeeded.

   Stop locating the failed drive:

./storcli /c0/e1/s5 stop locate

  Example output:

CLI Version = 007.1017.0000.0000 May 10, 2019
Operating system = VMkernel 6.7.0
Controller = 0
Status = Success
Description = Stop Drive Locate Succeeded.

  To stop locate for all controllers, run the following command:

./storcli /cALL set activityforlocate=off

1) Go to Network Preferences

2) Configure IP-address on the wired connection: 10.39.105.2/24

3) Edit a new file for the server-configuration, run sudo nano /etc/bootpd.plist and add:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>bootp_enabled</key>
      <false/>
      <key>detect_other_dhcp_server</key>
      <integer>1</integer>
      <key>dhcp_enabled</key>
      <array>
        <string>en0</string>
      </array>
      <key>reply_threshold_seconds</key>
      <integer>0</integer>
      <key>Subnets</key>
      <array>
        <dict>
          <key>allocate</key>
          <true/>
          <key>dhcp_router</key>
          <string>10.39.105.1</string>
          <key>lease_max</key>
          <integer>86400</integer>
          <key>lease_min</key>
          <integer>86400</integer>
          <key>name</key>
          <string>10.39.105</string>
          <key>net_address</key>
          <string>10.39.105.0</string>
          <key>net_mask</key>
          <string>255.255.255.0</string>
          <key>net_range</key>
          <array>
            <string>10.39.105.100</string>
            <string>10.39.105.200</string>
          </array>
        </dict>
      </array>
    </dict>
</plist>

Save the file by hitting Ctrl+X then typing y and then hit the enter-key

4) Start the DHCP-daemon: sudo /bin/launchctl load -w /System/Library/LaunchDaemons/bootps.plist  

5) Stop the DHCP-daemon: sudo /bin/launchctl unload -w /System/Library/LaunchDaemons/bootps.plist

Use ovftool to deploy the image directly to the ESXi-host instead:

ovftool -dm=thick -ds=<DATASTORENAME> -n=<VMNAME> --net:"VM Network"="<VMNETWORKNAME>" "junos-media-vsrx-x86-64-vmdisk-18.2R1.9.scsi.ova" vi://root@esxi-host.tld

Replace with your own settings

Enable IKE debug logging in Junos by configuring the following:

set security ike traceoptions file ike-debug
set security ike traceoptions file size 10m
set security ike traceoptions file files 2
set security ike traceoptions flag all
set security ike traceoptions level 15
set security ike traceoptions gateway-filter local-address 10.0.0.123 remote-address 172.16.0.123

The log file is written to /var/log/ - disable the configuration when it's no longer needed, to not wear down the CF/SSD in the device.

Extras:

request security ike debug-enable local 10.0.0.123 remote 172.16.0.123

show security ike traceoptions

show security ike debug-status

Add the following line to /etc/fstab to create an 8 GB RAM-drive in Linux with tmpfs

tmpfs           /mnt/ramdisk tmpfs      defaults,size=8192M 0 0

Mount with sudo mount -a and use /mnt/ramdisk/

If a snapshot seems stuck, use the console to verify a task is actually running:

1) Run vim-cmd vmsvc/getallvms and note the relevant VM-ID 2) Run vim-cmd vmsvc/get.tasklist <VM-ID> and note the Task-id 3) Run vim-cmd vimsvc/task_info <Task-id> to get task status 4) Browse to the VMs location on the datastore and run watch -d 'ls -lut | grep -E "delta|flat|sesparse"' to monitor the process