Difference between revisions of "Bering-uClibc 4.x - User Guide - Advanced Topics - Setting Up a File Server"

From bering-uClibc
Jump to: navigation, search
(Added initial NFS content to NAS section)
(Expanded NFS section)
Line 59: Line 59:
 
===NFS===
 
===NFS===
 
'''Note:''' NFS Server support is currently under development and not included in Bering-uClibc 4.0 Beta1 !
 
'''Note:''' NFS Server support is currently under development and not included in Bering-uClibc 4.0 Beta1 !
 +
 +
While support for NFSv4 is included, only the AUTH_UNIX authentication option is currently supported. RPCSEC_GSS, typically configured to use Kerberos (KRB5), is not supported.
  
 
====Packages and Modules for NFS====
 
====Packages and Modules for NFS====
 
NFS support is a little more complicated than the other protocols:
 
NFS support is a little more complicated than the other protocols:
 
* Most of the "work" is done by the Linux kernel, specifically kernel Module <code class="filename">nfsd.ko</code> (not to be confused with <code class="filename">nfs.ko</code> which implements NFS ''client'' functionality.)
 
* Most of the "work" is done by the Linux kernel, specifically kernel Module <code class="filename">nfsd.ko</code> (not to be confused with <code class="filename">nfs.ko</code> which implements NFS ''client'' functionality.)
* The kernel code is accessed via a set of user-space helper programs. These are provided by the <code class="filename">nfsutils.lrp</code> Package.
+
* The kernel code is accessed via a set of user-space helper programs. These are provided by the <code class="filename">nfs-utils.lrp</code> Package.
** One of these helper programs, <code class="filename">rpc.idmapd</code>, relies on <code class="filename">/usr/lib/libnfsidmap.so</code> from separate Package <code class="filename">libnfsidmap.lrp</code>.
+
** One of these helper programs, <code class="filename">rpc.idmapd</code>, relies on shared library <code class="filename">/usr/lib/libnfsidmap.so</code> from separate Package <code class="filename">libnfsidmap.lrp</code>, but <code class="filename">rpc.idmapd</code> is only required for NFS version 4.
 
* NFS protocol versions 2 and 3 rely on the ONCRPC "port mapper" daemon which is provided by the separate Package <code class="filename">portmap.lrp</code>.
 
* NFS protocol versions 2 and 3 rely on the ONCRPC "port mapper" daemon which is provided by the separate Package <code class="filename">portmap.lrp</code>.
** The port mapper is not required when supporting NFS protocol version 4 only.
+
** The port mapper is not used by clients when using NFS protocol version 4 only, but seems to still be required on the server.
 +
 
 +
The <code class="filename">nfsd.ko</code> Module will be loaded automatically when required, ''provided that file and the files it depends on are present in directory <code class="filename">/lib/modules/</code>''. These files need to be extracted from <code class="filename">modules.tgz</code> and copied to <code class="filename">/lib/modules/</code> manually. The full set of kernel Module files and their paths in <code class="filename">modules.tgz</code> are:
 +
* <code class="filename">kernel/fs/exportfs/exportfs.ko</code>
 +
* <code class="filename">kernel/fs/lockd/lockd.ko</code>
 +
* <code class="filename">kernel/fs/nfsd/nfsd.ko</code>
 +
* <code class="filename">kernel/net/sunrpc/sunrpc.ko</code>
 +
* <code class="filename">kernel/net/sunrpc/auth_gss/auth_rpcgss.ko</code>
  
 
====Firewall Settings for NFS====
 
====Firewall Settings for NFS====
NFSv4 uses only TCP port 2049.
+
NFSv4 uses only TCP port 2049, for the NFS daemon.
  
 
NFSv3 uses:
 
NFSv3 uses:
* UDP port 111 for the port mapper daemon.
+
* UDP port 111 and TCP port 111 for the port mapper daemon.
 +
* UDP port 2049 and TCP port 2049 for the NFS daemon.
 +
* Dynamic port numbers for the mount daemon.
 +
** A fixed port number can be specified via the -p / --port command-line option to <code class="filename">rpc.mountd</code>.
 +
 
 +
====Troubleshooting NFS====
 +
Directory <code class="filename">/proc/fs/nfsd/</code> contains files which report on the NFS server configuration and status, for example:
 +
cat /proc/fs/nfsd/versions
 +
+2 +3 -4 -4.1
  
 
===FTP===
 
===FTP===

Revision as of 10:16, 27 December 2010

Advanced Topics - Setting Up a File Server
Prev Bering-uClibc 4.x - User Guide Next


This material copied directly from http://leaf.sourceforge.net/doc/bucu-nas.html - needs to be checked/updated for Bering-uClibc 4.x!
Davidmbrooke 21:01, 16 November 2010 (UTC)

Introduction

This Howto provides a description about the packages and configurations to use Bering-uClibc 4.x as a NAS (Network-Attached Storage) and/or SAN (Storage Area Network) solution.

To be ready for this special usage, Bering-uClibc versions 3.0 and above have DMA enabled by default when available. This will speedup harddisk performance considerably.


Requirements

Base packages

The following basic packages are recommended to build a NAS or SAN solution:

hdsupp.lrp to setup and maintain harddisks
hdspind.lrp and hddma.lrp with some helper scripts.

mdadm.lrp to manage Linux Software RAID arrays (http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html)

smartd.lrp to monitor the integrity of the harddisks (http://smartmontools.sourceforge.net/)

hdsupp.lrp currently contains the following programs: badblocks, e2fsck, e2label, fdisk, hdparm, syslinux, tune2fs, dosfsck, mke2fs, mkdosfs, mkfs.ext2, mkfs.ext3, mkfs. msdos, mkfs.vfat, mkswap, swapoff, swapon, fsck, fsck.ext2, fsck.ext3, fsck.msdos, fsck.vfat and losetup.

hdspindn.lrp is a simple script package which put the harddisk(s) in standby mode using hdparm which is available in the hdsupp package.

hddma.lrp is a simple script package which forces harddisk(s) in dma mode when it's not automatically recognised or a when a specific controller kernel module is necessary. hddma.lrp also uses the hdparm program from the hdsupp package.


Configuring a NAS solution

The configuration procedure for a NAS server depends on which file sharing protocols will be used. With Bering-uClibc 4.x the supported protocols are:

  • CIFS, also known as SMB, typically used by Microsoft Windows client machines.
  • NFS, typically used by UNIX / Linux client machines.
  • FTP

CIFS/SMB

Packages for CIFS/SMB

Package samba.lrp (or samba22.lrp) is required for CIFS/SMB support.

The standard samba package is based on samba version 2.0.10a, is small and will do in most cases. The samba22 package is based on samba version 2.2.12, which has more options, but is also much bigger.

Firewall Settings for CIFS/SMB

SMB uses TCP ports 137 and 139 and UDP ports 137 and 138. Direct hosted "netbios less" SMB traffic uses port 445 UDP and TCP (Samba22 only)

NFS

Note: NFS Server support is currently under development and not included in Bering-uClibc 4.0 Beta1 !

While support for NFSv4 is included, only the AUTH_UNIX authentication option is currently supported. RPCSEC_GSS, typically configured to use Kerberos (KRB5), is not supported.

Packages and Modules for NFS

NFS support is a little more complicated than the other protocols:

  • Most of the "work" is done by the Linux kernel, specifically kernel Module nfsd.ko (not to be confused with nfs.ko which implements NFS client functionality.)
  • The kernel code is accessed via a set of user-space helper programs. These are provided by the nfs-utils.lrp Package.
    • One of these helper programs, rpc.idmapd, relies on shared library /usr/lib/libnfsidmap.so from separate Package libnfsidmap.lrp, but rpc.idmapd is only required for NFS version 4.
  • NFS protocol versions 2 and 3 rely on the ONCRPC "port mapper" daemon which is provided by the separate Package portmap.lrp.
    • The port mapper is not used by clients when using NFS protocol version 4 only, but seems to still be required on the server.

The nfsd.ko Module will be loaded automatically when required, provided that file and the files it depends on are present in directory /lib/modules/. These files need to be extracted from modules.tgz and copied to /lib/modules/ manually. The full set of kernel Module files and their paths in modules.tgz are:

  • kernel/fs/exportfs/exportfs.ko
  • kernel/fs/lockd/lockd.ko
  • kernel/fs/nfsd/nfsd.ko
  • kernel/net/sunrpc/sunrpc.ko
  • kernel/net/sunrpc/auth_gss/auth_rpcgss.ko

Firewall Settings for NFS

NFSv4 uses only TCP port 2049, for the NFS daemon.

NFSv3 uses:

  • UDP port 111 and TCP port 111 for the port mapper daemon.
  • UDP port 2049 and TCP port 2049 for the NFS daemon.
  • Dynamic port numbers for the mount daemon.
    • A fixed port number can be specified via the -p / --port command-line option to rpc.mountd.

Troubleshooting NFS

Directory /proc/fs/nfsd/ contains files which report on the NFS server configuration and status, for example:

cat /proc/fs/nfsd/versions
+2 +3 -4 -4.1

FTP

Packages for FTP

Package vsftpd.lrp implements a small and secure FTP daemon.

Firewall Settings for FTP

FTP uses TCP ports 20 and 21 (for passive ftp only port 21 is used).


Configuring a SAN solution

Internet SCSI (iSCSI) is an official standard ratified on February 11, 2003 by the Internet Engineering Task Force that allows the use of the SCSI protocol over TCP/IP networks. iSCSI is a transport layer protocol in the SCSI-3 specifications framework. An iSCSI target is the server piece of an iSCSI SAN. The client piece/driver is called "initiator".

The iSCSI protocol uses TCP/IP for its data transfer. Unlike other network storage protocols, such as Fibre Channel (which is the foundation of most SANs), it requires only the simple and ubiquitous Ethernet interface (or any other TCP/IP-capable network) to operate. This enables low-cost centralization of storage without all of the usual expense and incompatibility normally associated with Fibre Channel storage area networks.

The SAN solution uses iSCSI extensively and recommends:

iscsid.lrp - an iscsi target daemon.

The iscsi target daemon can be used, together with an iscsi initiator on a host, as a SAN solution. The iscsi target daemon supports block devices, regular files, LVM and RAID. It uses the following kernel modules which are available in the kernel tarball: iscsi_trgt.o and fileio.o.

Configuration

An example iscsi target configuration (more information in the ietd.conf file) where the block device /dev/hdc is used:

 ############################################################
 User joe secret
 # Targets definitions start with "Target" and the target name.
 # The target name must be a globally unique name, the iSCSI
 # standard defines the "iSCSI Qualified Name" as follows:
 #
 # iqn.yyyy-mm.<reversed domain name>[:identifier]
 #
 # "yyyy-mm" is the date at which the domain is valid and the identifier
 # is freely selectable. For further details please check the iSCSI spec.
 Target iqn.2006-08.network.private:storage.disk1
 # Users, who can access this target
 # (no users means anyone can access the target)
 User joe secret
 # Lun definition
 Lun 0 /dev/hdc fileio
 ############################################################

To use a regular file, it first has to be created on the target disk with dd (this example assumes you mounted the harddisk under /home):

dd if=/dev/zero of=/home/nas.img bs=4k count=<some very big number>

Where the resulting size is count*bs.

The Lun definition would look like this:

Lun 0 /home/nas.img fileio

Firewall settings

If you run a firewall on the SAN box, you need to open tcp port 3260.


Links

Some iscsi clients (initiators): Windows:

http://www.microsoft.com/windowsserver2003/technologies/storage/iscsi/default.mspx

Linux:

http://unh-iscsi.sourceforge.net

http://linux-iscsi.sourceforge.net

http://www.open-iscsi.org

Other iscsi links:

http://cuddletech.com/articles/iscsi/index.html

Additional information:

Network Attached Storage on wikipedia



Prev Up Next