On Thu, Aug 10, 2000 at 09:24:30AM +1200, Stephen Blackheath wrote: > So, on Unix, would it be $HOME/.freenetrc, or $HOME/.freenet/.freenetrc ?
IMHO it would be neither. > I thought the directly was quite a good idea, because we have a few files > we need to store. I thought we could put the data store there, too, > because I am a great believer in software being simple and not having > unnecessary options. In development we'll need to run multiple copies > under the same user (so I could allow for that somehow), but I can't see > any reason why an end user would do that. Well, in nfreenetd (a C implementation of a Freenet node), I am going to store the configuration file at /etc/nfreenetd.conf and store the datastore under the /var/spool/freenet directory (with the datastore index being at /var/spool/freenet/index). The reason for this arrangement is that I think that a Freenet node should be treated more as a system service (like mail transfer agent, print spooler, or a NNTP server) than a user level program. This philosophy is also one of the reasons why it isn't a bad idea to have a Freenet node implemented in C. > The other consideration is that if you make the Java do one thing on > Windows, and something else on Unix, then it's "un-java-like". I believe > HotJava Browser does (or at least used to) use the Unix convention, which, > translated directly to Windows, became C:\.hotjava\... But, then, of > course, there are more Windows users to consider than anyone else. Why > don't I just use the Unix convention for now and we can refine it later? Personally, I like Unix conventions. Of course, that is just my opinion. > On remote configuration: > > > This is just a bad idea. Please do not allow remote configuration. Its > > never necessary to change the configuration of a running node anyway. > > Is it all right if I have 'remote' configuration that only accepts > connections on localhost? It's attractive, because it's an easy way for > the client to find the running node, and I like convenience of use. > Trouble is, (on Unix) it doesn't authenticate the client's user id. I > thought I could get around this by optionally allowing a password, but > that leads on to remote configuration, which we're not going to do (now > that I know). This is unnecessary and a waste of time. Why couldn't you just SSH into a box and do the configuration through that (assuming it is a Unix/Linux box)? > The other option would be to have the client modify .freenetrc directly. > Perhaps then we could have the equivalent of a -HUP signal that works by > connecting to the right port. The advantage is security: unauthorized > users could only make the node reload its configuration, which would have > no exploitable effect. I think I will go with this instead, if that's all > right with you guys. Yeah, I think that SIGHUP should be caught and signal the node to reread the configuration file(s). Of course, this cannot be done with a node implemented in Java. Note that catching SIGHUP is secure because one has to be logged in as root (or as daemon, or whatever UID the Freenet is running under) to send this to a the node. > > Why not configure from stdin? And I agree with Scott about the > > dubiousness of configuring running nodes. We rejected remote > > administration many times. > Hmmm... And what do you think of the idea of the node having an HTTP proxy > built in (disabled by default)? Again, I'm think of all this from the > point of view of ease of use by an ordinary Windows user (to use the most > respectful term I can think of.) It's enough to get them to run one > daemon (hence the idea of the client spawning the daemon). I see HTTP > proxying as the most important feature from a user's point of view. I don't deny that HTTP proxying is a good idea, but I don't think that it should be integrated into nodes themselves. I think that the most appropriate place to put HTTP proxying is in a HTTP<->Freenet gateway (or you could do a similar thing with a SMTP<->Freenet gateway). > Another possibility is for the user not to run a node, but to run the > client only, and have the client pointed at the network somehow (by means > of this same magic mechanism for a node to join the network). The client > could then be configured to run an HTTP proxy itself, just for the period > during which the client is running. This would be an ease-of-use thing > for OWU's. Ideally, we want as many people as possible running nodes. Anyways, with how a node would work, you wouldn't really even need to have a node be shut down while the network connection is down. When the network connection is down, the local Freenet node can be used to cache (like an HTTP cache used by a Web browser) so that one does not have to save files that they saw on Freenet to access them while offline. A Freenet node should be started up when the computer starts up and shut down when the computer shuts down/reboots. -- Travis Bemann Sendmail is still screwed up on my box. My email address is really bemann at execpc.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 3640 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000809/103ae46a/attachment.pgp>
