Installing RabbitMQ rpm on RHEL 5.11

Rough notes for installing RabbitMQ on RHEL5.11.

Install the EPEL repo (not sure if this is needed for the RPM install or not):

curl -O http://archives.fedoraproject.org/pub/archive/epel/5/x86_64/epel-release-5-4.noarch.rpm
rpm -ivh epel-release-5-4.noarch.rpm
yum update

Install the erlang dependency (from answer here):

wget -O /etc/yum.repos.d/epel-erlang.repo http://repos.fedorapeople.org/repos/peter/erlang/epel-erlang.repo
yum install erlang

Download the noarch version of RabbitMQ:

wget -O http://www.rabbitmq.com/releases/rabbitmq-server/v3.1.1/rabbitmq-server-3.1.1-1.noarch.rpm

Note on my initial install of RHEL 5.11 I could’t wget or curl to any https based sites, as I’d get SSL connection/certificate errors. I downloaded the rpm on another machine and scp’d it up to my server.

Install the rpm:

rpm -i rabbitmq-server-3.1.1-1.noarch.rpm

Enable the admin console:

rabbitmq-plugins enable rabbitmq_management

Delete the default guest user:

rabbitmqctl delete_user guest

Create a new admin user and add to the admin group:

rabbitmqctl add_user newuserid password
rabbitmqctl set_user_tags admin administrator

Start/stop/restart the server:

/sbin/service rabbitmq-server start
/sbin/service rabbitmq-server stop
/sbin/service rabbitmq-server restart

Additional notes:

I tried the generic Linux version wouldn’t start up for me, it gave this error, so found a working RPM above instead:

{"init terminating in do_boot",{undef,[{rabbit_prelaunch,start,[]},{init,start_it,1},{init,start_em,1}]}}
init terminating in do_boot ()

WordPress error uploading photos on nginx: “client intended to send too large body”

Attempting to upload some new photos between around 3 to 5MB, the majority of the uploads failed, and this error was occurring repeatedly in my nginx error.log:

2018/08/06 07:18:37 [error] 43#0: *5 client intended to send too large body: 3125530 bytes

Based on this tip from here, the solution was to increase the default POST body size config with this setting in my nginx.conf:

client_max_body_size 5M;

Increasing VMware ESXi guest desktop resolution for Ubuntu 14.04

By default, my Ubuntu 14.04 desktop guest running under VMware ESXi has a maximum resolution of 1360×768 when accessed with the Remote Client, which although usable is not great on my MacBook Pro:

In the guest settings for my Ubuntu guest, I have rather limited graphics settings:

I tried bumping up the memory and see if that opens up some additional settings but that didn’t change anything, although for higher resolutions it’s most likely I would need more gpu memory, but that’s not the issue with the limited settings here.

Searching for ‘ESXi linux guest maximum resolution’ I found this article:

https://communities.vmware.com/thread/527747

which suggests to install a ‘desktop’ version of the open-vm-tools:

sudo apt-get install open-vm-tools-desktop

Let’s try that. After a reboot, now we’ve got higher resolutions! Awesome!

Local Jira server install: Unable to search: “An unknown error occurred while trying to performa search”

On starting up my VM where I have Jira installed, all my logged issues are not displaying, and there’s errors about searching and indexing:

On the Admin / Advanced / Indexing page it shows:

This page on search and indexing issues and a number of other pages and articles talk about deleting the temp Lucene index and cache files, but the docs and other posts miss the important part of stating where these files are.

This page gives a good overview of the file structure of Jira, but doesn’t talk about the Lucene indexes.

This page talks about deleting the Lucene indexed at $JIRA_HOME/caches/ but doesn’t say where $JIRA_HOME points to. It isn’t the /opt/atlassian/jira directory structure mentioned by the previous article, but there isn’t a caches there or anywhere below that directory.

Not knowing where else to look, I just did a find from the root for ‘caches’ and found the location elsewhere here:

$ sudo find . -type d -name caches

./var/atlassian/application-data/jira/caches

Ok. Stopping my server with

sudo /etc/init.d/jira stop

and then moving the caches/indexes folder to indexes-old, retstarting Jira with:

sudo /etc/init.d/jira start

and now there’s a new error about Lucene:

Ok. Clicking the Find out More link shows the results of this health check:

Clicking the How do I resolve this link takes you to this page, which suggests to do a re-index, which is from the Admin / Advanced / Indexing page and where I got the second error originally. Going back there and trying the ‘lock and re-index’ option which was recommended in some of the other index related issus posts:

I then got this:

Ok, no errors! Let’s see if my logged issues are back.

They’re back! Now I’m back in business!