Migrating to JIRA 4.4

Migrating to JIRA 4.4 is now complete. It has't been without hickups however : JIRA 4.4 en Fisheye 2.6.0-2.6.3 don't get along when using trusted authentication. You get Seraph errors : Error handling trusted applications authentication attempt:BAD_SIGNATURE Make sure the user that is authenticating the application link (and managing the JIRA project) has read errors to Fisheye projects. Else you can't link you repo to the JIRA project.

Confluence

I've installed an milestone of Confluence. I never liked the 3.x editor : Wiki just isn't my thing. Fortunately, the 4.x release has a brand new editor, and it's WYSIWYG. No more fancy tagging, no more thinking on what wikimarkup to use. A nice addition is that it also allows macro's to be embedded into that page. I'm going to use that to add some information of my own personal projects, like commit history.

Migrating to Atlassian tools

So.. Finally found to spare time : I've migrated my old setup to include (most) of the Atlassian tools. I've got Crowd, JIRA, Confluence, Bamboo and Fisheye up-and-running, with SSO authentication. Next step is to figure out how to make Bamboo build my C / C++ projects (which use make, not Ant or Maven which are supported native in Bamboo). I also need to look at the testsuite, for which Bamboo assumes it generated JUnit XML reports.

Working with re2c, lessons learned

I've completed the parser that parses bind9 style config files. The parser itself is based on the lemon parser generator, and the lexer is based on re2c. While testing and developing the parser, I've ran into some strange, undocumented issues. Error checking is practically absent. Bad input results in bad runtime behaviour instead of errors. Make sure that all input in conditions is handled; Input encountered in states without a matching rule results in the resulting code jumping to a (semi) random rule.

Migrating from Xen Citrix to RHEV

Since I've got fed-up with all Citrix bugs (operations that het stuck on locks, resumes not working, etc) and the fact that the're probably going to drop Xen in favor of Microsoft Hyper-V we are going to migrate to RedHat RHEV. The software installs fine (except for the know issue that you can't register on RHN), but migrating 35 VM's is not something I really like doing. Well, virt-v2v comes to the rescue according to the docs.

PHP and the reasons why we consider switching

PHP is a nice language, with numerous advantages : Easy to learn Easy to install and upgrade serverwise Interpreted, so no compile and deploy worries The disadvantages are starting to annoy me more and more over time : Zend engine is huge. It's a major memory consumer Not all extensions are stable. When it comes to thread safety, there are major problems

Booting a > 2 TB partition using EFI

When our new storage server arrived last week, I wanted to skip use EFI t0 boot this system. It requires en EFI capable system, which this Intel server mobo is capable off. The CentOS installer doesn't grasp an GPT partition table (needed to enable > 2TB partition tables), so I installed manually. Well.. That didn't go to smooth. Manually installing CentOS, and the GPT partition table was, looking at it afterwards, the least of my problems.

Migrating to SSO

We at JDI are moving to a project based working method. We decided to use the tools from Atlassian, since those tools seem to do what we require. We also run a number of internal tools, and all those together mean remembering about 6 different usernames and password. We decided to give Crowd a try : SSO, with an option to integrate with custom applications. It uses SOAP internally, and SSO is managed with a domain cookie.

We're at Maildir now

As noted in this posting, we migrated to Maildir. It went relatively smooth, and faster then anticipated. I'll be posting the code to the actual migration script (41 lines of PHP code), and the code code to the milter that temporary locks the mailbox (aboyt 150 lines of C actually written by me). This way, it reduced downtime to the actual time needed to do the conversion, instead of shutting down the whole MTA.

Moving from mbox to maildir

I've decided that it's time to move from mbox to Maildir. Mailboxes are getting larger every year, and so serverload continues to increase. During scheduled maintenance the end of March, I'm converting all mailboxes to Maildir format. I've run into a number of issues during some preliminary tests : The conversion can't hand the situation that mail get's delivered during the conversion IMAP / POP mutations on the mailbox while converting screws up the conversion process.