Freenet Installation and Administration

Peter demonstrates how to take advantage of the World Wide Web alternative, Freenet.
Resource Configuration

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.

Other Options

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!

Testing

Now that you've got your node up and running you want to see if it works, right? First try running:

freenet_request test-key

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.

Establishing Your Node

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!

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState