[freenet-support] unsubscribe
Error support has no subscribed addr [EMAIL PROTECTED] . support list run by [EMAIL PROTECTED] support administrative interface (requires authorization) At 23:20 16.11.2002 +, you wrote: On Sat, Nov 16, 2002 at 08:27:34AM -0500, Greg Wooledge wrote: [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: when specifying ClientPut/RemoveLocalKey=true, does fred remove the stored key (chk) BEFORE or AFTER trying an insert? If you removed the key after insertion, then the insertion will not have worked, because the key will be gone. So that wouldn't make much sense. experiments with build 618 (btw - the new layout (bullets, small title frame, typo) sucks in my opinion) revealed, that a ClientPut succeeds with RemoveLocalKey=true, even if that key *already existed*! this leaves me to think that the *old* key is removed before the *new* key is stored, leading to no key collision. Well, yeah. That's kind of the point. the IMHO correct way would be to remove the *new* key *right after* it has been inserted, and if such a key already exsits when trying the insert, returning a KeyCollision! But then you'd be deleting keys from your data store and not replacing them. Given that the point of the RemoveLocalKey option is to improve propagation of your keys, deleting from your data store afterward seems to be a step backward. If your goal is to remove all traces of the key from your data store after insertion to hide your tracks, then I think you should consider stopping your node and running rm -rf store_* or DELTREE store_*. And make sure you're using a transient node for this purpose, not a permanent one. Um, you have no plausible deniability if you run a transient node... if it's in your datastore and you are transient, you must have put it there. If it's in your datastore and you are permanent, it probably came from another node, and you have no reason to know what it is.. greatly improving your legal position in most sane places (IANAL, but this is well known to be one of the major principles on which freenet is based). -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] | - The Red Hot Chili Peppers http://wooledge.org/~greg/ | -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/
[freenet-support] old and now wrong freenet.ini comments
i spotted some mistakes within the .ini file. of course you already know about these ;) but these are again from the stone age ---~~--- # Freenet configuration file # This file was automatically generated by WinConfig on 11/17/02 now you know where it's from ---~~--- # The byte size of the datastore cache file. Note that it will maintain # a fixed size. If you change this or the storePath field following, # your entire datastore will be wiped and replaced with a blank one storeSize=24G this only applies for the old monolitic store, not for the native please add remarks for the new m/M/g/G modifiers, too boy - am i a free-space-gifted :p ---~~--- # The path to a single file (including file name, or a comma-separated list of files, # containing the data store. The size of each file is given by storeSize. # Defaults to cache_port in the main freenet directory. storeFile=D:\_freenet\store recently there was a mail with this in it: remove storeFile=E:\FreenetStore in -this mabe wrong because you set : storeType=freenet (And this means that you will have a DS-directory - not a file If you want to set the path to the Datastore use storeDataFile= i don't know if this is right, if so, the above comment has to be fixed and the property storeDataFile= should be included with corresponding comments ---~~--- # Should we use thread-management? If this number is defined and non-zero, # this specifies how many inbound connections can be active at once. maximumThreads=120 a hint should be added, that there are two thread factories: + and - or add a new property threadFactory=classname with some example classnames ---~~--- # The name of a symmetric cipher algorithm to encrypt the datastore # contents with. Supported algorithms are Twofish, Rijndael, # and null, none, or void (for no encryption). storeCipherName=none i'm not sure if this works for me. the stored metadata on files is cleartext and the Data section is encoded with rjindael. or is this already encryption none (because i can read the metadata)? ---~~--- there are for sure some more fields, but a) i'm no expert in the .ini files of freenet and b) i'm not sure if some of these are deprecated or whatever and c) there are too many undocumented fields have a nice day ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
Re: [freenet-support] Something died on me
On Sun, Nov 17, 2002 at 12:15:13AM -, Vitenka - Zen wrote: Which file do I need to delete to get it back up and running this time? Killing the rt files didn't help. 17-Nov-2002 00:13:48 (freenet.node.Main, main): starting filesystem 17-Nov-2002 00:13:53 (freenet.node.Main, main): loading data store 17-Nov-2002 00:13:53 (freenet.node.Main, main): loading routing table 17-Nov-2002 00:13:55 (freenet.node.Main, main): Unexpected Exception: java.lang.NullPointerException java.lang.NullPointerException at freenet.node.LoadStats.init(LoadStats.java:74) at freenet.node.Main.main(Main.java:645) java.lang.NullPointerException at freenet.node.LoadStats.init(LoadStats.java:74) at freenet.node.Main.main(Main.java:645) What build number? -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ msg02168/pgp0.pgp Description: PGP signature
Re: [freenet-support] RemoveLocalKey
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: [RemoveLocalKey] i think about RLK=t like a GenerateCHK - doing some stuff, looking if it works, but not performing any (permanent) operations on the store itself - i thought this was the intention of this field? if not, what *is* it's intention? The intention is to let you insert or request a key from the rest of Freenet even if it's already in your data store. The implementation is that it deletes the key from your data store first. It's supposed to help you propagate a key. Assume for the moment that you have a Freenet site, which you have inserted through your node. But other people can't reach it -- maybe because all of the nodes to which you inserted it originally, other than your own, have gone away. If you re-insert it through your own node, nothing will happen -- you already have the key, so it just spits back a KEYCOLLISION (fcpputsite terminology) and the key isn't propagated. But if you remove the key from your local data store, and *then* insert it, then it can be propagated to other nodes. -- Greg Wooledge | Truth belongs to everybody. [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | msg02169/pgp0.pgp Description: PGP signature
Re: [freenet-support] Re: [freenet-dev] Getting rid of the last central point of failure
On Fri, Nov 15, 2002 at 06:45:45PM -0500, Alex Snow wrote: If you want to make sure the webinstaller hasn't been messed with, just sign it with something like gpg. Oh yes it's all so simple we sign the webinstaller in fact we don't even need to do that we just insert it under an SSK. /sarcasm. The problem is that we need to be able to revoke and/or update the signing key, otherwise a Bad Guy who got the key could destroy most of the network just by distributing compromized nodes. Explorer has caused a general protection fault in module kernel32.dll. I'm sick of Winblows! - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 9:30 AM Subject: [freenet-support] Re: [freenet-dev] Getting rid of the last central point of failure For a while now, we have been working on the distribution servlet, which is basically designed to allow people to give copies of Freenet, together with seednodes, to their friends erm - why? doesn't there exist some webinstallers? just bundle a webinstaller (or even a webinstaller-installer) with your seednodes and mail them away to the new user. hu will then receive this mail with some installing instructions/installer files and can build up hus (sounds stupid :p) node. the needed jar files can be d/led fom /snapshots/, or, if you think this may be potentially tainted somehow, d/led by a minimal-fred provided by the installer from the freenet under a CHK or SSK-site, which will contain all releases of fred, inserted by the developers. either way you will have a weak spot: the program that installs fred. either it will report you to someone or download a modified fred and install that one on your system. or you can not guarantee that your /snapshot/ files are valid, if you point the new user to the url to let him download the files all by himself. one possible way is to mirror the released snapshots and version within freenet, so noone can touch them, but to be able to rerach them, you already have to be able to access freenet, this speaks for a mini-fred, which will download the files for you. but the miniinstaler can be tainted, too, leaving you with a loop of possible weak points. i personally have no clue how you can make *sure* a user gets untainted files if the user does not have already freenet access. maybe it would be wise to start a new site within freenet, which will mirror the developers' cvs tree and snapshots *done by a trusted person (=devl)*, so one can be sure, the /snapshots/ files are not the only location to get one of the newer builds (it is possible to modify streams from a webserver, so you can be sure, it is possible to modify the response to your get some file from snapshots in that way, that you will receive a modified fred which can harm your anonymity) so at least you can make *sure* the user will stay clean if you start inserting the snapshots within freenet and use a SSK'ed site to gather them, too ---~~--- geeh - i think i have to read my mails more often so i've got to add something to General Discussion, nearly all of my topics have been adressed so far by others ;) ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ msg02171/pgp0.pgp Description: PGP signature
Re: [freenet-support] Freenet performance
On Sun, Nov 03, 2002 at 06:50:54PM -0600, Robert Carroll wrote: I think alot of problems with freenet are performance related. The network as a whole would benefit from faster freenet code. Perhaps the developers should consider converting some java methods into native methods. Given the 90/10 rule, a small number of converted methods could yield a huge performance increase. I'm not suggesting that java support should be dropped, but this effort would be paralell to the main java codebase. Unsupported platforms could still use the java methods. This probably wouldn't be a big deal to transients (directly anyway), but it would be a HUGE benefit to the permanent nodes which are the backbone of freenet. This is incorrect. The node has numerous major network level problems at the moment - inserting a file on one node at HTL 25 and then getting a DataNotFound at HTL 25 on another node, is not a good sign. Mostly this is due to growing pains and old versions of the node though, hopefully. Eventually, we may make fred use nonblocking I/O; this will drastically reduce the number of threads needed, but it will be a lot of work and it is not a major priority because there are easier things with a bigger impact to do first. -- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ msg02172/pgp0.pgp Description: PGP signature
Re: [freenet-support] Freenet performance
On Sun, Nov 03, 2002 at 06:50:54PM -0600, Robert Carroll wrote: I think alot of problems with freenet are performance related. The network as a whole would benefit from faster freenet code. Perhaps the developers should consider converting some java methods into native methods. Given the 90/10 rule, a small number of converted methods could yield a huge performance increase. I'm not suggesting that java support should be dropped, but this effort would be paralell to the main java codebase. Unsupported platforms could still use the java methods. This probably wouldn't be a big deal to transients (directly anyway), but it would be a HUGE benefit to the permanent nodes which are the backbone of freenet. This is incorrect. The node has numerous major network level problems at the moment - inserting a file on one node at HTL 25 and then getting a DataNotFound at HTL 25 on another node, is not a good sign. Mostly this is due to growing pains and old versions of the node though, hopefully. Eventually, we may make fred use nonblocking I/O; this will drastically reduce the number of threads needed, but it will be a lot of work and it is not a major priority because there are easier things with a bigger impact to do first. It seems to me a lot of the cpu-sucking just comes from os process-switching-overhead. I'm seeing this problem with a project of mine that makes heavy use of threads. It's not actually doing much work, but sucking up the cpu anyhow. I remember having a vm once that actually mapped java threads to linux pthreads (or something), not processes. Would that be a workable/functioning workaround to the problem? I tried to try IBM jre 14 (since I think it was an IBM vm that did the thread-mapping), but couldn't get it to work (exec: cannot execute binary). probably libs missing, but dunno which. Anybody got a hint for me? Does anybody use a vm that does this? Am I off-track with the concept? I dont like that jni approach by the way, after all, fred is a reference-daemon and it should run anywhere. If you want a perfomance-oriented version, I would suggest to reimplement completely in portable c++ or something. cheers, nick ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
Re: [freenet-support] Something died on me
java.lang.NullPointerException at freenet.node.LoadStats.init(LoadStats.java:74) at freenet.node.Main.main(Main.java:645) What build number? 524. Killing the lsnodes seems to have fixed it. And I may have messed up my settings, but now my node only knows about 50 nodes, and never seems to learn about more. Can I guage other peoples performance on freenet? Personally - I can only ever see about four or five of the sites linked from TFE. And very very rarely any pages linked off of them - Yodel now shows up, but the 'bankbot' page does not, for example. Is this normal? What settings should I be using? ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
[freenet-support] Idiots guide to writing line 1 of a shell script
I see more and more of this: #!/usr/local/bash or #!/usr/bin/python2.2 That is not the proper way to define a shell or programming environment in a script for multiplatform use. This is how you do it: #!/usr/bin/env python or #! /usr/bin/env bash That is what the env program is for. Use it! For the terminally clueless type man env. Thanks. -- - The Numeric Python EM Project www.pythonemproject.com ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
