Jacques Marneweck's Blog

Every now and again one is asked how one can lock down rpcbind from with a shared-ip zone without being able to use ipfilter from within the zone. Fortunately tcpwrappers save the day by allowing us to enable rcpbind to use the tcpwrapper functionality to lockdown who can connect to port 111 (the port which Sun RPC use).

You have run rpcinfo against a zone and it returns numerous lines saying that rpcbind and additional rpc based serivces are available remotely.

rpcinfo -p IP.AD.DR.ESS
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100024    1   udp  62025  status
    100024    1   tcp  36015  status
    100133    1   udp  62025
    100133    1   tcp  36015
    100021    1   udp   4045  nlockmgr
    100021    2   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100021    1   tcp   4045  nlockmgr
    100021    2   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr

For tcpwrappers to allow and deny traffic to rpcbind, we need to create two files namely hosts.deny and hosts.allow both under the /etc directory.


echo "rpcbind: ALL" >> /etc/hosts.deny
echo "rcpbind: 10. 192.168. 127." >> /etc/hosts.allow


Once this has been done, we are now ready to enable tcpwrappers to disallow access to rpcbind:


svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
svcadm refresh rpc/bind


One can also run a quick script which I quickly put together that will run the four commands mentioned above for you:


curl http://github.com/jacques/adminscripts/raw/master/lockdownrpcbind.sh | sh -x


One can verify that rcp/bind is sitting behind tcpwrappers using by running:


# svcprop -p config/enable_tcpwrappers rpc/bind
true


And remotely one can verify this by running:


# rpcinfo -p IP.AD.DR.ESS
rpcinfo: can't contact portmapper: RPC: Rpcbind failure - RPC: Failed (unspecified error)


Posted by Jacques Marneweck at 9:36 PM | Permalink | Comments (0) | TrackBacks (0)

I was chatting to Jerry Jelinek during the week on IM about an issue that I was working on debugging - the reason Crowd 2.0.7 was not behaving under SMF - it was being randomly killed off and never transitioning to an online state even though it's start_crowd.sh script had cleanly exited with an exit code of zero.

Looking at the scripts that Confluence and JIRA comes both of those start tomcat up with passing the argument of start to the catalina.sh script which starts tomcat up.

When doing a "svcs -p crowd" it would keep showing that the state was "offline*" - randomly it would get killed and I would have a cronjob running every minute to clear the service while digging into this.

Turns out the dear Atlassian folks regressed and put in start_crowd.sh a "run" instead of "start" for apache tomcats catalina.sh script which due to the way it starts java SMF thinks that it is still running the command and will zap the java process when the timeout comes around. So to fix this, one has to edit the start_crowd.sh and change run to start and then one is good to go. Crowd starts behaving itself while under SMF and life is good once again.

The manifests which I use for Crowd, Confluence and JIRA are available on GitHub.

Posted by Jacques Marneweck at 4:31 PM | Permalink | Comments (0) | TrackBacks (0)

Dear Lazyweb,

Does anyone have a solution for Atlassian Crowd keeping on crashing. I recently upgraded from 2.0.6 to 2.0.7 and that is were the issue started. Crowd randomly crashed every couple of minutes after startup. I have a cronjob that runs svcadm clear crowd every minute to try and keep the downtime to a minimum. Is there something like xdebug (for php) for java?

Posted by Jacques Marneweck at 9:46 PM | Permalink | Comments (0) | TrackBacks (0)

When running OpenSolaris SX:CE >= snv_100 on different flavours of VMWare (Fusion, ESX, etc.) one needs to change edit the grub menu to include "disable-pcieb=true" at the end of the kernel line. To do this you will need to hit "e" to edit on the grub menu item, and then "e" on the line for the kernel. At the end of the line if there is no "-B" with options after that, add the "-B disable-pcieb=true". Once you have installed OpenSolaris, you can go ahead and edit your /boot/grub/menu.lst and add this there as well.

Posted by Jacques Marneweck at 9:41 PM | Permalink | Comments (1) | TrackBacks (0)