March 2007

You are currently browsing the monthly archive for March 2007.

New VMotion Boundary

In an earlier article about VMotion compatibility, I mentioned that SSE support was a VMotion boundary, i.e., a host with SSE3 CPUs and a host with SSE2 CPUs would not be able to VMotion guests between them without first masking the SSE support bit.  I used this technique myself in our lab (more info in this article), and this issue drew some attention as the result of a presentation at VMworld last year.

Now, according to this posting on the VMTN forums, the introduction of the Intel quad-core CPUs has introduced another VMotion boundary, and that is the introduction of SSE4.  What this means is that you won’t be able to seamlessly integrate both dual-core and quad-core CPUs into a DRS cluster, because VMotion won’t work between these CPUs.  The only way to move systems from a dual-core SSE3 CPU to a quad-core SSE4 CPU will be a cold migration.  Having now been spoiled by live migrations with VMotion, I suspect a lot of administrators will be more than a bit perturbed by this.

It’s odd that this comes up—I was just speaking to some customers a couple of days ago about VMotion boundaries and CPU compatibility, and I commented that I was not aware of any major developments in CPU capabilities that might introduce new VMotion boundaries.  I guess I was wrong!

I have a feeling that VMware is going to need to resolve this kind of issue sooner rather than later.  As the hardware vendors race with each other to add new features and new virtualization support, we are going to see more and more artificial VMotion boundaries being introduced, and this will eliminate much of the flexibility that VMware currently offers organizations since they will have to resort to buying exactly identical systems.  The sooner that VMware can move into a position of being able to support custom CPU masks, the better off they’ll be in my opinion.

Tags: , , ,

Many VMware Virtual Desktop Infrastructure (VDI) deployments will likely be environments where the virtual desktops will be the only desktops that the user ever logs into.  Environments like outsourced development (developers use hosted desktops so that the source code never leaves the company’s equipment) and call centers are two examples that come to mind.  A recent project in which I was involved, though, was a bit different:  the customer wanted to use hosted desktops to provide access to a specific application (an application which was very data-intensive), but all other applications would be run from traditional “fat” PCs.  Users would be logged in to both a traditional PC as well as a hosted desktop session, typically at the same time.

The customer couldn’t use more mainstream server-based computing solutions such as Citrix Presentation Server or Microsoft Windows Terminal Services because the application wasn’t supported in those environments.  It had to be a desktop environment.  To complicate the matter, the business needs of the organization dictated that users logging into these hosted desktops needed to have some of their settings travel with them (sort of like roaming profiles), but—and here’s the catch—only when logging in to a hosted desktop session.  The settings the user configured inside the hosted desktop session should move between hosted desktops, but should not affect their traditional PC login.

That’s right:  the saved settings should only apply when they were logging in to a hosted desktop session, not a regular desktop session.  That meant we couldn’t use roaming profiles to these settings travel between hosted desktops, since that attribute is set on a per-user account basis in Active Directory and would affect logons to both traditional PCs as well as hosted virtual desktops.  Now things start to get interesting.

Fortunately, a tool designed for multi-user environments such as Citrix and Terminal Services was able to save the day.  That tool, the Flex Profile Kit (FPK), allows administrators to selectively save portions of a user’s profile to a simple file, which can then be reapplied at next logon.  Using a configuration file and a small executable, we can define groups of settings that should be saved to a file.  That file is stored on a central file share, and then copied back down and re-applied when the user next logs in again.  Using this functionality, we can mimic the effect of a roaming profile without having to modify any user objects in Active Directory (and thus limiting the impact to hosted desktops only).

In the following sections I discuss some of the specific challenges we faced when using FPK for this project.

Mandatory Profiles

Normally, an FPK deployment requires the use of mandatory profiles.  Otherwise, the FPK is unable to fully configure the environment to account for “deleted” or “removed” settings, such as a drive mapping that no longer exists or a printer that has been uninstalled.  The only way I can describe this is to say that the FPK only stores the settings that should be saved; it doesn’t store settings that should be removed or overwritten.  As a result, changes in the user’s profile that result in the removal of data from the Registry or file system—such as disconnecting a mapped network drive—don’t get captured and continue to show up in future sessions.  Mandatory profiles fix that because nothing gets saved to the base profile, so only what’s in the FPK saved settings will get applied.

However, we couldn’t assign mandatory profiles in this case because mandatory profiles are also roaming profiles, and we were under strict mandate that the hosted desktops and the physical desktops were not to affect one another.  Try as I may, I couldn’t think of any way to assign roaming profiles without those settings also affecting logons to physical systems.

We were finally able to circumvent that problem by using REG.EXE, from one of the Windows Resource Kits, to delete the Registry keys associated with the values that were being stored by FPK.  At logoff, the logoff script would use FPK to store the values in the user’s profile, then REG.EXE would “clean” those values out of the user’s profile.  When the user logged in again, he or she would receive only the values stored by the FPK.

Running FPK at Logon/Logoff

Again, due to the fact that we could not allow the hosted desktops to share settings with the physical desktops, we also couldn’t run FPK through the user’s regular login script (again, the attribute is specified via Active Directory and would affect logons to both physical and hosted desktops).  This means we needed a way to run FPK at logon and logoff, but only for hosted desktops.  Fortunately, this challenge was fairly easy to overcome:  use a Group Policy object (GPO) on the OU where the hosted desktop computer accounts are found, enable loopback processing, and set the logon/logoff scripts there.

For those that aren’t familiar with loopback processing, here’s what it is (in a nutshell).  Normally, Active Directory would process the computer settings portion of a GPO based on the location of the computer object in Active Directory, and apply the user settings portion of a GPO based on the user’s location in AD.  However, in some cases, we might want to apply user settings based on the computer’s location, such as when a user is logging into a particular machine or particular type of machine.  This situation is a prime example of just such a case.  We want user settings applied only when the user logs into a hosted desktop, so we include the user settings in a GPO that is linked the OU where the computer accounts for the hosted desktops reside and enable loopback processing (in “Replace” mode, in this instance).  Then, those user settings will only apply when the user logs into one of those systems, and not any other systems.  Problem solved.

If you are currently considering a VDI project, I’d encourage you to have a look at FPK.  You may find it useful, as I did.

UPDATE:  Michael Roth of thincomputing.net has provided an updated URL for the FPK. Thanks, Michael!

Tags: , , , ,

For those that aren’t familiar with this latest TLA (three-letter acronym), VDI stands for “Virtual Desktop Infrastructure” and it’s an alternate way of utilizing virtualization in the datacenter.  Instead of virtualizing server instances, we virtualize desktop instances, and then provide a means for users to connect in to one of these available instances.  (You can learn more at VMware’s Virtual Desktop Infrastructure web page.)

VDI isn’t a perfect fit in all situations; in some cases, a more “traditional” approach such as Citrix Presentation Server or Microsoft Windows Terminal Services may be a better fit.  However, in some cases, VDI is a good fit.  That’s the kind of situation I’m working in right now, where a customer of mine needs to deploy an application that needs fast access to corporate data, but can’t use Citrix (for a variety of reasons).  So we’re looking at VDI.

Part of any VDI solution is a connection broker.  The connection broker, at its most basic level, performs the following tasks:

  • Accepts incoming connection requests from clients
  • Finds an available hosted desktop
  • Brokers the connection between the client and the available hosted desktop

There are a number of connection brokers (CBs) out there from a variety of vendors.  I haven’t had the opportunity to use all of them; only Propero and Leostream.  I found Propero’s product to be much too complicated; it seemed as if the application was really designed for something else and acting as a VDI connection broker was kind of an afterthought.  Leostream’s product, on the other hand, seems really streamlined and really focused on the CB market.  With Leostream’s product, I was able to fairly quickly setup and test the following functions:

  • Integrate CB authentication with Active Directory, so that users authenticated to the CB using their AD username and password
  • Make policy assignments within the Leostream CB based on AD group memberships, so that members of different groups were assigned to different policies
  • Control access to different pools of hosted desktops based on policy assignment
  • Create pools of hosted desktops by assigning “tags” to them; these tags create pools of hosted desktops by collecting instances with similar characteristics
  • Integrate the CB into VirtualCenter, so that the CB could suspend a VM when a user disconnected, then resume the VM when another user needed it

It may be that some of the other CBs out there also work as well as Leostream; I don’t know since I haven’t had the opportunity to work with all of them (note to vendors:  I will delete blatant marketing pitches in the comments).  I do know that the Leostream product works well thus far.

It took me a little bit of time to get accustomed to how the Leostream broker works (different terminology, I suppose), but once I understood how it works I found it pretty easy to make it do what I wanted it to do.  The pieces are all interconnected, though, so allow me to walk through a set of steps in the event you find yourself using the Leostream product in the future.

Let’s say you wanted to create a pool of workstations running Windows XP Professional, and you only wanted members of the “Hosted XP Users” group in Active Directory to have access to that pool of hosted workstations.  The process is actually pretty straightforward:

  1. Configure the VC integration, so that the CB can automatically retrieve the list of available VMs from VirtualCenter and import them automatically.
  2. Tag the VMs running Windows XP Professional with a tag, such as “WinXP”.
  3. Create a policy, perhaps called “WinXP Policy”, that defines the pool by selecting all systems with the “WinXP” tag.  (If you wanted further limit the VMs inside that pool, you could add additional tags and use the “AND” logic to say that all VMs must have all selected tags.)
  4. Configure the AD authentication server to assign members of the “Hosted XP Users” group to the “WinXP Policy” using the Assignments section of the authentication server configuration.

That’s it!  When an AD user who is a member of the selected group authenticates to the CB, he or she will automatically be brokered to an available system in the pool of systems with the selected tag(s).  Further, since this is WinXP (and of course we selected RDP as our connection protocol), sign-in to the hosted XP desktop is automatic—the user will not get prompted again for credentials.  Cool, eh?

Tags: , , , ,

The information below comes from site reader Shannon VanWagner, who had the time to research this and come back with the information necessary to integrate SuSE Linux Enterprise Desktop (SLED) 10 into Active Directory (on Windows Server 2003 R2) using Kerberos, LDAP, and Samba.  I haven’t tested these instructions (no copy of SLED with which to test), but I imagine that they should be fine.  It’s really just the SLED-specific tweaks to the existing AD integration instructions, anyway.

Preparing Active Directory (One-Time)

Enabling Editing/Display of UNIX Attributes

On your Windows Server 2003 R2 Domain Controller, enable “Identity Management for UNIX” via Add/Remove Programs > Add Windows Components > Active Directory Services > Identity Management for UNIX.  Note that this will require a reboot and does require Schema Admin privileges.  This will add a UNIX Properties tab to each user account in AD Users and Computers that will allow you to control the user UID, primary group GID, NIS Server setting, and user shell setting (e.g. /bin/bash).

(As an aside, I’ll refer readers back to my earlier article on various ways of making the “UNIX Attributes” tab appear.)

Create an LDAP Bind Account

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.  This helps minimize any potential security risks as a result of this account.

Prepare Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.  (Installing the “Server for NIS” component enables this, as mentioned previously.)  Be sure to set login shell, home directory, UID, and primary UNIX group ID.

After all the user accounts have been configured, then we are ready to configure the Linux server(s) for authentication against Active Directory.

Configure the SLED Workstation

On the SLED 10 client setup your config files as illustrated in the following configuration files.  See the file comment headers for the file names and locations (replace items such as “domain.com” with settings specific to your environment).

We’ll start first with the /etc/hosts file:

###############
# /etc/hosts
###############
# This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# “named” name server.
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
#
127.0.0.1 localhost
10.10.10.1 WINDOWS-DC-HOSTNAME.DOMAIN.COM WINDOWS-DC-HOSTNAME
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback

fe00::0 ipv6-localnet

ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
ff02::3 ipv6-allhosts
127.0.0.2 client-hostname.DOMAIN.COM client-hostname

Next, we configure the krb5.conf file:

###############
# krb5.conf for connecting with Windows Server 2003#
###############
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON

[libdefaults]
ticket_lifetime = 24000
default_realm = DOMAIN.COM
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 aes256-cts arcfour-hmac-md5
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 aes256-cts arcfour-hmac-md5
[realms]
DOMAIN.COM = {
kdc = windows-dc-hostname.domain.com
admin_server = windows-dc-hostname.domain.com
default_domain = DOMAIN.COM
}

[domain_realm]
.domain.com = DOMAIN.COM
domain.com = DOMAIN.COM

Once Kerberos is configured, we configure LDAP:

###############
# custom ldap.conf for connecting with Server 2003 R2
###############
host 10.10.10.1
base dc=domain,dc=com
uri ldap://windows-dc-hostname.domain.com/
binddn cn=linux-ldap-user,cn=Users,dc=domain,dc=com
bindpw ldap-user-passwd
scope sub
bind_timelimit 15
timelimit 15
ssl no
referrals no
nss_base_passwd dc=domain,dc=com?sub
nss_base_shadow dc=domain,dc=com?sub
nss_base_group dc=domain,dc=com?sub?&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
nss_initgroups_ignoreusers root,ldap

And then configure the Name Switch Service to use LDAP:

###############
# /etc/nsswitch.conf
###############
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry ‘[NOTFOUND=return]’ means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# compat Use compatibility setup
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# [NOTFOUND=return] Stop searching if not found so far
#
# For more information, please read the nsswitch.conf.5 manual page.
#
# passwd: files nis
# shadow: files nis
# group: files nis

passwd: files ldap
shadow: files ldap
group: files ldap

hosts: files dns wins
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files

bootparams: files
automount: files nis
aliases: files

Almost there—next we need to make sure that time synchronization is working, since this is a prerequisite for Kerberos authentication.  To make sure time synchronization is working, we’ll configure NTP:

###############
# /etc/ntp.conf file
#
# Sample NTP configuration file.
# See package ‘ntp-doc’ for documentation, Mini-HOWTO and FAQ.
# Copyright © 1998 S.u.S.E. GmbH Fuerth, Germany.
#
# Author: Michael Andres,
#
###############
#
# Radio and modem clocks by convention have addresses in the
# form 127.127.t.u, where t is the clock type and u is a unit
# number in the range 0-3.
#
# Most of these clocks require support in the form of a
# serial port or special bus peripheral. The particular
# device is normally specified by adding a soft link
# /dev/device-u to the particular hardware device involved,
# where u correspond to the unit number above.
#
# Generic DCF77 clock on serial port (Conrad DCF77)
# Address: 127.127.8.u
# Serial Port: /dev/refclock-u
#
# (create soft link /dev/refclock-0 to the particular ttyS?)
#
# server 127.127.8.0 mode 5 prefer
#
# Undisciplined Local Clock. This is a fake driver intended
# for backup and when no outside source of synchronized time
# is available.
#
server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized

#
# Outside source of synchronized time
#
# server xx.xx.xx.xx # IP address of server
server 10.10.10.1

#
# Miscellaneous stuff
#
driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile /var/log/ntp # alternate log file
# logconfig =syncstatus + sysevents
# logconfig =all

# statsdir /tmp/ # directory for statistics files
# filegen peerstats file peerstats type day enable
# filegen loopstats file loopstats type day enable
# filegen clockstats file clockstats type day enable

#
# Authentication stuff
#
# keys /etc/ntp.keys # path for keys file
# trustedkey 1 2 3 4 5 6 14 15 # define trusted keys
# requestkey 15 # key (7) for accessing server variables
# controlkey 15 # key (6) for accessing server variables

At this point we have Kerberos authentication configured, LDAP configured, NSS configured to use LDAP, and time synchronization configured and running.  Now we need to get Samba configured to help automate the process of integrating into Active Directory.

############### # /etc/samba/smb.conf file ############### # smb.conf is the main Samba configuration file. You find a full # commented version at /usr/share/doc/packages/samba/examples/ # smb.conf.SUSE if the samba-doc package is installed. # Date: 2007-02-07 [global] workgroup = DOMAIN-SHORTNAME realm = DOMAIN.COM security = ads encrypt passwords = yes use kerberos keytab = true password server = windows-dc-hostname.domain.com netbios name = client-hostname winbind use default domain = yes winbind separator = + idmap uid = 1000-59999 idmap gid = 1000-59999 winbind enum users = yes winbind enum groups = yes deadtime = 10 winbind cache time = 10 winbind nested groups = yes template homedir = /home/%U template shell = /bin/bash client use spnego = yes socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384 idmap backend = ad ldap idmap suffix = dc=domain,dc=com ldap admin dn = cn=Administrator,cn=Users,dc=domain,dc=com ldap suffix = dc=domain,dc=com dns proxy = no domain master = no preferred master = no max log size = 100 log file = /var/log/samba/%m.log printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \%L\profiles\.msprofile logon home = \%L\%U\.9xprofile logon drive = P: usershare allow guests = no [admin] comment = Windows Admin Access path = / valid users = “@Domain_Admins” admin users = “@Domain_Admins” read only = No create mask = 0664 browseable = No inherit permissions = Yes [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/drivers write list = @ntadmin root force group = ntadmin create mask = 0664 directory mask = 0775

SLED uses PAM (Pluggable Authentication Mechanism) to control authentication and authorization, so we next need to configure PAM to use Kerberos and LDAP, where necessary.  There are a number of files that need to be configured to make this happen:

###############
# /etc/pam.d/common-account - authorization settings common to all services
###############
# This file is included from other service-specific PAM config
# files, and should contain a list of the authorization modules
# that define the central access policy for use on the system.
# The default is to only deny service to users whose accounts
# are expired.
#
account sufficient pam_krb5.so
account required pam_unix2.so

###############
# /etc/pam.d/common-auth - authentication settings common to all services
###############
# This file is included from other service-specific PAM config
# files, and should contain a list of the authentication modules
# that define the central authentication scheme for use on the
# system (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default
# is to use the traditional Unix authentication mechanisms.
#
auth required pam_env.so
auth sufficient pam_krb5.so
auth required pam_unix2.so

###############
# /etc/pam.d/common-password - password-related modules common to all services
###############
# This file is included from other service-specific PAM config
# files, and should contain a list of modules that define the
# services to be used to change user passwords. The default is
# pam_unix2 in combination with pam_pwcheck.
# The “nullok” option allows users to change an empty password, else
# empty passwords are treated as locked accounts.
#
# To enable Blowfish or MD5 passwords, you should edit
# /etc/default/passwd.
#
# Alternate strength checking for passwords should be configured
# in /etc/security/pam_pwcheck.conf.
#
# pam_make can be used to rebuild NIS maps after password change.
#
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
#password required pam_make.so /var/yp

###############
# /etc/pam.d/common-session - session-related modules common to all services
###############
# This file is included from other service-specific PAM config
# files, and should contain a list of modules that define tasks
# to be performed at the start and end of sessions of *any*
# kind (both interactive and non-interactive). The default is
# pam_unix2.
#
session required pam_limits.so
session required pam_unix2.so
session required pam_mkhomedir.so umask=0077 skel=/etc/skel

All these files are in turn referenced by a “master” PAM configuration file, like this:

#%PAM-1.0
###########line above is part of this file#################
#/etc/pam.d/su config file
###########################################################
#auth sufficient pam_rootok.so
auth include common-auth
account include common-account
password include common-password
session include common-session
session optional pam_xauth.so

Once all these configuration files are in place, we can proceed with the following steps:

  1. Run “getent passwd” (you should only see SLED 10 local users in this listing).
  2. Run “kdestroy” to destroy any cached Kerberos tickets you may currently have.
  3. Run “kinit domain-admin-user@DOMAIN.COM” to create a new Kerberos ticket for the machine with Domain Admin credentials; you can then run “klist” to verify the Kerberos ticket.
  4. Run “net ads join -U domain-admin-user@DOMAIN.COM” to join the machine to the domain using the Kerberos ticket of the domain administrative user
  5. Restart the applicable services and daemons:
    /etc/init.d/smb stop
    /etc/init.d/winbind stop
    /etc/init.d/smb start
    /etc/init.d/winbind start
  6. Run “getent passwd”; the output should now list domain users and their associated UIDs. Likewise, “getent group” should output domain groups and GIDs.
  7. The “wbinfo -u” and “wbinfo -g” commands should list domain users and domain groups, respectively.
  8. Finally, run “su <domain-username>”.  It should prompt you for the user’s password, create a home dir for that user if necessary, and then switch you to the user.

We’re not really sure if it’s necessary, but you can add the LDAP bind account (used to bind to LDAP for queries) to the list of SMB users with the “smbpasswd -w” command.  It may prove over time that this command isn’t necessary.  (Anyone want to double-check this for us?)

Finally, using YaST (System > RunLevel Editor), enable the NTP, SMB, and Winbind daemons (I’m fairly sure that Winbind isn’t necessary).  Also, disable the nscd daemon to avoid caching problems and unwanted interaction with Winbind.

At this point, if you were successful in using su to switch to a Windows user, you should be able to reboot the machine and login to the machine as a Windows user (be sure to use a Windows server that has UNIX attributes assigned in Active Directory).

NOTE: If you happen to get yourself locked out of the system, it will be likely an /etc/nsswitch.conf file problem.  Simply boot to the SLED 10 installation disc using the “Recover System” option, then issue these commands to change the /etc/nsswitch.conf file:

mount -w /dev/hda1 /mnt (where “/dev/hda1” is your system partition)
vi /mnt/etc/nsswitch.conf (remove the “ldap” from
passwd, group, and shadow - should only say “files” or “compat”)

You can now reboot and login as root so you can troubleshoot the problem.

Some additional resources and information:
http://forums.suselinuxsupport.de/index.php?showtopic=53004
http://forums.fedoraforum.org/archive/index.php/t-29825.html

Thanks again to Shannon VanWagner for sharing this information with me so that I could post it here.  As always, feel free to post any questions, clarifications, or corrections in the comments below.

Tags: , , , , , , ,

Various VMware Links

I think I’ve mentioned before that I use NetNewsWire for subscribing to various RSS and Atom feeds for various topics.  Of course, given my interest in virtualization, VMware and VMware-related tags are things that are included in my feed list, and quite often I come across a link from a tag search or del.icio.us subscription that I find interesting.  It may not justify a dedicated blog post about that particular item, though, because it may not be anything about which I can contribute useful information.  After all, there’s enough useless junk floating around the Internet as it is; why should I contribute to the problem?

Likewise, I typically won’t post a link to my del.icio.us bookmarks unless it’s something that I know I’ll need to reference again, and these tidbits of information sometimes aren’t useful reference articles.  So, instead of blogging about these or just posting them to del.icio.us, I thought I’d post the links here.  It seems like a reasonable compromise between the two, if you ask me.

There you go.  Enjoy!

Tags: , , , , ,

When I first started using virtual desktops with Mac OS X, I went through a couple of different iterations before settling on an application called Virtue (later to be renamed VirtueDesktops). Although it took some time to get used to the idea of not having a desktop pager window always present, the hotkey for popping up VirtueDesktops’ translucent pager became almost as ingrained in my fingers as the hotkey for Quicksilver (note I said “almost”).

After a near death experience around the release of Tiger, VirtueDesktops progressed steadily until just last week, Tony Arnold announced that he was ceasing the development of VirtueDesktops. I can understand his position; with Spaces set to debut in Leopard, it’s difficult to justify the continued development of a virtual desktop application. Given that VirtueDesktops is an open source application, though, there’s hope that another developer will pick up the source code—much like Tony did himself after Virtue was abandoned by the previous developer—and continue the project.

I mostly stopped using VirtueDesktops after switching to my MacBook Pro. I guess the problems that the application experienced during the transition to a Universal application scared me away from it, and it’s only been recently that I started using it again on occasion. Since then, I’ve gotten used to using Exposé to manage windows instead of spreading them around multiple desktops, and I don’t know if I’ll ever switch back on a full-time basis. Nevertheless, I appreciate Tony and his hard work on the application, which served me very well for quite some time. I wish Tony the best of luck in his future projects and I hope, for the sake of other VirtueDesktops users, that one or more talented developers will take up the mantle and continue development.

Tags: ,

I’ve got a lot of respect for OpenBSD, whose maintainers’ relentless focus on security has really paid off.  Until today, the OpenBSD tagline was “only one remote hole in the default install in almost ten years.”  Now, due to the discovery of a new critical vulnerability, that tagline must change to its current form:  “Only two remote holes in the default install, in more than 10 years!”

Fortunately, this new vulnerability is fairly easy to mitigate and is fairly limited in scope to begin with.  This page (look for the security fix dated March 7, 2007) provides some workarounds and a link to the patch that fixes the problem.  If you’re already using OpenBSD’s pf firewalling functionality, then pf can easily be configured to block the traffic that triggers this vulnerability.

If you manage any OpenBSD-based systems, it would be prudent to configure pf and/or apply the patch to address this vulnerability.

Tags: , , ,

About a year ago, I wrote briefly about Reflex VSA, a security appliance designed to operate in the virtual environment to provide additional security functionality to the virtual networking environment.  Within the last few days, another security vendor, BlueLane, has joined the effort to provide additional security by releasing their VirtualShield product.

Generally speaking, anything that adds security to the infrastructure—virtual or physical—is usually a good thing, so I’m excited to see more vendors creating security solutions that are aware of virtualization solutions.  What I’m not so keen to see, though, is the trend among security vendors (and some analysts) that the addition of server virtualization completely changes the security picture.

I disagree with that statement.  Does the addition of server virtualization technologies, such as VMware ESX Server, introduce some new security challenges?  Sure.  The addition of any new technology creates new security challenges.  Consider the explosion of wireless networks and VPNs and the security challenges created by the widespread adoption of these technologies.  Server virtualization is no different.  But does server virtualization completely change the security landscape of your network?  Personally, I don’t think so.

That’s not a view that is particularly shared, especially among the security vendors themselves, who stand to benefit from increased paranoia about the security implications of server virtualization.  This Dark Reading article implies that the increased complexity that is inherent in most (if not all) server virtualization implementations breeds additional security concerns.  Similarly, this related article states:

The Gartner report says virtual machines may be convenient, but they also bring with them “embedded vulnerabilities and require special consideration for patching and updates.” Gartner recommends building security into VM implementations, and watching out for the common security “holes” in VM environments…

“Special consideration for patching and updates”?  Huh?  How is patching a virtual instance of Windows Server 2003 any different from patching a physical instance?  Administrators will still need to maintain virtual instances just like they maintain physical instances—both will need to be patched, reviewed for insecure configuration, scanned for malicious software, etc., generally using the exact same processes in both cases.

I will agree that the limited view into the virtual network switches (and inter-VM/intra-host traffic) is a security concern, but this isn’t anything that a quick installation of Snort (or any other intrusion detection/prevention system) can’t fix.  Likewise, the addition of a new quasi-OS (in the form of the host software, such as ESX Server) does introduce some additional security concerns.  It just doesn’t change the security landscape in some sort of basic, fundamental way.  At least, I don’t think so.

Feel free to disagree with me in the comments—just be sure to state your reasons why.

Tags: , , , ,

Comparison of WAFL and ZFS

This comparison of ZFS (Zettabyte File System) and WAFL (Write Anywhere File Layout) by Network Appliance (no direct link for WAFL) is an interesting comparison of these two advanced filesystems and their feature set. Be sure to read the comments for some additional insight on the comparison of the two filesystems and some clarification about supported features.

One distinction raised in the comments that’s worthy to be noted here is that any comparison of this sort also, by its very nature, takes into account the operating system that runs the filesystem. As a result, any comparison of ZFS vs. WAFL also involves, to a lesser extent, Solaris and Data ONTAP, respectively. Similarly (and I think this may have been pointed out in the comments as well), the underlying hardware used by these filesystems (and their operating systems) also comes into play as well.

For these reasons, it’s impossible—in my mind, at least—to perform any sort of apples-to-apples comparison of these two technologies. It’s still an interesting article, though.

Tags: , , , , , ,

Autopatching ESX

Vincent Vlieghe over at Virtrix just published a great how-to on setting up an internal repository for ESX patches.  It’s a must-read.

For complete details, see Vincent’s article here.

Great article, Vincent!

Tags: , , ,

« Older entries