Dear Joseph, thanks for your suggestion, using cgroups is probably a better option than using --uid-owner. Still I'll have to setup a rule for each user, but I'm coming to the conclusion that I can't avoid that. Paride On Sun, Dec 22, 2013 at 07:00:34PM +0100, Joseph Santaniello wrote: > 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 -- 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
