ProZerver Documentation - Help Text

On each of the admin web pages that is used to configure and manage a ProZerver, there is a link for "Help". Along with the data field names and description that is self-evident, this text also tries to describe what each data field means, recommended usage, interaction with other features, and information for problem analysis.

The help text for each admin web page, and some other notes that needed to be put somewhere, are included here.

What is a ProZerver ?
Admin Default Password
General Setup - Admin Passphrase and Network Name
Date, Time, Time-Zone, Time Sync
Alert for System Conditions
Software/Firmware Update
Configuration, Task, Userid System Data Save and Restore
Shutdown or Restart the ProZerver
Network Configuration Information
Network Configuration for TCP/IP
Server for Web Browser
Server for Windows SMB/CIFS Protocol
Server for Macintosh AFP Apple File Protocol
Server for Unix NFS Protocol
Server for FTP File Transfer Protocol
Server for SmartMirror Rsync Protocol
Other System Management Protocols
List of Disk Devices
Raid Groups
Creating a New Raid Group
Zerver Pair - Link RAID Group and File System between two ProZervers
List of Defined Shares
Create a New Share
Edit Share Attributes and Select Users for Share Access
Delete One or More Share Definitions
List of Users
Create New User Account
Change User Account Attributes or Pass Phrase
Delete One or More User Accounts
Current Permission for All Shares for All Users
SmartMirror Task Current Status
SmartMirror Task Schedule
Create or Edit a SmartMirror Task
SmartMirror Log Files
System Status - Short or Long
System Major Events Log
Login History and Connect Attempts
Most Recent System Startup Details Log
Most Recent File System Operation Details Log
System Operation - Current Details
Agreement and Licenses
Support/Register
Unexpected fnc Parameter Value
About
Defer Delete for SMB/CIFS Protocol
Board Set-up and the Security Back-Door
Useful Command-line Operations for admin

• RAID (Redundant Array of Inexpensive Disks) used to protect against disk failure -- RAID-5-Checksum can keep operating after the failure of any one disk in a Raid-Group, RAID-6 can keep operating after the failure of any two disks, and RAID-1-Mirror can be used to any desired level of redundancy.
• RAID used to create large file-system space from multiple disks, up to 16 TB.
• Software RAID allows use of a wide range of disks (compare with "hardware" RAID in which the firmware is on a controller board, and can only operate with the disks directly connected to that controller board).
• Journal-File-System (EXT3) used for quick recovery from unexpected shutdown (generally minutes, not hours for a full File-System Check).
• SmartMirror uses rsync to create and efficiently maintain back-up files between two or more systems, on schedule of hourly, daily, weekly, or monthly, using whatever bandwidth is available.
• SmartMirror scheduling, job linking, and options can be used to automatically make daily, weekly or monthly full-back-up sets, or sets of changed files.
• Zerver Pair allows immediate mirror of a file system to a completely separate system (but requires high-speed link between the systems), to protect against catastrophic loss of an entire system.
• As NAS-Network-Attached-Storage, sharing data between users is easy.
• With multi communication protocols, sharing data between users accessing with Windows, Macintosh, NFS (for Unix/Linux systems), web-browsers, and/or FTP is easy.
• Using Linux for the kernel and many FOSS Free and Open Source Software projects, there are no per-seat license fees.
• System structure is intended to allow current versions of each of these projects.
• System structure is intended to use a wide-range of hardware, from one to four Intel/AMD CPU, up to 4 GB of memory, from one to four network connections, with a wide range of disks using IDE, SCSI, SATA, and/or USB.
• The ProZerver part of this system is focused on these limited goals, so that set-up and operation will be simple.
• For operation,
  • e-mail alerts are used for system conditions
  • SNMP can be used for performance monitoring
  • NTP can be used to keep time synchronization
  • program ZerverView can be used for some control operations
  • SSH-Secure-Shell can be used for specialized maintenance tasks
• Firmware, configuration, and long-term log files are on a small flash ZerverModule™. All disk space is available for data storage.

What a ProZerver is not --

• Does not have transparent, automatic fail-over. Within a redundant Raid-Group, drives can fail without any disruption, but failure of an entire ProZerver (by flood, lightning, rust, etc) is not recovered automatically. Zerver Pair can be used to keep two ProZerver mirrored within a few seconds of each other, but the recovery will require each client for each protocol to make use of the mirror.
• Does not have support for disk-drive hot-swap. Within a redundant Raid-Group, failure of a disk-drive does not cause any disruption, but replacement of that disk-drive will require some scheduled down-time.
• Does not have an elaborate security model. Network administrators who wish to maintain exhaustive ACL-Access-Control-Lists of operations, users, and groups for every directory and for every file will not be pleased with the ProZerver security model of Share-Directories, User-Names, and very simple access controls. The ProZerver is much better suited for those trying to share data rather than prevent it.
• Is not intended for use in a hostile (network) environment. Although all admin operations are done with admin web pages which are user-password protected, those passwords are not SSL-encrypted.
• Does not encrypt data on disk. Upon theft of a ProZerver, the data would be readable.

Under some conditions, a ProZerver can be booted up and running, but the ZerverModule, or other flash memory, is not accessible. This will result in a state similar to factory-default, however the admin password will be "noflash" (without the quote marks). This is done to signal that something very basic has gone wrong with the flash-device method.

Under other conditions, it might be possible that neither the password-file with the admin:admin password, nor the file with the admin:noflash password can be established. If so, the admin password may be set to "bigproblem" (also without the quote marks).

Although this is a secret, it is possible, perhaps, given enough time, that someone could guess this value. Please change the admin password to a more challenging value at your earliest opportunity.

Several password values are actively discouraged, such as "123", "nimda", or returning the value to "admin", and will be met with a snippy rejection if selected as the new password. There are times, however, when a poor password is better than no password (or the default password), and so the checkbox Apply New Password even if weak can be set, and the lame password will be allowed through (and which can still fail -- in some cases setting the new password to match exactly the old password will be rejected in the lower-level routines).

Note that the "weak password" filter is not exhaustive. Getting through it does not mean that your new admin password is a good password.

You can use letters, numbers, spaces, special characters. The maximum length is somewhere around 120 characters. Insert standard advice here about names of children and pets, words in a dictionary, and spouse's birthday.

After a successful admin password change, you will be prompted to login again with the next admin web page that you select.

Network Name for this Zerver is one of the key values during setup, and it can be set on the System / General page as well as the Network / TCP/IP web page. Some proposed names will be rejected, in the interests of getting a network name that can be used by all of the supported network protocols.

The field Location of this Zerver is used as one of the values within SNMProtocol. It is also handy to include with e-mail alert messages to help identify something about the physical location of the Zerver.

The two submit-buttons Save Next/Config Value and Save and Apply Now appear on several of the web pages for network protocol configuration. There might be a number of changes which should all take effect together that must be set on separate admin web pages. If so, the values can be selected or entered, and Save Next/Config Value used to save the values with the configuration data, but do not attempt to "Apply" them.

The button Save and Apply Now is used to save the new values with the configuration data (as above), and immediately "Apply" those changes, and any other pending configuration changes that had been Saved but not Applied.

In General, the ProZerver does not need to be re-booted after a name change, or other network changes. It will not hurt the ProZerver, however, if you go and reboot all of your Windows systems.

Note that during a change of Network Name -- for this and most of the other admin web pages, the flow of control is to produce the top of the page with the title, navigation links, and the banner using the old Network Name, and then process the change request.

• If any problems are encountered in the processing, error messages can be produced directly (rather than deferred until after header generation).
• The banner with the old Network Name has already been produced and sent by the time the "Name Change Successful" is done. So you won't see the new Network Name in the banner until the next admin web page.

As items of importance during initial setup, this web page also contains links to the pages to Show Agreement and Licenses and Support/Register.

The primary use for the system date and time is to tag entries made in the system log. When used as a file server, the ProZerver stores files and their attributes, including date and time, as set by the client system.

The fields to Set Date and Time for Local Time Zone will set the date and time for the running system, and will also set the "hardware clock" which continues to run while the system is off, for use with a later system-start.

Even through the system will be running using UTC, the values are entered using time in the currently selected timezone.

To Set Local Time Zone a number of values are available, including versions in which "Daylight Savings Time" is not used. This may be handy if tinkering with the U.S. law causes "Daylight" time to start or end on the wrong dates. You can select one of the timezones in which there is no adjustment.

There is also a data field in which you can compose your own timezone. The timezone name can be any 3 or 4 letter sequence, followed by the hours to add to get UTC. So "ATX4" would be one hour ahead of "EST5", and then 30 minutes ahead of "ATX4" would be "NST3:30" (Newfoundland?). For timezones east of the prime meridian, hours must be subtracted to get to UTC -- "CET-1" would be for Paris, and "AFG-4:30" for Kabul, Afghanistan. An additional 3 or 4 letters can be added after the number to indicate "Daylight" time, but it is likely to assume the northern hemisphere, and be applied based on U.S. dates at the time the library code was written.

A more entertaining alternative to setting the system date and time is to discover, set, and maintain the current date and time from one or more time servers, using the fields with Automatic Time Set/Synchronization.

The choice for Continuous monitor and adjust will start a time-monitor program, and will also start that program at the next system re-start. The auto-time program will attempt to contact the configured time-servers, judge which one provides the best time service, and then synchronize the system date and time to it. Under controlled conditions, the time can be kept synchronized within 128 milliseconds.

The Set time once choice will go through many of these same steps, but after establishing an idea of what the current date and time is, the program ends. When run from the admin web page, this process can take part of a minute (e.g. 10 to 25 seconds), and then will display the result log. This is valuable for testing. If the value Set time once has been set at system startup, the configured time servers will be contacted, and the system date and time set. When the time has been set this way, the system date and time can drift.

So where are these time servers to be found? Within an organization which manages machines using DHCP, the message which assigns an IP address to a machine such as the ProZerver can also provide an address of a time server. If so provided, that time server should be used and can provide a time-standard for all local machines.

There are spaces to configure up to four time servers, either by IP address or by DNS name.

And as a last possibility, as shown at ntp.isc.org/bin/view/Servers/NTPPoolServers the DNServer for "pool.ntp.org" returns IP addresses from a large pool of servers that have volunteered to provide time service. Each time that you request an address for "0.pool.ntp.org" you may get a different address, thus directing the load to a wide range of time servers. These are mostly stratum 2 and 3 servers, with the occasional stratum 1. Because these are widely distributed, this would not be the carefully controlled conditions that achieve 128 millisecond accuracy.

Note that an e-mail alert will be sent, or attempt to be sent, when a condition is found, but if that e-mail cannot be sent within a few seconds, the e-mail is abandoned. Messages are not queued for transmit at a later time.

To try to resist the flood of spam messages, it appears common these days for e-mail messages to be silently discarded if some element of the sender information, receiver, or route does not seem completely proper. This has made debug of e-mail configurations more difficult.

The SMTP Mail Server can be given by IP address, and identifies the mail server to be contacted by the ProZerver when an e-mail alert is to be sent. This value may need to be provided by your local network wizard, especially if your network limits which SMTP servers can be accessed. Some people whose internet service is provided by a cable company, such as cox, have found that they can use any mail server they want, as long as it is at cox.net, and all other SMTP traffic is blocked.

Many of these systems use the value 128.121.4.6 which is the value for mail.netzerver.com

The DNS name of the SMTP server, such as "mail.netzerver.com", can be used in some circumstances. One or more DNServers must be defined for the ProZerver, on the TCP/IP configuration web page, and such a server must be accessible and provide prompt mapping to the IP address at the time the e-mail is to be sent. The event system-shutdown, for example, will not be delayed by more than a few seconds by an attempt to send an e-mail alert, DNS lookup included.

The Sender E-mail Address field may have to be set to appease the SMTP server -- it had to be "valid_cox_userid@cox.net" to get through the cox.net server. This field might also be set to help recognize or filter the e-mail alert message -- sending from "dasher@netzerver.com" might identify the ProZerver named "dasher" from some number of other nodes. Keep in mind that only a very few organizations need just one ProZerver.

Within the fields Receiver E-mail Address and Additional Receivers as many as three e-mail addresses can be given. These should be addresses in minimal form -- "user_name@dns.name"

A frequently-used form for e-mail receiver is "organization_name@netzerver.com" when the mail.netzerver.com SMTP server is used. Then "organization_name" is configured at the "netzerver.com" server to forward the alert to one or more support and monitor mailboxes for the organization.

To aid in recognizing or filtering by subject line, the Add Node Name or the Add Net Adapter ID check boxes can be set. The "Net Adapter ID" is the twelve-hexadecimal-digit unique identifier for the network adapter, in the form "01:23:45:67:89:ab".

For the conditions in which to send an e-mail alert, a few notes.

Disk and Raid-Group Event is intended to be the critical category, including raid-group problems found, recovery-begun, and recovery-complete. The messages in category Disk and Raid-Group Information are expected to be non-critical conditions for which an event-log entry occurs, and so an e-mail alert can occur. Examples of the non-critical messages -- during build or re-synchronization of a raid-group, when progress has passed 20%, 40%, 60%, and 80%. Informative, entertaining, perhaps useful, but non-critical.

File System Low Space can be set to trigger at various levels, and works by periodically running a task which checks the amount of free space. This means that a ProZerver could go from sufficient space, perhaps 11% free, to no space, and the alert might not be sent for nearly an hour.

The File System Space Monitor condition will generate a report on file-system space available on a regular schedule. A sequence of such e-mail alert messages can be used to monitor that

• the ProZerver is up and running,
• e-mail alert messages can be successfully delivered,
• the sequence of space-available values in the sequence of messages can be used to document space-usage trends.

Two problems can occur with any product with Software/Firmware Update capability.

• If the update procedure is interrupted in an unanticipated way, part-way through the procedure.
• The upgrade firmware, successfully installed, is not an improvement.

Your ProZerver tries to solve these possible problems by keeping two or more complete versions of the Software/Firmware available. The "current" Software/Firmware is always the default choice when your ProZerver is re-started, however, the "previous" version, and sometimes a version marked as "old", are available after an update, and can be selected from the system console at a suitable moment during the re-start sequence.

If there have already been two or more downloads when new Software/Firmware is to be downloaded, then one of the old versions will be deleted. Generally, the Software/Firmware that had been known as "previous" will be deleted, and the "current" Software/Firmware will be renamed before the new Software/Firmware is downloaded. Upon operational catastrophe (e.g. power-off in the middle of the update operation), there will still be workable Software/Firmware available for selection at system-start-time, either under the name "previous" or "current", depending on the nature and timing of the failure.

Upon software engineering catastrophe (that is, the new/better Software/Firmware does not start), and recovery using the Software/Firmware marked as "previous" (selected at the right moment from the PC console during startup), the failed Software/Firmware is known to have never been successfully started (it is known internally as "next" rather than "current") so that when a Software/Firmware set must be chosen for delete, the failed set can be chosen.

There are several ways that the Software/Firmware update operation can fail (in addition to random-moment power-off).

• Wrong file. The log will show a message from program "tar" similar to -- "tar: This does not look like a tar archive" and "tar: Skipping to next header"
• Incomplete file. If the file did not have all the required pieces, the operation will fail. There may be one or more messages of the form "tar: nextaaaa: Not found in archive".
• Corrupt file. There is a heavy-duty checksum, using program "md5sum", that ties together several components. Regardless of whether the file was corrupt in transport to your client station before it was selected in the admin web page, or whether some previously unrecognized feature of a particular web browser has mangled the data, the checksum has an excellent chance of detecting it. The log will contain the text "Problem with checksum".
• Not enough space. Despite the mechanism of deleting a previous Software/Firmware set, it may be possible to run out of space within flash. A 64MB flash drive might be able to hold three full sets of Software/Firmware and configuration information and various log files. But it could be close. Upon failure to extract the components, the error log includes a display showing the available space. Along with a bunch of mysterious numbers and some column-header text that lines up perfectly when fixed-size fonts are used, the display for "Available" and "Use%" could appear as "0 100% /flash".
• No ZerverModule flash device. Under some circumstances, the ProZerver might not have flash memory to be updated. This would result in messages with the problem described as "Cannot use directory /flash/boot" or with the message "Cannot find device name for flash".

The admin web page "Configuration, Task, and Userid System Data Save and Restore" is intended to allow a single file to be created which holds a copy of all of the files needed from flash memory to be able to restore normal system operation. This file is written to a local raid-group (or to a share-point within a local raid-group) so that its content is RAID-protected, and can be protected by Zerver-Pair duplication or by SmartMirror operation.

This is intended to protect against several possible disasters --

• The data on each Raid-group is okay, but the flash-device has failed.
• A system has failed or is gone, both the Raid-group data and flash device, but the data is okay on another system by Zerver-Pair or by SmartMirror operation.
• Inexpert use of the admin web pages.

In each of these cases, the Raid-Group, File-System, and data may be okay, but restore of access to the data cannot occur until there is full re-configuration of the replacement flash device or of the system with the backed-up data. If done step-by-step, this re-configuration could take hours and be error-prone.

The data which is maintained in flash which would need to be restored --

• The node-name.
• For each network interface, the DHCP and STATIC choices.
• For each network protocol, whether enabled and with what config choices.
• For each share-point, the location within the file-system tree, and the attributes of the share.
• For each locally-defined user, the userid value and passphrase.
• For Windows Active-Directory Domain members, the credentials that define domain-membership.
• For locally-defined userid and for userid known by Windows Domain membership, the access permission for each user to each share-point.
• For SmartMirror, each task definition.

All these need to be restored for there to be full-access by all users to all data with all protocols.

In addition, there are --

• The admin passphrase.
• Choices for alert-messages.
• Choices for time-synchronization.

All of this configuration, task, and userid system data can be restored in one easy step. Provided that a Config-Save file has been created at an appropriate moment.

Creating a Config-Save File

You can select any raid-group or any share as the destination for the back-up configuration data. Use the RAID-Group or Share for Config-Save File(s) selection for where the Config-Save File should go.

Selecting a share (rather than a raid-group) has the advantage that the Backup file can be visible on the network, such as with SmartMirror, so that the Backup file or files can be replicated. Selecting a raid-group (rather than a share) has the advantage that during recovery from a catastrophe, the Backup files in a raid-group are immediately visible to a replacement ProZerver board, but a share (which was not at the base of a raid-group) would have to be re-defined before the Backup file would be visible for use with a restore operation.

Use the Set Directory for Config-Save Files submit-button to select the directory, which will produce a list of the files in that directory with names that might already be Backup files.

To create the Config-Save File, create a passphrase which will be used to encrypt it, and hit the Set Directory and Create New Config-Save File Now button. You should see the result file, with the current date and time, in the list of possible recovery files. The file that will be created will be named ProZerverBackup.NODENAME, using the current actual node-name. If there had been a file with that name, it will be kept, renamed to be ProZerverBackup.NODENAME.old

The result file is normal, in terms of ownership and permission, and can be copied, moved, or deleted. If a Config-Save File is renamed, it is a good idea to keep the text "Backup", with capital-letter "B", as part of the name, so that the file will be listed as a candidate to select for restore.

Why a Passphrase for the File?

The two Passphrase entry input-fields indicate that a new passphrase is being established which will be used to encrypt one new Config-Save File. This passphrase can be the same or different from the current admin passphrase, and can be the same or different from the passphrase used for any other Config-Save File. Different has advantages, provided the value needed can be recalled weeks or months later (or found in the "Critical Passphrases" folder held in the safe maintained in the Security Office by the guy who always worries about disaster recovery).

What is being protected by this passphrase, and why --

• Among the data in the files held in flash are some clear-text passphrases and "clear-text equivalents". During normal operation, these files are protected by file-permission attributes, and so are accessible to the privileged processes that need them, but not accessible in general. Each part of a Config-Save File is as readable as any other, however, so the file passphrase should be chosen to protect these kinds of data fields.
• Occasionally you will hear someone say, "My password used to be my dog's name, but I have changed it to a better password now." Someone with access to the Config-Save File from the right era and its passphrase would not have to untangle the contents of a Config-Save File, but could just restore using that file, which would roll-back any userid passphrase changes, and all the current data for that userid would be accessible using the revealed old passphrase, the dog's name.

Although the ProZerver is not really intended to be used in a hostile security environment, it does have some capability to allow access by some users and restrict it to others. This capability can be seriously weakened by improper protection of a Config-Save File.

Since there are times when a weak passphrase is better than no passphrase, there is a check-box to Apply New Passphrase even if weak, which will bypass some checks that look for particularly weak passwords. Those tests are not exhaustive -- if you create a passphrase that is accepted without having to use the "weak" checkbox, it is not necessarily a "strong" passphrase.

For internal technical reasons, a text string had to be chosen to act as an internal delimiter, with the result that the string could not be used as a passphrase. Thus, "weak" checkbox or not, you cannot use "password" as a password.

Recovery Steps

In a recovery situation, use the RAID-Group or Share for Config-Save File(s) selection to select the location where the recovery file is to be found. In a serious recovery situation in which all the share-definitions have been lost, it may be necessary to create a temporary share-definition to the directory with the Config-Save Files. After submit with the Set Directory for Config-Save Files button, any files that have names that might be Config-Save Files will be listed below.

The files listed will be those with "Backup", the name "ProZerver", or the current node-name as part of the filename. The file-date and size are also shown to help identify each file. Select the desired file from the list.

The Passphrase for Selected File is the value used when the Backup file was created. It might or might not be the same as the current admin passphrase, and might or might not be the same as the admin passphrase that will be restored.

After considering again whether this is, indeed, the Config-Save File that you want, hit the Restore from File and Reboot Now button. If the passphrase is valid for the file, and the file contents appear to be a valid Config-Save File, then flash will be restored and a reboot will be started.

Note that after system restart, the set of network interfaces will be the same. The set of disk-devices will be the same, as will the name of any Raid-Groups and the content of the File-System.

However, there may be many changes in the state of the system. The admin passphrase needed will be the one in effect when the Config-Save File was written. Depending on the nature of the recovery being done, the IP-addresses may be different (if STATIC addresses had been used or come into use), the node-name may be different, the network protocols enabled may be different, the set of userid may be different, the passphrase that would be needed for each userid would be the value in effect when the Config-Save File was written, the share definitions may be different, the share-userid-permissions may be different, the set of SmartMirror tasks may be different, the config choices for Zerver-Pair may be different, and the key-identity for ssh access will be the one in use when the Config-Save File was written.

• apply recently-loaded firmware
• access the hardware clock so that it can run in UTC (GMT), rather than some local Time Zone, and maybe other BIOS values
• initiate absolute protection from all known types of on-line security attacks
• get a few minutes break from heavy data use or firmware testing to fetch coffee
• reduce the fan noise in the server room enough for a conversation
• trim your organization's carbon footprint a little bit
• many others

The IP-Internet-Protocol address of the web-client which initiates a shutdown/restart is noted, along with other identifiers such as the reported browser type, to be used in any e-mail alert about the shutdown, and which can also appear in any e-mail alert generated at the subsequent restart.

For the choice "Restart the system", under some conditions there will be a display of the list of Shares after the restart. Whether this occurs depends on timing of the restart, and the behavior of the web-browser (in persistence and retry for a timed refresh directive).

By popular demand, there is a check so that a refresh of the web page with the message "System Restarted" at an unfortunate moment does not produce an extra, un-intended, system restart.

Even though the choice says "Shut Down the system", note that an actual power-down might not occur, depending on the power-supply type, BIOS configuration, and kernel module configuration. Currently, the general result is that the ProZerver does a clean shutdown and then waits, without actually dropping power.

• If a stream of text messages is visible on the console during shutdown, one might say "Power down", sometimes followed by low-level messages from disk-controller cards announcing successful buffer-disk flush-synchronization.
• If such a stream of console messages is not visible, perhaps a burst of disk-activity lights will be visible, followed by quiet.
• If such disk activity lights are not visible, just wait 20 to 30 seconds after the "System Halting" web page appears, and then hit the big red button.

Configuration changes for all of the protocols shown can be made in one step with the controls on this page. There are some additional values that may be found on the web pages for individual protocols that are not shown here, generally for clutter-appearance reasons.

For each protocol, Enable has choices of either Yes or No, and has Current Status as either off, started, or stopped.

There are security advantages to disabling any and all protocols that are not needed. For some of these protocols, there may be performance or resource-use advantages for disabling a protocol (which will be mentioned in the Help for that protocol). On the other hand, it is convenient to have all protocols enabled that might have any use. Note that if a protocol is off or stopped and is later needed, it can be re-enabled with little difficulty, and without the need for a system restart.

Enable or Disable of each protocol is independent of the choice whether the protocol would be allowed for a given Share. There can be a Share or Shares for which this protocol would be allowed, even though the server for the protocol has been disabled and is off. Also, this protocol might be enabled and using some system resources even though there are no Shares which are allowed to be accessed using it.

The submit-button Save Config/Next Values will save any choices from this page to the configuration file, but does not attempt to Apply them. Any values listed in the column Current Status should be unchanged.

The submit-button Save and Apply Now will save choices from this web page to the configuration file, as above, and attempt to Apply them and any other pending configuration changes. The values listed in the column Current Status will show the result.

The submit-button Save, Apply, and Join Windows Domain Now will save the choices to the configuration file, as above, and attempt to Apply them, as above, and also attempts to Join a Windows Domain, as described in the Help for the admin web page for Windows.

Changes made and Saved, but never Applied, will stay in the configuration file indefinitely, and would be applied with a system restart, if there is ever a restart.

The ProZerver Name can be set here, as well as with a field on the web page System / General, where it might be more convenient, since setting the Network Name of a Node is likely to be nearly as important as replacing the default password.

From one to four Ethernet interfaces can be handled, marked as eth0 to eth3, and discussed below as ethN. For each Ethernet port that has been found, several values are displayed and several values can be set. The MAC-Media-Access-Code is the 48-bit unique value for the interface, expressed in 6-bytes of hexadecimal.

The ethN_type field is the major choice for each interface.

• DHCP-Dynamic-Host-Configuration-Protocol is a mechanism to automatically assign a suitable IP Address, and provide other necessary values. For this to work, the network segment must be running a machine as a "DHCP Server" which receives requests to allocate an address, consults a table to see if that interface, identified by its unique MAC-address, has already been assigned a value within the network. If so, the DHCP Server re-assigns that same address. If not, an unused address within the allocation range, if available, is assigned. A DHCP Server might support a "Reservation Table" such that every request on behalf of a particular MAC-address will always produce the same result IP-address.

  The DHCP Server mechanism is simple, quick, nearly ubiquitous, and a ProZerver can be moved from one network to another with no problems. Another advantage is that the DHCP assignment of an IP-address can also provide several other important IP-addresses and values, such as IP-address of a Gateway-router and one or more DNS-Domain-Name-System Servers.

  The nature of any File Server is to support long lifetime mappings from a large number of client machines who might depend on the IP-address being stable, and might even depend on proper access for their own boot-up. DHCP-assigned IP-addresses, even with a "Reservation" address set, could be a problem if --

  • the DHCP Server is a heavy-duty machine that takes many minutes for its own re-boot and recovery after a power failure or reset (due to a big filesystem or much hardware) before it can hand out any DHCP addresses, during which time the ProZerver, and all other DHCP-dependent machines on the network, cannot get any IP-addresses.
  • the DHCP Server is a light-weight machine, perhaps one of the inexpensive NAT-Network-Address-Translation Routers that reboots in a few seconds, available for a few dollars from chain electronics stores everywhere, with a Reservation Table, but without a back-up of that table for the day when that inexpensive hardware needs to be replaced by other inexpensive hardware.

  If DHCP is a suitable choice for an interface, then all values needed for that interface will be supplied, and some or all of the other values, needed for the machine as a whole (rather than for a single interface on the machine) may also be supplied.

• STATIC is the alternative to DHCP for the ethN_type selection. STATIC addresses are assigned by some other mechanism, generally human, recorded in an official-looking notebook or on a whiteboard. This choice can be made separately for each interface -- some may be STATIC and others DHCP. A full discussion of IP address assignment for a network is beyond the scope of these notes, but here are a few remarks --
  • ethN_ipaddr -- Must be unique. Must be consistent with the other IP-addresses on the LAN. "Unique" may refer to all the IP-addresses in all the sub-networks in the world, or it may refer to the set of IP-addresses isolated from the rest of the internet behind a NAT-Network-Address-Translation firewall.

  • ethN_mask -- A bunch of consecutive "1"-bits, that mark what IP-addresses would be "local," available on the LAN through the ethN interface. An IP address that does not match exactly ethN_ipaddr, but does match when masked by ethN_mask is directly addressable on this LAN, and does not need to be sent to a Gateway-router. A frequently-used value is 255.255.255.0 representing 24-bits for the network-identifier part of an IP-address, and 8-bits for the local part, which would support as many as 254 devices (the count available in 8-bits, minus some reserved values) on the LAN segment.

    There is nothing especially magical about the 255 value. The transition from consecutive high-order "1"-bits in the mask to "0"-bits could use 128, 192, 224, 240, 248, 252, 254, along with 255 and 0. For example, 255.255.252.0 is a mask of 22-bits, leaving 10-bits to identify up to 1022 devices on the LAN. A mask of 255.255.255.224 is 27-bits (128+64+32 is 224), leaving 5-bits to identify up to 30 devices on the LAN.

    While the ethN_ipaddr must be unique, the ethN_mask must have the same value used by all other devices on the LAN.

  • ethN_bcast -- IP-address to select broadcast addressing on interface ethN.

    This can be left blank, since the value can be computed from ethN_ipaddr and ethN_mask for all normal cases as the network-address part of ethN_ipaddr, plus all-bits-set for the local-address part as taken from ethN_mask.

    This value has fairly specialized uses, such as the Samba SMB/CIFS server generating broadcast traffic, such as browser elections, that should occur on one LAN but perhaps not on all attached LANs.

    This field is here so that if there is some exotic configuration, perhaps ethN_mask in non-standard form, then a hand-crafted value can be specified.

  • ethN_gway -- IP-address of a Gateway-router on this LAN. This could be empty, especially if there is no Gateway-router on this LAN.

    Packet routing is something done by the machine as a whole, using each Ethernet ethN port as a piece. Full network access requires at least one Gateway-router for the machine, but a single interface could have an entry here, or not.

    This field is present so that a DHCP server that provides all other information about an ethN interface can provide the Gateway-router, if any, associated with that LAN.

    See additional rant about routing with field Other Gway below.

• OFF is a much more limited alternative to STATIC and DHCP for ethN_type. Not available for eth0, to enforce the idea that not all interfaces can be turned OFF.

The field Other Gway provides one more opportunity to specify a Gateway-router. It can be left empty if one or more of the ethN_gway fields provide a suitable value.

At this level of the internet, routing for a packet can be over-simplified as --

• if the IP-address is for me, grab the packet and process,
• if the IP-address is directly-addressable on a LAN, judged using each pair of ethN_ipaddr and ethN_mask, send it directly through port ethN,
• if not, send it to a Gateway-router, let him figure it out.

Routing is done by the machine as a whole, not by each individual Ethernet interface. For full network access, the machine needs at least one Gateway-router. Each individual Ethernet interface could have one defined or not.

This field, Other Gway, would be used if there is an IP-address that should be used as a Gateway-router that was not supplied by a DHCP-Server, or that should be used even if one or more interfaces are OFF or unavailable.

The IP-address given here must be directly accessible -- it must be within the LAN addresses of at least one of the Ethernet ethN that are expected to be available.

DNS Name Servers, if specified at all, must be given by IP-address, and allow DNS-Domain-Name-System names, like "pool.ntp.org" used by the Date-Time service, to be resolved to an IP-address.

One or more values for this field may have been provided by a DHCP Server, if used for any of the Ethernet ethN ports.

This field is not required, and may be left empty.

Unlike the IP-address for a Gateway-router, which must be directly reachable, the IP-address for a DNS Name Server must be reachable in some number of steps, and does not need to be reachable in one step.

As with the configuration of high-level network protocols shown on the admin web page Network / Information, there are columns marked Current Status to show the current values being used for each of these fields, and a column marked Config/Next Value into which new values are put or selected.

Also like the other Network control admin web pages, there is a submit-button marked Save Config/Next Values that will Save the specified values with the configuration data, but does not attempt to Apply those values. The Current Status values should be unchanged.

The Save and Apply Now submit-button will Save the values, as above, and attempt to Apply them immediately. The Current Status values will show the result of the Apply-attempt.

Note about changing an IP-address while using that IP-address --

Success in this case is announced by a partial web page display, with the browser display hanging, progress bar perhaps marching toward a time-out, waiting for more output and connection-close from an IP-address that no longer exists. This is normal for Apply Now for IP-address change which starts using the IP-address to be changed. A "Stop Loading" control for the browser, if any, can be used to abandon the wait for the connection, and then you can try connecting to the expected new address.

If the new address is not known, as might occur for a change from STATIC to DHCP, you can try browsing to a newly-assigned ProZerver Name. Note that attempted contact to a new, unknown IP-address for a previously existing Network Name may be frustrated by the number of helpful agents that have cached the previous-Name, previous-IP-address relationship, with time-outs from a few minutes to many hours. In some cases, the PC program ZerverView can be used on a PC on the same LAN segment with the ProZerver to discover what IP-address is being used for eth0. Alas, the program does not report anything about any other ethN port.

There can be a more conventional success-display if the IP-address to be changed is on another interface, and is not involved in the connection for the admin web page itself.

If an ethN_type of STATIC has been set using wrong values, or if a machine has been moved from one network location to another and good STATIC values no longer work, the recovery can be tricky.

The PC program ZerverView can be used in this situation also on a PC on the same LAN segment to find what IP-address is in use for eth0. There are mechanisms within that program to change the IP-address for eth0 of a ProZerver, but they work clumsily in an environment in which the IP addressing is inconsistent. There can be 30-second (or longer?) time-outs at various steps along the way.

If the value of the incorrect IP-address can be discovered, and if there is no conflict with other IP-addresses on the LAN, the IP-address of a PC might be temporarily changed to be within the subnet that the ProZerver can address, and then the admin web page used to fix the address.

It may be necessary to use a keyboard and monitor on the ProZerver, and run a console command, after login as userid "admin". See section Useful Command-line Operations for admin for more details, or call ProZerver Customer Support for help.

Although it appears that you can disable the Server for Web Browser, such a request is rejected, since there would be no way to re-enable it again. This field is present to document that there is a server listening on a port for this protocol.

The admin web page exists since there may be additional configuration choices for this network protocol at some time in the future.

A crucial choice for any machine running Windows SMB/CIFS Protocol is membership in an "Active Directory Domain."

The older, more simple choice is to use a Workgroup name only in the field Windows Workgroup/Domain Name. Machines with the same Workgroup name can easily locate shared resources, printers and directories, within that group. Shared resources on machines in Workgroups with other names can also be found and used. For such an arrangement, there is no single centralized point of control, and the userids, passwords, permissions and restrictions are done on an informal basis. For use within a Workgroup, very little else is needed beyond the name of the Workgroup. Other entries on this admin web page related to Domain values can be ignored.

The informal arrangements of a Workgroup are in contrast to the elaborate control mechanisms available with "Active Directory", in which a Domain Name is needed in the Windows Workgroup/Domain Name field, and there must be a step in which the machine Joins the Domain. Once that is done, the userids known to that Domain, as part of that Domain or as part of another "trusted" Domain, are also known to the ProZerver. Share permission can be allocated to such "DOMAINNAME\Userids". Upon attempted access, userid and password checking is done by Domain services, not by the ProZerver, so that a password change in one place, with the Domain, will be reflected in accesses to any shared resources anywhere within the Domain.

The process of Joining an Active Directory Domain requires a Domain User for Join, a userid from that Domain with sufficient privilege for the Join. In some cases, this does not have to be "Administrator". This userid and associated Password are used during the Join operation, by hitting submit-button Save, Apply, and Join Windows Domain Now, which will Save and Apply the other configuration values. This userid and password are also saved for possible later use in receiving the list of Domain users. There could be interesting symptoms if that userid later changed the associated password at the domain controller, which would be fixed by re-joining the domain using a different userid or that same userid with the new/better password.

The result of a Join is not setting a flag-bit for "join", but the establishment of a shared-secret value between the machine and the Domain, so that messages about userids and passwords, and the identity of the machines requesting and responding, can be cryptographically authenticated.

There seem to be a large number of reasons why the Join-Domain operation might be rejected, including unrecognized Domain User, wrong password, or insufficient privilege. One that occurs regularly during system testing is because a machine with that name is already a member of the Domain. Here is a machine claiming to be "TEST1", but the message offered shows no evidence of knowledge of the shared-secret value known to the first machine named "TEST1", so the Join is rejected as coming from an imposter. The message is not over-eloquent -- "Unable to join domain DOMAINNAME". The fix is to perform the Domain operation to select and delete the previous instance of the machine name from the Domain at the Primary Domain Controller, and try the Join again.

After a Join operation, the Current Status will show Join to domain 'DOMAINNAME' is valid, and the Security / Share-User-Permission admin web page will show DOMAINNAME\Users as part of the list of Users that can be granted permission to a Share.

After a successful Domain Join, a restart of the ProZerver is not required, however, if there were already SMB/CIFS client connections when the Join was done, there can be odd Share-permission and Share-denial problems.

After Join to a Domain, it appears that a machine can be a member of one and only one Domain. The machine could join to a different Domain (with potentially interesting results for SMB/CIFS clients whose userid and password values were checked by the former Domain).

There appears to be no "un-Join" of a Domain. If there are circumstances in which the list of DOMAINNAME\Users for Share permission is undesirable, for the Windows Domain Users field, select Are Not Used.

Thus ends the list of admin web page controls that are related to the Domain Name field.

The field Syslog Message Level is used to change the amount of commentary produced by the SMB/CIFS Server as viewable at the Status / Current Details web page. The default value of "1" reports only major events or conditions. Higher values, up to "10", can produce a lot of syslog messages, with the effect that the most recent messages retained and shown may cover only the most recent minutes or seconds. An elaborate syntax is available, used by the developers of the Samba code, for selective logging. A value such as "1 winbind:3" uses a lower log level for most of the code, but a higher log level within one or more sections. When this value is changed and applied, new SMB/CIFS connections use the new value immediately, and existing SMB/CIFS programs are signaled so that the new value takes effect within a minute or so.

There are applications which can access a ProZerver Share using a UNC-style connection, rather than mapping a drive, which might spend otherwise idle time by initiating access and then ending access to the Share. Each of these operations can create an entry in the Status / Login History for Begin-Share-Use and End-Share-Use. Sometimes these are the messages that are needed to help diagnose a problem, especially if it is for a "Public" Share in which there is no "Login" or "Logout" messages. However, if these messages are incessant and useless, the field Share Name Begin-use, End-use with default value Should be written to Login History Now can be set to value Should not. This configuration choice operates differently from almost all the others. Generally, values can be Saved with configuration data but do not take effect until an Apply Now operation (or system restart) is done. The effect for Share Name Begin-use, End-use field occurs as soon as Save is done, regardless of whether Apply is done.

For Macintosh AFP Apple File Protocol, there are two tasks using a modest amount of memory space and other system resources that would be eliminated by disable of this protocol. Also note that recent Macintosh versions can run Windows CIFS/SMB protocol as a client to a file-server, in addition to AFP-Apple-File-Protocol. This is another reason why Macintosh AFP, although useful, might not be required.

There may be additional configuration choices for this network protocol at some time in the future.

For NFS, there are several interacting system tasks that would be eliminated by disable of this protocol.

There may be additional configuration choices for this network protocol at some time in the future.

For the other network protocols, a client is a user (or at least has a User Account of some kind), with the access coming from some system which has a mostly-irrelevant IP-Internet-Protocol address. The clients of the NFS server, in contrast, are systems, perhaps identified only by an IP address. Each of those systems could have one or more clients identified by a User Account, but for an NFS server, the client is the system. Among the config choices needed here is an ability to restrict NFS clients to those using some set of IP addresses.

NFS on a ProZerver is configured with option "all_squash" (whose name is clear evidence that NFS was created by engineers with a problem to be solved, and not dreamed up by a marketing department), so that all accesses from these client-systems use the same userid. That userid is "public", so that files and directories have the same ownership regardless whether creation was done by NFS, Windows, SmartMirror, FTP, or Macintosh.

For FTP, there are virtually no resources allocated for running the protocol until a client appears.

There may be additional configuration choices for this network protocol at some time in the future.

For SmartMirror Rsync Protocol, there are virtually no resources allocated for running the protocol until a client appears.

In client server mode, SmartMirror works really well for hundreds or for thousands of files. It works, but not as well for millions of files, mostly because of building an in-memory list of the names of the files to be transferred, in whole or in part. The load on the memory of a ProZerver can be substantial. To prevent too many concurrent SmartMirror server tasks from running and allocating too much of the system's memory, the field Max rsync connections can be used to limit the number of simultaneous SmartMirror server connections. If the limit is hit, additional connection attempts are refused.

The value for Time Out is used when the client or server end has created the list of candidate files to process, and the list must be resolved with the other end. When used in directories and subdirectories that have millions of files, the difference in time between the quicker end and the slower end can be substantial. This value sets how long is too long to wait for the other end.

Note that SmartMirror and rsync clients can use ProZerver userids, as created with the Security / Create User admin web page. Currently, "Active Directory" DOMAINNAME\Userids usable by other network protocols cannot be used by SmartMirror and rsync.

The admin web page Other System Management Protocols provide controls for several network and system facilities.

SSH-Secure-Shell can provide a secure, encrypted login to a command-line prompt, and could be used by ProZerver Customer Support to help with unusual system diagnosis and maintenance problems. There may also be future use with an encrypted SmartMirror and secure FTP. In the absence of any of these, the Server for Secure Shell could be set off.

To make use of SSH, perhaps for remote help from Customer Support, the Server for Secure Shell must be set On, and keys unique to the system must be generated with the submit-button Save, Generate/Replace SSH Keys for Server, Apply Now on this web page.

The count of Host SSH Keys starts at zero at the factory. Server for Secure Shell can not run until keys have been generated. After generation, there should be three keys, marked rsa1, dsa, and rsa, in which the public-part is represented by a long hexadecimal "fingerprint". A fully paranoid correspondent may ask you, using some out-of-band communication (e.g. over the phone, rather than e-mail), to read all or part of the fingerprint for the rsa key. This assures the correspondent that he is communicating directly with the correct system, and avoids possible "Man-In-The-Middle" eavesdropping on the secure connection.

If there is ever any question about the security of the private part of these keys, that there might be an unauthorized copy of the private part taken from the ZerverModule, the SSH keys can be generated again, replacing the previous keys. The fingerprint should show a completely different value. The downside is that a previous correspondent who painstakingly verified the correct public key from the fingerprint of the previous value will get an alarming-looking message on the next connection-attempt warning that the public key is not the same as before, thus a Man-In-The-Middle attack may be in progress.

There are other system-management facilities controlled from this web-page.

ZerverView is a PC program to find and manage Zervers of various kinds. The field Agent for ZerverView enables communication between that program and this ProZerver. ZerverView can locate Zervers on the same LAN segment with the PC, keep track of Zervers from more remote IP addresses, can report an IP-address and perform a few useful operations, such as reboot. Unfortunately, ZerverView can only report on one IP-address of a ProZerver.

SNMP stands for Simple Network Management Protocol, is quite a bit less simple than ZerverView, might be used in a network with hundreds or thousands of nodes, and can be used to collect performance data as well as availability data. To be used it must be Enabled, as shown in the field Agent for SNMP, and there must be a Community String which functions a little like a password. A frequent value in this context is "public" (but please do not tell anyone).

To deal with hundreds or thousands of nodes, knowledge of the physical location is important. The fields Location to report for SNMP and Contact Person can have any sort of value, especially if it helps with the physical management problem. The Location field is also used, since it is available and handy, within e-mail alert messages and several Status admin web pages.

Boot-up System Messages can be directed to the system console, which is where most people would expect to find them, but which can be distracting, especially if there are ominous-looking messages that say "Fatal" related to the well-being of some sub-subsystem which are not, in fact, Fatal or critical. These messages could also be sent to the first serial port, at 38400 baud, which was very handy during firmware development since one could scroll through messages from the previous shutdown, as well as boot-up messages.

Almost all configuration changes within a ProZerver take effect when an "Apply" submit-button is used. This selection, however, does not take effect until after the next firmware update and restart.

The partition table is a key part of a disk device. By entries in this table, a disk can be divided into multiple pieces of various sizes. For each partition, there is an offset within the device where the partition begins, and the count of sectors in it. These are 32-bit values, and refer to 512-byte sectors, so that maximum start-offset and maximum partition size are limited to 2Tbyte (41-bits worth of bytes). The basic partition table has space for four partitions (although there are conventions which allow more than four).

For each partition, an 8-bit type field provides a hint of the data intended.

• 00 -- partition not currently in use.
• 83 (hex) -- Linux kernel.
• 82 (hex) -- Linux swap space.
• fd (hex) -- Linux raid autodetect.

Many other values are used for many purposes.

In particular, when a Raid-Group is to be assembled, those partitions with the "Linux raid autodetect" value are the ones that are examined, to see if a Raid-Group can be assembled from the components. A Raid-Group piece in a partition with the wrong type value would not be auto-detected after a reboot.

To use a disk-drive when creating a Raid-Group, the partition table must show that the disk is fully available. If there are partition definitions left over from earlier use in a ProZerver, or earlier use in another system, or in-place from the disk factory expecting use in another system, those need to be deleted.

For each disk, there is an entry for any of the basic four partitions showing the size and type. If the disk does not appear to be in use, there will be a radio-button to select each partition to be deleted, or to delete all of the partitions on the disk. Select Del Partition to delete one or select Del All Partitions to delete all from that disk, and hit the Delete Partition Now submit-button.

The partition table on each disk is very small, but the implications of a change are very large, for a number of kernel data structures. The update takes several seconds, and is done in a way that all of the associated kernel structures are updated properly.

Perhaps because there is in-memory representation of this critical data, the Devices web page does not do a good job of showing failed devices, showing the state of the partition table as it existed the last time the device was dealt with, even for devices that are now missing or dead. For a better indication of the health of disk drives, check the RAID-Groups web page.

High on the list of requests for admin web page changes is a single control that would delete all partitions on all available drives, rather than require at least one interaction for each available disk. Yes, such a change could be included in the future. Note that instead of a response of 3 - 4 seconds for each disk, such an operation for 16 available disks would have no response for 45 - 60 seconds, with no easy way to display progress.

RAID is an acronym standing for "Redundant Array of Inexpensive Disks" or possibly "... Independent Disks". There should be a reference here to an authoritative source which defines the acronym, defines the variations, and describes the advantages and trade-offs with each.

More information about different types of Raid-Groups is included with the help associated with Create RAID Group web page. If such an operation has been initiated, the current status is shown as Create Raid-Group and File-System.

The web page RAID Groups is intended to describe everything related to each Raid-Group and the associated File-System. The most-likely configuration for a ProZerver will be one Raid-Group, using all disks, perhaps with one marked as a "spare". However, everything works fine with multiple Raid-Groups on a system, with details of each Raid-Group listed in different columns.

The Raid-Group Name is the value chosen during the Raid-Group Create operation. The Raid-Group id is an internal identifier, md0, md1, ..., in which "md" stands for "multi-disk", and is provided here because some kernel error messages or status displays might use the mdN identifier, rather than the Name.

The field Overall Status is actually a summary of other status fields from this page, and is intended to be a quick-way to see if the status is "OK" or something else. Values --

• Degraded -- Checksum Raid-5 down one drive, or Mirror Raid-1 down one or more drives.
• Degraded-1 -- Raid-6 down one drive.
• Degraded-2 -- Raid-6 down two drives.
• Failed -- Too many drives failed, Raid-Group is Failed.
• Re-sync -- Spare drive being written to restore redundancy level.
• No File-System -- File-System structures not found.
• Off-line -- File-System okay, but not Available to clients.
• Unknown -- Raid-group status is not "active".
• Unrecognized -- Set of conditions un-anticipated
• OK

Field RAID Status considers only the state of the software-raid-driver (nothing to do with the File System). The value "active" is good. Any other value is ungood. For example, an attempt to assemble a raid0 group with insufficient drives (since there is no redundancy in a raid0, all drives must be present and working), the RAID Status will be "inactive" (since the result cannot run).

The field Type shows checksum/raid5, raid6, mirror/raid1, striped/raid0, or jbod/linear.

The field Drives shows the current number and the desired number for the redundant Raid-Groups. A value of "8 of 8" is good. A value like "7 of 8" is not so good. These values come from the software-raid-driver, and are not reported for striped/raid0 or jbod/linear, and so are not displayed.

If a Raid-Resync is in progress, either because of initial construction of a Raid-Group or after a spare drive has been added to a Raid-Group that had been in Degraded mode, then there will be rows for Completed, showing the percentage complete, and Remaining, which shows an estimate of the minutes remaining before full Raid-synchronization is complete. These numbers can be very helpful, but should be interpreted with caution. For example, on initial Raid-Group and File-System creation, the progress on the Raid-Resync is deferred in favor of creation of the File-System structures. The time-remaining estimate can be days or weeks, based on slow progress up to that point. Once the File-System structures are complete and the File-System is Available on-line, the Raid-Resync will begin to make much better progress, and within 3 - 4 minutes may show progress at a rate of 100 GB/hour (writing speed), with completion time of 300 minutes for a raid5 or raid6 made from 500 GB disks. If a heavy File-System load is put on that system during the Raid-Resync, then progress will be slowed and the estimated end-time may (again) become higher, perhaps much higher.

The fields Blocks (1024) and MB (1000000) show the capacity of the Raid-Group space (in contrast to the size of the File-System which is held within that space). The value "1000000" is spelled-out so that it is unambiguously a decimal-million (in contrast to a power-of-two approximate million, as is sometimes more convenient to use within computer engineering).

These numbers may be smaller than would be expected by adding up the values printed on the box that the disks arrived in --

• For Raid-Groups with redundancy, the net-space is less than the gross-space -- a raid5 made with 5 disks will have the space of (approximately) 4 disks.
• On each disk, there is a partition table (which is small).
• On each disk, some space is set-aside for control of the Raid-Group itself, perhaps 64KB.
• For a Raid-Group, allocation by Raid-block size and stripe size can leave little pieces of the disk unused.
• For each disk, allocation may involve cylinder boundaries, or other reasons why little pieces might be left unused.
• Except for jbod Raid-Groups, the part used on all drives must be the same -- if the disks are different sizes, there can be large pieces left unused on the bigger disks.

File System Used MB is related to the File-System within the Raid-Group space, rather than the Raid-Group space itself. This would include file-content, directories, and space for the journal used for fast File-System recovery (32 MB), which is why a freshly created Raid-Group File-System shows 33MB used. Also note that since file-content is held in 4096-byte blocks, a system with a very large number of very small files might have much less in content than this number would indicate.

The fields File System Free MB and File System Free, which shows percentage in part so that there is a number that can have highlight in yellow, show space available for file-content and directories. Note that the procedures for placing appended file data "near" the rest of the file cannot be very effective when the file-space is low. Even though 1% of a TByte space is still a lot of free space, there are performance reasons to not let it get that low.

The fields File System Used MB and File System Free MB together will not match the field MB (1000000)  --

• The space used by the File-System is larger than Used + Free by the size of the File-System structures. Super-blocks and inodes are pre-allocated for about .3% of the space (128 bytes for each 40960 bytes of space). For 100 GB of space, this can be 320 MB.
• For possible later use with the Zerver Pair feature, space that would be needed, 128 MB, is reserved within the Raid-Group space, but is not part of the File-System.
• A Zerver Pair could be made with Raid-Groups of different sizes. The File-System, its inodes, and the reserved space for Zerver Pair operation all must fit within the size of the smaller, and would leave space unused on the larger Raid-Group.

File System Status shows any need for a File-System check operation. Value can be "clean" or "in use" for good status, or "not clean" for not-so-good. The value "clean with errors" can occur if File-System operation encounters a problem (which would be shown in the Major Events Log). A File-System Check operation should be done at an early opportunity to perform repairs on the File-System structures.

A field File System Check will appear, with value "started", if such an operation is in progress, either manually initiated, or due to serious problems at system start-up.

A line Zerver Pair Use will appear if the Raid-Group File-System has been configured as part of a Zerver Pair.

If the File System is mounted and available on-line, an entry appears for Available As, showing the name of the mount-point. The File System must be mounted in order for any of the share-points within it to be visible. For a File System named "raidblue", the mount-point is most likely to be "/hd/raidblue", using the File System name. There could be a variation if a system is booted and finds disks from two or more Raid-Groups which happen to have the same name (as can happen in an engineering lab with test scripts which create Raid-Groups using the same names over and over). In such a case, you could see Available As "/hd/raidblue" for a Raid-Group and "/hd/raidblue1" for another. If the File-System is not on-line, perhaps because the Raid-Group is Secondary in a Zerver Pair, perhaps because it has been manually taken off-line, the field shows "(Not Available)".

The File System Type field is "ext3" to show that a journal-File-System is in-use. There might be different values in the future.

The Disks and Partitions area is a list of all disks, providing an internal identifier (hda, hdb, hdc, ..., sda, sdb, sdc, ...), the I/O path to the disk (e.g. ide2-M, scsi4-0-3-0), the disk size in blocks (1024-bytes) and MB, and the text-description reported by the disk (e.g. Maxtor, SEAGATE) or by a controller (e.g. 3ware Logical Disk 3).

Disks and Partitions is intended to show the relationship between disk-partitions and Raid-Groups for one Raid-Group, for multiple Raid-Groups which use only one partition on a disk, or even for multiple Raid-Groups in which a disk could have multiple partitions used in separate Raid-Groups (created by some method different from the ProZerver interface, and then installed in a ProZerver).

In the column for each Raid-Group, any disk-partition which is part of the Raid-Group is shown in the row with the other disk information. There is an internal identifier for the partition (hda1, hdb1, ..., sda1, sdb1, ...), the partition size in blocks (1024-bytes) and MB. There is also a field [k] that shows the relationship of the partition to the Raid-Group. Values include --

• [0], [1], [2], ... current working members of the Raid-Group. For an N-drive Raid-Group, the values are [0] to [N-1].
• [k] FAIL -- For k from [0] to [N-1],the partition (and drive) have Failed.
• [S] -- The partition is a Spare.
• [N] or [N+1] -- The partition is being built as part of a Raid-Resync. For an 8-drive Raid-Group, the working members are [0] to [7]. If a drive has failed and been removed, one of those values will be missing. If a Spare-drive is provided to the Raid-Group, it will be marked as [8] during the Raid-Resync, and will replace the missing value when the Raid-Resync is done. If the Raid-Group is type raid6, there could be two Failed drives, two Spares could be applied, and there could be two partitions with numbers, e.g. [8] and [9], outside of the working range.

Within Disks and Partitions beyond the columns for each Raid-Group is a column marked Select with radio-select buttons, one for each disk-drive, used with some of the Raid-Group operations for repair and replace, described below.

There are also entries marked other which show for each disk the space, in blocks (1024-byte) and MB that is not in use by Raid-Group partitions.

There is a lot of useful information in this display, and it can be lengthy, so the fields Raid-Group Name and Raid-Group id are repeated above the selectors for various Raid-Group and File-System operations, so that if there are multiple Raid-Groups, there is a better chance that the right one will be selected.

Some operations cannot be done while a File-System is Available on-line and perhaps in use, and there may be other reasons why a File-System should be made un-available at some time.

The File-System operation Take File-System Offline if not busy will succeed if there are no clients using the File-System or any files on it, and will fail with a message about "Busy" otherwise. The operation Take File-System Offline Now signals those client-tasks to relinquish use of the File-System (using a function named "kill"). Note that the "Now"-operation can still fail, with message "Busy", if there is a root-user login, through the console or ssh-secure-shell, using a file or with a working directory within that File-System. There may also be problems taking a File-System Offline if there has been NFS-Network-File-System access within the File-System.

For these File-System operations, you select the desired operation for the desired Raid-Group, and then hit the submit-button marked Apply Raid-Group Change Now.

With a File-System Offline (no longer Available), Run File-System Check is possible. A File-System can be a complex structure, with a very long lifetime for operation results, and sudden-shutdown, hardware-glitch, and software imperfection can leave odd problems. Use of a Journal, as part of the ext3 File-System, eliminates much of the problem of a sudden-shutdown -- after the pending changes in the Journal are applied at system re-start, the File-System can be known to be in a clean state, just as if a proper shutdown had been done. Still, there are times when a series of seemingly in-explicable problems occur, and it would be prudent to take the File-System Offline and run a File-System Check, to find and fix any inconsistencies. The ProZerver is configured to make File-Systems which do not call for automatic File-System check after some number of re-boot, or during a re-boot after some number of months, since multi-TB File-Systems can take a half-hour at best, many hours at worst, and this can be a really unpleasant consequence of a re-boot intended to clear some simple condition. Thus the capability to run a File-System check manually, at a time of your choosing.

There will be a File System Check status line with a value of "Started" if one is in progress. There will be no such line or no value when the File System Check is done, and result log can be seen on the web page Status / FileSys Op . To put the File-System back Online, so that it will be Available for clients, use the submit-button Assemble All Raid-Groups, Enable All File-Systems Now. There has been a request to add an operation to initiate a File-System Check and then automatically put the File-System Online if there are no problems.

The operation to Stop the Raid-Group can be selected if the File-System is Offline, and after Apply Raid-Group Change Now is hit, has the effect that the Raid-Group is no longer assembled, and will disappear from the Raid-Group display. This is a step in using those disks to create a new Raid-Group. The next step would use the Devices web page to delete the partition definitions on each device. (After Stop the Raid-Group, the data are not gone, and the Raid-Group can be re-assembled and the File-System made Available Online by hitting the submit-button Assemble All Raid-Groups, Enable All File-Systems Now.)

The operations manipulating individual drives within a Raid-Group can be done while the File-System is Available Online or is Offline.

Mark Selected Drive as Failed can be done if a drive is suspected of having problems, or to test Raid-Group recovery mechanisms, by selecting the operation with its radio-button, selecting the target drive in the Select column, and hitting the submit-button Apply Raid-Group Change Now. The result will be a drive marked "FAIL" in various ways, with a tag [k] FAIL. Raid-Groups with redundancy should continue to operate. Raid-Groups with no redundancy, like raid0, will not.

To Remove Drive from Raid-Group, the drive must be either a Spare or marked FAIL. The drive is chosen with the radio-button in the Select column, the operation is selected for the Raid-Group, and hit the submit-button Apply Raid-Group Change Now.

Add Selected Drive as Spare is used to add an unused drive to a Raid-Group. If that Raid-Group had been in degraded mode, the arrival of a Spare will initiate a Raid-Resync to write the newly-arrived drive, so that full redundancy will be restored. The drive is chosen with the radio-button in the Select column, the operation is selected for the Raid-Group, and hit the submit-button Apply Raid-Group Change Now.

The last submit-button, Assemble All Raid-Groups, Enable All File-Systems Now, is not associated with a single Raid-Group or single File-System or single drive, but with all drives and all Raid-Groups. Similar to the steps that occur at system start-up, all partitions on all drives (marked with the "Linux raid autodetect" partition type) that are not already in a Raid-Group are examined, any and all Raid-Groups are assembled and started, if possible. Then any and all Raid-Groups (except those to be used by Zerver Pair) are checked for File-Systems and mounted Online, if possible.

For use with the Zerver Pair feature, there is a specialized case in which the name field can be left empty. On the node to be used (initially) as a Secondary, an empty name is used to select that a Raid-Group should be created (disk-space assembled and redundancy synchronization done), but that a File-System is not to be created within it. That space will receive a copy of the File-System as created and used on the Primary node of the Zerver Pair. Note that after a role-reversal, the name of the Raid-Group and File-System that had been selected for the node formerly known as Primary would now appear on the node formerly known as Secondary. For use with Zerver Pair nodes known as "EAST" and "WEST", this suggests that the Raid-Group File-System name should not be related to either East or West.

The Type of Raid-Group to Create selection is the critical choice which balances redundancy, capacity, and throughput. The choices as listed have a short summary of the advantages of each type.

• Checksum RAID-5 Best mix of redundancy and throughput

  For a Raid-Group with 8 drives, the File-System will be the size of 7 drives. The equivalent of one drive is redundant. For performance reasons, the actual blocks of checksum values are distributed among all the drives. Any one drive can be lost with no problem, all File-System data will be fully available.

• RAID-6 two drives are redundant

  For a Raid-Group with 8 drives, the File-System will be the size of 6 drives. The equivalent of two drives are redundant. Even with two drives lost, all File-System data will be fully available.

• Mirror RAID-1 Maximum redundancy

  The size of the File-System will be one drive, and the redundancy level is based on the number of drives applied, two, three, or more. If there are four drives in a mirror Raid-Group, any three could be lost with no problem, all File-System data will be fully available.

• Striped RAID-0 Best throughput but with no redundancy

  For a Raid-Group with 8 drives, the File-System would be the total size of all 8 drives. Nothing is redundant, checksums are not computed nor written. Consecutive blocks of the File-System go to consecutive drives, so that all drives are used equally. This would be used in situations in which maximum capacity or maximum throughput was needed.

• One Disk or a Bunch of Disks with no redundancy

  If a Raid-Group must be made from one drive, this is the choice. If a Raid-Group must be made using the maximum space from disks of different sizes, this is the choice. Consecutive blocks of the File-System would all go to the first drive in the set until that space was filled, and only then begin to use blocks from the next drive. This choice is sometimes listed as JBOD-Just-a-Bunch-of-Disks.

Checkboxes marked Use in Raid-Group appear with disks which have space available. Use these to select the drives to be used in the Raid-Group.

Each disk is identified with several pieces of information, in which recognizable text might occur in the way that the disk identifies itself (e.g. "Maxtor", "Seagate"), or is identified by a controller (e.g. "Logical Disk 3"). Among the cryptic pieces will be internal identifiers (e.g. hda, hdb, hdc, ... or sda, sdb, sdc, ...), input/output path identifiers (e.g. "ide1-M", "scsi4-0-3-0"), disk-capacity as reported by various mechanisms expressed in either 512-byte sectors or in 1024-byte blocks, for the full disk, for any partitions already allocated, and for other available space. Although cluttered, the display warms the heart of those engineers who would rather have more information than less.

There can be disks listed without a select checkbox. Disks that are already fully in use will have no checkbox. Disks that are considered empty but that have had other use, either in a ProZerver or in another system, or which have come from the factory preconfigured for another system, may have a partition table which allocates the disk space in various ways. To initialize these disks for use within a ProZerver Raid-Group, use the Devices admin web page.

A small-size device will be listed with an indication "/flash" for the ZerverModule that holds the firmware, configuration data, and long-term log files. It is not available for use within a Raid-Group.

Currently, only one partition of a disk can be used in a Raid-Group. This means that a disk could have much space available, and there could be a Use in Raid-Group checkbox for a disk, but if the first partition of that disk has already been allocated, then that disk cannot be used in another Raid-Group. (Such a partition is shown as a line with an internal identifier such as hda1, hdb1, ... sda1, sdb1, ...) A feature to look forward to, perhaps.

The field Size from each disk can be left empty to select the maximum usable space from each disk. For JBOD, this is the maximum size of each selected disk. For the other Raid-Group types, the usable size is limited by the smallest selected disk. There are reasons why one would want less than the maximum, primarily to create a Raid-Group and File-System of a particular size to match another File-System, either for use by Zerver Pair or other backup mechanism. Creating a Raid-Group of a limited size is also useful for performance tests for different Raid-Group configurations.

The submit-button marked Check Raid Group Selections leads to the next step. The selected values are checked for consistency (e.g. too few disks selected for a Mirror group), and if no problems are found, a summary of what would be done is given (e.g. "Create a Raid-Group of approximately 400000MB...") with another submit-button marked Create Raid Group Now. You can initiate creation of the Raid-Group, or you can change any of your selections and re-run the checks with the Check Raid Group Selections submit-button.

Success from the Create Raid Group Now operation means that Raid-Group construction has begun, or at least that it did not fail on step-0. The current state of the create operation can be checked on the main Raid Group page.

For a minute or more, it may appear that there is almost no disk activity, as partition tables are changed on each disk. The build of File-System structures will be marked by furious I/O activity that can last a half-hour (depending on size) before the File-System is on-line and available for use.

If this is a Raid-Group with redundancy, then the Raid-Resync gets into full swing in which mirror-disks are written or checksums computed and stored. A Raid-5 made from 500GB disks can be in full synchronization after about 5 hours (around 100 GB/hour being written). The File-System is usable during the Raid-Resync (with some performance penalty) to create shares and store data, but the data is not fully protected by redundancy until the Raid-Resync is complete.

Write operations to the File-System within this Raid-Group are also sent to the ProZerver with the Raid-Group in the Secondary role, and are written there within a few seconds. In some sense, this is two Raid-Groups holding mirror copies of one File-System.

The network connection between the two systems should be able to keep up with write activity to the File-System in the Primary Raid-Group -- a good amount can be buffered, but if the copy sent on the network gets too far behind, local disk write operations will be held back. Thus the two Raid-Groups are always within some number of operations and a few seconds of being identical.

Upon catastrophe at the Primary, either loss of all hardware by fire/flood/tornado/theft or loss of the Raid-Group due to excess disk-drive failure, the roles can be changed, the system with the Raid-Group formerly known as Secondary can be manually designated to be Primary, a File-System Check and Repair should be only a few seconds (since this is a journal File-System, ext3), and set Available mounted Online. The data in this copy of the File-System will be within a few seconds of the data that had been written to the failed system.

The newly-activated Primary will need to have Share definitions in place, User Accounts may need to be ready, and client-connections will need to be changed.

The basic mechanism is from a project called DRBD for Distributed Replicated Block Data, which is intended for environments in which an automatic fail-over between two systems can be done, and some kinds of client-programs can continue with no disruption. The client-programs used with a ProZerver can be very generalized, and configuration, set-up, and proper operation to support transparent automatic fail-over is not included with (beyond?) current capabilities.

As used in Zerver Pair, manual diagnosis of any failure is needed, with manual fail-over.

Even without an attempt at automatic state change, the number of conditions which can occur between two systems using Zerver Pair during configuration, set-up, initial synchronization, normal operation, recovery operation, and re-synchronization is fairly large and the conditions can be complex. The goal is to allow use of this feature for over-all simple and reliable operation.

Much more can be written. For now, please contact ProZerver Customer Support for more help.

A system might have one Share definition, or many. Within File-system space, multiple shares could be disjoint or could overlap in various ways.

The Share Name and Description columns are the externally-visible identifiers for a share.

The Path column defines the location of the share-point in terms of the Raid-Group name (or Raid-Group mount point) and directory-path within that File-System. This is the column which will reveal if one share is actually a sub-set of another share. Two shares could actually have the same share-point -- same Raid-Group and same directory-path. For example, one share might be Public and Read-Only, and another could be Read-Write to a Restricted set of User-Accounts.

For Attributes of a share, the most significant is first -- either ok or n/a. The value ok means that the Raid-Group exists, is Available mounted Online, and the directory-path for the share definition exists and is usable as a directory. Access to the share should not fail for technical reasons (but access might be denied for Permission reasons). The value n/a is for "no access", is generally highlight in yellow, and means

• that the Raid-Group is not known
• or has failed,
• is not Available mounted online by manual operation,
• or for a File-System Check operation,
• or has become Secondary within a Zerver Pair,
• or that the Raid-Group is Available mounted online but that the directory-path for the share no longer exists
• or is not usable as a directory.

Other Attributes --

A public share has the attribute p -- anyone with access to the ProZerver (for a given protocol) can access the share. The absence of "p" is for a non-public, restricted share -- access is allowed only for those User Accounts selected in the Permission list.

A read-only share has the attribute r -- modifications to the share files and directories are not allowed. The absence of "r" is for a read-write share, modifications to the share files and directories are allowed (provided the share is public or the User Account has access permission to the share).

A hidden share has the attribute h -- for several protocols, a request for a list of available shares will omit hidden shares from the list. Access might be allowed, but first the client needs to know that the share exists. This can help protect data from accidental access by users who click on every visible link, but does not really increase the security of the system since no user is actually denied access. The absence of "h" means that the share-name is visible.

Windows file-systems maintain a number of properties about each file which do not have any correspondence in Linux, including "Archive-needed", "System-file" and "Hidden" (which should not be confused with the share-name property of the same name). If the ProZerver attribute a appears, then these Windows file-attributes will be maintained (encoded using the Linux "execute" permission bits), which is probably a good choice for Windows clients. The absence of the "a" means that Linux "execute" permission will be maintained for each file, which is way better for Linux or Unix clients using NFS. For other protocols, using the Windows attributes is generally not harmful.

The column Protocols shows which protocols have been selected to access the share and which protocols cannot be used for the share. Note that these selections and this display are independent of whether a given protocol has been enabled and is currently running, as set with the Network admin web pages.

The link marked Permissions and the link using the name in the Share Name column go to the same admin web page, in which the share properties can be changed, and the list of User Accounts for the share can be checked and adjusted.

To see the access permissions for all User-Accounts for all Shares, check the admin web page Security / Share-User-Permission.

Characters not allowed in a Share Name --

• / -- ambiguous path-handling
• \ -- ambiguous path-handling
• = -- internal delimiter
• * -- process problems
• ? -- process problems
• " -- process problems
• ' -- process problems
• : -- delimiter problem for Windows, Macintosh
• # -- delimiter problem for NFS

For the characters that can be used, Share Names might be created that cannot be handled by some clients for some protocols. During testing, a share named "A!B@C$D%E^F&G _-+H" gets heavy use with Windows, HTTP, SmartMirror, FTP, and NFS within a test script.

Some possible Share Names are dis-allowed, because of conflict with other parts of a ProZerver.

• IPC$, IPC_ -- conflict with Windows server
• flash, var -- conflict with FTP config
• admin, cgi-bin, icons, prodicons, server-info -- conflict with HTTP reserved use

The Share Description field is visible in a number of contexts in which a list of shares is given, and would be used by clients to help recognize the Share. The maximum length is 48 characters.

The Share Attributes describe the fundamental properties of the Share.

For a Public Share anyone with access to the ProZerver (for a given protocol) can access the share. For a Non-Public Share or Restricted Share, access is allowed only for those User Accounts selected in the users list on the Permissions admin web page for the result Share.

A Read-Write Share allows modifications to the share files and directories, provided that the share is public or the User Account has access permission to the share. Within a share which is Read-Only, modifications to the share files and directories are not allowed.

For a Hidden Share, for several protocols, a request for a list of available shares will omit hidden shares from the list. Access might be allowed, but first the client needs to know that the share exists. This can help protect data from accidental access by users who click on every visible link, but does not really increase the security of the system since no user is actually denied access. For non-Hidden Shares, the Share Name will be visible, and will appear on various protocol lists of Shares.

If Encode Windows File Attributes is selected, Windows file-system properties "Archive-needed", "System-file" and "Hidden" (which should not be confused with the share-name property of the same name) will be maintained for each file, encoding the values using Linux "execute" permission bits. This is useful for Shares in which Windows programs expect to be able to set the "Archive-needed" bit, and have it stick. This can be confusing if the Share actually contains Linux or Unix executables when viewed by a Windows program, because all of those files will be reported as "Hidden" (or not reported at all). The alternative is to Use Linux/Unix File Attributes, and is important if the share will be used for NFS access by Linux or Unix clients that need the execute-permission bits to operate properly.

The various network Protocols can be enabled or dis-allowed for the Share.

The process to define, and perhaps create, the Directory for the Share is done in several steps. If you happen to know the full-path desired for the share, and that directory already exists, you can select Full Path Name for Directory and enter the path directly. Generally you will start with Select Raid-Group, and hit the Check Share-Create Values submit-button.

Once a Raid-Group has been selected, the re-display of the Create-Share web page will show any directories that already exist, with a field that can be selected and used to create a new directory. Each time that the Check Share-Create Values submit-button is hit, focus moves up and down the tree of directories within the Raid-Group.

If there are no problems detected, an additional submit-button is offered -- Create Share Now, which will use the Share Name, Attributes, Protocols, and Directory for the Share values to Create the Share Definition.

If you return to the List Shares admin web page, the new share will be shown with links on the name of the share, and in a column named Permissions. Either of these links will select the web page Edit Share Attributes and Select Users for Share Access for the share. This is where the list of Users with share permission is set. Many other Attributes of the share can be adjusted also.

Two properties that cannot be altered are Share Name and Directory for the Share. You have to create another Share definition if either of these values are unsatisfactory.

The Share Description field is visible for several protocols which provide a list of Shares.

The Attributes that can be altered --

For a Public Share anyone with access to the ProZerver (for a given protocol) can access the share. For a Non-Public Share or Restricted Share, access is allowed only for those User Accounts selected in the users list below.

A Read-Write Share allows modifications to the share files and directories, provided that the share is public or the User Account has access permission to the share. Within a share with Read-Only Access, modifications to the share files and directories are not allowed.

For Share Name Visible, the Share Name will appear on various protocol lists of Shares. For a Hidden Share, for several protocols, a request for a list of available shares will omit hidden shares from the list. Access might be allowed, but first the client needs to know that the share exists. This can help protect data from accidental access by users who click on every visible link, but does not really increase the security of the system since no user is actually denied access.

If Encode Windows File Attributes is selected, Windows file-system properties "Archive-needed", "System-file" and "Hidden" (which should not be confused with the share-name property of the same name) will be maintained for each file, encoding the values using Linux "execute" permission bits. This is useful for Shares in which Windows programs expect to be able to set the "Archive-needed" bit, and have it stick. This can be confusing if the Share actually contains Linux or Unix executables when viewed by a Windows program, because all of those files will be reported as "Hidden" (or not reported at all). The value Use Linux/Unix File Attributes is important if the share will be used for NFS access by Linux or Unix clients that need the execute-permission bits to operate properly.

For the Protocols listed, each protocol can be allowed for the share or disallowed. These values are security selections, and might show, for example, that a share is not to be accessed using FTP. That selection remains, independent of whether the FTProtocol is enabled or disabled within the Network controls.

The list of Users shows both User-Accounts defined on the ProZerver and those names known through Active Directory. Those with permission to access the share have a select-mark in a checkbox. If this is for a Non-Public Share, only those selected Users would be allowed access to the share. If this is for a Public Share, then all Users would be allowed access to the share, and the list is maintained in case the share becomes Non-Public at some time in the future.

Below the list of known users, there may be a section Additional names found showing User-Account-like or Windows-DOMAIN\Names that are listed as having permission, but that are not in the list of known names. This might occur if one or more Windows-DOMAIN are in-accessible, so that a set of DOMAIN\Names are temporarily unknown. There could be circumstances in which a ProZerver-local User-Account was deleted, but that name was not removed from the permission list for a share. These names can be kept, by leaving the select-mark in the checkbox, or removed from the permission list, by removing the select-mark in the checkbox.

This display shows the permission list for all users for this one share. There is another admin web page at Security / Share-User-Permission, with a matrix showing permission for all users for all shares. That may be more comprehensible, and can be used to change permissions for all shares at one time, but it does not handle changes of any other Share attributes.

All of these values can be changed, and put into effect by hitting the Save and Apply Security/Permission/Attribute Choices Now submit-button. The new values take effect immediately for new clients, or previous clients re-establishing a connection. There can be long-life connections between a client and a ProZerver, and those would continue to exist and run with Attributes and Permissions as existed when the connection was established. Removing a User-Account from a permission-list, with Save and Apply, will not disconnect a previously-connected User.

Note that the Delete Share operation does not delete any of the data. The directory-path in the Share-Definition, if any, will remain, and all contained files and sub-directories will be untouched. Only the Share-Definition -- including Attributes, Protocols, and list of Users -- is removed. The data may no longer be visible using the deleted Share Name, but the existence of the data is not affected.

Select one or more Share-Definitions by marking the checkbox by the Share Name and hit the Share Definition Delete Now submit-button. Share-Definitions will be deleted, and configuration data for all protocols will be updated. Subsequent client connections will use the updated, shorter, list of shares. (Note that current connections, established with the earlier share list, can continue.)

There is even a use for selecting zero Share Names -- the re-evaluation of configuration data for all protocols is still done. There could be some odd conditions in which ProZerver config files have been updated by some non-standard means, such as using FTP to the /flash directory. Select zero Share Name entries and hit the Share Definition Delete Now submit-button to force the re-evaluation, to ensure that the configuration data for all protocols is consistent and up-to-date.

The display is sorted under the userid column, with each name a link leading to a Change User Attributes or Pass Phrase web page for the userid.

The column Full Name or Description shows the descriptive data, if present.

The column web-admin shows which userid have been granted admin web page access privilege. The value "yes" appears for those userid, in addition to admin, which may access the admin web pages. No value is shown for ordinary userid.

The column ssh shows which userid have been granted command-line ssh login privilege. The value "yes" is given for those userid which may use SSH-Secure-Shell protocol to login to a command-line prompt. This can be used for certain kinds of system diagnosis and maintenance, but is expected to be seldom used. There are other uses for ssh login possible in the future. No value is shown for ordinary userid.

The userid admin is not shown in the list of userid. To change its Pass Phrase, use the System / General admin web page.

Other built-in userid names, such as root and public are not shown, since proper system operation requires that those userid be left alone.

This is in contrast with userid that are part of a Windows "Active Directory" Domain in which a DOMAINNAME\Userid is created at a Windows Domain Controller, can be known and used by any number of machines which are part of that Domain (or part of another Domain with a suitable trust relationship), and the Pass Phrase is a secret between the DOMAINNAME\Userid individual and the Domain Controller.

The userid field itself is the short, unique, perhaps cryptic, identifier that would be considered "machine friendly." You can use "a" - "z", "A" - "Z", "0" - "9", "$", underscore-"_", and dash-"-", up to 31 characters in length. (The space character can also be used, for some very limited purposes.) By tradition, Linux/Unix userid use lower-case letters, but the wider range of userid characters work, provided they are used consistently. Note that userid of all digits are not allowed, because it would be ambiguous (in some contexts) whether the name "123" was intended, or the userid whose assigned user-number was 123.

The field Full Name or Description is intended for more human-recognizable text. This may be left empty, does not need to be unique, can be up to 120 characters, with a wide range of values allowed but not colon-":", double-quote-'"', or single-quote-"'". Each of these limitations is for various internal technical reasons, and the last is disappointing, since there is a Mr. D'Ascoli on staff whose correct name cannot be entered.

The field is named Pass Phrase/Word to encourage use of a phrase, rather than a single word or word-like clump. The Pass Phrase is limited to 120 characters, and the only character rejected is "new-line" (created with the "Enter" key), but that character (and "tab") cannot be passed as data from many browsers anyway.

The admin web page access checkbox sets admin privilege, permission so that the newly-created userid will be able to use the admin web pages (and thus create additional userids, as well as all the other admin operations).

The command-line ssh login checkbox, if granted, would allow that userid to login, using protocol SSH-Secure-Shell, to a command-line prompt. This can be used for certain kinds of system diagnosis and maintenance, but is expected to be seldom used. There are other uses for ssh login possible in the future.

The Create New Userid Now submit-button initiates the syntax checks, and creates the userid in two steps -- first create the userid, then set the Pass Phrase so that the userid is usable for each protocol. Because the Pass Phrase is stored in different format for use by Windows SMB/CIFS, SmartMirror, and for all other protocols, there could be some odd failures in which the Pass Phrase is set properly and will work for some protocols, but not for others. Any failure message should be considered carefully -- after partial success (i.e. partial failure), the userid should probably be deleted.

Note that if the userid already exists, this operation will work as an update, and change the previously existing Full Name, permissions, and Pass Phrase, rather than reject the operation. This behavior is the result of using a small number of simple mechanisms for userid management, is handy for system test scripts which can create and re-create userids many times, but does seem to violate the principle of least astonishment.

Some possible userid values are dis-allowed due to conflict with pre-defined, special purpose userid -- root, bin, nobody, sshd, and public. The userid admin should be manipulated from the System / General web page.

Although intended to be simple, this userid mechanism has been tested with up to 400 userid.

The userid is the unique identifier that specifies the User Account. Only userid which are local to the ProZerver can be updated, as created with the Security / Create User web page.

The Full Name or Description field is the more human-recognizable text, and can be used for any descriptive purposes, or left empty. It may be up to 120 characters, but may not use characters colon-":", double-quote-'"', or single-quote-"'".

The admin web page access checkbox sets admin privilege, permission so that the userid will be able to use the admin web pages (and thus create additional userids, as well as all the other admin operations).

The command-line ssh login checkbox, if granted, would allow that userid to login, using protocol SSH-Secure-Shell, to a command-line prompt. This can be used for certain kinds of system diagnosis and maintenance, but is expected to be seldom used. There are other uses for ssh login possible in the future.

The Update Userid Information Now submit-button can be used to change the above elements, and leave the userid Pass Phrase unchanged.

The Pass Phrase/Word field can be up to 120 characters, and if only the Pass Phrase needs to be changed, the Set Userid Pass Phrase Now submit-button can be used.

If the Pass Phrase is to be updated, and one or more of the elements from the Userid Information section must also be updated, the Change Both Userid Info and Pass Phrase Now submit-button can be used.

These are userid which are local to the ProZerver, created with the Security / Create User page.

As userid are deleted, any Share Permission granted to that userid for any Share is also removed.

The column Userid includes userid created on the ProZerver using the Security / Create User web page, and Windows "Active Directory" DOMAINNAME\Userid from the Windows Domain that was joined, and any Domains with a suitable trust relationship.

The Shares are listed by name as a link to the web page that shows and allows edit of the Share properties.

For each userid and each Share, the current permission is shown, and a checkbox is available to change it.

For a given userid, an ordinary read-write share will show

• "RW" if the userid has Share permission,
• "Pub" for a Public Share, all userid have permission, and
• "-" for no permission.

• "RO" if the userid has Share permission,
• "Pro" for a Public Share, all userid have read-only permission, and
• "-" for no permission.

If Share Permission has been granted to a Public Share, the "RW" and "RO" are displayed, rather than "Pub" or "Pro", so that the explicit permission is visible. That permission would become significant if the attributes are changed, and the Share is no longer Public.

After review of these values, any number can be changed using the checkboxes, and Update Share * User Permissions Now submit-button can be used to apply all changes in one step.

The display is intended to make clear the relationships between userid and Shares. The set and update for multiple Shares has the advantage of all changes being applied at the same time.

If the Share definitions have been made so that no two Shares overlap, then this display of permissions is a complete display of who can access what. It is incomplete, however, if any Share is a subset of another -- the Share-point directory of one is a subdirectory of the Share-point of the other. For this case, userid with permission to one share have partial access (through the subset) or complete access (through the superset) to the other. These relationships are not shown on this display. See the admin web page Storage / Shares, and examine the Path column to see if there are any subset-superset relationships.

Recent Task Start/Stop is the time-stamp on a file generally written only when a SmartMirror task is started. The Task Name is shown, if known.

If Most Recent Task Status matches Date & Time Now, then the SmartMirror Task was still running when the page was displayed, and there should be some progress-log text. If the Task Status time-stamp is in the past, then the SmartMirror task had ended (when the page was displayed), and there should be progress-log text that looks like a task ending result.

Start/Stop and Task Status will be "(none)" if no SmartMirror client Task has run since system startup.

Web page Schedule for List of Defined SmartMirror Tasks has an entry for each Task, with the Task Name, source and destination, scheduling values, and the name for the Next Task, if part of a chain of Tasks. To check or to edit complete details, use the link on the Task Name.

There can be as many as 360 scheduled tasks.

For the Source and Destination columns, for each entry, one will be marked as Local: with a Share name, and the other will be identified with an IP-Address or DNS-name, along with a Share name to be found on that Remote Server. A directory within the Share, Local or Remote, can also be shown. This is the representation for Direction choices Pull from Remote Server and Push to Remote Server.

A column next to Source may say newer: to represent Direction choices Pull from Remote, Newer Files Only and Push to Remote, Newer Files Only.

The column next to Source may say rename: with a (not really) Remote Source of "127.0.0.1" to show Direction Pull by Directory Rename, along with del: next to the Local Destination for Delete Local and Pull by Directory Rename. The IP-Address "127.0.0.1" is a special case, known as "localhost", and refers not to a machine which is actually Remote, but to the ProZerver itself.

If the Task has been scheduled to run once in a day, then the Start Time field will display as HOUR:MINUTE, such as 23:30 for 11:30 PM. If the Task is to run multiple times in a day, the HOUR field can be ALL, to select all the hours from 00 to 23, or can be DAY, to select every hour from 07 to 19, 7 AM to 7 PM. A Start Time field of DAY:30 would appear for a task to run every hour from 7:30 AM to 7:30 PM.

The MINUTE field may appear as 15,45 to represent twice in an hour. The value 0,10,... means every ten minutes within an hour. The Start Time value of ALL:15,45 means the task is scheduled twice an hour throughout the night and day. The value 03:0,10,... would be shown for a Task to be scheduled 6 times, from 03:00 AM to 03:50 AM. An immediate, practical use for such a selection does not come to mind.

The display of SmartMirror Tasks is sorted in a way intended to make the schedule comprehensible, to show the Task relationships, and to make a Task findable based on Frequency, with Weekly Tasks shown ahead of Monthly, with MTWTF Tasks ahead of Monday-only, with Monday Tasks ahead of Tuesday, with Monthly Tasks sorted by DayOfMonth, and Start Time value sorting for tasks with the same Frequency. (The Enable/Disable Status is not used to determine the display order, so you can find a Task by its Frequency scheduling, whether Enabled or not.)

For Tasks that are part of a chain shown with Next Task names (and whose position is not otherwise determined), an attempt has been made to display in chain-execution order. A chain of tasks with a recognizable begin and end will display fairly well. (For stress testing with a never-ending loop, there is no recognizable last-task.) If there is a Task with two predecessors, it may be displayed in an order that makes sense for one of them.

And if nothing else, the Tasks will be sorted by Task Name.

You can have up to 360 SmartMirror tasks.

SmartMirror Task Settings

The Task Name identifies the task on the Task Schedule list, appears in status and error messages, and can be used as the target name when building a chain of tasks. It can have up to 20 alphanumeric characters.

You can add a little bit more description in the Comment field. This value is only shown with this Edit Task page. The comment can contain up to 45 alphanumeric characters, including the space.

Select the Direction that the data in the SmartMirror backup is to go from the list of radio buttons. Is the data to be pushed from this system to the remote system, or is the data to be pulled from the remote system to the ProZerver?

The Direction choice also selects what happens at the destination end. The basic choices Pull From Remote Server and Push to Remote Server will duplicate exactly the source directory at the destination, and will remove any extraneous files at the destination that do not exist at the source. Use special caution with these choices. If the Destination Share or Path in Share are close, but not correct, there can be massive file delete from that Destination directory to make it match the Source Directory.

Other Direction choices, Pull From Remote, Newer Files Only, and Push to Remote, Newer Files Only, will send files that have a newer time-stamp on the source system, or which do not exist on the destination system. For these Update choices, a file on the destination system with a newer timestamp is not overwritten, and no files are removed from the destination system. These choices are used when both source and destination might have valuable data to be maintained (rather than the source system holding the real data, and the only role of the destination is backup).

Additional choices for Direction are very specialized and were added to be part of a chain of tasks used to maintain a time-sequence of backup directories. For selection choices Pull by Directory Rename and Delete Local and Pull by Directory Rename see further discussion below in section Directory Rename.

Local Settings. Select the name of the share for which you want to schedule the SmartMirror backup from the Share drop-down list.

If you want to narrow the SmartMirror backup to a folder within the share, enter the path to the folder in the field Path in Share. Use Unix/Linux path name rules -- Uppercase and lowercase letters must match exactly, and directories and folders are separated by a "/"-slash character. If used, this field must name a directory, not a file. A leading "/"-slant character is not necessary. For example, within a share named "ABC" might be a file with path-name of "ABC/Def/ghi/JKL/file.txt". To select the directory containing this file, select share "ABC", and set Path in Share to "Def/ghi/JKL" (without the quote marks).

Remote Server Settings. The Remote Address may be identified either by its IP-address or by its DNS-name. You must also provide the name of the Share on the Remote Server, the Path in Share if you want to backup a specific folder in the share, and the Login Name and Password for that Share on the Remote Server. Since the configuration and status of the Remote Server is not as well known (as the Local Server), the possible Share names are not listed as a drop-down list. However, a listing of Shares from that Remote Server can be obtained using the Check Remote Host submit-button, described further below.

Data Transfer Settings. Additional options can be selected for the scheduled SmartMirror backup.

If you select Compress Data, the files from the source will be compressed as they are transferred. This takes additional processing time, but may be worthwhile if a lot of data must go through a limited speed link.

You can choose to Create Backup Files in the Destination Share of any data files that are updated. The old version of the data file is renamed with a "~"-tilde character on the end, so that a file named "ab.cd.ef" is renamed as "ab.cd.ef~" before the new version of the file is written. If there already was a file with a "~"-tilde character, then it is renamed with two, to be "ab.cd.ef~~". A lot of back-up files can be created, with the filename with the single trailing "~"-tilde as the most recent before the current version. Excess back-up versions of a file are not removed automatically, and must be managed manually.

If you select the Test Run Only option, the ProZerver will run the SmartMirror task right up to the point where the data is actually transferred. The "SmartMirror Logs" will report whether the test operation was successful. This can be used to check the validity of the Remote Address, the Remote Share, the Path in Share, and the Remote Login Name and Password.

The Other Parameters field allows for some specialized uses. The most widely useful value would be "-v" which would run the SmartMirror operation in verbose mode. Additional information is written to the SmartMirror Log file, including a list of files transferred and a list of any files deleted from the destination. A value of "-v -v" (but do not include the quote marks) would provide even more data in the Log file, which may be useful in understanding certain kinds of SmartMirror problems.

The Other Parameters field can be used to achieve much more elaborate results using the full range of command-line parameters available for rsync, the program which does the heavy lifting for the SmartMirror feature. For example, to re-initialize an elaborate directory structure, duplicating the set of all directories and folders, copying none of the data files from the source, and removing any left-over data files at the destination, you can set the Other Parameters field to

"--include */ --exclude * --delete-excluded"

(but do not include the quote marks, and note the double "-"-minus character that introduces keyword parameters, rather than single-letter parameters). This feature is not recommended for use by the casual user.

Other Options. After the Task Name and Comment fields, everything else defined above is related to the rsync task that will transfer the data -- the direction, location info, and options for the transfer.

What follows are the options for SmartMirror, which schedules the task, sends e-mail alert messages for some conditions, and perhaps combines tasks into a chain of multiple tasks.

Only one SmartMirror client is allowed to run at one time, so that the Current Task status display and SmartMirror Log output are unambiguous. Setting the Maximum Minutes to Wait field will allow the task to wait for other tasks to finish. If a task almost always completes within a few minutes, but might, under some conditions, run for hours over a slow link, then another task can be scheduled to run 10 minutes later and allowed to wait e.g. 720 minutes (12 hours).

Alert messages can be sent by E-mail under any or all of a set of conditions -- at SmartMirror Task Start, if a task Cannot Start within Max Minutes, if a task Ends with a Problem, or when a task Ends with no Problem. A message will be sent to one or more recipients as configured on the System / Alert Setup admin web page. Sending a message for normal ending, as well as abnormal conditions, from at least one regularly scheduled task can provide verification that E-mail alerts are being properly delivered.

If there is a SmartMirror Task which should be followed by another only if the first task ends normally, then the Task Name of that second task can be given in the field Next Task to Run. This might occur if one Task pulls some data from one Remote System, and then a second Task should push that data to a second Remote System, provided the first transfer ended with no problem. Such a chain of Tasks can be of any length.

Is it legal (and useful) to create a chain of Tasks that is a loop ? Yes, and this has value in creating system stress test load, and for running monitor tasks for which several times an hour scheduling is not responsive enough. In order to protect against un-intended never-ending loops, an upper-bound is enforced, currently 999 tasks in a chain.

Scheduling. The scheduling of a SmartMirror Task can be toggled on and off by selecting the Enable or Disable values for Status. A task which is disabled does not run by its schedule selections, but can still run if it is named as the Next Task to Run of a Task which is run, or if the Save Info and Run the Task Now submit-button is used.

For scheduling, indicate the Start Time you want this scheduled task to begin, using 24-hour clock notation. For example, if you want the scheduled task to begin at 11:30 PM, enter 23 in the first field and 30 in the second.

On what days do you want this backup task to occur? You can indicate either a weekly or monthly cycle.

If you select the Weekly radio button, you can choose from one to seven days on which to schedule the task. For example, you can schedule a task that backs up Share ABC every Tuesday and Friday at 3 o'clock in the morning. Choose all seven days if you want a backup done every day.

If you select the Monthly radio button, select the day of the month you want the scheduled task to occur from the drop-down list. For example, if you want Share ABC to be backed up on the 15th of every month, select the number 15 from the list. Note that the value 31 means to run the task on the last day of any month which has 31 days (it does not mean "the last day of every month"). Tasks that must be run after a month has ended should be scheduled to run at the beginning of the following month.

Special Start Time Hour, Minute Choices

For specialized SmartMirror synchronize tasks, there are some additional choices for Start Time Hour and Minute. Instead of picking one of the hours from 00 to 23, you can choose ALL, which means that the task will be scheduled to run during every hour of the day. Another choice for the hour value is DAY, for which the task will be scheduled to run during every hour from 07 to 19, 7 AM to 7 PM.

The choice for minute within an hour also has some extra values. Pick 15,45 so that if a task is to be run within a particular hour, it will be run twice, at 15 minutes and at 45 minutes after the hour. The value 0,10,... can be used to run a task every ten minutes. The value many can be selected to run a task even more often -- every four minutes.

Update Task-Pair, Automatic Restore

The combination of using an Update Task, selecting Pull From Remote, Newer Files Only, or Push to Remote, Newer Files Only, with scheduling once every hour or several times per hour, can be used to solve some difficult synchronization and back-up problems.

Two ProZerver with shares linked by a pair of Update Tasks (a Push and a Pull scheduled on one of them, or a Pull Task from the other scheduled on both of them) will do automatic backup, and will also do some kinds of automatic restore -- if a file is deleted accidentally, it will be restored from the other system by the next scheduled task-pair (e.g. within the hour).

There is a certain amount of load-sharing possible -- users can map to either system based on load, speed, or availability, regardless of which system was the "original" and which the "back-up".

This is not the same as real-time remote-mirror with file-locking, however. If a file is updated, separately, on both systems during the interval between scheduled Update Tasks, then the changes made to the file with the earlier time-stamp will be lost, the file with the later time-stamp will prevail, and that file will appear on both systems after the next Update Task-pair.

Also, if a file is deleted deliberately from one system, it will be automatically restored from the other. If a file or directory is renamed deliberately on one system, another copy with the old name will automatically re-appear. Removing or renaming must be done on both systems before the Update Tasks run.

For those who find the idea of automatic restore to be very pleasant, an additional caution -- the files need to be created and updated with sensible time-stamps. The ProZerver can be configured to use a time-server for synchronization, but the time-stamp left on a file updated by a client using a ProZerver is usually up to the client, not the ProZerver. A PC-client with an ill-configured clock, or which failed to get a good setting from a time-server, might be creating time-stamps at some point in the future. Interesting symptoms can result from this condition.

Directory Rename

Direction choices Delete Local and Pull by Directory Rename and Pull by Directory Rename were created for use within an elaborate chain of SmartMirror tasks that can be used to manage a time-sequence of directories, such as when directories named "Week1", "Week2", etc. hold copies of a repository of files and folders as it existed one week ago, two weeks ago, etc.

SmartMirror tasks using these direction selections require that the Remote Address of the "Remote Server Settings" be "127.0.0.1", which is a special IP address generally known as "localhost". On all systems, it addresses the "loopback" pseudo-device, and is thus an IP address by which a node can address itself.

Therefore the entries under "Remote Server Settings" for Share and for Path in Share are not located on some remote system somewhere, but are on the same system with "Local Settings" entries for Share and Path in Share. In order for a directory-rename operation to work, the directories thus identified must be within the same Raid-Group File-System, and the expected use is that these will be two directories within a common container directory.

A SmartMirror task defined with a Direction value of Delete Local and Pull by Directory Rename will perform several steps.

(1) The directory identified under "Local Settings" by the entries for Share and for Path in Share will be deleted, including all subdirectories, folders, and files.

(2) A rename will be done for the (local) directory identified under "Remote Server Settings" by entries for Share and Path in Share to use the name of the just-deleted directory given by "Local Settings".

(3) An empty directory will be created using the just-abandoned name given by the "Remote Server Settings".

For example, for an environment in which the state of a repository is captured every week and kept for four weeks, the Local Settings might select Share "ARCHIVE", Path in Share "Week4", within a task with Direction Delete Local and Pull by Directory Rename, which would delete directory "Week4" containing files more than four weeks old. If Remote Server Settings (with Remote Address of "127.0.0.1") selected Share "ARCHIVE" and Path in Share "Week3", then directory "Week3", holding files more than three weeks old, would be renamed and become directory "Week4". An empty directory named "Week3" is then created. The effect is that all of the files, folders, and subdirectories that had been within "Week3" are now within "Week4", files older than four weeks are gone, and this has been achieved without having to do a copy-operation.

A SmartMirror task defined with a Direction value of Pull by Directory Rename differs from the above in that the target directory defined by "Local Settings" for Share and Path in Share must be empty (or not exist at all) -- a delete of any and all files, folders, and subdirectories is not done.

For example, if directory "Week3" is known to be empty (as it would be after the previous example), then a SmartMirror task with Direction Pull by Directory Rename could have Local Settings of Share "ARCHIVE", Path in Share "Week3". If directory "Week2" had files which were more than two weeks old, then the task would have Remote Server Settings (with Remote Address of "127.0.0.1") of Share "ARCHIVE" and Path in Share of "Week2". The effect will be that the files and folders that had been within directory "Week2" will suddenly be found in directory "Week3". An empty directory named "Week2" will be created so that there can be a chain of these tasks.

If a SmartMirror task with Direction Pull by Directory Rename encounters a non-empty target directory, then something has gone wrong and the task ends with error message "Directory is not empty" to be found in the syslog.

Because both directories are to be found on the local system, the entries for Login Name and Password within "Remote Server Settings" are not used.

Save Info

Hitting the submit-button Save Info for Task will initiate a check for a certain amount of pickiness for the values specified. If all is well, a check is done for an internal identifier for this task. This is a value such as "[0000]" or "[0350]", and if one has not already been allocated (for a Create Task or Duplicate this Task operation), a value is chosen now. This can fail, if too many tasks already exist.

Not all error checks are run when the task is saved. The value for Task Name is checked for duplicates, and the Next Task to Run value is checked for a match when the Task Schedule is displayed.

The submit-button Save Info and Run the Task Now operation will attempt to run the task immediately, regardless of whether the Status is Enable or Disable, regardless of the other Scheduling values. As with any SmartMirror task, the result or current status of the run can be found on the SmartMirror Current Status web page.

As mentioned above with the "Remote Server Settings", the submit-button Check Remote Host will use the Remote Address, either IP-address or DNS-address, to get a list of Shares. On success, the response from the Remote Address is shown, and indicates that the DNS-name, if any, can be resolved to an IP-address, that the IP-address is valid, at that IP-address is a ProZerver with the SmartMirror server enabled (or another system with the rsync program listening and available on its port number, 873), and the non-hidden Share names are listed. There could be additional Share names (or rsync "module" names) that could be accessed, but which have the "hidden" attribute.

What is not tested with the Check Remote Host operation is the validity of the Login Name, Password, Share name, Path in Share, and permission. You can use the Test Run Only setting for that.

The submit-button Delete this Task ... leads to an "are-you-sure" step, which will remove the SmartMirror Task definition from the system.

The Duplicate this Task submit-button appears to re-display the same web page with all the same values (including any Task Name value), but is set to be handled as a New Task. This is intended to allow starting with a current SmartMirror Task definition that works, and is to be kept, but for which a variation is desired.

For example, after a task is created to Push to Remote, Newer Files Only, and tested using Save Info and Run the Task Now, you can use Duplicate this Task and change the Direction to create a second task to Pull from Remote, Newer Files Only. The Local and Remote Settings are already set, the Task Name would have to be changed, and the Next Task to Run could be set to chain the two together.

SmartMirror Log Files can become much too large to be held within a ZerverModule flash memory area, and so are located on a Raid-Group.

You can choose the RAID-Group or Share to hold Log File. Placing it within a Share will allow the Log Files to be visible (within the Share), and so can be examined by clients and users who have access to the Share.

You can choose to place the Log Files within a Raid-Group in an area which is not accessible to any Share, which can be an advantage, sometimes. If so, the only access to the Log Files would be the links on this admin web page (and with the possibility of creating a Share definition for the root of the Raid-Group, which would make all files visible to that Share).

Any non-empty FileName or Path/FileName for Log File can be chosen. SmartMirror is run so that any file with that name is excluded from rsync operations, to prevent reading or writing a file which is also being used as a Log File. A typical name might be "smirror.txt".

The method is to use two files, and when one has been written large enough, it is renamed, and then writing continues. If file "smirror.txt" has reached a limit, it is renamed to be "smirror.txt.old" (and any existing file with that name is deleted). Writing continues, with a new file "smirror.txt" starting out empty.

The current mechanism checks the file size only at the beginning of a SmartMirror Task. If the size is larger than Minimum Log File Size to Retain in KBytes, then "smirror.txt" can be renamed to be "smirror.txt.old", and at least that many KBytes of log data will be kept. The newly created file "smirror.txt" would be written throughout the task, and throughout any chained tasks, and could, in fact, become much larger than the Minimum Size. It is beyond argument, however, that checking the file size once at task-begin involved debugging less code than watching for a Maximum Size limit, with possible file close, rename, and open throughout a chain of SmartMirror tasks.

Use the submit-button Save Location and Name for Log File to change these values. There will be no change for a currently-running SmartMirror task.

The size is shown, in bytes, for the two parts of the log, "smirror.txt.old" and "smirror.txt". The submit-button Discard older part of detail log file now will delete the older part, if any, and rename the file to be the older part. If there were log data in both files, this has the effect of discarding the older part. If you repeat this operation, the remaining part will be discarded.

The link Show SmartMirror detail log file will display the content of both pieces of the logfile. The link Show SmartMirror log file last 100Kbytes will be only the tail-end of what would be the full display. These are click-able links so that if your browser allows "right-click" and "Save Link Target as ..." (or similar), you may be able to save the result display as a text file. A long-accumulating log file could be 100 MB or more, and it sometimes happens that trying to open a browser window with that much text, even simple text, leads to problems.

A Log File entry begins with a time-stamp on a line with --
--------- Begin SmartMirror operation --

This is immediately followed by a line with the Task Name --
--------- Begin SmartMirror task --

The bulk of the display is from the rsync program, including the command-line parameters and output as it runs showing progress, warnings, errors, and success.

If there are SmartMirror Tasks chained together, each will be named with another line --
--------- Begin SmartMirror task --

When a SmartMirror task has run which has no "Next Task" in a chain, or if rsync ends with an error, the log entry finishes with a time-stamp on the line --
--------- SmartMirror operations ends --

The interpretation of the field Available Memory is not simple, in large part because Linux will tend to hang on to the buffers used to read and write particular files, after the I/O is complete, just in case the content of one of those files is needed again. So a large chunk of memory is not counted as Available, but it can, in fact, be re-allocated for another purpose immediately.

A system which starts out busy with file operations will show the Available Memory drop steadily, lower and lower, seemingly headed for a memory crisis, but actually just retaining the buffers for more and more files in case that is useful. When the Available Memory drops below some limit, some of these potentially-useful buffers are picked and declared Available. As file operations continue, the Available Memory stays close to this lower limit. There is useful information in the Available Memory field, but the interpretation is not so simple.

Also on this web page is a link marked System Status Internal Details which will show the details of the system state in great detail. This is intended partly for problem diagnosis and for development, and also for the curious. Among many items, for example, is a display for "meminfo" in which the state of Available Memory is described with about a dozen values.

There may be system problems for which a copy of the contents of this web-page would be helpful. It is a selectable link so that if a web-browser allows "right-click" and "Save Link Target as ..." (or similar), then a text file can be easily created.

(The Login History is also held in flash. The logs for "Recent Startup", "File-Sys Op", and "Current Details" are held only in RAM, and can only have information from after the most recent system restart.)

The Major Events include

• The Network Name of the machine, described as hostname.
• For each Ethernet interface, the 48-bit unique MAC-address, and whether the interface is configured as dhcp or static address.
• The set of IP addr used by the machine.
• The sw/fw version which is running.
• The TZ TimeZone value which is used, since that affects the interpretation of the time-stamp values on all the log files.
• File-System check operation done.
• Raid-Group File-Systems found, mounted, and available.
• For Zerver Pair feature, Pair connected.
• Raid-Group events, such as Degraded-Array, RebuildStarted, and Spare Active.
• Joined domain for Windows "Active Directory" Domain.
• For register of a ZerverModule, note when Support/Reg is successful.
• Firmware update loaded.

These are events and conditions that may be of interest for some time -- days, weeks, or longer.

Every hour or so, a system program runs to check the size of this file (and of the Login History file), and if above a limit, trims it back.

The submit-button Discard older half of System Major Events Log File Now can be used to chop back the size of this file at any time, if there are older messages known to be of no interest, but with more recent messages that should be retained.

The submit-button Clear System Major Events Log File Now can be used to clear all entries from this log. The other log files are unaffected.

You can add your own entry to the Major Events Log File using the data field and the submit-button Add Text to Log File. This might be done to annotate a Log File to be sent to Customer Support. This might be done for very long life-time Log Files which must have copies retained for years, because nothing in the time-stamp values of the log indicates what year it is. (There is a year-value in the sw/fw version message, but that is the year the sw/fw was created, not necessarily the year of the boot-up message.) Some time early in January, you could add a message to the log saying "Happy New Year 2008."

All these messages, and any annotations added, also are sent to the Current Detail log.

This login log is kept in ZerverModule flash memory, so as to be available over a system restart, similar to the Major Events log. (The log files "Recent Startup", "FileSys Op", and "Current Details" are kept only in RAM, and so only have information from the most recent system restart.)

Also similar to the Major Events log file, every hour or so a system program checks the size of this file, and trims it back if too large. It is distinct from the Major Events log file so that a flurry of events added for one purpose does not force out events recorded for the other purpose.

Because entries are made in this log based on external events (connection attempts), it would be possible for an uncivilized user to create hundreds or thousands of entries in this logfile. The size-check program runs once an hour. A possible attack would flood the system with login attempts fast enough to fill all space within the ZerverModule flash memory. The system will not crash, the file size will be reduced and space recovered within the hour, and other log files will still be written, but after the first write-failure to the Login History file, no further writes are attempted. The visible symptom would be that the login log file is filled with messages with time-stamps all within a single hour, and that no further events have been written. Login History has effectively been turned off. Currently, the only way to re-enable Login History (short of system restart) is sort of non-obvious -- if you change the Network Name of the machine (perhaps using the System / General web page), the syslog program must be restarted to use the new name, and if the Login History file is now writable, it will be used again. There can be other network-access issues created by the name change, even if you immediately change it back again.

The Samba program running the Windows SMB/CIFS protocol has, as a feature, the ability to note Begin-Use and End-Use of a Share. This can occur after a login, as Shares are mapped and perhaps unmapped. If the Share or Shares are Public, there might not be an SMB login recorded at all.

The Samba Begin-Use End-Use messages can be a problem with some applications or system services, perhaps because of using UNC access rather than a mapped drive, which can Begin-Use and End-Use several times a minute, filling the Login History file and obliterating other useful events. The admin web page Network / Windows has a control to stop the Begin-use, End-use messages.

As with the Major Events log, there are submit-buttons to Clear Login History File Now and to Discard older half of Login History File Now. Annotations can be made using the data-entry field and the Add Text to Log File submit-button, perhaps before sending a copy to Customer Support, or before making an archive copy in which the year needs to be made explicit.

Entries to the Login History are also added to the Current Details log.

Before the ZerverModule has been located and configuration information found, the ProZerver does not know the right Network Name to use, nor what TZ Time Zone is desired for the time-stamp values. Initially, the Startup Log uses the name zGMT and shows time-stamp values in UTC - Universal Co-ordinated Time, formerly known as GMT - Greenwich Mean Time.

There can be a large number of entries from the beginning of start-up with the same time-stamp value. This is misleading. A large number of kernel start-up messages will be buffered, and eventually the syslog facility (and other programs) will be ready to receive those messages. The initial burst of messages has the time-stamp of when these messages were received by the syslog facility, not the time-stamp of when they were generated.

Eventually the time-stamp values will show a gap of a few seconds or more. At that point, the initial kernel message burst has been processed, and subsequent messages in the syslog would have time-stamps, or perhaps time-stamp differences, that are more meaningful.

The initial message in this log is likely to be tagged with syslogd restart, to denote that at some point during start-up, syslog began, and then received the kernel start-up messages.

The kernel messages should show that CPUs are counted, hardware is discovered, software modules are loaded, hardware is initialized. Eventually ZERVER Mount config device ... as /flash occurs. Shortly after this, the configured (or default) name is found, the desired (or default) Time Zone is found, and the Startup Log messages begin to make use of both.

After this, network interfaces are enabled, protocols started, Raid-Groups assembled, Shares and access are configured.

Some network protocols take quite a few seconds to become fully operational, such as AFP-Apple-File-Protocol, and the last message about success or failure for those might occur after the arbitrary point at which the Startup phase is declared to be done. Any such messages go to the Current Details log.

One possible difficulty -- this file actually begins as the Current Details log, which is copied to make the Startup Log. For a system with a lot of hardware, such as 16 disk drives, in which there were a lot of messages about each disk, the size-limit for the Current Details log could be hit, and older text would be discarded. The beginning of the Startup Log file would have lost some of the beginning events.

If the previous shutdown was not perfectly clean, there may be a line about recovering the journal.

If applying the journal does not bring the File-System to a clean state, or if a File-System Check operation was forced from the Storage / RAID Groups web page, then there will be a longer display. If problems were found and fixed, or (worse) were found and could not be fixed, the details will be found with this web page.

The handling of a File-System with serious damage is beyond the scope of these notes -- call Customer Support.

The real motivation for a web page to display the results of a complex and perhaps time-consuming operation comes from Raid-Group Create. There are a number of steps, and when Raid-Group Creation has failed, it has been because one or more of the disks intended as component pieces were in some un-anticipated state, such as low-level formatted for a block-size different from 512-bytes. Not often, but every once in a while, nothing will do but to look at the result log.

Although there are a considerable number of complex steps, the size of the log file for Raid-Group creation will not be too large. A File-System Check, on the other hand, that encountered problems could create quite a large file. This file is held in RAM, so as not to clutter up a disk anywhere, and could conceivably be large enough to use up all space for this region of memory, which could affect other system operations.

The submit-button Clear FileSys Operation Log Now is used to discard this file from RAM.

The Current Details log file is kept in RAM, and so contains only events from after the most recent system restart, starting at the point where the log Recent Startup ends. This is in contrast to log files Major Events Log and Login History which are written to ZerverModule flash memory to record events over multiple system restarts.

The Current Details log file is size-limited, so that no matter how rapidly some run-away program generates event messages, all events can be sent to the log without danger of running the memory area out of space and complicating diagnosis of the real problem. The size-limit means that the log may contain messages from several days, several hours, or perhaps only covering a few minutes.

Copies of events sent to the Major Events Log and Login History also appear in the Current Details, but will be pushed off the end by more recent events much more quickly.

As with Major Events and Login History, annotations can be added to the Current Details log using the data field and the Add Text to Log File submit-button, perhaps useful before sending a copy of a log to Customer Support.

A Clear Current Details Log Now submit-button can be used to discard details considered irrelevant. This affects the Current Details log only -- the other log files, especially Major Events, are unchanged. For technical reasons, an operation to discard the older-half of Current Details was not done.

The information on the Agreement and Licenses admin web page involves the components of the product. A Slackware 10.1 distribution was the original starting point, in part because the start-up scripts were simple enough to still be within possible human understanding.

Various component pieces have been compiled from source code, to support the desired configuration and security choices. For each component compiled from source code, the License which allows us to use it is included, most often "GPLv2", the "GNU Public License, Version 2". At this writing, GPLv3 has been created, and might be used for future versions for one, or more, or all of these components.

The version number of each of these components is shown for reference.

Q: For FOSS Free and Open-Source Software, shouldn't the price always be free?

The preamble to GPLv2 has a good discussion of this question. Since this is a web page description, here is a bumper-sticker-sized summary as frequently seen on website slashdot.org -- "Free as in Free Speech, not Free Beer."

Q: Can I download each of the pieces using the links from the Agreement page, do a few compiles, and make my own system ?

Yes.

Q: How would such a quick home-grown system differ from a ProZerver ?

It would not be as pleasant to install, boot-up, configure disks and Raid-Groups, configure shares, allocate permissions, monitor, maintain, backup with rsync, and update, including thorough testing, without considerably more work. Configuration would involve careful editing of a number of interacting config files. There would not be friendly customer support. Perhaps most significantly, there would not be thoughtful, carefully researched, generally informative, occasionally amusing little essays available on each web page with a link marked "Help".

• What is being registered ?
  • The unique identifier from the Flash ZerverModule™ with the configuration data and firmware.
  • The unique identifier (MAC address) from any one of the Ethernet network interfaces.
  • A time-stamp.

• Are there any advantages to registration ?
  • Defined shares become externally visible to each protocol.
  • Support problems will be aided by having some record of system history.
  • There can be on-going development and maintenance of the firmware.

• If the Support/Register web-site becomes inaccessible at some time in the future, will my ProZerver suddenly stop working ? Is there periodic back-door access by the ProZerver reporting on my activities back to ProZerver world headquarters ?

  No. Registering can be done once (or multiple times), and remains valid indefinitely. There is no back-door communication anywhere.

• If I change hardware, will the registration be invalid ?

  Additional network interfaces can be added or taken away, disk and controllers can be added or taken away, CPU can be upgraded or taken away, memory size adjusted, or motherboard replaced (provided the selected Ethernet address was on a removable card that goes with the ZerverModule to the new motherboard) -- all these things can be done without affecting the validity of the registration.

• How would there be an invalid registration ?

  If the Ethernet network interface which was used with the registration is not present with the ZerverModule, the system will be marked as not registered.

• Is this so-called help-file going to explain the Register operation ?

  The Support/Register operation is a quick, simple, two-step process.

  (1) Send to Register web-site. In an admin web-page generated by the ProZerver, the relevant values are entered and chosen. The submit-button Submit to Support/Registration web site sends the selected values to the ProZerver World Headquarters Register web site (not back to the ProZerver), from the machine running the web browser, perhaps your PC (not from the ProZerver).

  The result is a web page from the ProZerver World Headquarters Register web site with the Registration result. This web page goes back to the machine running the web browser (not the ProZerver).

  (2) Send to ProZerver. So far, the ProZerver has heard nothing about the interchange between the machine running the web browser and the Register web site.

  On success of step (1), the result will be a big, long, value marked as a "PGP SIGNATURE" in a web-page with a submit-button marked Send Support/Register Value to System. To complete the Support/Registration operation, hit the button. The generated value within the web-page will be sent to the ProZerver, which will respond with a web-page indicating the resulting level of happiness.

• Two steps seems like too many. Why not just one step ?

  A one-step process would have required that the ProZerver have code to act as a client to a server at ProZerver World Headquarters, and this client code would have no other use.

• Can Registration be done from an isolated sub-net ?

  Yes, because the two-step sequence allows some useful half-steps.

  If the ProZerver is on an isolated sub-net such that any web-browser which can access the ProZerver is prevented from reaching the World Headquarters web site (by firewall rules or an air gap), then the needed values can be entered in fields of a web-browser which can reach the World Headquarters web site. The result PGP SIGNATURE can be transferred back to the isolated sub-net, by sneakernet if not by e-mail, and pasted into the field Support/Reg Value at the bottom of the page, being careful to keep the same UTC for Support/Reg Value. The submit-button Send Support/Reg Value to Zerver sends this value to the ProZerver, and the result web-page may indicate nearly as high a level of happiness as if the value had come more directly from the web page from the Register web site.

• Result from register web site -- "Okay -- Register ID has been allocated, and is ready for first support/register operation" or "Okay -- Register ID can be re-registered"

  These messages would occur on a web page with the result PGP SIGNATURE and a submit-button which will send the value on to the ProZerver. This is a successful step (1). Hit the submit-button for step (2).

• After step (1) generated a PGP SIGNATURE, I failed to hit the button for step (2). Now what ?

  The Register operation can be done again, from the top, without problem, as many times as needed or desired, provided that the same Ethernet ID is used as before.

• Result from register web site -- "Problem -- Cannot complete support/register operation --"
  • "Register ID unknown"

    The ZerverModule Register ID is not recognized.

  • "Register ID has been created, but has not been allocated to a device"

    The ZerverModule Register ID is recognized, but was not expected to be found in any ZerverModule just yet.

  • "Register ID previously used with another Ethernet ID"

    The ZerverModule Register ID is recognized, but has been previously registered with a different Ethernet ID. If that Ethernet ID is for another network interface on the system, then select that interface and re-submit.

• After "Okay" result from Register web site, then submit of value back to the ProZerver, result is -- "Problem -- After save of values for Support/Reg, result flash/system validity unexpected -- no"
  • This can occur if the ZerverModule Register ID is not actually found on your Flash Device.
  • This can occur if the Ethernet ID used to register is not actually found on your system.
  • This can occur if the exact "UTC" value used to register was not stored. For the procedure described for use with an isolated sub-net, in which the PGP SIGNATURE is pasted into a data area marked Support/Reg Value, make sure that the value for UTC for Support/Reg Value is the same as was used to generate the Register Value.

• Result from the register web site -- Connection refused, No response, No permission, from register.zerver.com

  ProZerver World Headquarters Register web site must be between up-times.

• Result from the register web site -- Connection refused, No response, No permission, from 10.0.1.63

  The IP-address 10.0.1.63 is used for internal development and testing. If the register operation attempts to use this address, there has been a mis-configuration of the firmware, or a config file has been left-over from development, testing, configuration, or burn-in.

• Result from the register web site -- Problem -- field "E-mail Address" does not look like an e-mail address

  The field E-mail Address should be of form name@example.com or "More Elaborate Name"@example.com

• Is a Contact Information E-mail Address required ?

  No. Either an E-mail Address, or an entry in Other Contact Info, or both.

• For the Contact Information E-mail Address, is there a defined privacy policy of any kind to discourage abuse ?

  No. The intention is to help identify what ZerverModule is where, to help with Support problems, and perhaps to announce availability of new/better firmware. Announcement of exciting new opportunities from ProZerver World Headquarters ? Ugh, I hope not.

• If my Contact E-mail address changes, can I re-register with the new address (since E-mail announcement of new/better firmware might actually be helpful) ?

  Yes.

• What is a PGP SIGNATURE ?

  A digital signature uses public-key cryptography, in which the private-key (here held at the ProZerver World Headquarters web site) operates on a message (here using the ZerverModule Register ID, the Ethernet ID and UTC value). The public-key can be freely distributed (and is a part of the ProZerver firmware), and can be used by anyone to verify that the signature is for that exact message, and had to be done with the private-part of that public-key. This provides a very high-level of assurance of validity, since it is thought to be infeasable to use the public-key to derive the private-key (such as for RSA, finding the two 512-bit prime numbers used in a 1024-bit key). "PGP" stands for "Pretty Good Privacy", and the understatement is 1-bit of computer humor.

• What is "UTC" ?

  Universal Co-ordinated Time was formerly known as GMT, Greenwich Mean Time. For convenience of the register operation, it is expressed here in decimal as the number of seconds since January 1, 1970, 00:00 UTC, and is used since the ProZerver might not be in the same time-zone as the ProZerver World Headquarters Register web site.

• My life will not be complete until I find a way to clone a ZerverModule with your well-designed, carefully-constructed, ingeniously-configured, thoroughly-tested, excellent firmware, and run it in multiple systems. Is this a hopeless quest ?

  One approach would use Network Interface cards with re-programmable Ethernet ID, and create a bunch with the same value, using one in each system, perhaps as extra, otherwise unused, hardware. Note, however, that if two of these non-unique network cards ever appear together on a single LAN, you may find yourself dealing with a network administrator in a murderously bad mood.

An error message of the form Unexpected value for fnc can occur if the set of admin web pages are generated by a set of programs that are not fully co-ordinated. One program has created a web page with a link or a form to invoke another program (or even the same program), and that target program finds that parameter fnc has an un-expected value. One program (or piece of code) is a bit ahead of the other, in development.

A Windows system can be running multiple applications, or running an application with multiple threads or multiple processes which together are manipulating dozens or hundreds of files at a time. However, the Windows system only establishes a single SMB/CIFS protocol connection to the ProZerver, and all of these file manipulations are multiplexed over this single TCP/IP connection.

There is a considerable amount of pipe-lining and overlap for these multiple operations on multiple files, and as long as each individual SMB/CIFS request is small, then the operation works well.

However, the process-time required for a file-delete operation is not related to the size of the request -- it is related to the size of the file. A delete of a file involves returning every block back to the free pool. A four gigabyte file has a million blocks, and the delete operation can take many seconds. During this time, processing of the queue of file requests from that one Windows System over the one SMB/CIFS TCP/IP connection comes to a halt until the delete is completed. This can create performance or responsiveness problems for the applications running on the Windows system.

(Other protocols which could handle multiple client processes making concurrent requests to a single ProZerver use one connection for each client process, rather than multiplex all requests over a single connection from the node. Delete of a multi-gigabyte file still takes time, but only one client process is held back waiting for the response.)

To try to avoid this performance problem, file delete operations done with SMB/CIFS protocol to a Samba task can be done in the background -- if the directory for a share contains a directory named ".defer_delete" when the share is defined or when share-attributes are being evaluated, then a file-delete operation is done by a rename of the file so that it appears within the .defer_delete directory. The rename operation does not depend on the size of the file, and so the response to the delete request occurs quickly.

A task named "deferdeleter" runs in the background, and every few minutes will check each share for the presence of a .defer_delete directory with files to be deleted. Sometime shortly after midnight, this task puts a report in the detailed event log describing the number of files found and deleted, and summarizing any problems found.

Because of the leading "."-dot character in the name ".defer_delete", several protocols treat this directory as having the "hidden" attribute. This may complicate checking for its presence.

Cleaning up a file-system that is low on space may present some confusing symptoms, if Windows and SMB/CIFS protocol is used to delete unneeded files. Gigabytes of files can be selected and deleted, but a check of Raid-Group or file-system information may show that the available space has not changed at all. This would occur if those files have simply been moved into the .defer_delete directory, and are not yet gone. A check ten minutes later will show that the space is now available.

• The hardware clock is usually set to run in UTC (GMT) on Unix-like systems, rather than for the Time Zone in effect when the system is configured.
• A keyboard and monitor is not required for normal system operation, provided the BIOS has been configured to let the boot-up proceed.
• The first serial port must be enabled. If it is not usable, the system will hang during the ZerverModule start-up sequence. In general, configuring-off unneeded hardware is a very good thing, however the first serial port is used internally as a serial-port terminal interface for development and debug.
• Recovery of a lost "admin" password -- A terminal connected to that first serial port, at 38400 baud (or a program emulating such a terminal), gets a prompt as the root super-user, without a login. This will allow someone with physical access to the system (and a suitable cable) to enter the command to reset the "admin" password, which is sometimes necessary, as well as enter commands that could do a lot of damage. The command would be --
  passwd admin

When this command is run as the root super-user, the previous value of the password is not required, and a new value can be set. This will allow login to the admin web pages, where the General web-page should be used to set the admin password again, so that various inter-related password values are all properly set.

For the cable that would be needed -- for the PC-board with a ZerverModule, under other conditions, the first serial-port could be used with a modem. For a PC running a program to emulate a 38400 baud terminal, the serial port also could be used with a modem. Therefore the cable and adapters that would connect these two serial ports, whether 9-pin, 25-pin, or something else, should look like a "Null modem".

The intention is that all system operations can be handled using the admin web pages. However, there could be circumstances that were not anticipated, are not handled by the admin web page operations, that can be handled by the admin user with a command-line operation.

A video console is not required on a ProZerver. If one is present, the system start-up messages, along with any other critial system error messages, are likely to appear there. (Those start-up and critical messages can be configured to go to a terminal on the first serial port, and so might not appear on a connected video monitor.) A "login:" prompt does not appear automatically.

In order to get a "login:" prompt from the system console, you must use key-combination Alt-F2 to select an alternate virtual terminal after system start-up is complete.

• If the network choices have become seriously mis-configured, such as all interfaces set for static addresses that conflict with other systems or that are not addressable from within the LAN, a console command can be run, after login as userid "admin" --
  /sbin/zerv_console_netconfig

  This will go through a sequence of questions that will allow reset and minimal re-configure of each of the network interfaces. Elaborate error and consistency checking is not done. The goal is to repair the configured values to make the ProZerver network-addressable, so that the regular admin web pages can be used for the major part of network configuration.

  After the network config values have been changed, the new values can be applied by reboot with the ever-popular Ctrl-Alt-Delete key combination, or by running command --
  sudo /sbin/zervnet

• If the File-System on a Raid-Group has become corrupted in some way, and repairs on the Raid-Group by the "File-System-Check" operation are insufficient, an interactive File-System-Check can be done.

  From the system console or a ssh-Secure-Shell terminal session, with login as userid "admin" --

  • Ensure that the current working directory for the admin session is not within the File-System to be repaired. To print out the path for the current working directory, enter command --
    pwd

  • From the admin web-page for Raid-Groups, use the Take File-System Offline if not busy or Take File-System Offline Now operations. If there are especially persisent users of the File-System, such as test-scripts that make never-ending Samba accesses, the "Offline Now" operation may need to be done several times before success.

  • From the system console or ssh-Secure-Shell terminal session, enter --
    sudo /sbin/e2fsck -f -v /dev/md0

    This will initiate an interactive File-System-Check operation. Depending on the size of the File-System and the nature of any problems hit, this can take many minutes. The answer to most interactive questions will be "y" for "yes".

    In this command, the "sudo" part checks a table to see if the current userid, admin, should be allowed to run this program as the root super-user (which is needed for sufficient permission to do repairs). "/sbin/e2fsck" is the name of the program, "-f" will force the check-operation even if the File-System state looks like it might not be needed, and "-v" calls for "verbose" output. "/dev/md0" identifies the Raid-Group which holds the File-System, and could be "...md1", "...md2", etc, as needed. Otherwise, the command must be entered exactly as above, or the "sudo" permission table will not allow the operation.

  • When complete, the File-System can be Enabled. The easiest method is from the admin web page for Raid-Groups, with the submit-button to Assemble All Raid-Groups, Enable all File-Systems Now.

Copyright © 2007-2009 NetZerver LLC

P.O. Box 87451, Phoenix AZ 85080-7451

1-602-619-2800

Last Modified: February 18, 2009