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!
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- RSS Feeds
- The Secret Password Is...
- New Products
4 hours 24 min ago
- Keeping track of IP address
6 hours 15 min ago
- Roll your own dynamic dns
11 hours 28 min ago
- Please correct the URL for Salt Stack's web site
14 hours 40 min ago
- Android is Linux -- why no better inter-operation
16 hours 55 min ago
- Connecting Android device to desktop Linux via USB
17 hours 24 min ago
- Find new cell phone and tablet pc
18 hours 22 min ago
19 hours 51 min ago
- Automatically updating Guest Additions
20 hours 59 min ago
- I like your topic on android
21 hours 46 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?