[
https://issues.apache.org/jira/browse/ARTEMIS-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484295#comment-17484295
]
Justin Bertram edited comment on ARTEMIS-3661 at 1/30/22, 3:31 AM:
-------------------------------------------------------------------
I wouldn't expect your command using {{--url tcp://localhost:61618}} to
actually work because the {{acceptor}} listening on {{61618}} is using SSL and
you didn't configure the command's url to use SSL.
----
bq. It looks when I run the below command without specifying the properties, by
default it picks up Connection brokerURL = tcp://localhost:61618.
Any command that can take {{--url}} by default will try to use the info from
the {{acceptor}} named _artemis_ in the local instance's {{broker.xml}}. This
is noted in the "help" for the command.
----
bq. Please confirm, This user is suppose to be created at the cluster level.
No users are created "at the cluster level." They are created on individual
servers. In fact, a centralized user repository (e.g. LDAP) is recommended when
running in a cluster so that only one update needs to be made to change user
info. If you use properties files on each broker of the cluster then _every
single_ broker will need to be updated when you want to add, remove, or update
a user. I expect it would be very difficult to keep all the data in sync with
such a configuration. [The
documentation|https://activemq.apache.org/components/artemis/documentation/latest/security.html#propertiesloginmodule]
has a general warning about this which states (in part):
bq. In general, using properties files and broker-centric user management for
anything other than very basic use-cases is not recommended. The broker is
designed to deal with messages. It's not in the business of managing users,
although that functionality is provided at a limited level for convenience.
LDAP is recommended for enterprise level production use-cases.
----
bq. Also, in previous versions we did not have to specify the --url property or
have the broker in running state prior to user creation. It looks to be
mandatory in 2.18.
This behavior changed in 2.16.0. This is noted in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html#2160].
I recommend you read the documentation for additional details.
was (Author: jbertram):
I wouldn't expect your command using {{--url tcp://localhost:61618}} to
actually work because the {{acceptor}} listening on {{61618}} is using SSL and
you didn't configure the command's url to use SSL.
bq. It looks when I run the below command without specifying the properties, by
default it picks up Connection brokerURL = tcp://localhost:61618.
Any command that can take {{--url}} by default will try to use the info from
the {{acceptor}} named _artemis_ in the local instance's {{broker.xml}}. This
is noted in the "help" for the command.
bq. Please confirm, This user is suppose to be created at the cluster level.
No users are created "at the cluster level." They are created on individual
servers. In fact, a centralized user repository (e.g. LDAP) is recommended when
running in a cluster so that only one update needs to be made to change user
info. If you use properties files on each broker of the cluster then _every
single_ broker will need to be updated when you want to add, remove, or update
a user. I expect it would be very difficult to keep all the data in sync with
such a configuration. [The
documentation|https://activemq.apache.org/components/artemis/documentation/latest/security.html#propertiesloginmodule]
has a general warning about this which states (in part):
bq. In general, using properties files and broker-centric user management for
anything other than very basic use-cases is not recommended. The broker is
designed to deal with messages. It's not in the business of managing users,
although that functionality is provided at a limited level for convenience.
LDAP is recommended for enterprise level production use-cases.
bq. Also, in previous versions we did not have to specify the --url property or
have the broker in running state prior to user creation. It looks to be
mandatory in 2.18.
This behavior changed in 2.16.0. This is noted in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/versions.html#2160].
I recommend you read the documentation for additional details.
> Receiving timed out while creating user in artemis 2.18
> --------------------------------------------------------
>
> Key: ARTEMIS-3661
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3661
> Project: ActiveMQ Artemis
> Issue Type: Task
> Components: Broker
> Affects Versions: 2.18.0
> Reporter: Ekta
> Priority: Major
>
> I am facing time out issues while I am running the below command from my
> broker which is currently running on 2.18. I have made some changes to the
> command since the old command does not work on newer version.
> Is there anything I am doing wrong here. My broker is up and running while I
> am executing the below command. This command use to work just fine in old
> versions.
> Command:
> {noformat}
> ./artemis user add --user-command-user test --user-command-password test1234
> --role test --url tcp://localhost:61618{noformat}
> Error:
> {noformat}
> Exception in thread "main"
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT
> message=AMQ219013: Timed out waiting to receive cluster topology. Group:null]
> at
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:743)
> at
> org.apache.activemq.artemis.cli.commands.AbstractAction.performCoreManagement(AbstractAction.java:35)
> at
> org.apache.activemq.artemis.cli.commands.user.AddUser.add(AddUser.java:52)
> at
> org.apache.activemq.artemis.cli.commands.user.AddUser.execute(AddUser.java:42)
> at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:155)
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:103)
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:134)
> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:50){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
