Managing RAID on Linux - Derek Vadala [96]
Once the resynchronization is complete, you can reboot and begin using your new, redundant Linux system.
The Adaptec Storage Manager
The Adaptec Storage Manager is a user-space application that can monitor and manage Adaptec RAID controllers. It is packaged as an RPM file and included on the CD-ROM that shipped with your controller. You can also download the package file from Adaptec's Linux web site (http://linux.adaptec.com). Follow the Linux Downloads link and choose the Storage Manager package for your controller and distribution. Adaptec provides package files for Red Hat and SuSE, and while they are usually a couple of revisions behind each distribution's most recent release, they tend to work even with newer versions of either distribution. You shouldn't have any problem using the RPM files with an unsupported distribution. I tested them with Mandrake and encountered no problems.
The Storage Manager includes a command-line utility for managing arrays and controllers (raidutil) and a GUI utility (dptmgr) that performs the same functions. It also includes a few daemons that provide event logging and a low-level communication layer for interfacing with the controller.
The Storage Manager RPM (dptapps) depends on the driver RPM (dptdriver). Since support is now included in the stable kernel, it's undesirable and unnecessary to use the prepackaged RPM kernel and driver that Adaptec provides. Just pass the --nodeps option to rpm when installing the storage manager:
# rpm -ihv --nodeps sm_linux_v314_install.rpm
There are a couple of device special files that also need to be created. These would have been created had we chosen the Adaptec installation for dptdriver, but because we skipped that step, we have to create them manually. Use mknod to create the files manually:
# mknod -m644 /dev/dpti0 c 151 0
# mknod -m644 /dev/dpti1 c 151 1
# mknod -m644 /dev/dpti2 c 151 2
# mknod -m644 /dev/dpti3 c 151 3
The -m644 option sets the permissions for each file (rw-r--r--), /dev/dptiN specifies the filename, and c indicates that we are creating a character special file. The device major number is 151, and we need to create minor numbers 0 through 3. That's why we execute the command four times, with slightly different parameters.
Once the files are created, start the DPT engine by executing the startup script that was copied into your init.d directory.
# /etc/rc.d/init.d/dpt start
If everything was successful, you should see several DPT-related processes running:
# ps xw | grep dpt
949 ? S 0:00 /usr/dpt/dptelog
967 ? S 0:00 /usr/dpt/dptcom
972 ? S 0:00 /usr/dpt/dpteng
976 ? S 0:00 /usr/dpt/dptcom
977 ? S 0:00 /usr/dpt/dptcom
978 ? S 0:00 /usr/dpt/dptscom -DAEMON
984 ? S 0:00 /usr/dpt/dptelog
985 ? S 0:00 /usr/dpt/dptelog
These processes control event logging and allow the operating system to communicate with the controller. Normally, communication with the controller occurs locally, using a Unix Domain Socket. However, in its default configuration, the dptapps package creates a configuration file that exposes the controller to the local Ethernet network when the daemon processes are started. This service is bound to port 2091/tcp by default. You may decide to provide a security mechanism for this port, if you plan to manage your controller from a remote workstation. I recommend disabling the network communication capability to avoid any potential exploitation. Edit the file /usr/dpt/dptmgr.ini and comment out (use ; to indicate that a line is a comment) or delete the line containing the word TCP in the [Modules] section. This disables remote management via TCP/IP and forces the programs in the dptapps package to use Unix