You might have a look at cgroups and net_cls to set classid for all the processes a user owns/starts and then make a tc filter that matches the classid and sends the traffic to a suitable class with the type of sharing/limiting you wish. Joseph On Sun, Dec 22, 2013 at 6:10 PM, Paride Legovini <pl@xxxxxxxxxxxxxx> wrote: > Dear all, > > I'm working in an Antarctic research station where our connection to the > Internet is a 512kbps satellite link. > > I want to set up a server where each research project has an account > where they send data via sftp or rsync; this data is then transferred > overnight to a server in Europe. My idea is to use a separate cronjob > or daemon for each user that runs with the user's privileges. > > What I want to do is: > > 1. Limit the total bandwidth that a group (GID) can generate. There > should be separate limits for inbound and outbound traffic. > > 2. Limit the bandwidth per-user (UID), so if the GID is allowed to > generate 384kbps of traffic, and 3 users are using the network, each > user can at most benefit of 128kbps. If there's only one user he gets > all the 384kbps. > Again there should be different limits for inbound and outbound > traffic. > This should work regardless the number of connections the user makes. > > I played a bit with iptables and tc, but the only way I found to do > something like this is to manually set a different mark for each user > and then use tc, but I'd prefer a solution where there's no need to set > up any rule manually if a user is added or removed. Also, the > --uid-owner option works only for outbound traffic. > > Do you have any suggestion? > I think that you understood the problem, so even if a different approach > comes to your mind please let me know. > > Thank you, > > PL > > -- > To unsubscribe from this list: send the line "unsubscribe lartc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html