A client arranged penetration testing in order to achieve PCI compliance and it was found that not all cookies contained the HttpOnly flag, which is an automatic fail because apparently you are more vulnerable to XSS attacks if you don’t set your cookies to use HttpOnly.
I’ve found plenty of articles out there explaining how to use KVM with graphical GUI tools. On most of the CentOS servers I administer, however, I use Kickstart to create a customised and minimal GUI-free install to keep things as simple and efficient as possible. Here, therefore, are some guidelines for how to set up a virtualisation environment and virtual machines using KVM on CentOS 6 via the CLI.
(This post assumes a PostgreSQL installation located at /var/lib/pgsql on a Red Hat-type Linux system such as Red Hat Enterprise Linux or CentOS. If your system differs from this, you may need to modify some of the paths accordingly.)
Following our successful migration to Amazon’s S3 service for media storage and delivery, we decided to move our entire server infrastructure from its traditional data centre colocation to Amazon’s Elastic Compute Cloud (or ‘EC2’). Using this cloud-based infrastructure instead of data centre colocation provides two main benefits for us.
Despite certain frustrations with our Apple Xserve G5s, I’ve found that they make decent Linux servers, especially considering their age. Recently I wanted to repurpose one as a development server, and in that role I really wanted disk redundancy for added protection of the data. Unfortunately there’s no RAID controller in these servers, so software RAID is the only option. Originally RAID wasn’t crucial and I gave up on software RAID as it seemed too complicated to justify the time spent figuring out how to do it. This time, however, it was more important and I was determined to get software RAID functioning.
I attempted to comment on this LOPSA blog entry about problems bundling EC2 volumes, but for some reason they haven’t approved my comment so I’m turning it into a blog entry here instead.
I recently watched Cargo (2009), which turned out to be a pretty decent sci-fi film (sort of a cross between Silent Running, The Matrix and Alien). One thing I particularly enjoyed about the film, however, was that a key member of the spaceship’s crew was a system administrator (and a female sysadmin at that!). I liked the way this character was important to the plot, and I was amused by the way the filmmakers gently poked fun at the geeky nature of sysadmins.
When I started playing Bioshock on my ageing Mac Pro, I found that the graphics card (a Nvidia GeForce 7300GT, apparently) was so poor by today’s standards that the game was practically unplayable. I therefore decided to get a new ATI Radeon HD 4870 graphics card. Despite the fact that Apple say this card is for recent Mac Pros (Early 2009 or Early 2008), it works fine in my original Mac Pro (2006).
Although I’ve got our Mac mini server nicely set up now, there are occasionally things I want to do on users’ Macs which can’t be done or don’t work properly via Server Admin and Workgroup Manager. However, one of the wonderful things about having an office environment consisting entirely of Macs (rather than Windows PCs) is that you can just SSH into them and write Bash scripts which can be triggered by cron (or, better still, by launchd.
As the usage of cron is now deprecated on OS X and OS X Server in favour of launchd, I thought it was about time I learnt how to use launchd so I could move all my cronjobs across to it. launchd is one of Apple’s various contributions to the Unix world, and its purpose is to be a single tool to take the place of init and to replace a variety of startup mechanisms such as the rc/rc.d startup architecture, cron, and inetd/xinetd. In keeping with most other technologies emanating from Apple it is simple, elegant, efficient and powerful. If you do a significant amount of Mac administration then now is the time to learn launchd if you haven’t already.