Passing a HTTP header HTTP_ACCEPT_ENCODING set to none back to HelpSpot via nginx's fastcgi parameter solved the issue of HelpSpot deciding to gzip data for it's css and javascript file combiner php code:
Turning gzip compression on inside nginx works as expected now with HelpSpot's css and javascript combiner scripts.
]]>Seeing we use Apache I placed the usual Apache directives in the configuration file for users to authenticate against the company replicated LDAP pair I had setup previously. Later it was reported some folks were having issues with a tomcat error page relating to basic authentication from when we used an outsourced IT company to handle user management they decided to drop the email prefix so the added awesome side effect of users being logged into JIRA or Confluence when getting past the HTTP Authentication dialog box required another Apache directive to not forward the Authorisation bits onto Tomcat.
The directive is:
]]>
<?php
require_once dirname(dirname(__FILE__)) . '/bootstrap.php';
Rather than having everything in your index.php file. Separating your configuration directives out to a separate configuration file outside the webroot and modifying that when making changes.
One can use your version control pre commit scripts to check that you've not borked a the file - checking for php scripts being of a file type php script vs file is one way of doing this - foo.php contains a php script starting with "i?php" and bar.php has same code starting with "
$ file foo.php foo.php: PHP script text $ file bar.php bar.php: ASCII text]]>
To fix the issue where screenshots get uploaded and don't redirect properly you can make use of apache's redirects to send anything destined prefixed by /browse to /jira/browse by adding the following to your virtualhost config:
Redirect /browse https://hub.yourdomainname.com/jira/browse
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)
$ personalwiki HOME Unable to log in to server: https://hub.example.com//rpc/soap-axis/confluenceservice-v1 with user: username. Cause: ; nested exception is: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target could not close pipe at ./vimfluence line 94.
A bit of an annoyance with Java is that you have to tell Java that it has to implicitly trust a self-signed SSL certificate if you want to connect to it via some jar. In my case I'm using vimfluence to connect to a wiki sitting behind a self-signed SSL certificate. To import the certificate into the keystore, one uses a binary called keytool which brings back strange memories of Actaris's biz.switch documentation from a previous joblet.
(cd /Library/Java/Home/lib/security && sudo keytool -import -keystore cacerts -alias example-wild -file ~admin/example-wild.crt)
One can easily get the SSL certificate by running:
openssl s_client -connect hub.example.com:443]]>
Before I started testing I created a test text file:
[jacques@auriga ~]$ cat far hello ABOVE BELOW ayoba
Then I wanted to insert the word testing above the word ABOVE:
[jacques@auriga ~]$ gsed -i"" -e "/ABOVE/i\ testing" far [jacques@auriga ~]$ cat far hello testing ABOVE BELOW ayoba
So that works well - after quite a bit of fiddling it was discovered to insert a line after something I needed to change the i script modifier to an a:
[jacques@auriga ~]$ gsed -i"" -e "/BELOW/a\ testing" far [jacques@auriga ~]$ cat far hello testing ABOVE BELOW testing ayoba]]>
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.
]]>
"cfg_openfile: unable to check htaccess file, ensure it is readable"
You can either be out of file handles or the parent directory is not readable or infact the .htaccess file is not readable by the user running apache.
]]>I'm running a git clone of flamework for testing some stuff and was looking to see if the I could view files under the .git directory. So I looked to see what files exist under .git and chose HEAD and went to my browser and pulled up http://flamework.example.com/.git/HEAD and it showed the file contents. After adding the snippet above to my apache config, I was no longer able to view files under the .git directory or the .gitmodules files.
]]>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?
]]>If you want a non-filtered service at this point in time use the Google Public DNS servers (they are using Level3 for their upstream connectivity):
8.8.8.8 and 8.8.4.4
And if you like filtered DNS results you would want to use the OpenDNS ones:
208.67.222.222 and 208.67.220.220
UPDATE:
Quick stat from doing DNS queries against Google, IS and OpenDNS's cache servers:
Google: 546ms and 243ms
IS: 303ms and 36ms
OpenDNS: 432ms and 297ms
Looks like all three cache the results on their anycast clusters.
]]>