When I was starting Wildfly 10 with full-ha profile, I was getting below error in the log file.
AMQ119099: Unable to authenticate cluster user: ACTIVEMQ.CLUSTER.ADMIN.USER
Even after this error, server was in running state.
I was getting this error because I have not changed the default password of subsystem messaging-activemq.
This error is gone after changing below line of domain.xml
<cluster password="${jboss.messaging.cluster.password:CHANGE ME!!}"/>
to
<cluster password="${jboss.messaging.cluster.password:mypass}"/>
It's required to specify a password for the cluster of messaging-activemq subsystem. It can be set using the following system property when starting the wildfly server:
... -Djboss.messaging.cluster.password=Abcd1234
Related
I am not able to connect with snowsql by Windows console:
<!-- language: lang-html -->
C:\Users\musik>snowsql -a [myAccount] -u [myUserName]<br>
Installing version: 1.2.0 [####################################] 100%<br>
Password:<br>
<!-- end snippet -->
I get this error message:
250001 (08001): Failed to connect to DB. Verify the account name is correct: [myAccount].snowflakecomputing.com:443. HTTP 403: Forbidden
If the error message is unclear, enable logging using -o log_level=DEBUG and see the log to find out the cause. Contact support for further help.
Goodbye!
Screenshot
Then I used -o log_level=DEBUG. In the log file I can see that I am getting a "forbidden" error:
2019-12-05 16:45:16,510 (6472/MainThread) snowflake.connector.network DEBUG network:822 - HTTP 403: Forbidden. Retrying...
What can I do? Has somebody the same issue?
From my comment earlier: Be sure to include the region and such in your account. It should include everything up to the snowflakecomputing.com in the URL that you use to access Snowflake through the UI.
Please use below command:
snowflake URL : https://abc.snowflakecomputing.com
Account_name : abc
User_name : Give fully qualified user name
snowsql -a <account_name> -u <user_name>
Note: Prior to this ensure you are able to login with user name and password using snowflake Web UI.
I'm trying to connect to MongoDB in a IBMCloud instance and I'm using MongoID. I ever use some configurations and try very things. I'm getting the error:
MONGODB | Error running ismaster on address:port: system lib
Here is my mongoid.yml that I'm trying to connect to mongoDB:
development:
clients:
default:
database: databasename
hosts:
- address:port
- address:port
options:
user: 'admin'
password: 'some-password'
auth_mech: :scram
auth_source: admin
connect: :replica_set
replica_set: replset
ssl: true
ssl_ca_cert: ./some-certificate.pem
ssl_verify: true
options:
log_level: :debug
What do I need to add to connect with the mongo database in IBMCloud?
"system lib" is coming from OpenSSL and indicates a problem with the CA certificate, such as the path not referring to an existing file. Note that in the configuration you specified a relative path which could cause problems.
I created https://jira.mongodb.org/browse/RUBY-1946 to add the exception class to the reported message which would clarify where the error is originating in the future.
Upgrade to the current version of Ruby driver (2.10.2 as of this writing) which provides more extensive diagnostics. Set driver log level to debug (https://docs.mongodb.com/mongoid/master/tutorials/mongoid-configuration/#logging). If you are having trouble identifying the problem then, post the
updated error and log messages here.
I'm trying to setup an instance on my phoenix app. I'm actually able to generate the app but I'm getting an error when trying to connect to the DB:
ERROR:
21:11:31.017 [error] Postgrex.Protocol (#PID<0.2223.0>) failed to connect: ** (DBConnection.ConnectionError) tcp connect (/tmp/cloudsql/statcasters:us-central1:statcastersdb): no such file or directory - :enoent
I'm not sure what is wrong? The file seems to exist but it seems to say it doesn't:
prod.secret.exs:
config :statcasters, Statcasters.Repo,
username: "postgres",
password: System.get_env("DATABASE_PASSWORD"),
database: "statcasters_prod",
socket: "/tmp/cloudsql/statcasters:us-central1:statcastersdb",
pool_size: 20
I'm not sure what more information I can give? Does anybody know what I could be missing here?
There are 2 flavors of App Engine so please see the instructions linked here: https://cloud.google.com/sql/docs/postgres/connect-app-engine
The socket name appears to include a redundant "/tmp" prefix and should start with "/cloudsql/..." for App Engine standard.
I have installed the Shibboleth SP[2.5.6 latest] in my Windows Server R 2012.I followed the links :
Shibboleth Installation
I verified the installation and ran this sitelink -https://localhost/Shibboleth.sso/Status
It throws ERROR.
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
This error is due to, the default site with id '1' may be in stopped state. Restart the default site and check.
I am trying to configure the Sonar with windows Active directory. I am getting the below error.
ERROR [rails] Error from external users provider: Unable to retrieve details for user xxx.xxx in
The below configurations are done in sonar.property file
# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.authentication: simple
sonar.security.savePassword=true
sonar.authenticator.createUsers=true
ldap.url=ldap://xxxx.group.root.ad
# User Configuration
ldap.user.baseDn=OU=Users,OU=Customs,OU=Group,dc=group,dc=root,dc=ad
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
# Group Configuration
ldap.group.baseDn=OU=Customs,OU=Group,dc=group,dc=root,dc=ad
#ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.group.request=((objectClass=group)(member={dn}))
anybody have an idea to fix the issue in sonar.
Regards
Arun.
I had similar issue with LDAP 2.1 on SonarQube 5.6 (LTS)
tl'dr
This format of ldap.user.request worked for me -
ldap.user.request=(uid={login})
If you are still reading ...
Here are some things that helped me resolving the issue
sonar.log :
Turn the DEBUG ON and look for the actual ldap search query thats getting build and the ldap context.
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=dc=test,dc=com, scope=subtree, request=(&(objectClass=inetOrgPerson)(uid={0})), parameters=[harvey], attributes=[mail, cn]}
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap.test.com, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.security.principal=uid=user,ou=People,dc=test,dc=com, com.sun.jndi.ldap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
ldapsearch :
Run lapsearch command with same parameters from the logs (step #1)
$ldapsearch -x -L -D"uid=user,ou=People,dc=test,dc=com" -w"pass" -b"ou=People,dc=test,dc=com" "(uid=harvey)" mail cn
sonar.properties -
here is my working LDAP configuration
#General Configuration
sonar.security.realm=LDAP
ldap.url=ldaps://ldap.test.com
ldap.bindDn=uid=user,ou=People,dc=test,dc=com
ldap.bindPassword=pass
#User Configuration
ldap.user.baseDn=ou=People,dc=test,dc=com
ldap.user.request=(uid={login})
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
#Group Configuration
ldap.group.baseDn=ou=Group,dc=test,dc=com
ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.user.request & ldap.group.request
From the step #1 you could find out whats the correct format for query filter parameter in your case and values for bindDn (-D) and baseDn _-b)
Hope this helps =)
Thanks!
I've just encountered a similar error in Sonar 5.1.1. Here's how I solved it:
The Base DN is incorrect for use with an AD server. This worked for me:
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
Anonymous authentication to an AD server apparently doesn't work with Sonar's LDAP plugin (this assumption is supported by the documentation which specifies anonymous authentication against an AD server as "untested"). You'll need to specify a Bind DN (here meaning a user) for connecting with the AD server:
ldap.bindDn=<user>#<domain>
ldap.bindPassword=secret