readme0500.txt

FileZerver firmware version V05.00.00 is now available for
use with Cyclone-2+ boards with 8MB of flash.  This is the
successor to the V04 series of firmware releases, and any
FileZerver or Cyclone-2+ system that could use a V04 release
will be able to use V05.  The internal structures are all
compatable in format and size, so there is no compatability
barrier to upgrade to V05 (and no difficulty with returning
to a V04 release, if V05 does not meet your needs).  But see
further upgrade notes below.


Differences between V04.17a and V05.00 --

-- A newer version of the rsync program (which is the protocol
which does the work for the SmartMirror feature) has been used,
to be able to use a recently-added feature that affects the
file-permissions on the receiving end.

-- Newly-created local userid will be in group "everyone"
in a way that can be edited but not defeated.

-- The code for creating ACL-Access-Control-Lists has been
removed, and replaced with a simpler, more direct, and (we
hope) more useful mechanism, in which, for each file and
directory, the onwer, the group-owner, and the permissions
can be adjusted.


Why a version-number which looks like a major change?  Is this
not an invitation for people to await V05.00.01?

The change in major-number is to indicate that something major
has happened, and that the owner of a FileZerver has a choice
whether to continue with a V04 release or to upgrade.  For many
software/firmware products, such a change is incompatable in
some way.  For this FileZerver V05 release, the change is the
discard of the ACL-Access-Control-List feature.  Those users
which depend on current operation of ACLs should continue to
use a V04 release.


What are ACL-Access-Control-Lists, and who needs them?

ACL-Access-Control-List allows permission to be set on a file
or directory in a very fine-grain manner.  For each file,
permission can be granted to one user or several users,
listed by userid, which can be the same or different from
other files in the directory, and this can be selected and
set on files throughout the file-system.  Each file could
have permission for one group, no groups, or several groups.
The permission granted can be a mix of read-only, read-write,
or no-access.  Directories, also, can have one or more users,
zero, one, or more groups.  These permissions operate in
addition to FileZerver share security, so an ACL-entry for
a given user for a given file can only be used if that user
also has some access to the share which holds the file.

This is a lot of detail to be managed, and keeping ACLs
complete, so that people can access the data they need,
is very labor-intensive.

There are sites and situations for which
ACL-Access-Control-Lists are exactly what is needed.  By the
sensitive nature of the data being held, there are sufficient
people motivated to keep the permissions minimized and yet
sufficient.

This feature is not a good match to the FileZerver.
The essence of Network-Attached-Storage is that access to
data should be reliable and straight-forward, and that
management of the system should not be a full-time job.
The V04 firmware offered admin web pages that appeared to allow
simple set-up for full, fine-grain control over every file
and every directory.  Our experience is that this "feature"
created operation and support problems way out of proportion
to any benefits delivered.

Thus FileZerver release V05.00.00 delivers on a
frequently-heard user wish about much contemporary software:
a hard-to-explain, hard-to-use, easy-to-mis-use, troublesome
mis-feature has been removed.


The Replacement --

There is still an entry for "File/Folder Security" under the
Security tab, but the web-pages no longer try to manipulate
ACLs.  What is now available are tools which manipulate
only the base-level properties for the underlying system.
Each file and directory has one owner userid (or number).
There is one group id (or number).  There are permissions
(read, write, and/or execute) for the owner, for userid in
the group, and for all others.

The result interface may still appear to be over-elaborate
and confusing, but the base capabilities are those of the
real operating system and of each of the protocols.


Note before upgrade --

If there is any chance that ACL-Access-Control-Lists have
been used anywhere in the file system for any raid-group
(perhaps while someone was clicking through all the links in
the admin web pages, selecting things at random to see what
would happen), then it is worthwhile to run the "Remove ACLs"
operation (from the "File/Folder Security" page within the
"Security" tab of the V04 system) on the file-system in each
raid-group.  This would have to be done with the V04 release
code, because this is one of the features removed for the V05
release.  A complete walk over all directories and all files
is done, so note that the "Remove ACLs" step can take hours.

If this is not done, catastrophe does not occur.  However,
when the V05 code is running, the file-system-blocks that
hold the ACL-information from previously created files will
still be allocated but not used.  If such a file is deleted,
and its data blocks are returned to the free-space list, the
ACL-block is not noticed and is not recovered.  This would
be a very small fraction of the available space.

These little ACL-blocks are not lost forever.  The next time
that a file-system check is done, during a system restart
sooner or later, one of the scans will find each of these
blocks as being allocated but not referenced anywhere, and
will recover the space (probably with an alarming-looking
message in the system log about how repairs were needed to
fix file-system problems).

For testing purposes, it does work to upgrade to V05, look
around, and then reflash back to a V04 release.  If there
had been ACL-entries before, by design or by accident, those
blocks will still be present after return to V04.  Unless it
happens that the reboot count (e.g. 30) or the elapsed time
(e.g. 6 months) is found to have expired for a file-system
check during the V05 reflash reboot, which would find all
the ACL blocks as being allocated but unused, and return them
all to the free list.

So if your system is not supposed to be using ACLs for any
reason, then (while V04 is still running) the Remove ACLs
step can be done.


October 30, 2007