An Introduction to iFolder

Test Objective Covered:

1. Describe the purpose and architecture of iFolder.

The iFolder component of NNLS is one of the coolest features of the product. iFolder solves two key problems network administrators face when working with end users' files:

• End users use multiple PCs to do their work. The average employee uses a desktop PC at his or her desk, a laptop on the road, and his or her home computer when working from home.

• End users tend to save their work on the local hard drives of these computers instead of using network storage.

These two factors cause headaches for network administrators and end users alike. For instance, end users must figure out a means for transferring their work files between these various computers. Sometimes, smaller files can be accommodated by floppy disks, whereas large files may be transferred by burning a CD.

Lately, one of the more popular means is email. Prior to iFolder, one of the easiest ways to get a large file from your work computer to your home computer was to simply email it to yourself. At home, you download the file to the local hard drive and work on it. When done, you send it back to yourself and download the updated version of the file at work.

This can lead to a critical issue: version control. If you've ever juggled files using the process described here, you know that you eventually end up with many different versions of the same file.

The risk of doing the wrong thing with the wrong file is significant in this situation. Is that file you just sent to your boss the final version, or did you accidentally send her an older version? Is that file you're about to delete an old version of the file, or is it the latest version? There's nothing more frustrating than the realization that you just erased the only good copy of a file you had.

The other problem this scenario presents is that of backup. Recall that we began the previous chapter with a description of the "ideal network." This network was planned before it was implemented and all possible contingencies were accounted for.

A key element of this ideal network is that users would save their data on a network storage medium instead of their local hard drive. The reason for this is simple: backup. If you're a network administrator worth your salt, you back up your server's storage media religiously . There's no better way to lose your job in the IT industry than to not have a current backup available after a system goes down.

In the real world, however, users almost universally persist in saving their work on the local hard drive. The reasons for this vary. For some, the network access time is too slow and they want file open and file save operations to be faster. Some fear that sensitive documents will be visible to others if saved on a network server. Others simply save their files on the local drive because that's the default location presented when they select File, Save As .

The problem with this is that most network administrators don't back up hard drives on users' workstations. The amount of time and tape space required to do this makes it unfeasible for all but the smallest organizations.

Imagine trying to back up thousands of 40GB workstations' hard disk drives each night. The fact that user workstations don't get backed up means that a huge amount of a given organization's intellectual property is continually at risk.

The iFolder component of NNLS is designed to fix these problems. iFolder is a slick product from Novell that synchronizes files between users' workstations and the iFolder server.

If users create, modify, or delete files of any type from a specified directory on their local hard drive, the changes are synchronized to a copy of the files stored on the iFolder server. Doing this allows end users to keep saving their files on their local hard drives as they are used to, but it also keeps an identical copy of their work on the iFolder server, which is backed up regularly.

If a given user logs in from a different computer, all his files are synchronized from the iFolder server down to the new computer. It doesn't matter whether the new computer is a laptop in a hotel room or a PC in the user's home office.

Warning

Remember that iFolder only synchronizes changes to files. However, if the user connects with a different PC (such as a borrowed laptop), all the files will need to be initially downloaded. If the user is connected with a modem, this could take some time.

Any changes he makes to these files is, again, synchronized back to the iFolder server. Then, when the user accesses them from his desk computer at work, all the changes he made are synchronized back to that system. This is shown in Figure 8.1.

Figure 8.1. iFolder data synchronization.

Sounds pretty good, huh? I've had many opportunities to introduce network administrators over the years to iFolder. I love the look that comes over their faces when they realize what it could do for them. Universally, they all say the same thing: "Coooooooooool ." Especially when it is mentioned that iFolder is extremely scalable. It has been tested with up to 10,000 users working on a single iFolder server!

Let's look at how iFolder works.

How iFolder Works

The iFolder service is composed of three components :

• The iFolder server ” The iFolder server is responsible for storing user files and synchronizing them.

• The iFolder client ” The iFolder client is a small piece of client software installed on Windows workstations. When it is installed, a specific directory on the workstation is configured as an iFolder directory.

  Tip

  Rumor has it that an iFolder client for Linux is due out from Novell any time.

  
  

  If you create a file in this directory, the iFolder client will synchronize it to the iFolder server. If you modify an existing file in this directory that has already been synchronized to the iFolder server, the changes will be applied to the version of the file that resides on the server.

  One cool feature of iFolder is the fact that it doesn't synchronize the entire file. Only the change made to the file is copied . This conserves huge amounts of network bandwidth and makes iFolder a feasible solution for dial-up connections.

  For example, suppose you have a 5MB word-processing file in the iFolder directory on your home PC. Your PC uses a 56Kbps dial-up connection to access the Internet. You review the document and notice an "a" that needs to be changed to "an" and you make the correction.

  If iFolder synchronized the entire file, it would take more than an hour to apply the change. However, iFolder only synchronizes the 4KB block of data where the addition of the letter n was saved. This transaction occurs in a matter of seconds.

  If you were to delete a file that resides in the iFolder directory on your workstation, the corresponding file stored on the iFolder server would be deleted as well.

• The iFolder applet ” If users need to access their iFolder files from a workstation that doesn't have the iFolder client installed, they can access the iFolder server using the Internet Explorer 5.0 or later web browser. The iFolder applet allows the user to download and upload his or her iFolder files.

  This is a nice solution that can be a real lifesaver for remote users who are in a panic trying to get access to their files. However, if your iFolder server resides behind your corporate firewall, you need to make sure ports 80 and 443 are opened up so users outside the firewall can get to the iFolder server.

Let's look at how iFolder leverages LDAP and eDirectory to control access.

How iFolder Authentication Works

iFolder uses encryption to protect data as it crosses the network. When users authenticate to iFolder, they must supply both a password and a pass phrase. The pass phrase is used to encrypt the files and protect them from prying eyes.

When a user authenticates, the iFolder server accesses eDirectory using LDAP to check the users' credentials. If the credentials match, the user is given access to the files associated with his or her user identity. The iFolder server can be configured to use the insecure LDAP port (389) or the secure LDAP port (636). Unless you have a good reason not to, you should always configure iFolder to use the secure port 636.

The reason to use port 636 is because the LDAP service doesn't have to be running on the same server as iFolder (although it can be). The iFolder service can use the LDAP service on any server in the eDirectory tree. If you use the insecure LDAP port and you have iFolder and LDAP running on different servers, all authentication information, such as usernames and passwords, will be transferred in clear text, thus allowing them to be easily captured using a network sniffer.

Tip

iFolder can also use Active Directory to authenticate users.

If you have iFolder running on the same server as the LDAP service, you can get away with using port 389. Because all LDAP queries from the iFolder server are made on the same machine, they don't cross the network medium and can't be sniffed. It's still good form, however, to use the secure LDAP port (636).

If you choose to use port 636 and your LDAP service is running on a different server than your iFolder server, you'll need to complete some additional configuration steps. You will need, for example, to export the LDAP server's trusted root certificate and copy it to your iFolder server.

It's also important to note that you can configure a single iFolder server to use up to eight different LDAP services to authenticate users. This is useful if your organization has multiple directory services where user accounts are stored.

Many students new to iFolder at this point ask, "If ports 80 and 443 must be opened up on the firewall for iFolder to work, should I also open ports 389 and 636 so LDAP authentication works too?"

Actually, no, they probably don't need to be opened. This is because the iFolder client doesn't send the LDAP requests to the LDAP service. It's the job of the iFolder server to do this. If both the iFolder service and the LDAP service are either behind the firewall or on the same server, you don't need to open the LDAP port(s) in your firewall configuration ”and this is usually the case.

If, for some reason, a firewall exists between your iFolder server and your server running the LDAP service, you need to open up your LDAP ports in your firewall configuration.

With that in mind, let's turn to a quick overview of the synchronization process.

Synchronizing Files with iFolder

The first time you log in to your iFolder server with the iFolder client, an account is created for your user object on the iFolder server and an iFolder directory is created in the local Windows user account's My Documents directory, as shown in Figure 8.2.

Figure 8.2. iFolder synchronization directory.

In addition, a shortcut to the iFolder directory is placed on the desktop for the local Windows workstation user account; this is shown in Figure 8.3.

Figure 8.3. iFolder shortcut.

With the iFolder directory created, you can begin using iFolder to synchronize data. iFolder uses the following process to do this:

1. The user supplies the required login credentials to the iFolder client running on his or her workstation.

2. The iFolder client sends these credentials to the iFolder server.

3. The iFolder server binds to the configured LDAP service and verifies the user credentials in eDirectory.

4. The iFolder client compares the files in the local iFolder directory against the files in the user's account on the iFolder server and identifies any 4KB file blocks that don't match up.

5. The iFolder client downloads any changes to existing files it has identified from the iFolder server. As mentioned earlier, the iFolder client doesn't download the entire file. It only downloads the 4KB blocks where data has been changed.

6. The iFolder client uploads any new files or blocks of files that have been changed since the last synchronization.

7. The iFolder server marks the files it has received as having been synchronized. It uses an attribute called the Sync Index Number. The iFolder server and client use this attribute in the future to determine whether a given file is synchronized or not. A file that has the identical value in this attribute in the server and client versions is assumed to be synchronized. A file that has differing values is assumed to be out of synchronization.

   If the two versions of the file have the same Sync Index Number but are obviously different, the file is said to have a conflict . iFolder will then compare the time stamps on the two versions to determine which version is the most current and use synchronization to update the other.

Note

If a conflict is detected , iFolder will keep the older version of the file in the Conflict Bin , just in case it was the correct version.

With this introductory material in mind, let's dig in so you can learn how to install and configure iFolder on your server.