Unable to set/override default_user/pass

[ghost]

Regardless of what i tried, it seems i can't override guest/guest

[michaelklishin]

and what have you tried? We are all engineers here, lets leave the guesswork out, please.

[cmluciano]

@nlawson Please provide the options that you have passed and the exact errors or messages you received.

[ghost]

ok, I'm setting the following attributes

{
    "rabbitmq": {
        "default_pass": "xxx",
        "default_user": "guest",
        "enabled_users": [
            {
                "name": "guest",
                "password": "xxx",
                "rights": [
                    {
                        "conf": ".*",
                        "read": ".*",
                        "vhost": null,
                        "write": ".*"
                    }
                ]
            }
        ],
        "loopback_users": [],
        "version": "3.5.1"
    }
}

And my run list looks like this

{
  "run_list": [
    "recipe[rabbitmq]",
    "recipe[rabbitmq::mgmt_console]",
    "recipe[rabbitmq::user_management]"
  ]
}

Oddly if i don't run "recipe[rabbitmq::user_management]" i can still login using guest/guest

[jjasghar]

Hi!

If that's your json then you're missing the override_attributes call. something like: https://github.com/stackforge/openstack-chef-repo/blob/master/environments/vagrant-multi-nova.json#L10-L14

Obviously that's for yum cookbook but you should be able to do something like that to help you out.

[ghost]

so the cookbook ignores the environment settings in default?

[ghost]

did try the override_attributes suggestion @jjasghar and the same result

[jjasghar]

Can you put your whole environment json override file here? I think that's the point we're at here now.

[ghost]

just tried that, and yes the same result

[jjasghar]

I'm sorry, but I just tested this and i know it works. If you can't give us the information, we can't help you. Please reopen this when you have file that we can look at that you are leveraging for this issue.

[ghost]

@jjasghar i gave you the information, and clearly it's not working, so just closing the issue doesn't resolve the problem.

[ghost]

however removing /var/lib/rabbitmq/mnesia and restarting rabbitmq does properly set the guest password, so I'm guessing there is an issue of order of events issue.

[ghost]

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"

[ghost]

=WARNING REPORT==== 7-Apr-2015::16:36:02 ===
HTTP access denied: user 'guest' - invalid credentials

=ERROR REPORT==== 7-Apr-2015::16:36:02 ===
webmachine error: path="/api/users"
"Unauthorized"

[ghost]

I'm setting the attributes in the environment, using knife environment edit ...
then changing the json

[jjasghar]

Yep, that's the crux; you need an override_attribute section to override the default attributes. RE: http://docs.chef.io/attributes.html

I'm thinking you're gonna need something like:

{
    "override_attributes": {
        "rabbitmq": {
            "default_pass": "xxx",
            "default_user": "guest",
            "enabled_users": [
                {
                    "name": "guest",
                    "password": "xxx",
                    "rights": [
                        {
                            "conf": ".*",
                            "read": ".*",
                            "vhost": null,
                            "write": ".*"
                        }
                    ]
                }
            ],
            "loopback_users": [],
            "version": "3.5.1"
        }
    }
}

Can you test the above first? We might have found an issue with the instantiation of the default and additional users; but first test the above if that fixes it it's NOT the fix but it should resolve the issue.

We are going to keep this open till we have a solid answer for this.

[cheeseplus]

I think I've isolated the behaviour:

1. Changes to default_user/default_pass in the config after initial start are disregarded
2. rabbitmq-server starts up automatically on install (at the very least on Ubuntu 14.04)
3. a consequence of reusing the guest account in the enabled_users hash with the user_management recipe is that it re-applies/resets tags and given the lack of the administrators tag the guest account loses admin access.
4. there may be potential and mostly unrelated issues wrt to using arrays for the data structure containing users/perms

So the only way you can get in and change the initial administrator user would be to lay down the config before the package is installed or else you're stuck with defaults. That said, it looks like the issue at hand has nothing to do with precedence levels or the fact the attributes are set at the environment level. @nlawson it looks like you're getting bitten twice here.

Suggested course of action:

1. Lay down config before initial install/start or remove option to configure default_user/pass
2. Note point 3 from above in the README
3. Add some tests to validate credentials

[DoctorOgg]

thanks for digging a bit on this, i have created a wrapper cookbook to uses your cookbook to delete the guest user than create the new admin user with desired password, seems to work alright, however it seems a bit hackish.

[DoctorOgg]

it would be curious to set the RUNLEVEL=1 during the dpkg -i event, in many cases this will prevent background process from starting automatically.

[cheeseplus]

I believe the user_management recipe could be fixed to preserve existing tags or at the very least be more intelligent.

If you've already got a wrapper, then I'd advise just using LWRPs themselves directly instead of dealing with the optional recipes which are themselves just opinionated wrappers.

As for setting a RUNLEVEL that seems like a potentially problematic cross-platform solution but there are a few ways that I can think of to get the desired behaviour.

[cheeseplus]

Additionally, there could be more testing of the optional recipes themselves.

[DoctorOgg]

i am using the LWRP's in the wrapper, made that part easy, thanks for responding on this, i will admit i could have provided more details on the initial complaint, however on a side note, i felt like i had to fight to get this looked at, didn't leave me with a great impression, i know we all could do better with these kinds of interactions..

[cheeseplus]

Reproducing errors is hard, doubly so without detail. Several folks volunteered their time today to look over this via video chat - I was brought in as a fresh set of eyes and even then it took me a few hours to fully repro and see that there were multiple issues in play.

Sorry that the initial experience wasn't delightful and thanks for reporting so we can make this better!

[DoctorOgg]

I do gratefully appreciate all the hard work that goes in to cookbooks like this one, and i'm grateful for this.

[cheeseplus]

I've got PR #252 open to address this issue and also, as a side affect, simplifies things a bit by having only one service resource declaration. @nlawson this should fix part of the issue but I'll need to open an issue for point 3 from #245 (comment)

The fix is 3 parts:

1. Disable service auto-starting using dpkg
2. Remove service declaration/starting from being platform specific on Debian platform family
3. Move rabbitmq.config template before rabbitmq-env.conf as default_user/pass are set on first boot.

I've confirmed this fixes the issue for both Debian and RHEL platform families and also means we are removing a few unnecessary starts/restarts of the service.

[jschneiderhan]

Did #252 definitly fix this issue? I'm still unable to change the default username/password as of v4.1.2. I think it's because the rabbitmq-env.conf template causes an immediate restart of the rabbitmq service before the rabbtimq.conf template is processed (which is where the default user/pass are specified):

[2015-08-13T18:03:34+00:00] INFO: Processing template[/etc/rabbitmq/rabbitmq-env.conf] action create (rabbitmq::default line 157)
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] created file /etc/rabbitmq/rabbitmq-env.conf
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] updated file contents /etc/rabbitmq/rabbitmq-env.conf
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] owner changed to 0
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] group changed to 0
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] mode changed to 644
[2015-08-13T18:03:34+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] sending restart action to service[rabbitmq-server] (immediate)
[2015-08-13T18:03:34+00:00] INFO: Processing service[rabbitmq-server] action restart (rabbitmq::default line 216)
[2015-08-13T18:03:38+00:00] INFO: service[rabbitmq-server] restarted
[2015-08-13T18:03:38+00:00] INFO: Processing template[/etc/rabbitmq/rabbitmq.config] action create (rabbitmq::default line 165)

Notice on the initial chef run for a node the

Processing service[rabbitmq-server] action restart

comes before the

Processing template[/etc/rabbitmq/rabbitmq.config] action create

[jschneiderhan]

BTW I was able to verify the above by changing the default_user/default_pass in the .kitchen.yml file and converging a node. After manually installing curl and enabling the management plugin, I was still able to access the dashboard:

vagrant@default-ubuntu-1404:~$  curl -i -u guest:guest http://localhost:15672/api/whoami
HTTP/1.1 200 OK
Server: MochiWeb/1.1 WebMachine/1.10.0 (never breaks eye contact)
Date: Thu, 13 Aug 2015 18:30:01 GMT
Content-Type: application/json
Content-Length: 85
Cache-Control: no-cache

{"name":"guest","tags":"administrator","auth_backend":"rabbit_auth_backend_internal"}

[jschneiderhan]

Would changing the rabbitmq-env.conf and rabbitmq.conf's notifications in the default recipe to delayed break all sorts of stuff? It allowed me to change the user/password, but all I was running was the default recipe.