Novell Open Enterprise Server 2 Best Practices Migration Guide - File System Installation & Migration
- 1 File System Installation & Migration
- 1.1 Supported File Systems
- 1.2 Traditional Linux File Systems
- 1.3 Best Bets
- 1.4 File System and Directory Structure Comparison
- 1.5 Linux File Permissions
- 1.6 Planning File System Migration
- 1.7 Installing NSS on Linux
- 1.8 Additional Information
- 1.9 Migrating NSS Data and Devices from NetWare to Linux
- 1.10 Post Migration Procedures
File System Installation & Migration
With Linux, over 20 different file system choices are available, ranging from very simple to extremely complex and rich systems. Novell surveys indicate that almost two-thirds of OES Linux customers use either ReiserFS (because of its simplicity) or NovellÃ‚Â® Storage ServicesÃ¢â€žÂ¢ (because they are already familiar with it or need the associated rights), with ext3 running a close third.
If you are already using Novell Storage System (NSS) on NetWare, you can continue its use, or opt for a traditional Linux file system in those cases where it's to your advantage. Primary Novell and Linux file system options are compared in this section, but other systems are available. Use the information and cross-references in this section to match the file system to the data, workload, and access control you need (sometimes very simple is good enough).
Note: OES 2 Linux requires a Linux traditional file system volume for the operating system.
Additional Information: A detailed comparison of Linux traditional file system features can be found at: [http://en.wikipedia.org/wiki/Comparison_of_file_systems]. An additional Novell discussion of file systems can be found at [http://wiki.novell.com/index.php/File_System_Primer] . Both OES 2 Linux and NetWare support Novell Storage Services as well as their respective traditional file systems. The following table and illustration compare the file systems available with NetWare and those available with OES 2 Linux.
File Systems Available on NetWare and Linux
| NetWare Traditional File System (NWFS)
(legacy system supported through NW 6.0)
|Open source version of the NetWare File System (limited functionality)|
|Novell Storage Services||Novell Storage Services (OES Linux)|
|Linux Traditional File Systems (ReiserFS, ext2, ext3, JFS, XFS, Others)|
Supported File Systems
Novell File Systems
Traditional NetWare File System
The NetWare File System (NWFS) is used in NetWare 3.x through 5.x as the default file system, and is supported in NetWare 6.x for compatibility. It is one of the fastest file systems available; however, it does not scale and is not journaled. An Open Source version of this file system is available on Linux to allow access to its file data. However, the Open source version lacks the identity management tie-ins, and therefore, has little utility. NWFS customers are encouraged to upgrade to NSS.
Novell Storage Services (NSS)
Novell Storage Services is available with NetWare 5.0 and above; it has been open sourced and is included in Novell's SUSE SLES 9 SP1 Linux distribution and later and with Novell's Linux Open Enterprise Server. The NSS file system is unique in many ways, mostly in its ability to simultaneously manage and support shared file services from different file access protocols. It is designed to manage access control (using a unique model, called the Trustee Model, that scales to hundreds of thousands of users securely accessing the same storage) in enterprise file sharing environments. It and its predecessor (NWFS) are the only file systems that can restrict the visibility of the directory tree based on the UserID accessing the file system. Both NSS and NWFS have built-in ACL rights inheritance. NSS also includes mature and robust features tailored for the file sharing environment of the largest enterprises.
Shared NSS Features
NSS on NetWare and OES 2 Linux share these features:
|Maximum device size (physical or logical)||2 TB|
|Maximum partition size||2 TB|
|Maximum # of partitions per pool||No practical limit|
|Maximum pool size (created by using at least 4 partitions of up to 2 TB each)||8 TB|
|Minimum pool size||10 MB|
|Maximum volume size||Up to 8 TB, depending on the pool size and available space in the pool|
|Maximum file size||Up to 8 TB, depending on the volume size and available space in the volume|
|Maximum number of files per volume|| Up to 8 trillion, regardless of how many name spaces are loaded
Note: NSS can support this. Browser and application ability can limit this.
|Maximum number of files open concurrently||1 million|
|Maximum number of volumes per server|| 255 plus the sys: volume.
You can mount NSS volumes beyond 256, but they are not visible or accessible through the normal NetWare APIs.
|Minimum server memory to activate a volume||Requires only 4 MB available RAM to activate a single volume of any size and any number of files. Loads a fileÃ¢â‚¬â„¢s metadata into memory only when you access the file.|
|Software RAID support|| RAID 0 (striping)
RAID 1 (mirroring)
RAID 5 (striping with parity)
RAID 10 (mirroring RAID 0 devices)
RAID 15 (mirroring RAID 5 devices)
|Data shredding||Yes, up to 7 times|
|User space quotas (user space restrictions)||Yes|
|Salvage or purge deleted files, directories, or volumes||Yes|
|Distributed File Services for moving and splitting NSS volumes||Yes|
|Novell Archive and Version Services||Yes|
|Device maintenance support||Activate and deactivate devices by pool.|
Novell Storage Services is generally best file system solution for customers migrating file sharing services from NetWare. NSS file systems created on NetWare can be mounted on Linux.
The following characteristics of NSS on OES 2 Linux should be noted in doing your planning:
- NSS volumes are cross-compatible between Linux and NetWare. NSS data volumes can be mounted on either NetWare or Linux and data moved between them.
- NSS devices and storage can be managed in the Web-based Novell iManager utility. NSS also supports third-party tools on both platforms for advanced data protection and management, virus scanning, and traditional archive and backup solutions.
- In a mixed-platform cluster with Novell Cluster Services, NSS volumes can fail over between Linux and NetWare, allowing for full data, trustee, and file system feature preservation when migrating data to Linux.
- In addition, NSS on OES 2 Linux:
- Retains all files, rights, meta-data, restrictions, etc.
- Includes NetWare Trustee access control (richer than POSIX)
- Retains file system access (NCP)
- Retains all file system administration and management features
- Can be easily clustered with Novell Cluster Services (NCS)
- Is best for shared LAN file serving: excellent scalability in number of files; scales to millions of files in a single directory
- Supports multiple data streams and rich metadata (its features are a superset of existing file systems on the market for data stream, metadata, namespace, and attribute support)
- Is journaled
NSS Features Added to OES 2 Linux
The following features have been added to NSS for OES 2 Linux since the initial release of OES 1 Linux.
- New Location for the NSS Configuration Files
In this release, NSS configuration files have moved from the /opt/novell/nss/conf directory to the /etc/opt/novell/nss directory.
- Encrypted Volumes
- Extended Attributes (XAttr)
- Group I/O Management
- Enhanced Hard Links
- High Memory Management
- Lightweight Audit Format (LAF) Audit Log Messages
- Metadata Migration (METAMIG) Utility
- The Metadata Migration utility is available for OES 1 Linux and later.
- NOATIME and NODIRATIME Support
- Novell Archive and Version Services
- Novell Distributed File Services
- Pool Snapshots
Note: Different pool snapshot technologies are used for NSS pools on NetWare and NSS pools on Linux. You can create pool snapshots on either platform, but you should not move them to another platform. Pool snapshots taken on Linux do not work on NetWare, and vice versa.
Snapshots taken on a given platform are unusable if you move the poolÃ¢â‚¬â„¢s devices cross-platform. Before you move a pool with existing snapshots to a different platform, delete all existing snapshots for the pool.
On Linux, do not use pool snapshots for clustered pools.
- Support for NSS software RAIDs 5 and 15 has been added for OES SP1 Linux and later
- User Quotas
- Linux User Management enhancements
Changes in NCP Server for Linux now make it possible for file ownership to be tracked for users of NSS volumes on Linux without requiring the user to be Linux-enabled with Linux User Management.
NSS Features Not Implemented in OES 2 Linux
NSS on OES 2 Linux provides an upgrade to NSS on Linux that is comparable to NSS on NetWare. In some cases, Linux is more feature-rich; for example, Linux and Vista Archive Versioning Service clients work only against a Linux server and not a NetWare server. There are, however, a few instances, where some of the supported features are not yet as feature rich as their counterparts on NetWare.
The following NSS features are available for NSS on NetWare but are not supported for NSS on Linux:
- NSS multiple path I/O to devices. Multipath I/O is not supported on Linux. Instead, use the same Linux multipath I/O management tools you use for Linux traditional file systems. You should configure multipath I/O before using NSS management tools to create NSS software RAIDs, pools, or volumes on devices. For information, see "Managing Multipath I/O for Devices" in the [SUSE Linux Enterprise Server 10 Storage Administration Guide].
The devices used by NSS pools can take advantage of multiple path I/O support only when they are assigned to a NetWare server. The NSS multipath priorities and failover preferences do not apply when the devices are on the Linux server.
- CD and DVD media and image files. These are handled differently:
On NetWare, CDs, DVDs, CD and DVD image files, and DOS partitions are mounted as NSS volumes. Disks in USB floppy drives are mounted as local DOS FAT partitions.
On Linux, these alternative media and partitions are mounted using Linux traditional file systems options.
For information, see "Some Other Supported File Systems" in the [SUSE Linux Enterprise 10 Installation and Administration Guide].
- Transaction Tracking System (TTS). TTS is not supported on Linux. On Linux, file content tracking capability is available for Linux traditional volumes (not NSS volumes) when you mount the volume with the Journal mode setting for file system journaling. The Journal mode logs all file system data including the data blocks and the metadata. For information about the journaling capabilities of Linux traditional file systems, see "Major File Systems in Linux" in the [SUSE Linux Enterprise 10 Installation and Administration Guide].
- Modified File List. The Modified File List attribute for NSS volumes is available only for NSS volumes on NetWare.
The following are treated differently on Linux than on NetWare:
|File access protocols||NCP
AFP, NFS, and CIFS
NFS and CIFS (Samba) require users to be Linux-enabled with Linux User Management. AFP is available only through third-party software.
|Management interfaces||Novell iManager
NSSMU for NetWare
Utilities in the server console ( NSSMU, RIGHTS, FLAG)
NSS commands in the server console
Novell Remote Manager for NetWare
Novell NetStorage for NetWare (via Web browser only, not WebDAV)
RIGHTS utility for NetWare
NSSMU for Linux
EVMS ( evmsgui)
Utilities in the terminal console (NSSMU, RIGHTS, NSSCON, ATTRIB, RAVSUi, RAVVIEW, nbackup)
NSS commands in the NSS Console ( NSSCON)
Novell Remote Manager for Linux (for Dynamic Storage Technology shadow volumes and for managing NCP Server connections to NSS volumes)
Novell NetStorage for Linux (via Web browser only, not WebDAV)
RIGHTS utility for Linux
(retain point-in-time version of a pool using block-level copy on write)
||The stored-on pool must be on a separate partition.|
|Volume encryption||You must mount encrypted volumes only from NSSMU on the first mount after a system reboot so that you can enter the password. The NSSCON utility does not support entering a password from the command line.|
|File system trustees and trustee rights to control access to directories and files||Works with or without concurrent running of NCP Server.||Requires NCP Server to enforce the rights and access on the extended attributes.|
|File system directory and file attributes to control functions available for directories and files||Files and Folders plug-in to iManager
|Files and Folders plug-in to iManager.
See also "Displaying Key NSS Directory and File Attributes as Linux POSIX Permissions" in the OES 2: File Systems Management Guide.
|Default mount location for NSS pools||Not applicable||/opt/novell/nss/mnt/.pools/poolname
|Default mount location for NSS volumes||Server root||/media/nss/volumename
|Volume name space||Accommodates all name spaces (DOS, Macintosh, Long, and UNIX).||Accommodates all name spaces (DOS, Macintosh, Long, and UNIX).
UNIX is the default name space, which is case sensitive. However, you can specify Long name spaces on mounting the NSS volume to make its directory names and filenames case insensitive.
|Software RAID support||RAID 0 (striping)
RAID 1 (mirroring)
RAID 5 (striping with parity)
RAID 10 (mirroring RAID 0 devices)
RAID 15 (mirroring RAID 5 devices)
|RAID 0 (Striping)
RAID 1 (mirroring)
RAID 5 (striping with parity)
RAID 10 (mirroring RAID 0 devices)
RAID 15 (mirroring RAID 5 devices)
RAID 0, 1, 4, 5 and 6. RAID 10 can be created using the mdadm(8) command as a complex RAID using the RAID10 option, or as a nested RAID. For information, see the [SUSE Linux Enterprise Storage 10 Storage Administration Guide].
|Novell Distributed File Services
For information, see the OES 2: Novell Distributed File Services Administration Guide.
|Supported||NSS volumes on OES 2 Linux can contain junctions or be a junction target.
DFS does not support junctions on NCP volumes.
|Novell Dynamic Storage Technology
For information, see the OES 2: Novell Dynamic Storage Technology Administration Guide.
|Not Supported||Available in the initial OES 2 release.
Note: For additional information, see Section F.0, "Comparison of NSS on NetWare and NSS on Linux" in the OES 2: NSS File System Administration Guide.
Traditional Linux File Systems
As the table below indicates, the OES Linux kernel supports a variety of Linux traditional file systems in addition to NSS. In fact, a Linux traditional file system is required for the system volume. The upper level of the kernel deals equally with these file systems through an abstract layer, the virtual file system (VFS).
Linux file systems differ somewhat from NetWare and Windows file systems. This section provides only minimal highlights. If you decide to use any of the traditional Linux file systems, you'll want more detail. Which file system you use largely depends on the purpose you are using the file system for. Some typical Linux traditional file systems and their recommended use are described in the following table:
Linux Traditional File Systems
|Linux Traditional File System||Description||Recommended Use|
|Second Extended File System (ext2)||ext2 is a legacy file system with a solid reputation for simplicity, quickness, and stability. It uses less memory than other options and is sometimes faster.
ext2 does not maintain a journal so it is not recommended for any server that needs high availability. Novell recommends moving to ext3.
|ext2 is the right file system for /boot|
|Third Extended File System (ext3)||ext3 has the same data and metadata format as its predecessor (ext2). It is considered the "Linux" file system. It's fast performing and offers options to coordinate its metadata journaling with data writes.
||ext3 is best for general purpose file and print, and databases such as Oracle, that feature only a few large files.
It is not recommended for GroupWise and other email packages as there are more than 500 files in a folder and GW will not run.
If used for GroupWise, enable the htree feature in ext3.
|Reiser File System (ReiserFS)||ReiserFS has a solid reputation for its simplicity, quickness, and stability.
It supports metadata journaling, but does not include data journaling or ordered writes. Its disk space utilization, disk access performance, and crash recovery are better than ext2/3.
|Reiser is best suited for collaboration (email), iFolder3, and web-serving applications.
It's designed to transact many small files being opened, read, written, and closed in a short timespan.
The downside is that tools for automatically fixing the file system in the event of a rebuild are not as robust as the NSS pool and volume rebuild
|Journaled File System (JFS)
|JFS was developed by IBM* to support high throughput server environments (AIX and OS/2) where performance is the ultimate goal; it was ported to Linux to allow for ease of migration of existing data. Performance is excellent across a wide variety of workloads.
This feature-rich system is a full 64-bit file system.
|Recommended for high-end hardware (64-bit, multiprocessor systems)|
|Extended File System (XFS)
|XFS originated from SGI (Irix) and was designed specifically for large files and large volume scalability. This high-performance system is good at manipulating large files and performs well on high-end hardware.
Extremely large file systems, large files, and large numbers of files. High-end hardware (64-bit, multiprocessor systems). Video and multi-media files. Note: SGI also offers a closed source cluster parallel version of XFS called cXFS, an asymmetrical model. It's slave nodes can run on Unix, Linux and Windows, making it a cross- platform file system. Its master node must run on SGI hardware.
Collaboration: GroupWise and other email/collaboration solutions typically deal with many little files. Since only the application process accesses the file system, the added overhead of rich ACL and file attributes found in NSS or NTFS is redundant. The characteristics needed are a file system whose performance remains relatively constant regardless of the number of files in the volume, and that performs well with small files. Best bets are ReiserFS and XFS.
Database: MySQL, Oracle, SQL, Progress, etc., typically deal with a few, very large files that are left open most all of the time. Virtually any file system with Direct IO capabilities (APIs that allow the database to directly manipulate the file buffers) can be used. Since databases do not create many files, file systems that do not scale to many files, but still have Direct IO interfaces will work fine. Reiser, ext3, and XFS all are recommended. If you are using MS SQL server, NTFS is required.
Web Services: Web services can encompass a broad set of workloads. For simple web services, virtually any file system can be used. Since these typically don't need rich access control file systems, you can avoid the extra overhead of NTFS or NSS to get slightly better performance. However, if the web services solution leverages identity and requires user security for many people (more than 50 accounts), then NSS is the better choice.
File Serving (NAS): Two NAS use cases need to be considered:
- Serving files to application servers in a tiered service oriented architecture (SOA).
Minimal access control is required, so choose a file system that is scalable and fast: Reiser, XFS, VxFS .
- Serving files to end users' desktops and workstations.
Quite heavy access control is required, so the access control and security management capabilities of NSS with CIFS and NCP file access protocols begin to be important.
NSS provides security between users and, at the same time, allows for very granular sharing between given users and groups. NSS includes a visibility feature that prevents unauthorized users from even seeing subdirectory structures they don't have rights to.
For additional information, see Section 1.2, "Linux Traditional File Systems" in the OES 2: File System Management Guide and "File Systems in Linux" in the [SUSE Linux Enterprise Server 10 Administration Guide].
File System and Directory Structure Comparison
Both NetWare and Linux file systems use directories and subdirectories. Linux directories can contain any number of subdirectories:
|SYS Volume||Root File system Ã¢â‚¬Å“/Ã¢â‚¬Â|
||Directories (conform to File system Hierarchy Standard v2.2)
- NetWare separates directories with a backslash. Linux uses a forward slash.
- NetWare filenames are not case sensitive. Linux file names are.
- File names in Linux:
- Can contain 255 characters.
- Can include special characters (like *?$) but these are sometimes not useful (for instance, a filename that starts with a $ can be mistaken for a variable).
- The path, including slashes (/), can be 4096 characters long.
- File types in Linux include the following:
- Normal files
- Device Files
- FIFOs (first-in-first-out)
- In Linux
- The file system is organized in one hierarchical tree.
- Partitions/volumes do not appear as drives, but are integrated into the file system tree under directories.
- Users store files in a directory; the operating system takes care of the physical storage, without regard to whether the file is stored locally on a hard drive or remotely on a file server.
- Every device and hard disk partition is represented in the Linux file system as a subdirectory of the root directory. Directories that are only one level below the root directory are preceded by a slash, to indicate their position and prevent confusion with other directories that could have the same name. For example, the floppy disk drive in Linux might be /etc/floppy.
- The root directory lives in the root partition, but other directories (and the devices they represent) can reside anywhere.
- Removable devices and hard disk partitions other than the root are mounted (attached) to subdirectories in the directory tree. This is done either at system initialization or in response to a mount command.
The table below lists some common second-level Linux directories:
|/boot||Kernel and files needed for booting|
|/root||Home directory of the sysadmin user|
|/bin||System binaries, user programs with normal user permissions|
|/sbin||System binaries/executables that need root permission|
|/data||A user-defined directory|
|/dev||System device files/tree|
|/etc||System configuration files|
|/home||UsersÃ¢â‚¬â„¢ home directories|
|/home/username||A userÃ¢â‚¬â„¢s personal home directory|
|/tmp||System temporary files|
(Unix Special Resources)
|Applications software, containing another layer of directories:
/usr/X11R6 File of the X Window system
/usr/bin Executable programs
/usr/lib Libraries for programs in /usr/bin and /usr/src
/usr/sbin Programs for system administration
/usr/src Source files, for instance of the kernel
|/var||System variables (spool directories for mail and print; log and lock files, etc.)|
|/lib||Libraries needed for installed programs to run|
|/media||Mountpoints for removable media|
|/mnt||Mountpoints for temporarily mounted file systems|
|/srv||Data directories for servers|
|/proc||Information about the running system. It's created by the kernel on system startup and is not stored on the hard disk|
|/sys||Similar to /proc, this directory contains information about the hardware|
Common Linux File Commands
|touch||Create a file/update access time on a file|
|cat||View a file|
|more||View a file and scroll|
|less||View a file and scroll|
|head||View the first few lines (default 10)|
|tail||View the last few lines (default 10)|
|ln||Create a link|
|cp||Copy a file|
|mv||Move/rename the file|
OES Linux File System Hierarchy
As a general rule, OES uses the Filesystem Hierarchy Standard (FHS) for file location, but there are exceptions; you'll want to check each application to determine where its files are located.
Linux File Permissions
File permissions, or rights, with traditional Linux file systems are not nearly as granular as the rights system available with NetWare; however, they should be adequate for most situations.
NetWare File System Rights and Linux Permissions Compared
|NetWare Rights||Linux Permissions|
|Supervisor||Set UID (Advanced)|
|Execute (file attribute)||eXecute|
Trustee Rights Management Utilities
|NetWare Rights||Linux Permissions|
|NetStorage (browser)||NetStorage (browser)|
|Novell Client||Novell Client|
|Rights utility||Rights utility
If you are using NSS volumes, you can use the Trustee Rights Utility for Linux to specify trustee rights for directories and files in NSS volumes on OES Linux. This utility does not provide support for Trustees on Linux file systems or for NSS volumes on NetWare. However, the trustee information does work seamlessly with NetWare if the volume is moved to NetWare.
Traditionally, three sets of permissions are defined for each file object on a Linux system. These sets include the read (r), write (w), and execute (x) permissions or their numerical counterpart (4, 2, 1). In addition, it is possible to set the set user id, the set group id, and the sticky bit.
- File permissions are assigned in three categories or to everyone (all):
users (u) groups (g) others (o) all (a)
- The root user receives the permissions available to all three categories of users.
- Permissions and meanings change depending on whether they are applied to files or directories.
The following tables summarize these concepts:
|Permission||Definition for Files||Definition for Directories|
|Read (r or 4)||Allows a user to open and read the contents of a file||Allows a user to list the contents of the directory (if theyÃ¢â‚¬â„¢ve also been given execute permission)|
|Write (w or 2)||Allows a user to open, read, write to, and edit file contents||Allows a user to add to or remove files from the directory (if theyÃ¢â‚¬â„¢ve also been given execute permission)|
|Execute (x or 1 )||Allows a user to execute the file in memory (if it is a program file) and shell scripts||Allows a user to enter the directory and work with directory contents.|
|Additional File Permissions|
|SUID||File executes with the permissions of the user who owns the file||No effect|
|SGID||File executes with the permissions of the group that owns the file||All files and sub-directories owned by the Group owner.|
|Sticky Bit||No effect||Files and sub-directories can only be deleted by the owner or root.|
- In order to remove a file, you must have write permission to it.
- In order to view the contents of a directory (see what files it contains), you need read permission for that directory.
- In order to access a file (read from it, write to it, or execute it) in the directory, you need execute permission for the directory.
- File permissions can be assigned with the chmod command (which accepts either letters or numbers to represent users, groups, and others) as indicated in the table below.
- If the numbering system is used, 655, for example:
- The first number in the group of three is the user's accumulative rights (r+w+x).
- The second number is the group's accumulative rights.
- The third number represents others accumulative rights.
Linux File Permission Examples Using Either Letters or Numbers
|chmod g+w file||Add write permission for the group to the file|
|chmod o-r file||Remove read permission for others|
|chmod a+r file||Assign all (user, group, others) only read permission, no matter what permissions they had before|
|chmod 644 file||Assign read and write (4+2) for the user (the first number), read (4) for the group (the second number) and read (4) for others (the third number)|
|chmod 755 file||Assign read, write, and execute (4+2+1) for the user, read and execute (4+1) for the group and for others|
|chmod 755 dirA|| Grant permission to list contents, create files and change into dirA for the user; group and others may not create files in dirA.
File Permission Scenario
Assume a directory has permissions of 777.
When user root goes to this directory and creates a file, this file now has permissions of 644 (_rw_r__r__).
Some assume that irrespective of what the parent directory permissions are, users in the Other category can only read the file created by root and would not be able to write to it or delete it. But, in this scenario, only the parent directory's permissions are evaluated. The permissions set at the file level are over-written. As a result, anyone can delete or write to the file created by root.
If users (owner, group, or other) have write rights to the directory, they can delete any files in that directoryÃ¢â‚¬â€regardless of the file level rights. To avoid this problem, turn on the sticky bit. (In this case, this means setting permissions of 1777 on the parent directory.) This prevents users from deleting files unless they are also the owner of the file.
The first column of the long directory list shows the access characteristics of a file, in the form of 10 flags, e.g. drwxr-xr-x.
Note that a hyphen (Ã¢â‚¬Ëœ-Ã¢â‚¬â„¢) denotes lack of the given permission type. For example, r-x means that read and execute permission are granted, but not write permission.
ACLs allow permissions to be assigned to individual users or groups even if these do not correspond to the original owner or the owning group. They are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS.
For example, when you replace a Windows server with a Linux server, some of the connected workstations may continue to run under Windows even after the migration. In this case, the Linux system offers file and print services to the Windows clients via Samba which supports access control lists. User permissions can be configured both on the Linux server and in Windows with a graphical user interface (only Windows NT and later).
Note: For an OES Linux server, you can control access to services locally or with eDirectory.
Planning File System Migration
Use collection tables to gather the information you need to plan the file services migration:
Plan the File System Layout
Consider the following:
Identify Needed File System Components
You'll need to determine which file service features best meet your requirements. All file system features in OES 2 Linux are mutually compatible; you can install NSS on OES 2 Linux, use traditional Linux file systems (ext3, ReiserFS), or use a mix.
In addition, the following file system components are available and need to be assessed if they will be included:
RAM. Only iFolder3 requires additional RAM.
Disk Space. For the file services you plan to install, compute the total additional disk space required (above the basic system requirement). Refer to the following for rules-of-thumb.
Other Considerations. Refer to the documentation for each service to gather any additional information before installing the service.
Plan the NSS Implementation
As you plan your NSS implementation, the following file system guidelines should be noted:
Identify NSS Coexistence and Migration Issues
For a complete discussion of the issues involved in the coexistence and migration of Novell Storage Services for OES 2 that might affect your planning, see the following sections in the [OES 2: NSS File System Administration Guide]:
Refer to the following sections in the [OES 2: NSS File System Administration Guide]:
Installing NSS on Linux
Important: Although the NSS kernel modules are included in SLES 9 and later, they are not usable without OES 2 because NSS is a unique file system that is tightly integrated with identity management. The root user is the only local user who can see NSS volumes on an OES Linux server. NSS needs Linux User Management (LUM) and Novell eDirectory to establish non-root connections to the volume. It is OES that provides Linux User Management, eDirectory, Novell Core Protocol Server, and volume and user space management tools that make NSS volumes usable on an Linux server.
The reasons the NSS kernel module ( km_nss) and its sources are delivered with SUSE Linux Enterprise Server 9 and later include the following:
To install NSS on Linux, include the NSS pattern install when you install the OES 2 Linux server. Make the following selections:
When you install NSS during the initial install, NSS is enabled automatically.
In order to use Linux services and utilities on an OES 2 Linux server, eDirectory users must also have a Linux identity. The Linux User Management (LUM) technology creates the local user identity and stores the UID for the user in eDirectory.
You don't need to Linux-enable users unless you plan to use the following NSS capabilities:
The new hard link support in NSS requires a media format upgrade after you have installed or upgraded the operating system. For guidelines and media upgrade instructions, see Section 3.5, "Upgrading the NSS Media Format" in the [OES 2: NSS File System Administration Guide].
For additional information on installing NSS on Linux, see the following sections,in the [OES 2: NSS File System Administration Guide]:
You can also install NSS after the OES 2 Linux install by selecting NSS from the software options in YaST.
OES 2 for Linux requires EVMS to understand and manage NSS partitions. However, the Linux kernel won't allow EVMS to manage LVM partitions and volumes, so LVM installs by default. Thus, the disk(s) where the boot partition (such as /boot for Grub) and system partition (such as for the swap and / ( root) volumes) reside are typically unavailable to NSS. This means that single drive servers require additional configuration to include both Linux system volumes and NSS on the same drive.
The device where you want to create NSS volumes must be managed by EVMS if you plan to use the Storage plug-in to iManager or NSSMU to create and manage NSS partitions, pools, and volumes.
To create an NSS data volume on the same device as your boot partition or system partition, make sure to configure the device for EVMS during the install. For information, see Section A.0 "Installing Linux with EVMS as the Volume Manager of the System Device" in the [OES 2: Linux Installation Guide].
When your data volumes are on non-system devices, do not configure devices during the install. Instead, leave the devices as unconfigured free space and do not assign a volume manager for them. After the install, create the volumes with NSSMU or the Storage plug-in to iManager.
Migrating NSS Data and Devices from NetWare to Linux
Two primary tools are recommended for migrating file system data (including NSS data) from NetWare to Linux:
Prerequisites for both source and destination servers are the same for either method.
Before beginning the migration, make sure you understand "Section 7.0, "Migrating NSS Devices from NetWare to OES 2 Linux" in the OES 2: NSS File System Administration Guide. This section includes the following subsections:
NSS Migration Prerequisites
Source NetWare Server
Destination OES 2 Server
You'll need to install NSS on the OES 2 Linux destination server before moving devices (shared or unshared) or data from NSS on NetWare to NSS on Linux.
The following prerequisites must also be met on the destination OES 2 Linux server.
For NSS Destination Volumes
For NCP Destination Volumes
If you have installed the NCP server for Linux, you can create NCP volumes on top of Ext3 or Reiser file systems on Linux. NCP allows you to use the same method of file system trustees and trustee rights to control access to data on Linux Traditional volumes as you use on NSS volumes and NetWare Traditional volumes.
Since both NSS volumes and NCP volumes use the Novell trustee model for controlling access to data, if you migrate data from an NSS volume on NetWare to an NCP volume, the trustees and trustee rights are enforced. You will need to make sure trustees are authorized users of the destination server
Be aware of the following:
Note: Moving files is now supported between NCP volumes. For example, you can move a file from an NCP volume on NSS to an NCP volume on a Traditional Linux file system. Trustee rights to files are maintained. However, file attributes unique to NSS, such as those associated with quotas and salvaging, are lost if the target volume is not NSS. In addition, NSS file attributes can now be set on NSS volumes from an NCP client.
If you will be moving NSS data to NCP destination volumes, complete the following:
NSS supports moves of devices containing NSS volumes between any servers that support a compatible media format, including moves between NetWare servers and OES 2 Linux servers.
The OES 2: NSS File System Administration Guide includes a table specifying which operating systems can be moved cross-platform between servers in the same Novell eDirectory tree. See "Table 5-1 Cross-Platform Compatibility of NSS Volumes by Operating Platforms." Links are also provided to examples of each category of move.
When moving a non-clustered device, you must also move any other devices that contribute segments to the NSS pools on the device you are moving.
Setting Up File Access for Users
File access for users on the OES 2 Linux server can be set up either before or after you move an NSS volume from NetWare to Linux.
One of the following protocols and services must also be set up and configured:
If you use non-NCP protocols or Linux services for user access on the destination OES 2 Linux server, you must Linux-enable the current users of the volumes with Linux User Management before you move the devices if you want file ownership information to be usable after the move.
Deactivating and Reactivating Pools
For each NSS pool, decommission the pool and its volumes on the original server and reactivate them on the destination server. See the following sections in the OES 2: NSS File System Administration Guide.
Migrating NSS Data
NSS data can be migrated to OES 2 Linux from NSS volumes on NetWare using the command line or GUI migration tools provided with OES 2 Linux.
See Section 2.2, "Using the Migration Commands" in the OES 2: Migration Tools Administration Guide for detailed instructions.
The File System Migration tool supports only full volume migrations. Source volumes on OES1 Linux servers must be NSS volumes. Access the tool from the graphical desktop at the destination OES 2 Linux server, by selecting Computer > YaST Administrator Settings > Open Enterprise Server > File System Migration Utility.
See Section 2.3, "Using the File System Migration Tool" in the OES 2: Migration Tools Administration Guide for detailed instructions.
Post Migration Procedures
Restore Rights and Ownership
After files are transferred, file permissions may need to be reset. As discussed earlier, Linux file system permissions are different from and not as granular as those used by NetWare or Microsoft Windows systems. This becomes extremely apparent for directories where multiple groups previously had access to the data within a file. On Linux file systems, this is not possible so an alternative must be found. Novell recommends the following permissions as a starting point. You may need to change the permissions to better fit your needs.