Editor's Note: This article is Part 3 of a five-part series. See the other developerWorks® articles in this series: "IBM open collaboration client solution: An introduction," "IBM open collaboration client solution: Organizational planning and user segmentation for desktop migration," "IBM open collaboration client solution: Migrating business applications to the Linux desktop," and "IBM open collaboration solution: Architecture decisions and execution options for an IBM open virtual client."

Client-side migrations are challenging due to their large scale, the potential uniqueness of each client system, and the direct impact on users. Part 2 of this article series presented organizational planning for desktop migration, including user segmentation. This article, Part 3, focuses on the next step: technical planning.

We start with an assessment of the IT environment and general infrastructure, especially the infrastructure services. Continuing, we define the preferred Linux distribution, the migration of the application, and the systems management. We finish with considerations of the deployment of the Linux Desktop, including post-migration tasks and the support structure to be implemented.

This article is based on the technical planning section of the IBM® Redbooks® publication, “Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux,” and is enriched with many additional real-life experiences. If you'd like to delve further into the client migration process, we recommend the IBM Redbooks publication.

Assessing the infrastructure

Integrating new Linux clients into your organization's existing infrastructure is essential for having a productive, cost-effective, and efficient Linux client migration. An analysis of the existing infrastructure must include the following considerations:

• What does the topology of the network infrastructure look like? (The answer to this question includes an architectural overview for local and remote connections, including bandwidth and the protocols used.)
• To which network infrastructure is the client connected?
• Which type of network is installed on the client to access the infrastructure?
• Which services do the clients use on servers, and how do they connect to these services? (The service can offer file or print services, DHCP, Web content, dynamic content, and others.)
• To which databases do the clients connect? Do they connect to the databases using native clients, APIs, message queueing, or direct application access?
• Finally, which mainframes do the clients access? Which type of connections do they use? Among the different means of accessing mainframes are native clients, Web interfaces, or API connections.

Figure 1 shows an example of an infrastructure analysis, focusing on a network with clients that use primarily mail messaging.

Back to top

Integrating with existing network services

After assessing the infrastructure for the Linux client, we plan for integrating the client with existing network services; that is, we consider how to incorporate Linux clients in an active Microsoft® Windows®-based network environment.

Preparing the environment

Let's discuss the Linux client migration in which back-end servers have not yet been migrated. Typically, you can perform a migration project from any of the following four environments:

1. NT4 domain with Microsoft Windows NT® 4.0 PrimaryDomainControllers (PDCs) [as well as BackupDomainControllers (BDCs)]
2. Active Directory domain with Microsoft Windows 2000 or 2003 servers
3. NT4 domain with Linux running Samba PDC and BDCs
4. Other non-Windows domain-based environments

Option 3 is widely used in today's networked world, in which we see a mix of Linux with Samba and NT4l. There is significant pressure to migrate from option 1 to another environment because Microsoft Windows NT 4.0 is already out of service. In general, the driving factors that urge us to focus on options 1 and 2 are these:

• They are pure Windows environments.
• Most domains fit into this model.
• There is sufficient information on how to put Linux clients in a Samba domain.

Samba is the most widely used protocol/tool for integrating Linux clients with Microsoft Windows. It is a successful UNIX® application based on the ServerMessageBlock protocol, which is used by Microsoft Windows to provide networking services for file and print.

Authenticating within a Microsoft Windows domain

Let's look at the technical issues involved when planning for authentication of Linux clients within an existing Microsoft Windows domain. The following scenarios can be involved when authenticating within a Microsoft Windows domain:

• Network services single sign-on (SSO), in which users have only a single username/password combination
• Accessing shared files or printers that are available in the network, which are available to users based on authentication
• A single window of user administration for better user administration

These days, there are multiple methods for authenticating with Microsoft Windows domains. Let's discuss the pros and cons of these three methodologies:

• Samba/winbind, without changing the existing infrastructure. The advantages of this approach are that no changes are required to the domain and that users and their credentials are maintained centrally. There is no requirement to create users locally. The disadvantages are that winbind does not scale well, and some implementations require creation of a local mapping for users, which might be different on each client.
  

  Use of the winbind separator can affect most applications being run on the client. Actually, the separator is a character that separates the domain name from the username in the Linux username. For example, AD1234+Administrator is the Linux username of the user administrator in domain AD1234, where the plus sign (+) is used as the winbind-separator.

• LDAP connected to changed Active Directory. The advantages of this approach are that LDAP is a general protocol to connect to Active Directory, in which users are mapped to uid and gid centrally, and that this task is done within the Active Directory. The disadvantage is that the schema of the Active Directory must be changed to include UNIX-like information such as uid for users and gid for groups.
• LDAP connected to synchronized Active Directory. The advantages of this approach are that LDAP is the general protocol to connect to an Active Directory, and the mapping of uid and gid is done centrally. The disadvantage is that two different directories must be synchronized.

Note that Kerberos is free software offering the functionality of a Samba server and native authentication with an Active Directory.

In summary, Samba, Kerberos, winbind, and LDAP are the applications that enable us to authenticate with a Microsoft Windows domain.

File sharing using domain names

Accessing shared folders from a Linux client can be done either using a mount command or using the smbmount/mount -t cif" command. Manually mounting a share, however, requires log-in information, which leads to these issues:

• Users are not accustomed to doing the mounting manually because it is done automatically in Microsoft Windows when they log on.
• Manual editing of the /etc/fstab file is required to have the auto-mount of shares done at log-on time.

You can avoid these issues by setting up a Pluggable Authentication Module (pam_mount), which helps enable automatic mounting at logon. Keep in mind, though, that the module pam_mount is not yet completely mature, so you should allow extra testing time before you implement it.

Print services in the domain

Almost all Linux distributions include the Common UNIX Printing System (CUPS). Therefore, it's possible to use CUPS in conjunction with Samba on the client to enable printing to the existing domain printers. You must, however, consider the following items carefully when planning to use CUPS on the Linux clients to print to existing printers:

• CUPS and Samba integration. The most vital thing to check is whether Samba is part of the CUPS backend.
• Printers and authentication. At times, printers in the domain can require domain authentication before you're able to use them, as they might be a shared resource. However, this authentication leads to exposing passwords to multiple CUPS configuration files. You can avoid this vulnerability either by having an unauthenticated printer or by having a special user for printing alone.
• Print server versus direct printing. Using CUPS, it is possible to use the domain print servers or to print directly to the network interface of the printer. Usually, if all clients in the domain use print servers, it is appropriate to follow this principle for the Linux clients as well.
• CUPS drivers. When you look for printers, you should determine a desirable balance between finding suitable drivers for legacy printers and choosing a new printer that works seamlessly with Linux clients.

Back to top

Standardizing the desktop

On one hand, standardization reduces flexibility and the freedom of choice. On the other hand, it helps cut costs and allows you to have predictable desktop setups and to incorporate your company's corporate identity, if desired. Cost savings of a standard desktop, including a standard set of applications, is realized through the savings in support and licensing.

One of the best advantages of Linux is its flexibility and freedom of choice. Linux is open source and freely available, and it can be customized – from changing the background image to modifications on the code level – far more than with proprietary operating systems like Microsoft Windows or Apple Mac OS. In addition, Linux offers many capabilities to lock down the system so that a standard can be established and maintained.

Standardizing the desktop affects much more than just the user interface, as the sections that follow show.

Linux distribution

The most important part of standardization is the choice of the Linux distribution. If you choose an enterprise Linux distribution from Novell SUSE or Red Hat, you can select their respective desktop Linux distributions directly; that is, Novell SUSE Linux Enterprise Desktop (SLED) 10 and Red Hat Enterprise Linux (RHEL) 5 Desktop (both Novell and Red Hat are IBM premium business partners).

You must evaluate the following criteria when choosing the Linux distribution:

• What is the cost reduction associated with this distribution?
• Which options in this offering does the distributor provide?
• How long is the lifetime of the distribution supported by the distributor?
• What are the stability and the technological maturity of this distribution?
• What features, such as file-system and driver support, does the distribution offer?
• Which applications and tools come with the distribution?
• Does the distribution offer the availability of other applications and tools?
• Does the distribution provide ease of integration with the back-end systems?

Desktop environment and its look and feel

Unlike other operating systems, Linux offers multiple desktop environments known as windows managers, the most popular of which are the GNU Network Object Model Environment (GNOME desktop environment, or just GNOME) and the K Desktop Environment (KDE), though there are several others.

They follow slightly different approaches and therefore offer a different basic look-and-feel and varying features. The environments can be combined to some degree, meaning that tools from one environment can be used on a different one, if the basic libraries are installed. This approach is not recommended, though, due to maintenance reasons. In addition, it leads to bigger images that might have an effect on the upcoming deployment.

GNOME and KDE are mature products, offering all the necessary capabilities for customizing your desktop with respect to icons, the application set, and application menus and for supporting the following:

• Themes
• Internationalization
• Accessibility for users with disabilities
• Basic operating system, up to administrative tasks

Lock-down and hardening

Linux itself and the window managers are also able to lock down the system and hide unwanted functions. Linux is derived from UNIX, which is quite safe by design, so it follows that Linux is a safe system that can also be locked down easily. GNOME and KDE allow you to lock down the system easily, up to a kiosk level. Note, however, that only one application can run at full-screen mode in a kiosk system; no additional graphical application can be used at the same time.

Low-level standardizations

In addition to standardizations of the user-interface areas and the application landscape, there are additional aspects to consider, such as the disk layout, the partitioning, and the file system being used.

It's important to consider file system types such as ext2, ext3, ext4, and reiserfs because they have different characteristics with respect to the following:

• The journaling feature
• Maximum supported partition size
• Maximum supported file size
• Performance and scalability
• Recovery options

There are also some special file systems such as crypts that let you encrypt an entire partition for storing confidential or personal data.

Hardware-level standardization

Standardization should also be performed at the hardware level, independent of the migration itself, to minimize the amount of hardware support needed. For example, after the migration, the IT team might support only two different desktop PC models and only four different notebook models.

Another way to establish standardization from a hardware perspective is to standardize certain segments of users on special types of client systems, such as the following:

• Thin client. This client is an always-connected, locked-down mini PC that comes with only a basic operating system and a couple of displaying components, such as a browser or a terminal-server client application. No business applications run locally. The mini PCs are often integrated into the monitor case.
• Rich client. This client is an at-least-periodically connected system that hosts locally installed applications that don't need a permanent network connection, but that connect from time to time to a server component for synchronization and updates. IBM Lotus® Notes® and IBM Lotus Expeditor are good examples of this type of client.
• Fat client. This client is long-term offline-capable and has everything installed locally. A functionality is often available to get data and updates by a means other than through the network.

Figure 2 is a graphical comparison of the features of the different client types.

All standardizations have an effect on the deployment and maintainability of the target infrastructure. Thus, it is important to weigh all options and make a wise decision during the technical planning phase.

Back to top

Client administration planning

Client administration cost is a significant, ongoing factor. Here we provide an overview of the methods for efficient administration of Linux clients, focusing on integrating additional clients after an initial deployment, and updating clients with respect to their operating system, applications, remote administration, and backup. Included are some examples of administering enterprise Linux distributions in general.

Adding and replacing clients in the network

Successfully adding new Linux clients after an initial deployment or moving existing clients to Linux depends on having an up-to-date image for the deployment. You must consider the following items when replacing a client:

• Host name. If the new client comes with a new host name, the former host name must be deleted in the back-end systems. If the new client uses the host name of the old system, determine whether potential issues can arise, for example, in the context of asset management.
• Configuration information. Configuration files must be moved from the old to the new clients.
• Business personal data. Business personal data must be migrated to the new client.

Operating system updates

The operating system of a client in a production environment must comply with security standards and therefore must include up-to-date enhancements and security fixes. In general, there are three different options to keep the clients up to date:

• Completely automatic. All updates regarding the operating system are processed automatically. This updating policy has the advantage that all clients are always up-to-date without user interaction. The disadvantage of forcing all updates applies mainly for traveling users with varying network bandwidth.
• Semi-automatic. Only critical operating-system updates are forced. Users are notified about all other updates and can trigger those updates manually. This updating policy has the advantages of lower network loads for the user for noncritical updates and an always current system with respect to critical fixes. The disadvantage is the varying levels of updates among users.
• User-triggered. The user receives notifications for all updates and determines the extent of updating. This policy brings with it the highest probability for different update levels of the clients and, because Linux distributions consist of many components with no dependencies, the number of different update stages can be high.

Another aspect of the update policy is the ownership of the client update server. In general, two options are applicable:

• Owned by distribution host. The distribution owner or a community manages the update server. These update servers are available for different distributions and offer the advantage of outsourcing the maintenance of the server, including the current software status, updates, and fixes. Because implementing fixes and updates in the distribution is owned outside of your organization, the server host should be a trusted organization.
• Owned by your organization. Your organization owns and maintains the update server. You have complete control of the server's status, so you are able to test single updates before releasing them on the update server and to disconnect the server from the Internet. Of course, complete control means that you also own the cost and responsibility of operating the server.

Most distributions offer tools to reduce the effort involved in updating clients. Examples of enterprise distributions are Novell ZENworks Linux Management and YaST. With Red Hat, you can use Red Hat Network's satellite architecture and kickstart.

In addition, open source alternatives such as apt (Advanced Packaging Tool) for Debian or yum (Yellow dog updater, modified) for RPM Package Manager-based distributions are available.

Application updates

In general, you can handle application updates either as part of the operating system or separately. If you include them in the operating system, the considerations in the preceding paragraph on updating applications can be applied. If you take them separately, you have different choices:

• Script-based updating. Generally, scripts can perform the download of updates from different network servers. In fact, there are designated applications that provide update scripts.
• Package-based updating. If updates are combined into a bundle, they can be handled by apt or yum.
• Complete client exchange. If the updates come close to the size of the client, a complete exchange of the client might be most appropriate.

Updating applications can cause changes in program calls and menu structures. These changes should have the least effect possible on the user's productivity. Therefore, you should integrate test cases focusing on menu structure stability and correctly working links on the desktop into your test case suite.

Pilots frequently start with challenging the functionality of a Linux-based client compared with the existing client. The functionality check can be closely followed by a usability check. Because only a few clients participate in your pilot, you can handle manual updates easily. Nevertheless, we recommend that you include updating policies in your pilot, to test the updating policy of your organization's choice.

Remote administration

In general, there are two different approaches for remote administration:

• Pro-active. The clients are monitored to identify potential issues before they become harmful. Monitoring of the client status can focus on, for example, checking the remaining disk space, the security status, or licensing issues in the context of asset management. The range of monitoring products goes from open source products such as Nagios up to enterprise-ready tools such as IBM Tivoli® Monitoring.
• Reactive. The clients are administrated in the event of system or application failure. Linux distributions provide different tools for remote administration ready for you to use as-is. A standard mechanism is ssh, which guarantees strong authentication in contrast to rsh, rlogin, or Telnet. Using ssh, the administrator can easily analyze the client and apply fixes by running scripts, or the administrator can collect data for security, health, or asset management checks. VNC and FreeNX are further examples.

Of course, you can mix different aspects of these approaches. For example, a pro-active approach can be appropriate for monitoring installed applications, in the interest of correct license managing. A reactive approach is efficient for managing individual client issues such as unintended user operations on their home directory structure.

Backup

Thin clients that do not offer any write access on local devices, for example offering only Web applications, do not require a backup. Rich or fat clients, however, have different backup needs: If the storage to write any business personal data is mounted to the client from a central managed data store, only configuration files and caches need to be updated. If business personal data is stored locally, the users' writable directories must be included in the backup. You might also consider including desktop configuration files.

You have a choice of a variety of tools to implement your backup strategy, including open source tools such as Partimage to backup and restore complete partitions or a commercial solution such as IBM Tivoli Storage Manager. It is recommended as a best practice that you include the implementation of the backup strategy in your pilot.

Back to top

Deploying the new client

The objective of planning a pilot for migrating from a given client system to a Linux client is to demonstrate proven methods for efficiently managing deployment of that client to the rest of your organization. You must do the following regarding the deployment of the client itself:

• Choose a deployment method
• Decide how to update the clients and how frequently to update them
• Personalize the clients

Deployment method

The two general deployment approaches differ as follows:

• Partition- or disk-image-based deployment. You can deploy these images by using existing enterprise deployment tools or open source tools such as Partimage. The advantage of an image-based approach is that it takes less effort to include all different flavors of customization. The disadvantage is that all customization must be implemented after deploying the image, for example, by executing special scripts that reflect the different customization needs of different user segments.
• Package-based deployment using distribution-inherent tools. Several distributions offer a mechanism to perform automatic and unattended installs. Red Hat relies on kickstart, which uses an answerfile to control anaconda, the Red Hat installer. Novell offers autoyast, which can be based on a configuration file that automates the answers of the YaST-based installation process. Both tools use RPM packages.
  

  The advantage of this approach is that all extra software and configurations are included as RPMs. The disadvantage is that you must invest the effort to build packages and to solve software dependencies for these purposes.

Keeping clients up to date

The two different methods of updating clients result in different approaches for the update:

• Updating image-based provisioned clients. If you have chosen an image-based update process, you must ensure that the image and the clients are kept up to date. If all software of the client is packaged to RPMs, you can update the client using the method that comes with the distribution. If not, you must invest in writing scripts and in management to install appropriate updates on the client that reflect application-specific update needs.
• Updating RPM-based clients. Clients provisioned by means of an installation-based deployment method, and thus based on RPM-packaged software, benefit from the availability of distribution-inherent updating mechanisms.

Personalizing deployed clients

Different types of information, such as the following, must be adapted to personal needs:

• Host name, if not dynamically assigned, must be assigned.
• IP address, if not dynamically assigned, must be assigned.
• Specific remote file systems must be mounted.
• Specific printers must be configured.
• Specific applications must be configured.
• Business personal data must be migrated.

The personalization process is done after installation. Each post-installation process requests access to the individual requested data. Different approaches of using this data are realized through a first-boot process or through scripts, which are triggered when the user calls the application for the first time. The first boot runs only once and writes its results into a file, to avoid a second start. The advantage of this procedure is that it is executed before the first log-in is done, which allows for the creation of accounts.

An alternative to the first-boot approach is the execution of scripts for specialized applications to customize the desktops. This approach can result in logging off and on.

If you are interested in other tools that automatically migrate from Microsoft Windows to Linux, take a closer look at Versora Progression Desktop.

Back to top

Conclusion

This article guided you through the most important technical considerations involved when introducing a Linux client in your organization and when planning for your migration pilot phase. We outlined the many planning options and discussed their advantages and disadvantages.

Resources

• Refer to the previous developerWorks article in this series, "IBM open collaboration client solution: An overview."
  
  
• Refer to part 2 of this series, "IBM open collaboration client solution: Organizational planning and user segmentatioon for desktop migration."
  
  
• Refer to part 4 of this series, "IBM open collaboration client solution: Migrating business applications to the Linux desktop."
  
  
• Refer to part 5 of this series, "IBM open collaboration solution: Architecture decisions and execution options for an IBM open virtual client."
  
  
• Read about the IBM open collaboration client solution.
  
  
• Refer to the IBM Redbooks publication, “Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux."
  
  
• Refer to the IBM Redbooks publication, “Migrating from Microsoft Exchange 2000/2003 to Lotus Notes and Domino 7."
  
  
• Read about the IBM open collaboration client solution powered by SUSE Linux Enterprise from Novell.
  
  
• Read the IBM white paper, "IBM Point of View: Desktops of the future and how to get started today."
  
  
• Read the developerWorks Lotus article, "Developing and deploying rich client applications on desktops and mobile devices using Lotus Expeditor V6.1."
  
  
• Read the developerWorks Lotus article, "Building an offline application in IBM Lotus Expeditor."
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Assessing the infrastructure
• Integrating with existing network services
• Standardizing the desktop
• Client administration planning
• Deploying the new client
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Lotus on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers