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 Re