Freenet Installation and Administration
By default, Freenet will store a maximum of 1,000 items in the data store and use a maximum of 500MB of hard drive space. The diskCache and dataStoreSize options control this. Note that, due to bugs, the actual amount of space used can easily go over this. Often files in the data store simply get lost and don't get deleted when they should be. Restarting the node periodically, every day or week, will clean out those lost files. Secondly, while transferring large files the node will store the whole file while it's in transit even if doing so makes the node go over the size limit. Hopefully by the time you read this article, these bugs will have been fixed, though the second problem is difficult to fix for various reasons.
After that we have the dataPath and dataPropertiesPath that control where the data store is (the default is the .freenet directory where you installed Freenet). The difference between the two is that dataPath is where the actual data gets put, and dataPropertiesPath controls is where the .inf files describing the data stored get put. In all but unusual cases the two will be the same value. You may want to set this path to another partition with more space available than the default. Any filesystem that supports long filenames is fine. Note that you can't use multiple partitions simultaneously, you'll have to run multiple nodes on different ports for that.
There is also an option to limit bandwidth used, bandwidthLimit. This limit applies to outgoing data only. Incoming data is not limited (see maximumConnectionThreads). For most people the 50K/sec limit is probably fine, but if you can, please increase it or disable the bandwidthLimit to about a third to a half of your outgoing bandwidth, about 50K/sec to 300K/sec for your average cable or DSL line. Note that the bandwidth limit does not apply to requests originating from the same machine.
Incoming bandwidth can be limited, to a degree, with the maximumConnectionThreads option. This option limits the maximum number of incoming connections from other nodes. Changing this changes the amount of bandwidth and memory used. Most people can probably leave it at its default of 50K/sec, but if you have memory restrictions (or excesses) you can reduce or increase it.
Note that there is currently no way to limit the amount of total data transfer in a given time period. So as of yet, there is no way to only allow, for example, 1GB of data transfer per month.
At the end of the configuration file are the options that control logging. A single log file is used, freenet.log, by default (controlled by logFile). The logging option controls the threshold of events logged. The default, “normal”, doesn't log any of the mundane details of your node sending and receiving data. The “minor” setting can often provide useful debugging information, however debugging is overkill. Setting logging to minor is probably your best bet.
Finally, there is one last option that's not in the default configuration file, informDelay. Before writing the node's address to informURL, the node will wait a default of 24 hours to make sure your node is stable. Your node must be running for 24 continuous hours before the informURL is notified. Initially, one of the big problems with the informURL system was that people would try Freenet for a few minutes, decide it wasn't worth it and remove the Freenet software. Meanwhile, the address of their nonfunctioning node was sent to informURL. When nodes tried to get a working address, almost every single address in informURL would be nonfunctioning. It got to the point where one of the big problems in getting a node up and running was finding another node!
If you plan on restarting your node once a day you'll have to change the informDelay to something different. Setting it to 0 by adding the line informDelay = 0 to the configuration file will disable the feature and is what you want. Otherwise don't touch informDelay, please!
Now that you've got your node up and running you want to see if it works, right? First try running:
If that works you'll see the message: Congratulations! You've fetched a Freenet key on the console after some debugging information. If it doesn't do anything for more then two minutes or so it's not working.
Next try the URL http://localhost:8081/KSK@Aardvark in your favorite web browser to see if fproxy is working. If it is, you'll see the page of Aardvark's Freenet Index come up.
Actually getting your node established in the network can be a little tricky. It should, and usually will, do so automatically, but it often helps to push the process along a little to speed it up. This is an optional procedure. There are two main parts to this: finding other nodes and getting known by other nodes. Note that if you're running a transient node the second part isn't important.
The first part is simple, use Freenet. Just take a look at some of the content, such as the above-mentioned Aardvark's Freenet Index (KSK@Aardvark) and gj's web page (KSK@webpages/gj_jump0).
The second part is a little bit harder. You can insert a random chunk of data (1K) into Freenet with:
dd if=/dev/urandom bs=1024 count=1 | freenet_insert -length 1024 CHK@
When your node inserts that data, other nodes will find out about your node from the SourceAddress on the packets of data.
In any case, remember that it will take a few days before your node becomes known and other nodes start to request data from you. So if nothing much seems to be happening—don't panic!
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Non-Linux FOSS: Code Your Way To Victory!
- Vagrant Simplified
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Libreboot on an X60, Part I: the Setup
- Dealing with Boundary Issues
- System Status as SMS Text Messages
- Bluetooth Hacks
- October 2015 Issue of Linux Journal: Raspberry Pi
- New Products
- Vigilante Malware