Deluge
Multiuser configuration
-
kinda cute
- Member
- Posts: 20
- Joined: Wed Dec 23, 2009 5:41 pm
Multiuser configuration
Is it possible to implement in Deluge multi user configuration. I see it is so. Each user has it is own account (pair of login and password and commit directory). Each user must see only his own downloads. Administrator must see downloads of all users. Also administrator should have possibility to manage all downloads of each user. After download of finished it must be committed to the folder of owner of this download. In future if you like this idea, we can group users. It is very intresting implementation for ISPs.
Re: Multiuser configuration
Currently you can authenticate as different users and different levels however they don't do much.
Having a proper multiuser system (as you've described) is planned for some time in the future.
Having a proper multiuser system (as you've described) is planned for some time in the future.
-
kinda cute
- Member
- Posts: 20
- Joined: Wed Dec 23, 2009 5:41 pm
Re: Multiuser configuration
Good news. Thanks
-
kinda cute
- Member
- Posts: 20
- Joined: Wed Dec 23, 2009 5:41 pm
Re: Multiuser configuration
Any updates with this features? maybe i should create a feature request?
Re: Multiuser configuration
No work's been done on it yet 
Probably a good idea to create a feature request.
Probably a good idea to create a feature request.
-
kinda cute
- Member
- Posts: 20
- Joined: Wed Dec 23, 2009 5:41 pm
Re: Multiuser configuration
Can you please give me a link where i can post a FR?
Re: Multiuser configuration
You create a new ticket: http://dev.deluge-torrent.org/newticket
and then specify that the ticket is a feature-request
You'll need to register to create a ticket: http://dev.deluge-torrent.org/register
and then specify that the ticket is a feature-request
You'll need to register to create a ticket: http://dev.deluge-torrent.org/register
-
gbear14275
- New User
- Posts: 8
- Joined: Sat Jul 10, 2010 7:37 pm
Re: Multiuser configuration
If anyone else would be willing to put their money where their mouth is I will match funds on this up to $500 US for this feature request.
Details of the goal should probably be hashed out in more detail but in general I would like to see the ability to assign users to groups and then make torrents viewable by groups. Look at the ticket number 1271 for more details: http://dev.deluge-torrent.org/ticket/1271
Details of the goal should probably be hashed out in more detail but in general I would like to see the ability to assign users to groups and then make torrents viewable by groups. Look at the ticket number 1271 for more details: http://dev.deluge-torrent.org/ticket/1271
-
gbear14275
- New User
- Posts: 8
- Joined: Sat Jul 10, 2010 7:37 pm
Re: Multiuser configuration
I'm going to just start brainstorming thoughts for multi-user functionality. I apologize if it comes across as nonsensical.
resource optimization and connection options: A single Daemon should be able to support a variety of users interfacing with it in different ways. Most commonly this would be a web interface and so perhaps this functionality should be implemented first. Web Users should NOT be able to kill the daemon although restarting it may be desirable (in case of malfunctions). Enabling a user to log into the daemon through SSH (or some other non web protocol) might also be desirable. Perhaps being able to establish an SSH connection with a headless machine and then enabling the GTK client to communicate with the daemon in this way. This may also require a GTK interface to be able to communicate with multiple Daemons (list?). The idea behind this being that multiple users would not have to launch concurrent daemons and therefor would minimize duplicate resource usage.
Bandwidth Allocation: Administrators should be able to set bandwidth allocations to each user as either an absolute value or as a share of available. e.g. The machine has a 100mbit connection. I want to cap each user to have no more than 50mbit ever (absolute speed limit) but I also want each of up to 5 possible concurrent users to be able to have equal share of the connection for their activities. e.g. While 1 user is logged in 100mbit is available for use but his absolute speed limit is capped at 50mbit. Later 3 users initiate torrents and each is set to have equal amounts. Therefor the 100mbit is divided by 3 to give each equal portions of the available bandwidth. I guess this would be a form of QOS...
Advanced Bandwidth/ratio allocation: Users would accrue bandwidth at a fixed rate. As a user either downloaded or uploaded files this bandwidth would be "used" (but should be configurable to count upload/download individually). When bandwidth becomes limited, user allocation would be determined by a ratio of your accrued balance of bandwidth and compared to others. So for a user who has banked 100MB of bandwidth their connection might be 10x faster than the user who only has 10MB saved. (this ratio/value should be administer configurable).
Sharing: Users should be able to "share" their activity with other specified users on a per torrent basis. For example: I share a file server with X, Y and Z. I want to be able to share with X and Y that I have downloaded a file they would be interested in but do not want to share it with Z. On another torrent I decide that I want to share it with Z alone. This determination should be done at torrent initiation so that users can see files in progress. Torrents should also be sharable after the fact. "Shared" torrents should have control of the torrent given to a group. When a user "deletes" a shared torrent they may simply be taken out of the ownership group of that torrent.
Thats all I got for now. probably be back later with more.
resource optimization and connection options: A single Daemon should be able to support a variety of users interfacing with it in different ways. Most commonly this would be a web interface and so perhaps this functionality should be implemented first. Web Users should NOT be able to kill the daemon although restarting it may be desirable (in case of malfunctions). Enabling a user to log into the daemon through SSH (or some other non web protocol) might also be desirable. Perhaps being able to establish an SSH connection with a headless machine and then enabling the GTK client to communicate with the daemon in this way. This may also require a GTK interface to be able to communicate with multiple Daemons (list?). The idea behind this being that multiple users would not have to launch concurrent daemons and therefor would minimize duplicate resource usage.
Bandwidth Allocation: Administrators should be able to set bandwidth allocations to each user as either an absolute value or as a share of available. e.g. The machine has a 100mbit connection. I want to cap each user to have no more than 50mbit ever (absolute speed limit) but I also want each of up to 5 possible concurrent users to be able to have equal share of the connection for their activities. e.g. While 1 user is logged in 100mbit is available for use but his absolute speed limit is capped at 50mbit. Later 3 users initiate torrents and each is set to have equal amounts. Therefor the 100mbit is divided by 3 to give each equal portions of the available bandwidth. I guess this would be a form of QOS...
Advanced Bandwidth/ratio allocation: Users would accrue bandwidth at a fixed rate. As a user either downloaded or uploaded files this bandwidth would be "used" (but should be configurable to count upload/download individually). When bandwidth becomes limited, user allocation would be determined by a ratio of your accrued balance of bandwidth and compared to others. So for a user who has banked 100MB of bandwidth their connection might be 10x faster than the user who only has 10MB saved. (this ratio/value should be administer configurable).
Sharing: Users should be able to "share" their activity with other specified users on a per torrent basis. For example: I share a file server with X, Y and Z. I want to be able to share with X and Y that I have downloaded a file they would be interested in but do not want to share it with Z. On another torrent I decide that I want to share it with Z alone. This determination should be done at torrent initiation so that users can see files in progress. Torrents should also be sharable after the fact. "Shared" torrents should have control of the torrent given to a group. When a user "deletes" a shared torrent they may simply be taken out of the ownership group of that torrent.
Thats all I got for now. probably be back later with more.