Authenticate Apache against JIRA

JIRA LogoA while back I explained in a post, how to setup Atlassian products behind an Apache with basic authentication using Apache’s user base. Although that can be quite handy to separate the user bases in some cases, it can be really annoying for users to have to authenticate twice. Once against the Apache user base, and after that against Atlassian’s. So I started to find out, how to get Apache to authenticate against Atlassian’s user base only – namely JIRA. Continue reading…

Running JIRA and Confluence behind Apache with basic authentication

Since I’m a big fan of the Atlassian products like JIRA, Fisheye and Confluence, I bought my own private Starter Licenses over a year ago. Installed as separate Tomcat deployments on my root-server, I put them behind an Apache server and forwarded requests to the localhost-only listening Tomcats using mod_jk.

Now,  >12 months later, support expired and so no updates or security-patches will be available for my installations without license renewal. Fair enough. So I thought, it’s time to restrict public access to my Atlassian products completely (even no start page) by just adding a basic auth to the Apache configuration. Oh, silly me :). Continue reading …

Fixing non-terminating cacti shell scripts

Cacti is a really useful tool when it comes to monitoring/graphing the state of a linux system like CPU load, free diskspace, database stats etc. utilizing the RRD-Tool. But recently I encountered, that one of my shellscript-based cacti data-input-method didn’t terminate as expected, driving my CPU crazy. It took me some time to track down the cause, so I thought it might be worth writing a line or two about it. Continue reading…

Using barman without additional postgresql connection

Using barman for incremental postgresql backups can really make life easier. But one thing bothered me while setting it up: why is an additional postgresql database connection from the backup server needed although there’s already an SSH account configured? I decided to take a deeper look into that problem. Continue reading…

Using barman to manage incremental postgresql backups

Recently I was searching for a way to avoid CPU peaks during backup of a production postgresql database. Until then, we used pg_dump to create single dumps for each database in the postgresql cluster. Everytime the backup was triggered, CPU load went up and sometimes also blocked new connections to the database for about 10-20 minutes because of that. Since we didn’t want to loose too much of the current data in a disaster scenario, we performed the backup multiple times a day. Doing that with an approx. 1 GB database seemed overkill to me.

Then I came across the concept of incremental backups using postgresql. Continue reading…

Setting things up

I’m currently setting up an Ubuntu JiffyBox as a replacement for an old root server (iron).

Virtualization seems to be the magic word. Execute the setup within a virtual machine. Up- or downgrade as you like, for as long as you like.

In-/decrease memory or cpu cores without re-installation of your server and almost instantly. Only pay for what you’re really using. Download your image and mount it locally and play with it. Backup and Restore your whole server with one click. Automatic weekly/monthly full-backups, one manual backup anytime you like. Use a webconsole and watch your server booting. Nice.

For now it seems working well. I’ll report back when the server is completely setup.