I need to change a configuration item on a RabbitMQ instance without having any down time.
I'm aware of using rabbitmqctl to evaluate Erlang expressions. I know I can set first level options easily with rabbitmqctl eval, like this:
rabbitmqctl eval 'application:set_env(rabbit, heartbeat, 1800).'
However, since I've no prior knowledge of Erlang, I haven't been able to figure out how to set nested options without changing the whole block. In this case specifically changing ssl_options.depth.
Related
Currently I am having an issue with trying to run a process/script in the background[The master starts it on the minion]
The script is something like this:
#!/bin/bash
nohup ping 8.8.8.8 >/dev/null&
And I call it from the master with:
Process-Name:
service.running:
- name: Script-Name
- enable: True
For some reason it gets stuck on the master,I've read a little bit on this issue[it has happenned before apparently] and tried their solutions on it but apparently nothing involving the service state seems to work.
Is there anyway to work around this?
In short, you should configure your script as system daemon first (SysV init.d script, or systemd unit, or ... depends on OS).
Details
The service.running function requires properly configured system service ~ daemon.
For example, on RHEL-based Linux, if you don't see your script name in the output of one of these commands, you should configure it as proper service first (which is a separate topic):
# systemd
systemctl list-units | grep your_service_name
# SysV init.d
chkconfig --list | grep your_service_name
And because you want to start it in background, cmd.run function is not the right tool either:
It will only report successful start of the script without waiting for its completion results.
It will also start new instance of your script every time.
However, if all you simply want is to "fire and forget", use cmd.run.
In Knox config file in Ambari we have defined:
<url>http://{{namenode_host}}:{{namenode_http_port}}/webhdfs</url>
The problem is we have 2 namenodes, one active and one passive for high availability. Our active namenode01 failed so namenode02 became active.
This caused problems for a lot scripts as they were hardcoded to point to namenode01. So we used a command to failover namenode02 back to namenode01 using a terminal, not Ambari.
Now, the macro {{namenode_host}} is defined as namenode02 and not namenode01.
So, where is {{namenode_host}} defined?
Or, do we need to failover namenode01 to namenode02, then failover again to namenode01 using Ambari to update the macro?
If we need to failover the namenode using Ambari, I'm assuming we need to select the "Restart" option? There isn't a direct failover command.
See issue here:
https://issues.apache.org/jira/browse/AMBARI-12763
This was committed to Ambari to support HA mode for Knox. However if you're still looking for the location take a look at the file that's edited in the patch. That file is the place where the macros are set. You'll have to find it on your local machine though.
Should be something like params_linux.py
My question builds off this one: Temporary queue made in Celery
My application needs to retrieve results, as it uploads them to an S3 file. however, the number of temporary queues being made is causing my broker to crash (machine doesn't have enough memory). I want to delete the temporary queue once the corresponding result as been retrieved. In my celery client script, I am iterating through a list of of results (where each result is from function.delay() ):
for result in result_list:
while True:
if result.ready():
#do something with result
#I WANT TO DELETE TEMPORARY QUEUE HERE
Is there any way I can achieve the above -- deleting the temporary queue once the result has been retrieved?
I would have used CELERY_TASK_RESULT_EXPIRES option in my celeryconfig , but I don't know when I can safely clean up the temporary queue, as the result may not have been retrieved. Is there anyway I can delete specific queues in this script (note that I have the queue Id from the result).
ADDITIONAL NOTE:
I am running all rabbitmq servers in a cluster with HA enabled.
The way I did this was to use the rabbitmqadmin from rabbitmq. I downloaded it via
wget localhost:15672/cli/rabbitmqadmin
after installing the management plugin
rabbitmq-plugins enable rabbitmq_management
Make sure your user has the administrator tag for rabbitmq, or you will not be able to perform commands. I then deleted the queue in my script using python subprocess import and rabbitmqadmin delete queue name='' . Keep in mind that the queue name is the same as the corresponding result id, except without the hyphens.
Also make sure you add the params -v myvhost -u myusername -p mypassword in rabbitmqadmin commands, default vhost is /.
I believe this will delete queues across all nodes in a cluster, though I am not completely sure of this.
I am using Spring Jedis Client to use Redis in my application. I want to rename the commands so that no one else can fire the same just in case they are able to connect to my server.
Can anyone give an example of how to use rename command from Jedis and then how to fire subsequent commands using the the modified one ?
You can't rename a Redis command yet w/o changing the config file issue #640.
Even if you add the rename-command config file directive and restart your Redis, Jedis doesn't seem to allow sending arbitrary commands easily or to provide a trivial (i.e. no code changes) way to rename them.
What you could do, however, if you're really insistent on renaming a command and then calling it from Jedis is EVAL it. This will probably go in my pantheon of ugly hacks (:)) but after adding rename-command get foo to my /etc/redis/redis.conf and doing service redis-server restart look what I can do:
$ redis-cli
redis 127.0.0.1:6379> set bar baz
OK
redis 127.0.0.1:6379> get bar
(error) ERR unknown command 'get'
redis 127.0.0.1:6379> foo bar
"baz"
redis 127.0.0.1:6379> eval "return(redis.call('get', KEYS[1]))" 1 bar
(error) ERR Error running script (call to f_db0e060e4f58231d51f21685b20ff847de8ab9e1): Unknown Redis command called from Lua script
redis 127.0.0.1:6379> eval "return(redis.call('foo', KEYS[1]))" 1 bar
"baz"
redis 127.0.0.1:6379>
Of course, if you take this route your code can get pretty messy in no time at all so be careful where you tread... Good luck!
If a malicious user connects directly to Redis, then one can access all opcodes.
There is no feature in the Redis library to rename commands. Even if you expose access to a custom API that renames commands, you cannot change the inner opcodes of Redis itself.
Edit:
You're right, it is possible to rename commands by changing the config file indeed!
After you set the new command names, you have to recompile Jedis.
First rename the enum on src/main/java/redis/clients/jedis/Protocol.java, line 203.
Now find the corresponding enum usage on src/main/java/redis/clients/jedis/BinaryClient.java and change it also.
It may be sufficient: everywhere you still keep the old command java interfaces (e.g. zadd etc.), and inside Jedis it will talk to Redis calling the renamed command.
Is that your intention ?
Is there any reason that the rabbitmq-management plugin wouldn't work when I'm using 'rabbitmq-multi' to spin up a cluster of nodes on my desktop? Or, more precisely, that the management plugin would cause that spinup to fail?
I get Error: {node_start_failed,normal} when rabbitmq-multi starts rabbit_1#localhost
The first node, rabbit#localhost seems to start okay though.
If I take out the management plugins, all the nodes start up (and then cluster) fine. I think I'm using a recent enough Erlang version (5.8/OTP R14A according to the README in my erl5.8.2 folder). I'm using all the plugins that are listed as required on the plugins page, including mochiweb, webmachine, amqp_client, rabbitmq-mochiweb, rabbitmq-management-agent, and rabbitmq-management. Those plugins, and only those plugins.
The problem is that rabbitmq-multi only assigns sequential ports for AMQP, not HTTP (or STOMP or AMQPS or anything else the broker may open). Therefore each node tries to listen on the same port for the management plugin and only the first succeeds. rabbitmq-multi will be going away in the next release; this is one reason why.
I think you'll want to start the nodes without using rabbitmq-multi, just with multiple invocations of rabbitmq-server, using environment variables to configure each node differently. I use a script like:
start-node.sh:
#!/bin/sh
RABBITMQ_NODE_PORT=$1 RABBITMQ_NODENAME=$2 \
RABBITMQ_MNESIA_DIR=/tmp/rabbitmq-$2-mnesia \
RABBITMQ_PLUGINS_EXPAND_DIR=/tmp/rabbitmq-$2-plugins-scratch \
RABBITMQ_LOG_BASE=/tmp \
RABBITMQ_SERVER_START_ARGS="-rabbit_mochiweb port 5$1" \
/path/to/rabbitmq-server -detached
and then invoke it as
start-node.sh 5672 rabbit
start-node.sh 5673 hare