Tag Archive : SAN

/ SAN

Installing SANnav Management Portal 2.0

22/12/2019 | SAN | 1 Comment

In our previous article, we have gone through the installation steps of RHEL/CentOS, and the basic configuration of SANnav. This article will further focus on implementing the prerequisites and installing SANnav Management Portal.

Before we start, make sure to read Preparing RHEL / CentOS Server for SANnav and SANNav Management Portal guide.

Implementing prerequisites

    1. If you are not the owner of the server, make sure to have the root privileges on your Linux system.
    2. Uninstall other applications from your server.
    3. If you have previously installed Docker, uninstall it.
    4. ‘Ensure that the entire physical server (boot, log, and data) runs on a single partition. In my case, I have 3 partitions and an LVM but I’m using virtual disks on the underlying layer.

 

  • Ensure that lsof and nslookup packages are installed on the server.

 

    1. To install, use the command:
yum install lsof, bind-utils

 

  • The ‘umask’ for the root user must be set to 0022.

 

    1. By default root has already this value, if not use the following command to change it:
umask 0022
  1. Open /etc/security/limits.conf and add the following line at the end: elasticsearch – nofile – 65536
    vi /etc/security/limits.conf
  2. Port 22 is by default in use for SSH. You either keep it for SSH and use it for SANNav repository or change it to another port. To change the default SSH configuration, open /etc/ssh/sshd_config, uncomment #port 22 and change it to 8022.
    Restart SSHD service using the command:

    systemctl restart sshd
  3. Port 80 must also be available. If you are using a firewall in your environment, make sure to open the ports. I would recommend to disable the firewall during installation and enable it after implementing SANnav. See also firewall requirements on the guide.
  4. It is required to have IP forwarding enabled. You can verify using the following command:
    /sbin/sysctl net.ipv4.ip_forward

    To enable IP Forwarding permanently, open the /etc/sysctl.conf file and add the following lines:
    # Enable IP Forwarding for SANnav
    net.ipv4.ip_forward = 1

  5. Ensure that hostname -i resolves to an IP address. If your server is in your domain, hostname -f must resolve to an FQDN.
  6. Ensure that nslookup is successful when launched against other servers.
    If not, verify that /etc/hosts, /etc/nsswitch.conf and that your network card interface is valid.

Installing SANnav Management Portal

I have already downloaded the .tar.gz (compressed packaged) file of SANnav. Using WinSCP I transferred it from my Windows computer to the /root/ directory of the RHEL server.

  1. Locate the file you downloaded and extract it using the command:
    tar -xvzf Portal_2.0.0-distribution.tar.gz
  2. Inside the /bin/diag there is a script which tests the prerequisites. Go to Portal_2.0.0_rc_bld204/bin/diag/ and launch preinstall_system_check.sh

    Verify SANNav Prerequisites
    Verify SANNav Prerequisites
  3.  On the screenshot above, the check claims that nslookup failed but it’s a false positive warning. Didn’t check further but it’s probably due to the package name having another name under RHEL. Launching nslookup commands towards my hosts works like a charm.
  4. To start the installation script, go to /<copied folder>/bin and launch install-single-node-server.sh.

    SANnav installation script
    Installing SANnav using the single-node installation script
  5. On the following screen, accept the License Agreement to continue the installation.
  6. Once the installation of Docker is completed, the setup will proceed with SANnav installation.
  7. At a certain point, you are asked to select the method of communication between SANnav Management Portal and SAN Switches. If you don’t plan to use https and your switches are not configured, select 0 for http. If your switches are already using https connections, select option 1. Optionally you can also select 2 which is https then http.

    SANnav port configuration
    SANnav port configuration
  8. The setup will continue for about 20 minutes. Once it has completed you can launch the client web page on http://<your sever ip>

    SANnav Management Portal 2.0
    SANnav Management Portal web interface.

In my next post, I will document the procedure to implement TLS/SSL certificates on SANnav Management Portal.

To enable https protocol on your Brocade switches, use the steps as described on Enable HTTPS protocol on Brocade switches.

 

Any suggestion or question? Leave a reply below, or contact us. Make sure to also subscribe to our mailing list.

This article will focus on implementing CA-signed certificates and enabling the HTTPS protocol on Brocade switches. I assume you already have a Certificate Authority implemented and you can sign certificates requests.

Required/used freeware

Putty: Used to connect to the switch.
Alex’s FTP Server: Used to upload and download files from or onto the switch.
OpenSSL: Used to convert and test certificate files.
Dos2Unix: Used to convert Windows-created filed to Unix/Linux files.

Deprecated commands:
secCertUtil
secCertUtil CLI will be deprecated. Use secCertMgmt for Certificate related operations.

The command seccertUtil is replaced by secCertMgmt.

It is highly recommended to back up your switch configuration before performing any changes. For tracing purposes, I have configured my Putty terminal to log every session. It will also flush the log file frequently.

Generating Certificate Signing Request (.csr) file

To list available certificates on the switch use the command:

secCertmgmt show -all

To create the .csr file in interactive mode type

seccertmgmt generate -csr https
Generate the Certificate Signing Request
Generate certificate signing request file on Brocade switch

Generate the file and export it locally. Accordingly, request your CA to have it signed.

The following command exports the .csr file in an interactive mode:

seccertmgmt export -csr https -protocol ftp
Export Certificate Signing Request
Export Certificate Signing Request (.csr) file using FTP

Preparing certificates for import

I signed the client’s certificate and got it in a .cer file. I also have the Root and Intermediate certificates in my possession.

Brocade switches require to have root and intermediate certificates merged into one file. The merge order is also important, first the Root certificate then the Intermediate. Work your way up the chain to the root certificate.

Before merging the certificates we will convert them to .pem files. To convert them from .cer to .pem file format use the following command

openssl x509 -in <certificate path & file name> -out <certificate path & file name>
Convert certificate .cer to .pem file
Converting certificate .cer files to .pem file format
Convert certificate files from .cer to .pem format
Converting certificate .cer files to .pem file format

Combining Root and Intermediate certificate

To merge the certificates use the Windows copy command. The /B parameter prevents Windows to append ASCII characters (CTRZ – Z) to the file.

copy /B <file name path 1> <file name path 2> <destination file name path>
Merge certificate files
Merging root and intermediate certificate files

Converting Windows files to Unix

Files created in Windows are sometimes incorrectly read in Unix/Linux. It’s because of Windows handling i.g. newlines and carriage returns in a different way.

In order to “clean” the certificates, we will use the tool dos2unix to convert them into Unix files.

dos2unix.exe <file name>

The file is rewritten and the output is saved under the same location.

Convert windows to unix files
Use dos2unix to convert Windows files to Unix-readable files

Testing certificates

Additionally, we can test the certificate chain and our client certificate using the following command.

openssl verify -verbose -purpose sslserver -CAfile <root certificate.pem> <switch certificate.pem>
Test certificate
Testing client certificate compatibility with the certificate authority chain

Importing certificates

First, we will import the root certificate using the command below.

seccertmgmt import -ca -server https
Importing CA root certificate
Importing CA chain certificate onto the switch

Finally, we can import the switch certificate file.

seccertmgmt import -cert https
Importing client certificate
Importing the client’s certificate onto the switch

We have enabled the switch to communicate over HTTPS protocol and HTTP requests are redirected to HTTPS.

I’ve noticed my Brocade Network Advisor claims that the switch is unreachable after installing the certificate. Finally, I got this resolved by performing a hareboot. The hareboot restarts the web linker daemon which is responsible for web communication.

Any suggestion or question? Leave a reply below, or feel free to contact us. Make sure to subscribe to our mailing list to get the latest.

Brocade ISL Trunk configuration

07/11/2019 | SAN | No Comments

One of the most interesting parts of administrating FC switches is implementing ISL’s (Inter-Switch Links) between 2 datacenters. In this article, we will cover the steps that need to be taken in order to create a fabric. We assume that the physical link (cabling) has already been set up and that the switch is already configured.

On the demonstration below I’m using Brocade SAN switches G62-series running Fabric OS version 8.0.2e.

  1. We start off by disabling the switch.
    FOS_STORCOM1:admin> switchdisable
  2. Next, we need to configure the port speed of the ports which will be inter-connected.
    FOS_STORCOM1:admin> portcfgspeed -i <port number> -f <port speed>

  3. Brocade SAN switches can be easily configured using the configure command. Once entered  it will lead you through some important configuration steps.
  4. Next, we’ll need to calculate the ISL distance. A rule of thumb will be to multiply the real physical distance with 1.5 to get the ISL distance.
    real_distance_km x 1.5 = ISL_logical_distance

    In my case, I have two switches with a physical distance of 146 km. I will use 220 km as ISL distance.

  5. To activate the port in LS (Long Distance Dynamic) mode enter the following command
    FOS_STORCOM1:admin> portcfglongdistance <port number> LS 1

    A vc_link_init value of 1 uses the ARB fill word (default). A value of 0 uses IDLE. The required value might depend on the link being used. The commands must be repeated for each ISL port.

  6. Optionally, you can enable the QOS on the ISL ports by using the following command:
    FOS_STORCOM1:admin> portcfgqos --enable <port number>
  7. To check and confirm the port parameters use the following command:
    FOS_STORCOM1:admin> portshow <port number>
  8. At this step the port is ready. Enable the switch and the ports using the following commands
    FOS_STORCOM1:admin> switchenable
    FOS_STORCOM1:admin> portcfgpersistantenable <port number>
  9. Log on to the second switch and perform the same operations from Step 1 to Step 7
  10. Your SAN fabric should be ready now. Verify it using the following commands:
    FOS_STORCOM1:admin> fabricshow
    FOS_STORCOM1:admin> trunkshow

The article Essential troubleshooting command lines every Storage Administrator should know offers interesting stuff related to the switch administration.

A complete command line list and other switch administration can be found on the Brocade Fabric OS Administration Guide.

Any suggestion or question? Leave a reply below, or feel free to contact us. Make sure to subscribe to our mailing list to get the latest.