FCI: Folding@Home Client Info (Web based client monitor)

[Shadowtester]

No that should not be a problem the only real reason I run 64 bit is due to the smp requiring 64 bit. I am part of the Mepis bittorrent team which help create the torrent and makes sure they are seeded so if you ever have a problem getting it let me know I should be able to help I have a little bit of a inside track

[smoking2000]

New release of FCI: v1.3.4

* Added explicit support for MEPIS instead of treating it as Debian.
* Automatically use /usr/lib/rasmol/rasmol.32 if this exists (as used by Debian [, MEPIS & Ubuntu], Gentoo, Slackware & Mandriva. If the distro package of rasmol is not installed, /usr/bin/rasmol or /usr/local/bin/rasmol will be used if one of these exist. If none of these exist, the rasmol binary shipped with FCI is installed into /usr/local/bin/. On FreeBSD /usr/local/bin/rasmol-32 is used automatically, or the same fall-back mechanism will be used.
* It's now forbidden to delete the only client or user listed in respectively clients.xml or users.xml. This keeps XML::Simple happy, and the ACLs as sane as possible.


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.4.tar.gz

[Shadowtester]

Wow that update was very fast and worked great Thank You for all your help and for adding support for direct support for Mepis it looks great on the web pages.

Thank you again!!!!!

[smoking2000]

Wow that update was very fast and worked great Thank You for all your help and for adding support for direct support for Mepis it looks great on the web pages.

It looks even better if you upgrade your FCI client which has been modified to detect MEPIS and report the OS name as "MEPIS 8.0 (Debian lenny)" instead on "MEPIS 8.0 (upgradable from Debian etch)"

[Shadowtester]

Thank you I originally only updated the server since the client file showed vers 1.2.1 which was the same as the previous version. I have since also updated the clients as well it looks great. Thank you again for all your hard work and help its a great software addition to the Folding@Home community!

Thank You

[smoking2000]

You're correct that the new FCI client has not been updated with a new version, this is still a manual process, so I forget it every now and then.

[smoking2000]

New release of FCI: v1.3.5

Thank you I originally only updated the server since the client file showed vers 1.2.1 which was the same as the previous version.

This release features an updated version number in fci-client to reflect the changes made in fci-1.3.4.

In another future release I'll include either upgrade functionality in the installer to avoid these issues, or document the procedure in the INSTALL files. In the mean time the only reliable way to install a new version of FCI is with a complete reinstall (rm -rf /var/www/fci /usr/local/bin/fci*), or manually merging the changes. Personally I use the latter method, but this is not very good for non-developers of FCI. When only the perl code has been changed, it's enough to copy the latest versions over the old, but if the XML files have been extended these changes need to be added by manually.

The upgrade functionality has now been implemented in the installer.

It will not overwrite any existing files by default. It will overwrite most files if used with --upgrade (or -u), the files not overwritten are those in the qd-data, xml-data & site-data directories. These are only overwritten if --force is used (either with, or without --upgrade).

So if you want to upgrade to a new version of FCI that you installed with:

Code: Select all

sudo ./install.pl --verbose --client --server --owner joe

Simply run:

Code: Select all

sudo ./install.pl --verbose --client --server --owner joe --upgrade

To do a complete reinstall overwriting even your data that is preserved on upgrade, run:

Code: Select all

sudo ./install.pl --verbose --client --server --owner joe --force

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.5.tar.gz

[Shadowtester]

I was getting ready to update to the new version and was looking at doing it for the first time without manually editing the fci-client.pl for each client. I read in the option where there is the option to use a client config file but when I tried to save the client config it told me that that option is disabled any idea when it might be implemented?

Thanks again

[Shadowtester]

Ok I spent the time to configure my crontab fci entries with the needed command line switches so that I did not need to manually edit the fci-client.pl files anymore and then I used the --upgrade function to update both the server and all the clients. I have to say its much easier and a huge improvement. Thank You!!

A couple of request for future additions/improvements if possible
1 add gpu project data to the projects list like the already cpu projects.
2 would be nice if you could add TPF info for each client to each project only keep the latest TPF for each client as a client history performance indicator for each project.

And Again Thank You for all the help and support FCI just keeps getting better and better all the time.

[MstrBlstr]

New release of FCI: v1.3.5

Or you can use the direct link:
http://fci.bile.nl/downloads/fci-1.3.4.tar.gz

Isn't that the link to the prior version, not the latest?

Edit: Nevermind, I just went ahead and fixed it for you.

[smoking2000]

Edit: Nevermind, I just went ahead and fixed it for you.

Yes it was the old link, I forgot to update the version there too. Thanks for the fix!.

I was getting ready to update to the new version and was looking at doing it for the first time without manually editing the fci-client.pl for each client. I read in the option where there is the option to use a client config file but when I tried to save the client config it told me that that option is disabled any idea when it might be implemented?

The feature will be implemented when there is demand, which is now I think

I disabled the partial implementation because I personally didn't need this functionality, and because I hadn't made the final decision what format to use for the client config file. I'm tempted to use XML like I do on the server because it's so easy to deal with in the code, but XML is not as good for humans to edit as it is for computers. I may choose to use YAML or the simple key = value format that was the original implementation.

Whatever format I choose, I'll implement the client configuration for the next release. It was a release goal for 1.0, but that release took forever, so this feature got dropped.

A couple of request for future additions/improvements if possible
1 add gpu project data to the projects list like the already cpu projects.
2 would be nice if you could add TPF info for each client to each project only keep the latest TPF for each client as a client history performance indicator for each project.

What do you mean exactly by "add gpu project data to the projects list like the already cpu projects."?

Do you want to see a project image for GPU WUs? If that is the case, I'll have to disappoint you unfortunately, because the FAH GPU client does not generate the current.xyz file from which the project images are generated using rasmol & image magick.

I'm planning the integration of RRDTool based graphs for one of the next releases, which will give a more detailed picture of your TPF and PPD over time. But this needs to be implemented still. I might implement the TPF stats per WU, but I have to improve the FAHlog parser for that as a prerequisite.

[Shadowtester]

What I am talking about is when you click on the Projects link on the menu it opens a list of Projects which you have worked on or are working on currently. And then if you click on one of those Project numbers it will then open up a detailed page with more info on that project as an example

Code: Select all

Project: 2653
Project Information
Number	: 2653
Status	: Active
Name	: p2653_Protein in POPC
Atoms	: 77583
Preferred	: 3.00 Days
Deadline	: 4.00 Days
Credit	: 1760.00
Frames	: 100
Code	: GRO-SMP
Contact	: kasson
Server	: 171.64.65.64
Last Update	: 2007-08-06 00:00:11

And it also will list what clients are currently working on that project as well I would like to see a page like that for all the GPU2 projects which my clients have worked on as well currently you get a page like that for the GPU2 client if you click on the Project number listed on the GPU2 client which it is currently working on but as soon as it finishes that work unit and starts a new project that info is lost. I would like to see it saved in the Project list like the SMP cpu projects are currently in the projects.plc. An no a mage for the GPU wu's is not necessary it would be nice but not necessary. But a time per frame historical benchmark saved again in the projects.plc would be great to indicate the previous and or current performance of the clients working on that projects to help track how the clients are preforming on the different projects.

The fci-client.conf would be great since all the command line switches being used in the crontab are a little excessive it would be a much nicer and cleaner application to just have a simple config file either manually edit or to generate once with the client save option then crontab command would not be so extensive currently the command I use to run the fci-client.pl is longer that what can be displayed in one line on my 20" monitor at a 1280x1024 resolution which I use. Previously I had been manually editing the fci-client.pl with the info and saving the fci-client.pl under multiple names such as gpu-fci.client.pl and smp-fci.client.pl and then it was a simple short crontab entry to run each separate fci-client file but that was a pain to maintain and edit manually each time there was a update. I think all the command line switches used may be one of the issues which limit the use of FCI by additional users as many folders are a little scared by having to use a terminal command line they are products of the Windows gui era and even if they are using Linux are not comfortable using the command line interface. I know the other thing that is holding FCI back for many users is that the server will not run on windows as many only have windows based farms and do not have any machine running Linux in that respect I am the opposite all I have are Linux machines running F@H and those with only windows based farms tend to use one of the other windows based monitoring tools since they do not want to learn how to setup a Linux machine.

As a security feature it would be nice to be able to define a specific port along with the server url in the fci-client.pl or fci-client.conf for people who have clients not on the lan with the server so that they can use port forwarding within their router firewall to help secure their systems from possible hacker attacks. I know on all telnet, ssh, ftp, and http communications I do originating outside my lan firewall from the internet I use non standard port and then setup port forwarding though my firewall so the standard ports are kept closed. The server would not need to be able to accept communication from a non standard port for most people since they could use port forwarding from within their routers firewall. For example currently using the command line interface options being able to use

Code: Select all

--url http://www.example.com:48057/fci/index.pl

And then the user could just setup a port forwarding rule for their router fire wall to forward the specified port to the server computer on their lan using the standard port 80 which the server is looking for or you could also allow them to set the port for the server as well for the client upload for additional security and flexibility.

I hope I am not overwhelming you with suggestions/possible improvement just trying to help with some suggestions that I think would improve FCI function and usability in the future.

[smoking2000]

What I am talking about is when you click on the Projects link on the menu it opens a list of Projects which you have worked on or are working on currently. And then if you click on one of those Project numbers it will then open up a detailed page with more info on that project as an example

[...snip...]

And it also will list what clients are currently working on that project as well I would like to see a page like that for all the GPU2 projects which my clients have worked on as well currently you get a page like that for the GPU2 client if you click on the Project number listed on the GPU2 client which it is currently working on but as soon as it finishes that work unit and starts a new project that info is lost. I would like to see it saved in the Project list like the SMP cpu projects are currently in the projects.plc. An no a mage for the GPU wu's is not necessary it would be nice but not necessary.

I see what you mean now, that shouldn't be to hard to implement. We only need to save the project-summary data of the project in question in known-projects.xml even when there is no image to generate because the current.xyz is missing. I'll implement this is the next release too.

The fci-client.conf would be great since all the command line switches being used in the crontab are a little excessive it would be a much nicer and cleaner application to just have a simple config file either manually edit or to generate once with the client save option then crontab command would not be so extensive currently the command I use to run the fci-client.pl is longer that what can be displayed in one line on my 20" monitor at a 1280x1024 resolution which I use. Previously I had been manually editing the fci-client.pl with the info and saving the fci-client.pl under multiple names such as gpu-fci.client.pl and smp-fci.client.pl and then it was a simple short crontab entry to run each separate fci-client file but that was a pain to maintain and edit manually each time there was a update. I think all the command line switches used may be one of the issues which limit the use of FCI by additional users as many folders are a little scared by having to use a terminal command line they are products of the Windows gui era and even if they are using Linux are not comfortable using the command line interface.

I concur regarding the need to the fci-client.conf, and so does The Art of UNIX Programming which I bought & read quite some time ago.

For that reason it was part of the original design of FCI v1.0, but release considerations convinced me to drop the feature for the time being.

I know the other thing that is holding FCI back for many users is that the server will not run on windows as many only have windows based farms and do not have any machine running Linux in that respect I am the opposite all I have are Linux machines running F@H and those with only windows based farms tend to use one of the other windows based monitoring tools since they do not want to learn how to setup a Linux machine.

Regarding Windows-only users, they are not my target userbase, and never will be for FCI. The client needs to run on all platforms the FAH clients does (including Windows), but the server will always require UNIX, whether that is Linux, FreeBSD or OpenBSD (and possibly Mac OS X in the future too) doesn't really matter from my support perspective.

For the major FCI rewrite of 2.0, I've planned a native C# .NET FCI client for Windows with a GUI and all, but this release not expected in the near future. Heck, I still haven't finished the QD-GUI for Windows & Mono which I started developing in early 2008 (2008-02-28 according to the ChangeLog).

To ease FCI server deployments for Windows-only users, I have planned to provide a VMware Appliance with the latest FCI preinstalled on Ubuntu LTS (I already have the VMware image), but I don't have the bandwidth to distribute such VMware image. Downloads would take forever hosted behind my DSL line. I may have the option to place a server in the network of my new employer, but this is a long term plan too.

For example currently using the command line interface options being able to use

Code: Select all

--url http://www.example.com:48057/fci/index.pl

And then the user could just setup a port forwarding rule for their router fire wall to forward the specified port to the server computer on their lan using the standard port 80 which the server is looking for or you could also allow them to set the port for the server as well for the client upload for additional security and flexibility.

To have the FCI server HTTP port configurable in the FCI client for non-standard ports is a good feature, for the server it's not required for me to implement support, simply edit your apache configuration to listen on the port you want, the FCI server already supports constructing URLs using non-standard ports.

Running your own webserver on your DSL or cable line in .NL is not really a problem, but I know of some ISPs in .US that disallow services on priviledged ports, so this would be good feature to have. It should have been supported already, just like proxy support, those are pretty basic requirements too, but I just don't want to spent time on features that I won't be using and don't expect other users to need either. So until my users tell me they need such a feature I'll consider implementing it, but not before.

I'll put the support for non-standard HTTP ports in fci-client on the TODO for FCI v1.4 too.

SSL support would be even better to have supported too, but dealing with SSL certs properly is far too much to ask of most users, so that's a very long term plan too.

Regarding NAT as a security feature, it's not. An open port on a non-standard port is still found by a standard nmap scan. And the vulnerabilities in that service by the Nessus scan that may follow. Running services on a non-standard port without any firewall restrictions is not much additional security, you only stop people that only paste your hostname in their browser address bar.

I hope I am not overwhelming you with suggestions/possible improvement just trying to help with some suggestions that I think would improve FCI function and usability in the future.

It's not overwhelming unless I take as an obligation to implement these features request, which I don't I'm happy to consider any feature request and will implement them if they seem useful. All within the limits of the time I have available of course.

[Shadowtester]

As for hosting a vmware client with the fci server already installed I think using standard Debian would be a better option vs Ubuntu since honestly its more stable most of the time than ubuntu and if you used bittorrent to help distribute your vmware client I know I could also help distribute it here in the US I have access to to different ADSL lines with a total combined upload bandwidth of 1.25mbit that I already use and have bit-torrent servers setup on. And I am sure there would be other people who use fci and could benefit from a vmware client with fci already installed that could also help spread the vmware client by bittorrent after they download it that is kind of how it works you would just need to get a tracker setup for the bit-torrent. I am not sure you could use a tracker such as the linuxtracker.org since it would not be an officially sanctioned distribution.

And I do not leave the ports open on the firewall that was not what I was suggesting when asking about being able to use non standard ports. The port forwarding just allows you to route the incomming traffic from that non standard port to a specific computer on your lan on a specific port. What increases the security there are some 65k ports that could be used and unless the hacker knows what port and what kind of traffic is ready to accept it would be much harder for them to gain access to the system vs just sending a http request to port 80 looking for a web server to reply.

[smoking2000]

New release of FCI: v1.4

Code: Select all

* Finished implementation of fci-client.conf usage. You can now save
  almost all commandline arguments in the ~/.fci/fci-client.conf
  by running fci-client.pl with the arguments you want to save, and
  --save-config. This will save the arguments and their values in
  fci-client.conf which will be loaded the next time fci-client.pl is run. You
  can overrule the configuration loaded from fci-client.conf using the
  commandline arguments.

* Add (GPU) projects to the known-projects.xml if they're not already listed.
  Projects were only added to the list if they uploaded a current.xyz file for
  that project, but GPU clients don't produce this file anymore.

* Removed unused subroutine update_known_project() from www/upload.plc.

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.4.tar.gz