Tag Archives: maintenance mode

Mac OS X Mac OS X Server Xsan

Promise X30 Ethernet Setup Woes

The Promise Vtrak requires 3 IP addresses. There are two controllers and each has an IP for maintenance. There’s also a 3rd, virtual IP. When you initially setup the devices, they pull a DHCP or APIPA address and then you typically use Bonjour to log into the WebPAM for the first time. Once in, you configure the addresses and then viola, you’re good.

However, what if something happens? What if you configure the virtual IPs and something happens before you get the maintenance IPs configured. Or what if you never set the maintenance IPs in the first place and always relied on the virtual? Well, the Vtrak used to come with those configured to a default 10.0.0.2 and 10.0.0.3 IP address. You could simply give your laptop 10.0.0.4 and use one of those to tap in. Or put the device in maintenance mode, then tap in that way. However, the devices now ship with the maintenance IPs set to DCHP. For some reason, they don’t always grab an IP properly.

Therefore, you have to log in using a serial adapter, as I described yesterday. Once logged in, you can configure the virtual IP using the command line, using the net command, along with information about the settings to use, using 10.0.0.10 in this example:

administrator@cli> net -a mod -t mgmt -s "primaryip=10.0.0.10, primaryipmask=255.255.255.0, gateway=10.0.0.1"

To set the management ports, use -m and -c followed by the controller number you’ll be configuring (let’s say we’re gonna’ use 10.0.0.2 as used to be the default):

net -a mod -t mgmt -m -c 1 -s "primaryip=10.0.0.2, primaryipmask=255.255.255.0, gateway=10.0.0.1"

To then do the second controller, use -c 2 (let’s say we’re gonna’ use 10.0.0.3 as used to be the default):

net -a mod -t mgmt -m -c 1 -s "primaryip=10.0.0.3, primaryipmask=255.255.255.0, gateway=10.0.0.1"

Once set the IPs should be immediately accessible. View information that’s configured using the net command with no options:

net

Mac OS X Server Ubuntu Unix WordPress

WordPress Site Stuck In Maintenance Mode

When doing updates in WordPress, upgrading the WordPress version or the Plug-Ins causes the site to enter into Maintenance Mode. While in Maintenance Mode, a message appears that says ”Briefly unavailable for scheduled maintenance. Check back in a minute.” rather than the actual site. Sometimes, especially if you’re using the automatic updating functions, an update might fail and the site may be stuck in Maintenance Mode.

WordPress looks at the root level of a directory for some hidden files that can tell a site to operate in a different manner. If there’s a file called “.maintenance” then the site will display the message above. When an update of a Plug-in fails, the .maintenance file is never deleted and the site is stuck in Maintenance Mode. To correct the error, simply ftp into the root of the site and delete the file. It’s hidden, so make sure your ftp software isn’t suppressing the ability to see a hidden file.

Whatever Plug-in or update failed likely also broke something. Usually, if it’s a Plug-in then you’ll need to re-install that plug-in, as the update process removes the old Plug-in and then adds it back. If it’s a Theme, you might need to re-install the Theme.

Programmatically, you can also enable Maintenance Mode by creating this file and then disabling Maintenance Mode by deleting (or renaming) the file again.