Ok ... So ... --connection-limit-per-user=0 means unlimited connections
when no connection quota is in ACLs ... But with a single change on a
different place (ACL file) it suddenly means the complete oposite ...
Correct?

I can live with it ... But it isn't exactly "user friendly" ...

Regards
Jakub
Dne 9. 8. 2013 19:11 "Chuck Rolke" <cro...@redhat.com> napsal(a):

> Hi Jakub,
>
> The doc tries to explain:
>   "Per-user connection quotas are disabled when two conditions are true:
> 1) No --connection-limit-per-user command line switch and 2) No quota
> connections rules in the ACL file."
>
> If your command line specified zero and you had no ACL settings then the
> zero would mean unlimited.
> With the ACL settings specified then quotas are enabled and zero means no
> connection allowed.
>
> To get your case to work you could use a setting like:
>
>  quota connections 10 user1@QPID0000
>  quota connections 1000 all
>  quota queues 5 user2@QPID0000
>  quota queues 10000 all
>
> which provide the unlimited flavor you are seeking. The specific rule for
> 10 connections for user1 will be applied and user1 will not get the 1000
> connections specified for everyone else.
>
> Note that in 0.24 the ACL module is no longer loadable but is built in.
> Connection counting behavior did not change and the enforcement behavior
> described above did not change.
>
> -Chuck
>
>
> ----- Original Message -----
> > From: "Jakub Scholz" <ja...@scholz.cz>
> > To: users@qpid.apache.org
> > Sent: Friday, August 9, 2013 9:40:09 AM
> > Subject: Re: ACL quotas have to be used for all members or not at all
> >
> > Hi Chuck,
> >
> > I see following situations (0.24 RC1), where the second doesn't work.
> >
> > a)
> > - Configuration:
> >
> > I use only the command line options (which are supposed to mean
> > "unlimited"):
> > connection-limit-per-user=0
> > connection-limit-per-ip=0
> > max-queues-per-user=0
> >
> > - Expected result:
> > I can create unlimited connections and queues
> >
> > - Actual result:
> > Works as expected
> >
> > b)
> > - Configuration:
> >
> > I use these command line options:
> > connection-limit-per-user=0
> > connection-limit-per-ip=0
> > max-queues-per-user=0
> >
> > And these ACL rules:
> > quota connections 10 user1@QPID0000
> > quota queues 5 user2@QPID0000
> >
> > - Expected result:
> > User1 can open only 10 connections and create 5 queues. For other user -
> > because there is no ACL rule for all - the command line option should
> apply
> > as per the first point in chapter 15.3.2 from the docu (which is 0 =>
> > unlimited).
> >
> > - Actual result:
> > Connection with user2 cannot be opened because of the connection limit
> set
> > to 0
> >
> > Perhaps it has something to do with the fact that "0" in command line
> means
> > unlimited, but in ACL it means denied?
> >
> > Thanks & Regards
> > Jakub
> >
> >
> >
> >
> >
> > On Fri, Aug 9, 2013 at 3:10 PM, Chuck Rolke <cro...@redhat.com> wrote:
> >
> > > Hi Jakub,
> > >
> > > Referring to
> > >
> http://qpid.apache.org/releases/qpid-0.22/cpp-broker/book/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Authorization-Specifying_ACL_Quotas
> .
> > > This document describes how the quotas work and some more subtle issues
> > > that arise when an ACL file is reloaded.
> > >
> > > You can set a quota value for "otherwise unnamed users" by using the
> > > keyword 'all':
> > >
> > >    quota connections 10 user1@QPID0000
> > >    quota connections 20 all
> > >
> > > Note that the ACL file 'quota connections X all' serves the same
> function
> > > as the command line option '--connection-limit-per-user N'. The ACL
> file
> > > value will overwrite the command line option value.
> > >
> > > Regards,
> > > Chuck
> > >
> > > ----- Original Message -----
> > > > From: "Jakub Scholz" <ja...@scholz.cz>
> > > > To: users@qpid.apache.org
> > > > Sent: Friday, August 9, 2013 8:36:13 AM
> > > > Subject: ACL quotas have to be used for all members or not at all
> > > >
> > > > Hi,
> > > >
> > > > I played a bit with the quotas for connections and queues in the ACL
> > > files.
> > > > It seems, that when I configure a quota for one user, the broker
> > > > automatically adds a quotas for all other users which are set to 0.
> > > >
> > > > For example, after adding the rule with connection quota for user1:
> > > >
> > > > quota connections 10 user1@QPID0000
> > > >
> > > > I can't connect with user2:
> > > >
> > > > 2013-08-09 12:23:39 [Network] info Set TCP_NODELAY on connection to
> > > > 127.0.0.1:49366
> > > > 2013-08-09 12:23:39 [Broker] info Using AMQP 1.0 (with SASL layer)
> > > > 2013-08-09 12:23:39 [Model] trace Mgmt create connection.
> > > > id:qpid.127.0.0.1:20000-127.0.0.1:49366
> > > > 2013-08-09 12:23:39 [Security] info SASL: Mechanism list: PLAIN
> > > > 2013-08-09 12:23:39 [Security] info SASL: Starting authentication
> with
> > > > mechanism: PLAIN
> > > > 2013-08-09 12:23:39 [Security] error Client max per-user connection
> count
> > > > limit of 0 exceeded by 'qpid.127.0.0.1:20000-127.0.0.1:49366', user:
> > > > 'user2@QPID0000'. Connection refused.
> > > > 2013-08-09 12:23:39 [System] error User connection denied by
> configured
> > > > limit
> > > > 2013-08-09 12:23:39 [Security] info
> qpid.127.0.0.1:20000-127.0.0.1:49366
> > > > Connection closed prior to authentication completing
> > > > 2013-08-09 12:23:39 [Model] debug Delete connection.
> > > > user:user1@QPID0000rhost:qpid.127.0.0.1:20000-127.0.0.1:49366
> > > >
> > > > The same seems to apply to the queue quotas.
> > > >
> > > > Is that the expected behavior? If yes, I do not really mind, since
> on my
> > > > brokers I anyway plan to have the quotas for every user. But it is
> not
> > > > exactly what I would expect.
> > > >
> > > > Thanks & Regards
> > > > Jakub
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Reply via email to