New release of FCI:
v1.3
Quite a few significant changes in this release, one of the reasons why it took more time to complete than usual since the 1.0 release.
New Feature: Access Control
This release's most prominent feature is the complete overhaul of the authentication functionality, which has been replaced by more powerful access control functionality. It introduces the concept of client accounts, and enhances the user accounts.
In previous releases you could only configure authentication for the main web interface (including client uploads) or only client uploads in the default realm, and you could also configure authentication for the client-data and settings web interface. Now you can configure authentication for every data directory on the FCI server.
In the design of the FCI server it's still the intention that only client uploads, client-data and the settings interface should be protected by authentication, which is therefor the default configuration. But the FCI administrator is now able to choose to protect all or any of the other data directories too, e.g. an FCI administrator may chose to enable authentication for the stanford-data directory to disallow people downloading its data files. You might want to do this if you pay for your bandwidth and don't want people wasting it by downloading your copy of daily_user_summary.txt (which is 25.64 MB at the time of writing).
The new access control functionality manages the access for the client and user accounts by granting access to protected directories. A directory is only protected if its ACL is enabled. There is an ACL for every web accessible directory, there also is one ACL governing client uploads, which is now separately configured from the main authentication, but is overruled by the main ACL if that's enabled. There is also an ACL for client-data which is a bit special. Because client accounts now exist, it's possible to allow an individual client access to only its own client-data. If the client-data ACL is enabled, every (enabled) client account has access to the top level client-data directory, but only the client itself has access to its client specific client-data directory. The user account of each clients contact is also granted access to the client specific client-data directories. This allows you to authenticate for the Client Data realm using your user account, and be granted access to all your clients client-data directories automatically.
Because this type of access control is now possible, there are now direct links to the uploaded client data files on every client page in the FCI web interface. This allows you to immediately access e.g. your FAHlog.txt if you notice in FCI that your client is hanging. In previous releases only the FCI administrator had this ability by manually entering the URL to the file and authenticating using the credentials configured for the client-data site. Now every FCI user can access the client data uploaded by his own clients (assuming he has been sent his user account credentials, and the user account is configured as the contact for his clients by the FCI administrator).
The client accounts are slightly enhanced user accounts. A client account is only required for
registered clients. A registered client has its own password (username is the client name prefixed with 'client_') which guarantees that it is the only client allowed to overwrite its client files on the FCI server. This feature is useful if you are not the administrator of all the FCI clients on your server and would not like your other users being able to overwrite your client data when they use a client name identical to one of your clients.
Every client in FCI can be assigned a contact (it's not assigned by default). A contact is the user account for the administrator of that client. If you are the admin of more than one FCI client it's recommended to use your user account credentials to authenticate against the FCI server, because the user account set as the contact for a client is also allowed to overwrite the data of the client in question. If you are trying to overwrite the client data for a client that your are not the contact of, access will be denied (403 Forbidden). As an FCI user you may choose to request registration of your clients for the same reasons.
The user and client accounts are now also stored centrally. Instead of having a separate .htpasswd file in each directory to protect as in previous FCI releases, all accounts are now stored in the same .htpasswd file and access to the various directories is implemented using .htgroups now. Also instead of having only one account (usually the FCI administrator account) for each protected directory, multiple accounts can be granted access. A special group of users, those with administrator privileges, can also be granted access to each ACL via a single setting (Allow Administrator). This allows you to e.g. allow all FCI administrator accounts access to the client-data of all clients (even those it's not the contact of).
New Feature: FAH Client & Operating System icons
Aka the "FCI is starting to look more like Nagios every release" feature. This release adds icons for the FAH client type (tooltip shows the exact type and version details), and operating system icons (with the details as far as provided by the FCI client: Linux distro and kernel versions, Windows favor en kernel version, or FreeBSD/OpenBSD release, or just which major OS in the case of pre-1.0 FCI clients that didn't send detailed OS info).
These icons make it much easier to identify what system your FCI & FAH client are running on, and to make a distinction between the FCI clients and their relative performance. The FCI server for Fatal Error Group for instance shows a happy mix of clients on Windows XP, Windows Vista, Debian, various releases and flavours of Ubuntu, and one lonely Mac.
To easily see what kind of FAH client is running, the icons have a distinct color. The SMP client is
green, the GPU client is
red, and the CPU client is
blue. These colors (or colours if you so prefer
) were chosen because they're primary colors, and quite conveniently red and blue are on one side of the color wheel and green is on the other. This nicely illustrates the difference between the High Performance (GPU & SMP) clients and the classic (CPU) client.
New Feature: Support for Slackware (Client & Server)
In my effort to support all the major Operating Systems on which the FAH client may be run, I've updated the installer & installation instructions to support Slackware Linux too. Slackware was not initially supported with the FCI 1.0 release because it took me too much time (both wallclock and CPU) to setup a Slackware VM and compile all the software required for FCI. But since I also support Gentoo, I finally took the (wallclock) time to setup the VM and allowed VMware the (CPU) time of the FAH client to compile all the software. Fortunately I didn't have to compile apache, which came with the default (full) installation.
Installation instructions on the FCI project website:
INSTALL.Slackware
Improved Functionality: Client State Markers
The client state markers now include more detailed information in their tooltip. The progress state warning (
!) & critical (
!) markers now include the time between the preferred & final deadline and the expected time of completion.
The inactive client state marker (
I) now includes the time since the last upload in its tooltip. The client state marker for new clients (
*) also includes this information in its tooltip for its first upload.
There is now also a client state marker for general error conditions (
e). This is currently used when the qd-data uploaded by the FCI client contained an error, e.g. qd could not read the queue.dat on the client.
Another new client state marker is for when fci-update-xml-files.pl detects that the FAH client is shutdown (
s), its tooltip only shows the same message as the last line of the FAHlog.txt: Folding@Home Client Shutdown.
Bugfix: fci-update-eoc-stats.pl
As a precautionary measure fci-update-eoc-stats.pl would quit if it encountered an error (not 200 OK) while downloading the EXTREME Overclocking Folding@Home Stats. If it tried to download the stats for a user that doesn't exist in the stats (yet), EOC would return with an error (404 Not Found) causing fci-update-eoc-stats.pl to stop downloading the stats for all the other users too. Now the script will try continue to download the stats for the other users, but if it encounters errors for 5 users, it will still quit. This is to make sure the EOC server is not continuously sent erroneous requests.
Not a bugfix, but a minor enhancement. The sleep time between requests is now configurable using the -s or --sleep commandline argument. The minimum sleep time is 1 second, the default is 2 seconds. The default used to be 1 second, but was incremented to 2 because the EOC server sometimes returned a warning in HTML for the XML request that corrupted the XML file cached by the FCI server. The HTML warning told the user to wait a minute between requests. The 1 minute sleep time is not enforced by the EOC server as you might expect (the XML FAQ says:
"Try to rate limit your queries. By that I mean don't try to make a couple dozen queries in one second."), and 2 seconds has currently shown to be the safe default.
Bugfix: fci-client.pl
This release also includes a fix for the problem that newer versions of the downloaded qdinfo.dat are not used by the FCI client if the date in the version string is the same as that of the qdinfo.dat already on disk. It also saves the downloaded qdinfo.dat to disk if the pg date of the downloaded qdinfo.dat is newer than the one on disk, even if the date in the version strings is identical.
Minor Changes
fci-update-jmol-projects.pl has been updated to know about the Jmol abbreviation for the new 0x14 core: GROGPU2-MT (Jmol: GG2MT).
fci-update-project-images.pl has been updated to redirect the output of the rasmol command (both STDOUT & STDERR) to /dev/null. This is a nice fix if you have your cron configured to email you any output of your cronjobs. You don't want an email every time the script generates images for recently added known-projects, you only want emails if it encounters an error while doing this. At least I do.
Since this release includes a new version of fci-client.pl
it's highly recommended that any FCI client you admin are updated to this new release.
The lastest FCI release (and previous releases) can be downloaded from the project website:
http://fci.bile.nl/?target=downloads.plc
Or you can use the direct link:
http://fci.bile.nl/downloads/fci-1.3.tar.gz