thinking sysadmin

There is a long-standing bug in (Open)Solaris and derivatives (including NexentaStor) that breaks Active Directory interoperability:

Beginning with Windows Server 2003, Active Directory supports VLV searches. Every VLV search request must be accompanied by 2 request controls: the SSS control and the VLV control. However, Active Directory imposes some general criteria on the SSS control:

1. Cannot sort based on more than one sort keys/attributes.
2. Cannot sort based on the “distinguishedName” attribute (presumably Microsoft does not use the “DN” attribute).
3. Cannot sort based on a constructed attribute (presumably an attribute not stored on Active Directory).

Unfortunately, Solaris LDAP clients use 2 sort keys/attributes: “cn” and “uid” in the SSS control. Subsequently, when dumping a container or a naming database, Solaris LDAP clients would receive LDAP_UNAVAILABLE_CRITICAL_EXTENSION.

$ ldaplist passwd
ldaplist: Object not found (LDAP ERROR (12): Unavailable critical extension.)

This issue has been detailed elsewhere, including at utexas.edu. There appear to be at least four solutions:

1. Wait for the fix from Sun Oracle to reach the light of day: this bug was apparently fixed in SNV 144. (I expect the fix is out in Solaris 11 Express now, but have not tested this myself.)
2. Apply the hotfix in Microsoft’s KB886683 to your domain controllers, which will disable VLV.
3. Run separate ADAM instances with VLV disabled, and point your Solaris machines at them instead of directly at your domain controllers. From the blog post linked above, it sounds like the University of Texas chose this route.
4. Use OpenLDAP as a proxy in front of Active Directory; configure your Solaris machines to use the proxies instead of Active Directory servers. This is the solution detailed in this blog post.

Read the rest of this entry »

1. Create a Fibre Channel LUN on your NetApp and map it to your NexentaStor machine (I’m using version 3.0.2 in this example). For this example, I’ve created a 10GB LUN on a filer running ONTAP 7.2:

   netapp01> lun show /vol/nexenta01/lun01/lun
           /vol/nexenta01/lun01/lun      10g (10737418240)   (r/w, online, mapped)
   

   There are eight paths from our NetApp to our NexentaStor appliance, so the LUN appears eight times on the “qlc” adapter (lines 9-16 below):

   nmc@nexenta01:/$ lunsync
   Cleanup obsolete (dangling) device links?  Yes
   Re-enumerating LUNs... done.
   
   nmc@nexenta01:/$ show lun
   LUN ID      Device    Type         Size       Volume     Mounted Attach GUID
   c0t0d0      sd0       disk         272.3GB    syspool    no      mega_sas 60024e805102c100118a3fa70ae8937a
   c1t0d0      sd128     cdrom        No Media              no      ata    -
   c2t5*DDDd0  sd6       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c2t5*DDDd0  sd4       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c2t5*DDDd0  sd7       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c2t5*DDDd0  sd5       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c3t5*DDDd0  sd3       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c3t5*DDDd0  sd2       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c3t5*DDDd0  sd8       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   c3t5*DDDd0  sd1       disk         10GB                  no      qlc    60a98000486e542f5034577076716469
   syspo~/swap           zvol         1.0GB      syspool    no
   

Read the rest of this entry »