Re: [freenet-support] Password protect the console?

2017-01-30 Thread Thomas Wuensche
If the interface is bound only to localhost you can make an ssh forward 
of the relevant port (with the -L option) to a local port on your other 
machine on Linux systems.


Am 30.01.2017 um 19:34 schrieb Steve Dougherty:

That isn't implemented, no. If other people have accounts on the system
they will be able to access it. (By default Freenet's web interface only
binds to localhost.)


On Mon, Jan 30, 2017, 8:59 AM neuman <neuman1...@gmail.com
<mailto:neuman1...@gmail.com>> wrote:

I see there is an option to password protect the downloads,  but is
there an option to password protect the console?   I have it running on
a headless pi system and would like to prevent anyone else from
accessing it.   Can I protect the console?
___
Support mailing list
Support@freenetproject.org <mailto:Support@freenetproject.org>
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org
<mailto:support-requ...@freenetproject.org>?subject=unsubscribe



___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe


--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106

Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com
___
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

[freenet-support] maxHopsToLive in Freenet configuration file

2002-12-09 Thread Thomas Wuensche
Hi Free Netters,

I just joined this list, so if the issue has been discussed
before please point me to the right location. Search of the
archive did not give me the required results.

I tend to believe that information in freenet is available
which I can not find reliably. While I can not prove that,
the behaviour in extracting information seems to indicate
it. Sometimes information drops in after repeating requests
for days. I am running a permanent node with a large data-
store, so I should have good prerequisites regarding rou-
ting.

What I found in the freenet configuration file is the
entry maxHopsToLive, which seems to have a default value
of 25 and is described to limit the HTL value of requests
passing a node. If this limit is active it would mean that
using a HTL value beyond that limit will be of no help,
since most likely the majority of users do not change that
default and the HTL will be limited at the first node the
request hits. Is that assumption correct?

I do not really understand why this value is introduced
and used. There is the risk that information available
can not be found, right? And I understand that circular
requests are terminated anyhow, right?

Please enlighten me, whether my assumptions are comple-
tely wrong, whether they are right but default is enough
to search a whole universe full of freenet nodes or whe-
ther the default should be changed. Are there other means
to increase the probability to find information in freenet?

Best regards,

Thomas


___
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support



Re: [freenet-support] maxHopsToLive in Freenet configuration file

2002-12-09 Thread Thomas Wuensche
Matthew,

Thanks for your fast and precise answer. I have removed all text
where I think it does not need more discussion. The following
points remain:

Snip


I do not really understand why this value is introduced
and used. There is the risk that information available
can not be found, right? And I understand that circular
requests are terminated anyhow, right?


Because we want to be able to limit the length of time and the amount of
network resources that a request takes. A request only goes to a certain
number of nodes, the hops-to-live. This means that unlike gnutella,
freenet should be able to scale as a single contiguous network, and an
attacker who just sends zillions of requests only gets (max HTL) *
(number of requests) load/bandwidth for his money, rather than (max HTL)
* (number of nodes).


Oh, agreed, protecting freenet against attackers definitely
is worth that considerations. However with a growing net the
percentual reach of a search is getting smaller. A net which
is willing to give only a fraction of the information it holds
to somebody searching for the information of course is also of
limited value. The problem specially is that information that
is new or rarely requested does propagate badly. From the view
of a node searching for the information it may become available
only after somebody in between has also requested it. The only
chance besides that might be a shifted search horizon of the
requester. Is there a chance that my node gets to know more
nodes out there in the freenet universe and to ask them in an
arbitrary sequence? Or is there another chance to find infor-
mation which is beyond my search range (as seen at a single
point in time)? This would at least help me to find the infor-
mation, even if it costs me more bandwidth. Repeatedly asking
the nodes that did not know it before in the hope they might
know it in the future will also significantly increase network
load, but with less probability of success for the regular
user.


Please enlighten me, whether my assumptions are comple-
tely wrong, whether they are right but default is enough
to search a whole universe full of freenet nodes or whe-
ther the default should be changed. Are there other means
to increase the probability to find information in freenet?


We may want to increase the default maximum HTL in 0.5.1, however there 
are lots of nodes left over from 0.5.0 and its immediate successors,
which would tend to prevent this, short of forking the network...

This would be welcome, please increase it to a value that
holds some margin for future growth. The impact of infor-
mation that is not delivered may be bigger than the impact
of an overload attack. The impact of an overload attack might
also be limited by limiting the bandwidth a node is willing to
provide to a single requester, would that be reasonable?

With regard to new versions, wouldn't it help if a certain
percentage of the nodes had higher limits? These would pro-
vide paths of deeper information flow into the network, even
if other paths stay shallow.

And of course it could easily be improved without a version
change, if people would change it manually. Is there a promi-
nent place where that could be published?

Best regards,


Thomas


___
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support