It'd be really to put include a script with the ebuild. Here's one I made, but I'm sure it has flaws somewhere. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 14491 [details] rc/init script for giFT.
Created attachment 14492 [details] rc/init script for giFT.
Created attachment 14493 [details] rc/init script for giFT
Sorry about the triple post, I was getting a bugzilla error after posting it and I thought it wasn't getting through so I tried a couple more times :(
I'll take a look at this soon, but I think it is more apropriate for giFT to be run by the specific user account who will be using it... **shrug**
I got giFT running once (should have not emerge on top of it, now it segfault) and here is one way I think it could be setup. I think the philosophy intended behind giFT (for now) is to have a central repository for all files downloaded. That's how I would set it up. So you create a sharable folder for the giFT daemon and each users connect to it with its client. Once the file is downloaded, they can either leave it there or grab the copy to put somewhere else. The advantage of this is that combined with samba to create a smb share for the folder, Windows clients of giFT can connect to that share also. Having a big network with lots of clients, I guess this setup could optimise the bandwidth by preventing multiple doanloads of the same file. I don't know what's in the head of the giFT guys, but I think they too have not commited the way they intend it to be setup. It's still relatively in an early development stage. My 2
I got giFT running once (should have not emerge on top of it, now it segfault) and here is one way I think it could be setup. I think the philosophy intended behind giFT (for now) is to have a central repository for all files downloaded. That's how I would set it up. So you create a sharable folder for the giFT daemon and each users connect to it with its client. Once the file is downloaded, they can either leave it there or grab the copy to put somewhere else. The advantage of this is that combined with samba to create a smb share for the folder, Windows clients of giFT can connect to that share also. Having a big network with lots of clients, I guess this setup could optimise the bandwidth by preventing multiple doanloads of the same file. I don't know what's in the head of the giFT guys, but I think they too have not commited the way they intend it to be setup. It's still relatively in an early development stage. My 2¢
I don't think we should add an rc-script. P2P protocols present a hudge security whole in the system (IMHO) and it is not a good idea to run it at boot time, rather the user should run it whenether it's required. Again this is IMHO only, and not being a security excpert I might be wrong. If so, correct me.
Passing this off to martin as I don't have time to play with it...
I really only see this opening possible security problems. I see no problem in relying on the user to start the daemon. Also, most clients now start the server automagically for you. Is there an argument in support of the init script other than "the user may have a central repository of files to share"? Again, this can be set up by the user if he/she so desires.
I never really though of the security issues when I made the script, I was just looking for an easy way to start/stop the deamon. How about an conf.d/giFT file where you could set RUNASUSER=, or some such? I know that start-stop-daemon support running things as a different user.
Also useful to start at boot with everything else if the person is running as a SEARCH or INDEX node only.
Please try gift-0.11.6-r1 Note that custom configuration is REQUIRED and this method is only suggested for people who have a central giftd on a home network, etc.
I think you'll want the /usr/share/gift dir to be owned by p2p so that it can be written to.
