Re: Limit bandwidth per-user (uid/gid)

[Paride Legovini <pl@ninthfloor.org>]

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@ninthfloor.org> 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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html