Running gtk-gnutella as root
 

Im getting sick of people that make linux programs telling me that I cant run it as root. If my box gets owned then its my problem, not anybody elses. I just compiled the latest version from rpm on redhat 9 and was rather annoyed to
find that it won't let me run as root. Is there a way to prevent it from doing this?
(Aside from running as normal user. I don't even have a normal user account on my box and I don't intend to create one just for this.

Although it is generally a bad idea to run as root, an application should *never* make that choice for the user. At most, any application should pop up a dialog or print out a short explanation like:

"Programs should not generally be run as the root user. Doing so puts your
computer at a greater risk with respect to security and could allow a
malicious user to do "bad" things to your computer."

Quoting Kirk Strauser on the gtkg-users mailing list:

RPM packages are not GPG signed
 

http://sourceforge.net/project/showf...?group_id=4467

So, whoever packages them, could GPG sign the rpm packages.

Currently a man in the middle can switch on the fly the packages being downloaded from mirrors and noone would notice.

http://www.rpm.org/max-rpm/s1-rpm-pg...-packages.html<http://www.rpm.org/max-rpm/s1-rpm-pg...-packages.html

To the main topic, I think it is sometimes good to protect "stupid" users for not running some program, especially p2p, as root.

Also while am at this.
CVS version currently seems to report a version of the servant just with "0.92u". Maybe somehow there should/could be a date of the latest changes in the version string.

I don't know, but seems like at least v0.92b and also 0.92c ultrapeers do not like to connect with v0.92u. (all gtk-gnutellas)

Re: RPM packages are not GPG signed
 

Huh? In the User-Agent headers etc. the compile/release date is announced.

I think you are seeing the automatic banning of unstable versions (= the old betas) that are older than 90 days, could that be ?

Re: Re: RPM packages are not GPG signed
 

Hmm..maybe.
Well anyway, I used to have ultrapeer connections to other gtk-gnutellas and finding stable ultrapeer connections was easier then. Now after I started using CVS version, I never seem to have any other gtk-gnutella servants as ultrapeers or leaves. Also the gnet connections seem to be rather short living. What I have noticed, the reason for BYE is very often "activity timeout"

But ofcourse, it could be, that before when I was using 0.92b, many other gnutella clients rejected as it being "harmfull", and therefore it only could connect to other gtk-gnutella 0.92b's.
http://gtk-gnutella.sourceforge.net/...page=faq#gnet5

I have IP TOS enabled, compression connections preferred, "try to keep at least 4 ultrapeer connections", so maybe I try to fiddle with those to get abit more long lasting gnet connections. Right now it is constantly trying to connect to new ultrapeers, as it cannot keep connections up to at least 4 ultrapeer but only few tens of seconds.

(And yes, I do know I am running an unstable CVS version, so some experimental behaviour can be expected.)

btw, Would be usefull, to see
http://gtk-gnutella.sourceforge.net/...page=faq#gnet4
(explanations of the flags) in that yellow hint box, when mouse pointer is over the header of the Flags column in gnutellaNet-connections subwindow. After time I am sure I'll know the flags by heart, but it's still so compacted information packet that a hint box with explanations would be a cool thing.

Re: Re: Re: RPM packages are not GPG signed
 

Hello zimon,

Hummmm... how is your bandwidth usage? Could it be that your upload bandwidth capacity is satturated and therefore possibly gnet connections timeout?

bye
Markus Goetz

gtk-gnutella ultra peers not communicating.
 

I also had the experiance that gtk-gnutella ultra peers were not communicating. I ran a .92c ultra peer for almost 3 days straight earlier this week. I had solid connections to other gtk-gnutella clients with them as leaves. In fact, the gtk-gnutella leaf clients were the ones that generally stayed connected for at least a day. (With the exception of one oddball Swapper.NET fella that stayed with me for 2 or 3 days.) During this whole time though, I never got a connection to another gtk-gnutella ultrapeer. I had on compressed connection preference, so I was limited almost exclusively to LimeWire ultrapeers. And limewire might be nice, but I couldn't hold a connection to them over a few hours.

I had a huge number of shareaza leaves. On the other hand, I never connected once to a shareaza ultra peer. Do they only accept g2 ultrapeers or something?

So is there some glitch where gtk-gnutella ultrapeers don't see each other, or are there just that few of us out there?

Later,

Isamoor

P.S. I did have .92u connections as leaves. .92b got booted off of me though, saying it was outdated. Is there any log file I could give you to help you out?

Never mind...
 

Never mind about that shareaza ultrapeer question. I asked around elsewhere and found out what was going on. I realize now that gtkg intentionally doesn't connect to shareaza hubs. I feel a little ridiculus now.

That doesn't explain why I couldn't find any other gktg ultrapeers though...

Are there just none of them out there?

Later,

Isamoor

lol
 

nice copy and paste guruz!.............lol you lamazoid.

And I figure since I got more than one box here Ill just settle for kazaa lite on a windoze box.

RE: Running gtk-gnutella as root
 

That's absurd. Consider this scenario. So your root, someone gets into your box. You have sendmail installed. Dude ques up several hundred thousand emails. Suddenly your ISP turns off your connection. I get spammed , your ISP's IP block is blacklisted..... how is that only your problem. Format and install windows , such a lack of responsibility with technology doesn't deserve the power tools that *NIX offers.