November 2007

You are currently browsing the monthly archive for November 2007.

Some Notes on Solaris-AD Integration

Tuesday, November 27, 2007 in Interoperability, UNIX by slowe | 8 comments

This afternoon, I walked back through my own instructions for integrating Solaris 10 and Active Directory, and I found that the process wasn’t as smooth as perhaps I’d believed it to be.  As a result of walking back through the process again myself, I’ve collected some notes.  At some point in the near future, these notes will be integrated into a new version of the Solaris-AD integration instructions.

So, without further ado, here are the notes I collected in no particular order:

  • The Blastwave Samba package does not create it’s own smb.conf file in /opt/csw/etc/samba.  This is correctly pointed out in the latest integration instructions, but I wanted to mention it again here.  You’ll need to manually create the /opt/csw/etc/samba/smb.conf file before attempting to join the Solaris server to Active Directory via the ‘net ads join’ command.
  • The defaultServerList portion of the ‘ldapclient manual’ command only supports IP addresses.  The LDAP client service kept going into maintenance mode when using hostnames.  On a hunch, I substituted IP addresses for hostnames, and it worked.  Go figure.
  • Apparently, you can’t use ‘ldapclient mod’ to change an existing attribute map.  I had a hunch about resolving a co-existence issue where both Solaris and Linux are both authenticating against Active Directory—more on that particular topic is coming soon as well—and needed to change the attribute maps for the homedirectory and loginshell attributes.  I ended up editing the ldap_client_file manually (found in /var/ldap; must be made writable using chmod) in order to make the change.  If anyone has a more elegant fix, please let me know.
  • The ‘net ads join’ command correctly creates a Kerberos keytab with the appropriate entries, but places it in the wrong location.  On my test system, it placed the krb5.keytab file in the /etc directory, and Solaris expected it to be in /etc/krb5 instead.  Until I moved that file, authentication against Active Directory consistently failed.
  • It turns out that it’s not really necessary to enable the DNS client using ’svcadm enable svc:/network/dns/client:default’; from what I’ve been able to gather, that’s there as a dependency only.  The ‘nslookup’ and ‘host’ commands seemed to work just fine with this service still disabled.

Again, I’ll be incorporating these changes into a future version of the Solaris-AD integration instructions.  I hope to have that complete within the next week or two, so stay tuned.  In addition, I have information coming to help with the co-existence of multiple UNIX and UNIX-like operating systems all authenticating against the same Active Directory forest, so keep your eyes peeled for that as well.

Tags: , , , , , ,

Is Apple Doing Enough for Mac Security?

Monday, November 26, 2007 in Macintosh, Security by slowe | 2 comments

Apparently, a bug similar to one fixed by Apple in March 2006 has appeared in Leopard.  More information is available from the heise Security and Dark Reading web sites.

The flaw allows attackers to create e-mail attachments that appear to be harmless—say, like a JPEG image—but are actually executables that run malicious code.  In Mac OS X 10.4, users were warned that the attachment is actually an executable file.  It’s doubtful that this new bug is the same bug as was fixed in earlier versions of the OS, although the end result is the same.

I have not seen any information as to a workaround for this flaw, other than to avoid opening e-mail attachments.  It is my understanding that this flaw was made public right around the same time as the release of the latest security updates for Panther and Tiger and the first major update for Leopard, 10.5.1, so I don’t think that a patch for this flaw has yet been made available.

I hope that the emergence of a flaw similar to one corrected in earlier versions of the OS does not indicate a more severe security problem within Leopard or even within Apple.  As it currently stands, I have concerns that Apple is not taking security seriously enough and is “resting on the laurels” that Mac OS X is already secure enough because of its UNIX underpinnings.  It would be a shame for a great OS such as Mac OS X to be tarnished because Apple wasn’t willing to put forth the effort to make it as secure as it needs to be in today’s environments.  Don’t get me wrong; I love the Mac, and I love Mac OS X.  This kind of mistake, however, would get someone like Microsoft tarred and feathered.  Why aren’t we holding Apple to the same standards?  Is Apple really doing enough for Mac security?

Tags: , ,

A Good Look at ESX Server I/O

Saturday, November 24, 2007 in Storage by slowe | 6 comments

This article showed up in my RSS feeds; it’s a fairly in-depth look at the ESX Server I/O stack, written by Nick Triantos.  Nick is with Network Appliance; I believe in their Global Services division.  I’ve bookmarked it for a more comprehensive review later, when I can really dedicate myself to the information he’s sharing here.

As an aside, Nick’s blog recently moved; he used to be here, but now can be found here instead.

Great information—thanks, Nick!

Tags: , , , ,

Happy Thanksgiving!

Wednesday, November 21, 2007 in Personal by slowe | No comments

For those of you that celebrate the Thanksgiving holiday, I hope that your holiday is a pleasant one.  I hope that you take the time to reflect upon all the blessings that God has poured out upon you, and to be thankful for everything good in your life.  I know that I am.  God bless you, and happy Thanksgiving!

Tags:

Quicksilver SSH Plugin

Tuesday, November 20, 2007 in Macintosh by slowe | 1 comment

If you’ve been reading my blog for any reasonable length of time, you already know that I value the Mac OS X-only utility Quicksilver.  It took me some time to get accustomed to it, but I quickly found it indispensable.  Since that time, I’ve been staying alert for new plugins that will help make my life easier.

So imagine my delight last night when I came across this SSH plugin for Quicksilver (updated version available here).  The plugin allows you to make SSH connections to remote hosts, cataloging the known_hosts file along the way to make it easier.  Since I use SSH a lot—it seems like I’m constantly opening an SSH session up to a Linux, Solaris, or ESX Server machine—this plugin is tremendously helpful.  If you use SSH and Quicksilver, I highly recommend this plugin.

Tags: ,

Customizing the Sysprep.inf Created by VirtualCenter

Friday, November 16, 2007 in Virtualization by slowe | 7 comments

The support that VMware VirtualCenter provides for using Sysprep to clone Windows virtual machines (VMs) is a key part of VMware’s quick provisioning functionality.  While VirtualCenter provides a means for creating unattended answer files (via Customization Specifications), it does not provide a way to allow users to customize the Sysprep.inf that is generated by VirtualCenter.  Of course, that is not to say that such customization isn’t possible, just that there isn’t a pretty graphical interface provided for it.  Fortunately, the process for customizing the Sysprep.inf isn’t too terribly difficult.

Using information provided by this Virtrix post, I managed to customize the Sysprep.inf.  A recent Virtual Desktop Infrastructure (VDI) project on which I was working called for VMs to have small Windows pagefiles, but Sysprep kept resetting the pagefile size to the default.  In this case, the default was much larger than the customer desired, so we needed a way to tell Sysprep not to resize the pagefile.

The first step in customize the Sysprep.inf is to decode the VBScript files used by VirtualCenter.  This script decoder works wonderfully, producing unencoded script files that can be easily edited.  Be sure to backup the original files first in the event you run into a problem!  Here’s the commands I used to decode the scripts, which are located in C:\Program Files\VMware\VMware VirtualCenter 2.0\scripts:

move autoprep.wsf autoprep.wsf.backup
move gensysprepinf.vbs gensysprepinf.vbs.backup
scrdec18 autoprep.wsf.backup autoprep.wsf
scrdec18 gensysprepinf.vbs.backup gensysprepinf.vbs

First, I moved the originals to a backup file, then used the backup file as the source for decoding to a new file with the original name.

Once the files are decoded, you can then edit gensysprepinf.vbs to add or remove entries from the Sysprep.inf that is generated by VirtualCenter.  In Vincent’s example, he had to modify the default regional settings; in my case, I needed to change the behavior of Sysprep with regards to the pagefile.  I modified the following section:

outStr = “[Unattended]” & vbCrLf _
& “ OemSkipEula=Yes” & vbCrLf _
& “ InstallFilesPath=\sysprep\i386” & vbCrLf _
& “ KeepPageFile=1” & vbCrLf _

That last line “KeepPageFile=1”, was what I added to tell Sysprep to leave the existing pagefile alone.  That line isn’t perfect, though; this Microsoft KB article describes how it works.  In our case, it was enough.

Once that’s done, I had to edit autoprep.wsf to indicate that the gensysprepinf.vbs file is no longer encoded.  I had to edit the line that referenced gensysprepinf.vbs:

<script language=“VBScript”
src=“gensysprepinf.vbs”>

The key change here is from “VBScript.Encode” to “VBScript” for the language parameter.  This is detailed in Vincent’s post as well.  That’s it!  Of course, you could edit the scripts far more extensively, if so desired.

Thanks to Vincent for a great post; without his post, I wouldn’t have known where to start.  It also looks like Jase McCarty used the same technique in extending the VM’s root partition; although I didn’t read his paper I would guess the same mechanisms are involved.

Tags: , , , ,

VMware Referral Program

Wednesday, November 14, 2007 in Virtualization by slowe | 4 comments

Some of you may have noticed the new “I Recommend VMware Workstation” and “I Recommend VMware Fusion” icons at the bottom of the sidebar on the right.  I hadn’t written specifically about these, but thought it might be a good idea to mention them.  This is part of a new referral program that VMware is testing.  If you are at all interested in using either of these programs and haven’t already purchased them, please consider using the links from this site.  Thanks!

I recommend VMware Fusion

I recommend VMware Workstation

Tags: , ,

Performance in Linux-AD Integration Scenarios

Tuesday, November 13, 2007 in Interoperability, Linux by slowe | 1 comment

A reader kindly shared with me some tips and tweaks he used to help resolve some performance issues with Linux-AD integration, and now I’d like to share them with you:

I ran into some nagging performance issues with Linux/AD integration the other day, and managed to solve them (mostly)—I thought you might be interested in the solution.

Since I’m not exactly following your integration guide (I use DNS lookups to locate LDAP servers in AD, and use GSSAPI authentication for nss_ldap instead of a binddn), I have a bit more overhead on my getent system calls, that was starting to get noticable when it came to getting directory listings, etc.

Two things I have done to alleviate this issue:

  1. Since we have a flat catalog, and all of our DCs are also GCs, I
    disabled recursion. This is not universally relevant, but it does assist me
  2. I edited /etc/nscd.conf to set a 5 minute cache time for passwd and group (but not host!) entries. Data is still usually piping fresh, but now we only call nss_ldap once every 5 minutes, instead of every time we need to know who owns a file. Then I started nscd, and set it to start on boot.

NSCD is a standard part of most RHEL and derivative installs.

Since implementing the above, the user-level experience is no longer
discernably different than the old /etc/passwd method of authentication/authorization.

This is good information to have.  Thanks to Brandon for sharing his experience!

Tags: , , ,

ESX Server and the Native VLAN

Tuesday, November 13, 2007 in Networking, Virtualization by slowe | 6 comments

It was December 2006 when I first published this article on using NIC teams and VLANs with ESX Server. As you can see in the “Top Posts” section in the sidebar, that article has since claimed the top position in the most popular post here on this blog. Note that “most popular” does not translate into “most commented”; that distinction falls to one of the Linux-AD integration articles, although I not sure which one right at the moment.

In that previous article, I demonstrated the use of a “dummy VLAN” which was set as the native VLAN for the VLAN trunk, like so:

s3(config)#int gi0/23
s3(config-if)#switchport trunk encapsulation dot1q
s3(config-if)#switchport trunk allowed vlan all
s3(config-if)#switchport mode trunk
s3(config-if)#switchport trunk native vlan 4094

The idea behind the dummy VLAN was this: because ESX Server needed—or so I thought—all the traffic to be tagged as it came across the VLAN trunk, creating a VLAN that is never used and setting it as the native VLAN solves our problem. Remember that the native VLAN is the VLAN whose traffic is not tagged as it travels across the trunk into ESX Server or another physical switch.

It turns out that I was actually mistaken—sort of. It’s true that the native VLAN won’t get tagged, yes; however, it’s not true that ESX Server requires all the traffic to be tagged. What was missing in my configuration was, quite simply, a port group that was intended to receive untagged traffic.

Configuring ESX Server to support VLANs involves the creation of one or more port groups configured with matching VLAN IDs. If a port group has a VLAN ID, it will essentially only accept traffic tagged with that VLAN ID. Traffic not tagged with that VLAN ID, or untagged traffic, will be ignored. So, if you create a series of port groups on a vSwitch for your various VLANs but neglect to create a port group that does not have a VLAN ID specified, untagged traffic will be ignored because there are no port groups configured to receive untagged traffic.

If, on the other hand, you create a series of port groups for your various VLANs and you create a port group that does not have a VLAN ID specified, then both tagged and untagged traffic will be handled correctly:

  • Tagged traffic with a VLAN ID matching one of the configured port groups will be sent to that port group
  • Tagged traffic with a VLAN ID not matching any configured port group will be ignored
  • Untagged traffic will be directed to the port group that does not have a VLAN ID configured

Now, it is true that VMware’s best practices documents (sorry, I don’t have a link for them at the moment) recommend that users avoid the use of the native VLAN, and one of the CCIEs in my office indicated that it is also considered a networking best practice to avoid the use of VLAN 1, the default native VLAN on Cisco equipment, for anything other than switch management traffic. With those things in mind, it may not be an issue for many deployments.

Except…

…when using automated scripts to build and install ESX Server. You see, after ESX Server is installed, then specifying a VLAN ID on the Service Console port group is no big deal and it will work just fine, as I described earlier. Before ESX Server is installed, though, there is no VLAN support and no way to specify a VLAN ID. Hence, installations that need to download and install from a FTP server or an NFS mount will fail, because the system won’t have any network connectivity. (Everyone understands why, right? If you don’t, go back and read the earlier paragraphs again.)

What’s the fix here? We come back, full circle, to the idea of the default VLAN and untagged traffic. While the system won’t accept any tagged traffic during the install process, it will happily accept untagged traffic during the installation. Therefore, if you set the native VLAN to be the VLAN to which the Service Console should be connected once the installation is complete, then everything should work just fine.

Don’t believe me? From the “Show Me” state? Perform this quick test yourself:

  1. On a test ESX Server, configure the Service Console port group with a VLAN ID of 0. The “esxcfg-vswitch” command is handy for this.
  2. Set the switch port to which the Service Console is physically connected to use a native VLAN different than the VLAN the Service Console was previously using. A VLAN with DHCP present is ideal, as you’ll see with the next step.
  3. Using the “dhclient” command, try to obtain a DHCP lease. You should get a DHCP lease for whatever subnet matches the default VLAN.
  4. Repeat steps 2 and 3 and you should see the DHCP lease follow the native VLAN configuration, i.e., whatever VLAN is set to native will be the VLAN that issues a DHCP address to your Service Console.

Hopefully, this helps clear up some of the misunderstanding and confusion around the use of VLANs, VLAN trunks, port groups, and the native—or untagged—VLAN. Feel free to hit me up in the comments if you have any questions!

Tags: , , , ,

Second VDI Article Published

Tuesday, November 13, 2007 in Virtualization by slowe | 2 comments

Another VDI article I wrote has been published by SearchVMware.com:

In my last article on virtual desktop infrastructure (VDI), I discussed the three main components of a VDI solution: the virtualization servers and supporting infrastructure, the hosted operating system (OS) instances, and the connection broker. In this article, I’d like to take a more detailed look at the connection broker and some of the functionality that brokers provide in a VDI deployment.

Go check out the full article!

Tags: , ,

« Older entries