RabbitMQ on Openstack Juno - rabbitmq

I am installing Openstack Juno on Fedora 19. I have deleted RabbitMQ default user "guest" and create a new user named "demo". And in all nova.conf I config rabbit_userid=demo. But connected to localhost:5672 failed. From the rabbitmq log, RabbitMQ still use default user "guest" to connect.I tried to set default_user "demo" in rabbitmq.conf but it doesn't work.Why and how to resolve?
Following is the error log:
{handshake_error,starting,0,{amqp_error,access_refused, "AMQPLAIN login refused: user 'guest'- invalid credentials",'connection.start_ok'}}`
The content in rabbitmq.conf:
[ {rabbit, [{default_pass, [<<"demo">>]}], [{default_user, [<<"demo">>]}]} ].

You need to set the user and password on your application AMQP Client. RabbitMQ default user has nothing to do with that. So if you want to use user demo and password demo, then when you open a connection on the application side, you have to use those credentials

Related

Problem authentication for the first time to Zeppelin Server web UI

I already installed Cloudera manager. After that, I add Zeppelin service and I start it.
I want to launch the Zeppelin Server Web UI and to authenticate with user=admin and password=admin but I didn't succeed. Error message: "The username and password that you entered don't match."
have you any idea please to unblock the situation?
Thanks.

Why the Weblogic console cannot be accessed by using port 80?

After installing patch 10.3.6.0.200114, Weblogic console could not log in, indicating "WebLogic Server has rejected this user name or password. Please try again. " However, the service can be accessed normally
There is a bug in this PSU which prevent web app like the admin console to authenticate users. Oracle published a patch to correct this issue : SU Patch [EIL8]: 10.3.6.0.200114WLSPSU Overlay: CANNOT LOGIN TO CONSOLE, BUT CAN LOGIN TO EM WITH THE SAME USER
Download it from MOS and patch your WebLogic server installation.

User:admin credentials on Ambari UI are not in sync with Ranger

Ambari shows me an alert message:
"Ranger Admin password check
User:admin credentials on Ambari UI are not in sync with Ranger"
How I can resolve this ? What should I need to do.
I have tried to set the same password for (amb_ranger_admin, admin, etc) but it didn't help.
My version of Ambari is 2.7.1
HDP 3.0.1
This topic seems to have been discussed here: https://community.hortonworks.com/answers/221995/view.html
To summarize, the key steps are:
Set the password first in ranger and then in ambari
Check if the passwords are the same
If they are not the same? : Analyze which one (likely Ambari) is not updating the config
If they are the same? : Analyze why you still get the warning

cannot register my app to MFP remove server

I am having an issue deploying my app to a remote server. This is the error I get when trying run the cli add command:
mfpdev server add myqaserver --url https://mbmfp.mycompany.com --login admin --password aaaa --setdefault
Error: URL 'https://mbmfp.mycompany.com' is not valid. The URL must have the following format 'protocol://host:port'. Run 'mfpdev help server add' for more information.
My hostname name https://mbmfp.mycompany.com contains the port. So adding the port again will cause an issue
Initially, I tried the register command and was prompt to used the add command
mfpdev app register https://mbmfp.mycompany.com mfp
How do I fix this issue?
INFO
IBM MFP version 8.0.0-2016121916
Thanks
Doesn't look like you're executing the commands correctly...
Here's an example:
mfpdev server add
? Enter the name of the new server definition: mydevserver
? Enter the fully qualified URL of this server: http://mydevserver.example.com:9080
? Enter the MobileFirst Server administrator login ID: admin
? Enter the MobileFirst Server administrator password: admin
? Save the admin password for this server?: Yes
? Enter the context root of the MobileFirst administration services: mfpadmin
? Enter the MobileFirst Server connection timeout in seconds: 30
Verifying server configuration...
The following runtimes are currently installed on this server: mfp
Server profile 'mydevserver' added successfully.
Then, navigate to the root folder of the application and:
mfpdev app register mydevserver
Learn more here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/application-development/using-mobilefirst-cli-to-manage-mobilefirst-artifacts/#add-a-new-server-instance

Glassfish active directory realm authentication occasionally reverts to file realm authentication

We are running Glassfish 3.1.2.2 authenticating against an Active Directory realm. Authentication works correctly the vast majority of the time, but occasionally, authentication will suddenly start failing for all users, and we'll see errors like this in the server log:
[#|2014-03-19T21:37:32.331+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=1098;_ThreadName=Thread-2;|WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for jeff.|#]
Note that the error message is failed file login. It appears as if Glassfish is occasionally reverting back to the file realm rather than the active directory realm.
When this problem happens, after a short time without any intervention on our part, authentication will suddenly start hitting Active Directory again and users will be able to login again.
Any ideas why Glassfish would occasionally revert to authentication against the file realm when we've configured it to use Active Directory? Should I delete the file realm altogether?
I finally determined the trigger for this. We had been connecting JVisualVM to our Glassfish instance to monitor performance. Everytime I connect JVisualVM (over JMX connection using Glassfish admin credentials), Glassfish immediately reverts to using the file realm instead of the LDAP realm. I have no idea why JVisualVM would cause this behavior in Glassfish, but it is consistently reproducible. The only workaround I have discovered is:
Disconnect JVisualVM.
In Glassfish admin console go to -> Configurations -> server-config -> Security
Change default realm (to anything other than LDAP realm), Save.
Change default realm back to LDAP realm, Save.
Clients should now again be able to authenticate against LDAP.