Mar 122014

Okay, this has been a long time coming, but thought I’d write this down before I forget all about it.

First a little bit of a rant. In the EMC world, we assign LUNs to hosts and identify them using a hex-id code called the LUN ID. This, in conjunction with the EMC Frame ID, helps us uniquely and “easily” identify the LUNs, especially when you consider that there are usually multiple EMC frames and hundreds or thousands of SAN-attached hosts in most modern enterprise data centers.

Okay, the challenge is when using a disk multipathing solution other than EMC’s expensive power path software, or the exorbitantly expensive Veritas Storage Foundation suite from Symantec.

Most self-respecting modern operating systems have disk multipathing software built in and freely available.  and the focus item for this blog is Solaris. Solaris has a mature and efficient multipathing software called MPxIO, which cleverly creates a pseudo-device corresponding to the complex of the multiple (or single) paths via which a SAN LUN is visible to the Operating system.

The MPxIO driver, then using the LUN’s global unique identifier (GUID) to, perhaps can be argued, rightly identify the LUN uniquely. This is however a challenge since the GUID is a 32-character string (very nicely explained here

When I first proposed to our usual user community – Oracle DBAs, that they would have to use disks named as shown below, I faced outraged howls of indignation. “How can we address these disks in ASM, etc?”


To work around, we considered creating an alternate namespace, say /dev/oracle/disk001 and so forth, retaining the major/minor numbers of the underlying devices.  But that would get hairy real quick, especially on those databases where we had multiple terabytes of storage (hundreds of LUNs).

If you are working with CLARiiON arrays, then you will have figure out some other way (than what I’ve shown in this blog post) to map your MPxIO/Solaris disk name to the valid Hex LUNID.

The code in this gist will cover what’s what. A friendly storage admin told me about this, wrt VMAX/Symmetrix LUNs. Apparently EMC generates the GUID (aka UUID) of LUNs differently based on whether it is a CLARiiON/VNX or a Symmetrix/VMAX.

In that, the fields that were extracted corresponding to variables $xlunid1 and so forth, and converted to their hex values, is the pertinent piece of information. Having this information then reduces our need to install symcli on every host so that we can extract the LUN ID that way.

This then will give us the ability to map a MPxIO/Solaris Disk name to an EMC LUN ID.

The full script is here —

Jan 072009

Steps to updating flashimage on Sun M5000 servers:

Download latest flash image

Download to usb drive.

I had to rename the file “[]” were put into the name on download.

I made a directory named images

Moved renamed file (FFXCP1071.tar.gz) into images directory.

(The usb port is on the XSCF card in rear of system)

Load image into system memory:

XSCF>getflashimage file:///media/usb_msd/images/FFXCP1071.tar.gz

Answer: Y (Loads image into memory)

Install image:

XSCF>flashupdate -c update -m xcp -s 1071

Answer: Y

Apr 032007


This is a post of an old high-level architecture design I’d worked on, to see how Open-source technology might fit into a Financial Organization’s (my then-employer’s client) Enterprise.

Long-term Goal

  • To design an Enterprise File Transfer mechanism based on high encryption/compression transport mechanism of Secure Shell (SSH).
  • Solution should be easy to use, easy to deploy and cost effective.
  • Solution should be scalable and robust.
  • Solution should integrate the two major OS platforms (UNIX and Windows) “seamlessly

Technical Solution Specs

Secure FTP solution for the Enterprise
Breakup of the requirements

  • Centralized “drop box” or “landing zone” type facility
  • Automated “feeds” type mechanism for further propagation/distribution of data/files
  • Should we try and integrate a transparent layer of version control that’ll maintain audit trails, etc?
  • Easy client access (preferably web-based)
  • Additional client access from Windows environment (fat clients as required)
  • Tight integration with existing authentication mechanism(s) – Active Directory + UNIX logins
  • Low learning curve (meaning, simple solution)
  • Fine-grained access control
  • Ease of administration (centralized user account + privilege management)
  • traceable usage history (auditable transfer logs, user access logs, user activity logs)
  • Easily replicable process of deployment/re-deployment

Possible Solutions (commercial and open-source)

  • Tumbleweed-based Secure transfer mechanism (already investigated and POC’ed)
  • Combination of Windows SSH/SCP/SFTP servers and clients and the pre-existing OpenSSH servers (on UNIX) with Jscape’s SFTP/FTPS applet based web front-end (opensource solution).
  • Vandyke Software’s Vshell software (which gives SSH servers + client command lines for both Windows and UNIX)
  • SSH Tectia software suite

Other Considerations

  • Inter-operability of different technologies
    • The biggest challenge in designing a comprehensive “seamless” Secure FTP solution for any enterprise is in the inter-operability between the disparate platforms. For example, the UNIX servers and the Windows servers need to be able to seamlessly communicate with each other in order for such a solution to be viable.
  • Integrated authentication mechanism
    • The UNIX systems can be made to authenticate against an LDAP server or the Microsoft Active Directory. With the introduction of either an LDAP_PAM module for LDAP based authentication or third-party plug-ins (such as Vintella’s VAS module) that will “hook up” with AD.
    • Keeping such an environment in mind, our solution should be designed to be able to automatically adapt to an eventual roll-out of such an authentication system.
    • This would, as a result, allow for easy, centralized management of user accounts and privileges.

Overview of the Open-technology solution

  • Web-based SFTP system
    • This solution is designed around existing OpenSSH server and client software currently running in the Enterprise (UNIX/UNIX-like platforms). Additional software components like Windows commercial SSH product(s) and Jscape Secure FTP applet will be required to realize this design.
    • Major components:
  • UNIX (Solaris/Linux platforms)
    • OpenSSH Server
    • Apache Web server
    • Jscape’s Secure FTP applet
    • HTML page to load the SFTP applet
  • Windows
    • Commercial SSH/SFTP server
    • IIS web server
    • Jscape’s Secure FTP applet
    • HTML page to load the SFTP applet

Application Client-side Requirements

Operating Systems (supported): Windows 98/2000/XP/ME, Linux, Solaris, Mac OS X
Browser: Internet Explorer or Netscape Navigator/Mozilla (gecko-based) browsers
Java VM: Java Plug-in 1.4.2 or higher enabled

NOTE: For Macintosh users, the MRJ (Mac Runtime for Java) does not include the necessary crypto classes required to establish a secure connection. If using MRJ, you will need to install the Sun JCE (Java Cryptography extensions) reference implementation.?

Strengths and Advantages

  • This solution leverages the existing SSH infrastructure in-house (OpenSSH on UNIX platform already exists in most shops or is available for free downloads) and a cost-effective OpenSource Java Applet based Web interface.
  • This is an extremely simple solution and with pre-determined “drop zone” servers in place at each location, using the mechanism of key-based authentication and command-line tools, administrators will be able to automate and schedule “feeds” transmissions to requested targets.

Additional Requirements

Design customizable scripting framework using Perl (and/or similar programming language) and XML that would allow for automated feeds to be implemented.

 Posted by at 4:16 pm