I have said before that for what concerns my paid job, I’m accepting the compromise of paying for closed-source software when there isn’t a clear, decent alternative for it in the Free/Open Source world. I don’t like, nor I go proud of this, but that’s just the way it is. It is for the best in most cases, as a lot of my work is FLOSS-based so I end up using those tools to create new, better software for all to use.
One of this tools – or to be honest the only one nowadays – is Visual Paradigm for UML which I use to work thoroughly on the abstract designs before actually starting to write code, which is a godsend when a paying customer leaves you the time to. I’m also of the idea that if I spend more time on designing the code, the end result is actually more convenient for the customer, as expanding that in a later future becomes much easier.
But I digress… let’s go back to Visual Paradigm as a software rather than as a tool. Its license system works in a way that is a bit uncommon for most non-professional users: you can either have a license for the single installation, or you can buy a (slightly more expensive) “floating license”. This latter method allows you to have as many installation of the software as you want, just as long as only one (or actually only “as many licenses as you own”) is started at once. It’s not bad at all, especially for those like me who have multiple boxes, standing or portable, throughout the home and office. For it to work, though, it requires a so-called “licensing server”.
When I bought my first license for VP, said licensing server was a standalone application (you find it in my overlay by the way); that you simply had to start, and it listened to a given port-IP combination and provided the keys for the application through HTTP. Later on, the developer replaced the standalone licensing server with a more sophisticated server, which is the “Visual Paradigm Server” framework, with a module for licensing (and a different one fork the TeamWork software). Like everything in the suite, it’s written in Java, of course, and this latter is a JSP webapp, which they distribute both standalone or in a webapp packaging so you can actually set it up on Tomcat.
For a long time I kept said application running on my home box, since at worst, I would have missed this on the go with the laptop, but I almost never use that for design anyway. Right now, though, I work much more out of office, and as I said before I have a bit of spare time now and then to work on things. Plus, I have a helper right now and I have to give her access to the design documents, to show the customers. All this considered, I needed access to said server on the public IPv4 network, so I decided to move it to my IOS server.
First problem: the system is Hardened and I like building everything for Hardened if I can. Turns out that the IcedTea ebuild requires a huge chunk of Xorg to build, including GTK+, and CUPS as well.. not exactly what I’d like to have on an headless server. The other alternative is of course to install icedtea-bin, but.. it stinks. Let’s go on with that though. Install the package, build Tomcat and mod_jk, and install on the server.
Second problem: there really isn’t a clear documentation on how you’re supposed to deploy a JSP application. Most of the documentation either points you to the Tomcat’s automatic deployment tools, or to a complete reference of each possible XML configuration elements that is supported. The end result is a long night of mix and matching tutorials and blog posts with an end result that looked satisfying.. until someone let me know this afternoon that my blog was reporting as the VP Server — somehow the default vhost was configured by mod_jk … I moved the configuration options later in the processing (some still at global scope, some down to the vhost scope), and it returned to normal.
All this considered, I’m thinking of replacing my current setup, where Apache runs both Passenger and mod_jk, with a reverse-proxy based one, with, respectively, lighttpd and Tomcat running in LXC guests and handling the dynamic part of the code. At that point the “frontend” Apache would only have to take care of serving static content, filtering requests (with ModSecurity) as well as handling rewriting (which was my first reason to move from lighttpd to Apache in the first place).
This would also solve me the problem I’ve been having trying to set up mod_perl so that I could run RT for my customers… when I did try to set it up, Apache decided to segfault on me. The same exact binpkg works fine on xine’s bugzilla — the only difference between the two setups is that my host had Passenger loaded. I’m almost sure that’s the problem. Considering that a few of my customers have shown interests in the possibility to set up WordPress, and the fact that I need to host a customer’s custom Rails app… I start to think using containers would be a good idea, even if I know that this also means increasing the attack surface as I’m adding more software to the system.
I just wish I could find the time to work on this in the short term, it’s unlikely though.