Bugzilla – Bug 1222591
rabbitmqctl command for add_user is broken
Last modified: 2024-06-19 08:30:25 UTC
I did a fresh install of SLE15SP6 RC1 and encountered an issue, that the “rabbitmqctl” command is broken. I tried the command within a script: echo $rabbit_random_password | rabbitmqctl add_user <username> which then prompts for the password instead of using it from the pipe Then I tried the command: rabbitmqctl add_user <username> it also prompts (this time correct) for the password. But it does not accept any passwords typed and remains frozen! Therefore the rabbitmq server is not useable with RC1 as the user configuration is broken… This was not the case in the SLE15SP6 Public Beta version.
I just checked that "rabbitmqctl add_user <username> <password>" works fine and while "echo <password> | rabbitmqctl add_user <username>" really hangs my first question would be if basic functionally is actually working why bug is P2 and Critical ?
(In reply to Anton Smorodskyi from comment #2) > I just checked that "rabbitmqctl add_user <username> <password>" works fine > and while "echo <password> | rabbitmqctl add_user <username>" really hangs > my first question would be if basic functionally is actually working why bug > is P2 and Critical ? My guess is atleast some customers are using this as part of a automated deployment process so for them its probably a significant break of workflow.
the problem is not in piping . when you run "rabbitmqctl add_user <username>" ( no piping and no second parameter ) and hit enter you will get "Password:" prompted but cursor immediately get into next line and now entering password will not change anything rabbitmqctl will keep hanging forever
I'd like possibly to also add that even the claimed wrong command in sle15sp6 works well with `xargs`: ``` read -s $rabbit_random_password; echo $rabbit_random_password | xargs rabbitmqctl add_user "username1"` ``` being however preferable the full command form `xargs rabbitmqctl add_user "username1" "$rabbit_random_password"`
(In reply to Maurizio Dati from comment #5) > I'd like possibly to also add that even the claimed wrong command in > sle15sp6 works well with `xargs`: > ``` > read -s $rabbit_random_password; > echo $rabbit_random_password | xargs rabbitmqctl add_user "username1"` > ``` > being however preferable the full command form: `rabbitmqctl add_user "username1" "$rabbit_random_password"`
The issue is also present in Tumbleweed, as a starting point i'm looking at updating both erlang and rabbitmq-server to see if the issue is still present there.
Simon, what is your estimate? Can you submit SR for this before the Labs conference?
(In reply to Radoslav Tzvetkov from comment #8) > Simon, what is your estimate? Can you submit SR for this before the Labs > conference? I leave Monday for the Everything Open conference in Australia before heading to Labs. I have started looking at the upgrade path to see if I can find a solution that way. But found another aarch64 bug (that also now has a fix) on the way. If updating Erlang and RabbitMQ to the current latest versions fixes the issue then that timeframe should be pretty easy even while traveling. If not it will depend on the support I get from upstream I don't know the codebase so it might take me a fair bit to debug if I don't get much help.
Hi Simon, as this is a blocker for PublicRC, do you think you can submit a solution for us to test before 17.04?
(In reply to Simon Lees from comment #3) > (In reply to Anton Smorodskyi from comment #2) > > I just checked that "rabbitmqctl add_user <username> <password>" works fine > > and while "echo <password> | rabbitmqctl add_user <username>" really hangs > > my first question would be if basic functionally is actually working why bug > > is P2 and Critical ? > > My guess is atleast some customers are using this as part of a automated > deployment process so for them its probably a significant break of workflow. Kind note: for a quick unblock, if they really use the second form with 'echo', I'd suggest for those customers a 'temporary' w.a. until all fixed, but working also after fix and in all versions: - assumed 'rabbit_username' and 'rabbit_password' pre-assigned in any preferred way, - they can pass those parameters to 'rabbit' this way: echo $rabbit_password | xargs rabbitmqctl add_user $rabbit_username; - or also as positional parameters: rabbitmqctl add_user $rabbit_username $rabbit_password; Regards.
(In reply to Radoslav Tzvetkov from comment #11) > Hi Simon, as this is a blocker for PublicRC, do you think you can submit a > solution for us to test before 17.04? Hi, I've verified that taking the latest erlang with the latest RabbitMQ fixes the issues, it does however break the build for aarch64 but there seems to be a upstream patch for that. I just need to verify that then I will submit the updated packages to both Tumbleweed and 15-SP6
Thank you very much. We'll wait for this critical fix. Even if it comes a few days later, don't hesitate to submit.
(In reply to Radoslav Tzvetkov from comment #14) > Thank you very much. > We'll wait for this critical fix. Even if it comes a few days later, don't > hesitate to submit. I've submitted 327124 and 327125. Direct from my home project on obs, and sent them to tumbleweed at the same time. If there are any issues with those requests feel free to reach out to me on Slack.
What is the situation with the upgradability to this version? PLS see https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability
(In reply to Radoslav Tzvetkov from comment #18) > What is the situation with the upgradability to this version? PLS see > > https://www.rabbitmq.com/docs/upgrade#rabbitmq-version-upgradability We probably need a patch to reintroduce some of the migration code as well that is my main plan for the week after labs. 3.13 makes this slightly harder but I think it will be doable.
Yes, Simon, please work on this with the highest priority as we need this _working_ before 15.05
Hi Simon, now it is after the conference. Do you have an idea when shall we expect the SR?
(In reply to Radoslav Tzvetkov from comment #21) > Hi Simon, now it is after the conference. Do you have an idea when shall we > expect the SR? Hi, I am making some progress however, Tomorrow morning I start my flight back to Australia and I don't land until End Of Business on Thursday, Friday I expect I will be quite jetlagged so at the moment I am targeting mid next week and I will let you know if there are any technical challenges that prevent this from happening if I become aware of any
OK, Eugenio will experiment with this solution branch. Meanwhile, please look at what is a possible solution by cheripicking some changes, just in case we can't roll back.
SUSE-FU-2024:2078-1: An update that solves five vulnerabilities, contains one feature and has five fixes can now be installed. Category: feature (important) Bug References: 1181400, 1185075, 1186203, 1187818, 1187819, 1199431, 1205267, 1216582, 1219532, 1222591 CVE References: CVE-2021-22116, CVE-2021-32718, CVE-2021-32719, CVE-2022-31008, CVE-2023-46118 Jira References: PED-8414 Maintenance Incident: [SUSE:Maintenance:34194](https://smelt.suse.de/incident/34194/) Sources used: openSUSE Leap 15.3 (src): erlang26-26.2.1-150300.7.5.1, elixir115-1.15.7-150300.7.5.1 openSUSE Leap 15.6 (src): erlang26-26.2.1-150300.7.5.1, elixir115-1.15.7-150300.7.5.1, rabbitmq-server313-3.13.1-150600.13.5.3 Server Applications Module 15-SP6 (src): erlang26-26.2.1-150300.7.5.1, rabbitmq-server313-3.13.1-150600.13.5.3, elixir115-1.15.7-150300.7.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.