This tutorial is aimed at the beginner-intermediat level Linux user. Although you won't have to be writing your own Perl scripts to get your FAH setup running, you most probably will have to know how to execute some basic command line operations, or at least know the manipulations required to duplicated those commands in a GUI. Without further ado, let's get this thing set up.
Step 1: Planning
Before we can dive into the fun stuff, , you will need to determine what kind of folding you want the target machine to run. Ask yourself the following questions:
- How many cores do you want folding?
- Do you want to fold 24/7?
- Is the target machine running other processes which might interfere with folding, and if yes, is folding or the said process a priority?
All those factors need to be taken in consideration for obvious reasons. On say, an e2140 system overclocked to over 3 ghz on air, don't be thinking that your setup will last 4 years plus if you decide to fold SMP with it: SMP folding under linux uses on average 90% of both cores at all times, in short just really rapes a machine. There also is concerns with other applications running on the target system. By default the FAH client has the lowest process priority all the time, but it still uses system resources and makes them less easily accessible to other apps. Lagging out your everyday use of your machine because of FAH is uncool, so you might want to either not fold SMP and have the client start on boot for the convenience, or start it manually all the time but in SMP mode, for those times where you are not using your computer. Decide on what you'll be running and what kind of priority you give to folding, and read on for more instructions.
Step 2: Setting Up FAH
For those who have been scared away from linux because of the relative complexity of source installs and all the dependency, config script and source code malfunction issues that it sometimes involves, worry not. Setting up the Folding at Home client in a Linux environment is as easy as extracting, giving the appropriate permissions and running.
Go ahead and grab the latest linux client from this page. Note that only the x86_64 package includes SMP folding. Once you have your package, extract it to where-ever the heck you want it to run: I personally choose /opt for that kind of stuff, but other popular choices might be /fah or /.fah (hidden folder) on the root of your filesystem. Be sure to use super user mode along with chmod to change the permissions for both the directory and FAH executable files.
If you are unsure about the permissions, go ahead and execute chmod -R 777 /directory/ , where /directory/ is the path to your FAH folder; it will open up your FAH folder to every user on your machine, eliminating the hassle of finding out the proper permissions.
Once it's extracted, cd to the FAH directory, and run ./fah (with -smp if you want to fold SMP) to run the client. Complete the initial config with your folding nickname, team (37726 of course), passkey and all the other options, and once the new cores and stuff are done downloading, press Control + C to exit. There you have it, a basic install of FAH. Now you can start FAH in a console simply by running /dir/ect/ory/fah [-smp] where /dir/ect/ory/ is the directory which contains the FAH executables. Note that you need to keep the console open to keep folding: shutting down the console closes the core.
And that's it. If you don't want FAH to kickin in on startup, then you're job is finished. If not, read on.
Step 3: Running on Startup
Although this is optional, in many cases it is very useful. Dragging a full tower case out of my server closet to start FAH manually every single time that power fails or that my cat plays with some wires isn't exactly my definition of fun, and chances are it isn't your's either. This is why having everything on your server daemonized is a practical thing to have: you just press the power button, and there it goes.
What we'll be doing is adding the the rc.d files, the ones that control the startup for services.
Cd to the directory /etc/rc.d/. This is the directory in which we will be working. You can try and ls just to see the content of the directory. It should look something like this.
The rcX.d (where X is a number) represent the runlevels, and what is to be initiated at each. We won't be messing around with that. Thankfully, linux dev people have created another launch list, which kicks in after the last runlevel script is initiated. This is the rc.local file.
This allows you to just put a command in, and it'll get executed at runtime. I've used this countless times to do stuff like mount network drives over CIFS, and the like.
However, you can't just put /opt/fah/fah in there and expect it to work properly, for two reasons:
- The FAH client is known to work erratically if it is started from somewhere else that it's own directory.
- Starting a program that needs a console window to be opened means that FAH will cause an interruption in the boot cycle, and any step after it in the rc.local file or otherwise will fail. This means that you will never get to the login prompt. Trust me, I know this from experience.
The solution to the first problem is quite simple, you just need to cd before executing. We can do this by adding a cd before the command and using the ./fah command afterwards, which would look something like this:
cd /path/to/ && ./fah
As you might have guessed, && seperates two commands on the same line.
For the second issue, it's a bit trickier. Since the FAH client needs to output its text somewhere, we can't just run it on startup and expect it to work properly, like I said before.
This is where a handy function function comes in: the > command line parameter. What this does is that it redirects all the text output that you would normally get onscreen to whatever path you specify. This brings us to two choices: we either create a FAH log, or send all the text into the abyss. In my case, creating a log file would just take up previous disk space, so I chose to ignore all the output, and send it to the "black whole" of linux: /dev/null. Think of it as an incinerator: you can put anything in it, but when something goes in it doesn't come out. The command would do something like:
cd /opt/fah/fah && ./fah >/dev/null &
Although I do not know what the final ampersand is for, I know that it is necessary, probably to allow additional commands to be run with the execution of the previous command still ongoing.
If you would want to log all the FAH activity, just replace /dev/null with whatever text file you want to dump your text in, like so.
cd /opt/fah/fah && ./fah >/path/to/log.txt &
Open up /etc/rc.d/rc.local with your favorite text editor, and add the new command we just created to a new line below any other commands that might be there.
Reboot, and your FAH should be working in the background!
If you want to monitor more closely the activity of your newly setup folding rig, you can always share the FAH working folding over the network with CIFS/SMB in read only mode, and use FAHmon to track the progress by adding a client with the following path.
\\*computer's ip*\sharename FAHmon has full support for checking work over windows shares, and the said shares are very easy to configure, as most distros come with a GUI SMB configuration tool.
That's pretty much it, feel free to contact me if you want any additions or modifications to be made to this tut.