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!
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
|diff -u: What's New in Kernel Development||May 06, 2015|
|Chrome-Colored Parakeets||May 05, 2015|
|Mumblehard--Let's End Its Five-Year Reign||May 04, 2015|
|An Easy Way to Pay for Journalism, Music and Everything Else We Like||May 04, 2015|
|When Official Debian Support Ends, Who Will Save You?||May 01, 2015|
|May 2015 Issue of Linux Journal: Cool Projects||May 01, 2015|
- diff -u: What's New in Kernel Development
- Mumblehard--Let's End Its Five-Year Reign
- Chrome-Colored Parakeets
- An Easy Way to Pay for Journalism, Music and Everything Else We Like
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Picking Out the Nouns
- Return of the Mac