Shadowtester wrote: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.
Shadowtester wrote: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.
Shadowtester wrote: 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.
Shadowtester wrote: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.
Shadowtester wrote: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.