If you're as comfortable with NetWare services as you are in your favorite old jeans, we've got good news: the NetWare services you've grown to know and love are also available on Novell Open Enterprise Server for Linux. The arguably better news is that getting and keeping Open Enterprise Server for Linux up and running is easier than you might think-and this series intends to prove it to you.
This is the seventh article in a nine-part series designed to help you bridge your NetWare skills to Open Enterprise Server for Linux. Like Novell's free training program upon which it is based, this series seeks to demystify the process of deploying and managing Open Enterprise Server for Linux. (See http://www.novell.com/products/openenterpriseserver/migrate.html.)
The first three articles in this series provide primarily background information, including a summary of the Linux history, a discussion of Linux fundamentals, and an introduction to Novell Open Enterprise Server. (If you haven't already, check these out: See "Got Skills?", Novell Connection Online, January 2006, "Back to Basics," Novell Connection, Q1 2006, Novell Connection Magazine, March 2006, Tech Talk #2.)
Parts 4 and 5 in this series move beyond this necessary foundation and take the first big steps toward achieving the series' goal. Bridging the gap between your NetWare know-how and Linux naivete, Part 4 walks through commonly-used NetWare tasks to highlight their functional equivalents on Open Enterprise Server for Linux. (See Part 4.) Further illustrating that NetWare knowledge serves you well in a Novell Linux environment, Part 5 discusses two familiar server management tools for Open Enterprise Server for Linux: Novell Remote Manager for Linux and Novell iManager 2.5. (See Part 5.)
This article is the second of two articles designed to increase your understanding of the Linux file system. Last month's article introduces Linux file system choices, structure and commands. (See "Got Skills? Bridge 'Em to Linux Part 6"), To continue this discussion, this article provides basic information about these topics:
- Linux disk partitions
- Novell Storage Services (NSS) on Linux
- Linux file system access control
- NetWare Core Protocol (NCP) server and file access for Linux
- Native client file access for Linux
As you probably know, partitioning enables you to take a very big and potentially unruly hard drive and divide it into several smaller and therefore more manageable parts. Each of these parts, or rather partitions, functions like a separate disk drive.
You can create a maximum of four partitions on an x86 machine: three primary and one extended. On an extended partition, you create logical partitions. The maximum number of logical partitions you create on an extended partition depends upon whether your hard disk uses SCSI (Small Computer Systems Interface) or IDE (Integrated Drive Electronics):
- On a SCSI drive, an extended partition supports as many as 15 logical partitions;
- On an IDE drive, an extended partition supports as many as 63 logical partitions.
On a Linux box, you assign each partition a code that represents the type of data stored there. (For information about common Linux partitions, see "Consider This".) For example, the code for a Linux Swap partition is 0x82, and the code for a partition that stores Linux Ext2, Ext3 or ReiserFS file sytem data is 0x83.
Linux accesses partitions differently than DOS/Windows accesses partitions. In the DOS/Windows world, you assign each partition a drive letter, and users thereafter use the correct drive letter to point the operating system in the direction of a particular directory or file. In this DOS/Windows world, each partition has its own set of directories and files.
In contrast, in the Linux world you associate each partition with a directory—more specifically, a device file—through a process called mounting. Thereafter, this partition's storage is available from this device file, which is called the partition's mountpoint. Hence, in the Linux world, all of the partitions work together to support a single set of files and directories.
Mountpoints for partitions are in /dev. The names for these mountpoints follow a standard: on IDE drives, the master drive is /dev/hda. Additional drives are identified with letters (for example, /dev/hdb and /dev/hdc). Partitions are identified with numbers. For example, the primary partitions on the master IDE drive would be /dev/hda1, /dev/hda2, /dev/hda3 and /dev/hda4. Logical partitions start with /dev/hda5.
Drives and partitions on SCSI drives (sd) follow the same lettering and numbering pattern, beginning with the master drive, /dev/sda. (See Figure 1.)
One partition holds the root file system. You then integrate other partitions into this root file system using the mount command. For example, the command mount /dev/hda7 /mnt would make the contents of this logical partition appear in the /mnt directory. (To familiarize yourself with the mount command options, check out the manual pages for this command by entering man mount from a Linux system command line.)
The /etc/fstab file stores all of the information about partitions and their mountpoints to enable partitions to mount automatically at boot time. The syntax in /etc/fstab is
Device mountpoint fstype options dump fschk
The codes for both dump and fschk are either 0 or 1. For dump, 0 indicates that the partition should not be backed up while 1 indicates that it should be. For fschk, a 0 indicates that when the system detects a problem, it should not start running a file system check, which a 1 indicates that in the event of a problem, the system should run a file system check. Hence, /dev/sda2 / reiserfs acl,user_xattr 1 1 indicates that the second partition on the master SCSI drive stores ReiserFS data and supports access control lists and extended attributes with dump and file system check options selected.
You can combine partitions from different hard disks using the Logical Volume Manager and Partition ID 0x8e. To do so, you select and combine physical volumes (that is, partitions) into a volume group. You can then divide this volume group into logical volumes, each of which may run a different file system (just like a partition). The effect is very similar to the effect of creating storage pools in NSS. As with creating storage pools, creating volume groups enables you to add physical volumes as the need for more space arises. More important, you can do so on the fly, that is, while your server is up and running.
Unless you choose to run NSS on Novell Linux, the plain truth about controlling access to files in a Linux file system is this: basic Linux does not offer the rich, robust access control mechanisms by which NetWare has spoiled you. That said, you do have a solid set of rights that you can assign to groups and users to control access to your files.
Where NetWare offers Supervisor, Read, Write, Create, Erase, Modify, File Scan and Access Control rights, Linux offers these rights, which in this arena are called permissions:
- Set UID
You can set permissions for groups and users from your browser using NetStorage and also from the Novell Client. Linux (like NetWare) also includes a rights utility, which you can use to set permissions.
Now For Something You Know
Of course, if you need finer-grained control over access to your file system, NSS on Novell Linux is always an option.
NSS volumes are cross compatible between kernels. That is, you can mount an NSS data volume on an Open Enterprise Server for either operating system—Linux or NetWare—and freely move the volume between servers. If you build a Novell Cluster Services cluster using a mix of Open Enterprise Server for NetWare and Open Enterprise Server for Linux, volumes can failover between kernels. This capability offers you the opportunity to migrate to Novell Linux while preserving your data and most of your file system features.
Most of the NSS features available on NetWare are also available on Linux. There are a few features that Linux does not support. For example, Linux does not support archiving and versioning services nor does it support Distributed File Services (DFS) for moving and splitting NSS volumes. (That said, DFS junctions on NetWare can point to NSS volumes on Linux.)
Overall, Open Enterprise Server for Linux with Support Pack 1 has improved the performance of NSS to the point where the difference is negligible. In fact, you will notice little if any difference in the performance between NSS on NetWare versus NSS on Linux. Furthermore, you will find on Linux most of the tools with which you are accustomed to working with NSS on NetWare, such as the NSS Management Utility. (See Figure 2.) and "Tools of the NSS-on-Linux Trade".)
Some of the commands for maintaining NSS on Linux are familiar albeit slightly different than their counterparts on NetWare. For example, on NetWare, you can verify and rebuild your storage pools using nss /PoolVerify=pool and nss /PoolRebuild=pool, respectively. On Linux, you verify and rebuild your storage pools using the Rebuild and Verify Simple User Interface (RAVSUI) utility.
You can move devices containing NSS volumes served up from a NetWare 6.0 or higher server to a server running Open Enterprise Server for Linux with Support Pack 1. Using Volume Copy Upgrade, you can also upgrade both NetWare 5.x NSS volumes and NetWare traditional volumes to Open Enterprise Server for NetWare. Once on Open Enterprise Server for NetWare, these new and improved NSS volumes are then cross compatible between Open Enterprise Server kernels.
Before you opt to run NSS on Open Enterprise Server for Linux, you should know that it requires the Enterprise Volume Management System (EVMS) to understand and manage NSS partitions. By default, Open Enterprise Server for Linux installs using Linux Volume Manager (LVM). This is a critical point to remember because the Linux kernel will not allow EVMS to manage LVM partitions and volumes. Therefore, if you plan to store both Linux system volumes and NSS on the same drive, you will need to do a little extra work during installation. (For more information, see Installing Linux with EVMS as the Volume Manager of the System Device.)
Regardless of the file system you choose to use, the next obvious question is this: "How will my users access files on a Linux server?" To enable access to files on your Open Enterprise Server for Linux consider these two options:
- NetWare Core Protocol (NCP) Server Services for Linux
NCP Server Services for Linux enables users to access on a Linux server from Windows and Linux workstations running Novell Client software. Furthermore, NCP Server Services enables them to do so in the manner they are accustomed to, that is, the same way they access files on a NetWare server. NCP is included with Open Enterprise Server and installs, by default, on Linux servers.
NCP supports the following:
- RSA authentication to Novell eDirectory
- NSS as well as POSIX file systems
NCP runs in the user space as opposed to the kernel space on the server. When it fronts NSS, NCP provides complete mapping of your entire file system. When it fronts a Linux file system, you have POSIX mapping of your file system, including access to such permissions as read, write and execute for users and groups.
On NetWare, the sys volume is automatically mounted at server startup. On Linux, the NCP server automatically both creates and mounts the sys volume in usr/novell/sys. The sys volume contains the login and public directories.
You can create a new NCP volume from any arbitrary point in the Linux file system using Novell Remote Manager or from the system command line. (See Figure 3.) To do so, you use the ncpcon command with this syntax:
ncpcon create volume ncp_volume_name path
To enable access to files on Linux servers for Windows workstations that are not running Novell Client software, you can use SAMBA. With SAMBA running on Open Enterprise Server for Linux, Windows users can access files on this Linux box just as if it were a Windows server.
SAMBA is an open source and free software suite that provides access to Linux boxes using the Microsoft SMB/CIFS networking protocol. SAMBA enables your Linux server to function as a fully-functional Windows NT server with the ability to serve as a primary or backup domain controller. SAMBA also enables your Linux box to act as a Windows client, enabling access to a pure Windows server. The SAMBA implementation in OES provides authenticated file services and integration with eDirectory.
When you run SAMBA on Open Enterprise Server for Linux, any CIFS or SMB client (such as Windows Explorer) can access the file services on that box. Users who will be accessing files from a Windows workstation by way of SAMBA must be enabled for Linux User Management. (For information about Linux User Management, see Novell Linux User Management Technology Guide.)
If you were to take the training program on which this series is based, you would be expected at this point to complete five exercises. Each exercise enables you to put into practice the principles you have read about in this article and last month's article. (See "Got Skills? Bridge 'Em to Linux Part 6.")
The five exercises provide step-by-step instructions designed to give you a hands-on introduction to the Linux file system. For example, the first exercise walks you through such tasks as creating a file, updating its time stamp, changing its owner and setting permissions. The remaining exercises assist you in accomplishing the following:
- Viewing various partitions and their mountpoints
- Using NSS on Open Enterprise Server for Linux
- Creating directories and NCP volumes on Open Enterprise Server for Linux from a Windows workstation running the Novell Client for Windows
- Accessing files on Open Enterprise Server for Linux from a Windows workstation that is not running the Novell Client for Windows (by way of SAMBA services)
The next article in this series discusses what it looks and feels like to monitor the Linux operating system on Open Enterprise Server.