Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings san The results would be similar to: san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name of the SAN, an array of serial numbers (if applicable – rarely encountered these days), the owner info plugged in earlier…
-
-
Configure Xsan Clients Using macOS Server 5.4
Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone, as of El Capitan, but unchanged from then to macOS Sierra (other than a couple of binaries moving around). These days, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf.…
-
Configure Xsan Clients In Server 5.2
Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone, as of El Capitan, but unchanged from then to macOS Sierra (other than a couple of binaries moving around). These days, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf.…
-
Xsan Command Line Options In macOS Sierra
Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: bash-3.2# serveradmin settings san san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name of the SAN, an array of serial numbers (if applicable – in a purely Mountain Lion/Mavericks SAN they aren’t), the owner info plugged in earlier and the metadata network interface being used. Next, we’ll take a peak at…
-
Configure Xsan Clients With OS X Server 5 For El Capitan And Yosemite
Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone. From now on, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf. To make the Xsan configuration profile, we’re going to use Profile Manager. With OS X Server 5, this trend…
-
Xsan Command Line Options
Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: bash-3.2# serveradmin settings san san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name of the SAN, an array of serial numbers (if applicable – in a purely Mountain Lion/Mavericks SAN they aren’t), the owner info plugged in earlier and the metadata network interface being used. Next, we’ll take a peak at…
-
Locate the UUID of a SAN
You can use the UUID of a SAN MDC in Xsan to perform a lot of tasks. To locate the UUID of a SAN MDC in Xsan: sudo serveradmin settings san:UUID The output is just the GUID of the san client UUID. Now you know.
-
Configure sFlows on a Brocade 8470
sFlow is an industry standard that allows network equipment with the appropriate agents to send data to sFlow collectors, which then analyze network traffic. You can install sFlow on routers, switches, and even put agents on servers to monitor traffic. Brocade (along with most other switch manufacturers) supports sFlow. Before you do anything log into the switch and check the current flow configuration: show sFlow To configure, log into the switch and use the the int command to access an interface. From within the interface, use the following command: sflow forwarding Then exit the interface using the very difficult to remember exit command: exit Repeat the enablement of forwarding for…
-
Yosemite Server And Logs
OS X Yosemite running the Server app has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for OS X Server called server setup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in Yosemite Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data. Sometimes the…
-
Yosemite and The Xsan Command Line
Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: bash-3.2# serveradmin settings san san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name of the SAN, an array of serial numbers (if applicable – in a purely Mountain Lion/Mavericks SAN they aren’t), the owner info plugged in earlier and the metadata network interface being used. Next, we’ll take a peak at…