Until the unveiling of Apple’s iPad, Amazon had an effective monopoly as a large ebook retailer with the Kindle tied to their online Store. This has allowed them to exert control over pricing because the publishers had no alternative options. However, that dominant position has now been challenged.
Apple is expected to recommend pricing at around $12.99 – $14.99 but publishers will have the final say on that. This is a different pricing model from the one currently operated by Amazon which involves a set price.
As a result of Apple entering the equation, a dispute arose concerning one of the big 6 US publishers, Macmillon, who wanted Amazon to provide the same variable pricing structure. This is interesting because Macmillon were getting their fee regardless – it was amazon that was taking the hit:
Amazon prices all its Kindle e-books at $9.99 or less. This becomes a selling point for Kindle, as new hardback books can cost up to $27. In some cases, Amazon is actually paying the publisher more than $9.99 per copy sold, and losing money. But Amazon has stacks of cash, and it’s a way to sell more Kindles and gain market share. – Amazon v Macmillan: free market fail, Guardian
Books already have pricing ranges. A new hardcover release is usually more expensive before the paperback comes out later at a lower price. So currently the big advantage of the ebook format is consumers can access the latest releases at a lower price than the hardcover. This is not only a lower price but means they can read it right now when they might otherwise have waited for the paperback. The new pricing introduces more pricing variability on a per title basis but probably more consistency across platforms.
Amazon attempted to fight back by removing Macmillon’s books from its entire site. The problem is that because this is essentially 1/6th of all books and consumers can just buy elsewhere, Amazon quickly gave in to the demands. Had this gone on, the other publishers may have become involved too. This is an interesting example of increased competition affecting the market, even where the competing product is not yet available.
This pricing structure is similar to how iPhone apps are priced with developers deciding how much to charge and Apple taking a 30% cut. Such a model provides more flexibility for publishers but removes the ability for the retailer to provide a competitive edge through pricing alone. However, there are a huge number of iPhone developers and they therefore have no individual power.
In adopting the Apple model, the balance of power would shift at least partly back to publishers, which regain control of pricing,” the report said. “In setting higher prices, they could provide a level playing field for all e-book retailers. The potential for publishers is that the device may generate greater volume for e-book sales.”
One publish executive surmised that book companies will be left with a choice to embrace Apple’s device and hope it attracts more people to e-books, or stick with Amazon’s model which offers greater revenue. – AppleInsider on WSJ report
The effect of this is that ebook manufacturers (namely Amazon and Apple, but also other companies who may enter the market this year) can no longer compete on price. Instead, they will need to look at other options. The Amazon Kindle is very much a single purpose device – reading – and it is said to do it very well. However, the iPad not only does ebooks but is a multi-purpose device – email, web browsing and all the apps currently available on the App Store.
Amazon knows that it needs to expand the abilities of the Kindle – it has recently announced the availability of a Kindle SDK. We have seen the iPod touch replace the general iPod range as a multi-purpose device and it seems that Apple are now looking to do the same with the iPad. People do not want to be carrying several devices, although there is an argument for carrying a couple of devices if each one is heavily optimised for its purpose.
Amazon still have a few advantages, namely the worldwide wireless access. It’s very convenient to be able to purchase and access content anywhere in the world for free (there is a small fee depending on your country of origin and the content you’re accessing), a convenience that the iPad does not have. It will be a pain if you’re required to have data subscriptions for each country you want to take the iPad to.
Aside from functionality, like other Apple products, the competitive advantage is in the experience. Anyone who uses the iPhone, iPod (and to a lesser extent OS X) knows how great the user experience is. This is because Apple control the whole system and spend a huge amount of time on the UI. The iPad will likely be the same when it comes to buying books – from the store to the reader application.
User experience is a competitive advantage. So many devices, software applications and websites have poor user experience and it really does matter. This is not something that can be outsourced and requires a deep focus on usability from the beginning. Everyone involved has to have great design and experience as the first consideration, not something that is added as an afterthought. It’s difficult to get right, particularly because users often don’t notice when things are done properly! But statistics show that improvements in usability have a real impact on important metrics.
We have yet to hear how good the iPad is for prolonged reading. The Kindle’s eInk display makes it much more like reading a physical book than reading from a screen, but that presents limitations in what can be achieved visually. If the war is going to be won based on visual experience then this will pose a big problem.
When book titles are priced the same, cost ceases to be a factor in choosing which device to purchase. This is especially so when the pricing differences between the two devices are minimal but one has superior aesthetics and functionality. It’s certainly going to be interesting to see how things develop and what Amazon does in the coming months.
Feedback from the users of our server monitoring service, Server Density, indicate that user experience plays a big role in decision making when it comes to choosing one product over competitors. Whether it is ease of use, a great looking UI or a tight shopping experience, user functionality and user experience are now the most important things, not price.
It is now possible to get alerts when specific processes are no longer running on your servers using our server monitoring service, Server Density.
Available for all users (free, trial and paid), you can now choose “Process not running” as an alert check type when adding an alert, enter the name of the process, and Server Density will then notify you when that process no longer appears on the process list. Just enter the exact process name as displayed on the process list in the server snapshot (click on any point on the graphs to view the snapshot for that timestamp).
This feature is useful so you can find out when your regular jobs stop running, or important system processes like MySQL, Apache or Nginx fail.
Let us know if you need any help, or have any questions.
Yesterday we experienced an outage of our server monitoring service, Server Density, lasting approximately 45 minutes. The problem was resolved and we are now in the process of implementing a number of changes to prevent a re-occurrence.
Technical Details
We are currently investigating what appears to be a bug within MongoDB that causes indexes to become corrupt on a single collection within a database. This is only on the collection storing the process list and means we are unable to delete items from it. End-user impact is therefore nil, but it affects our backend processes such as data retention. The MongoDB developers are trying to reproduce but the interim fix is to drop the indexes and recreate them.
Yesterday, this was done on a single, but large collection. The expected impact was a short period of blocking (affecting a small percentage of users due to our split database structure) as the indexes were rebuilt. This completed as expected but immediately afterwards, the entire MongoDB instance started throwing “too many files open” errors. This caused the instance to do down.
We have experienced this error before and it resolved itself after a few minutes. However, this time it persisted long enough for us to decide to failover to our off-site replicated slave. Unfortunately this was further delayed because we were waiting for the primary MongoDB instance to quit, but a bug in the network layer prevented this from happening. Further, once failed over, our checks picked up some inconsistencies with the replicated database which meant that data for the previous 24-48 hours was unavailable for some users.
In the meantime, working with the MongoDB emergency support team, we resolved the problem on the database master and so decided to bring that back online instead of remaining with the problematic failover.
Subsequent actions
We have submitted a full incident report to the MongoDB team but a number of changes will be implemented immediately:
- Previously, our failover mechanism was entirely manual. This has been replaced with the MongoDB replica pair system. Our servers in multiple datacentres now continually communicate so that in the event of an issue, failover will occur immediately and automatically. This was not implemented sooner because it requires a period of downtime, so this outage presented a good opportunity to set it up.
- Non-blocking index building is now available in the latest MongoDB development code and we will be deploying this once it is released in the stable branch.
- The bug affecting closing the network layer has been fixed and will also be deployed once it is released as stable.
- Investigation will continue into the index corruption issue.
- We are also in the process of planning a new server architecture to incorporate more automated failover.
I’d like to apologise for this outage. If you have any questions then please get in touch.
A few weeks ago we announced that the agent for our server monitoring application, Server Density, was available as a Debian or Red Hat package, with associated repositories. Over my next few posts I will be outlining how we created our Linux-based packages and repositories, and what our steps are going to be to improve these processes in the future.
Structure of a Debian package
Debian packages must adhere to a strict directory structure. This includes a so-called control file and other scripts that look after what happens during installation of the package. Here’s a sample of our directory structure:
The control file, DEBIAN/control
The control file is the core of the Debian package; it contains all relevant metadata. Things such as package name, version, supported architectures, and dependancies are all included in this file. Here is what our current control file looks like:
Package: sd-agent
Version: 1.4.2
Architecture: all
Essential: no
Section: web
Priority: optional
Depends: python (>=2.3)
Maintainer: Ryan Duffield
Installed-Size: 96
Description: The Server Density monitoring agent.
The conffiles, DEBIAN/conffiles
Configuration files, or “conffiles”, are files that are included within a Debian package that may be changed by a user. When uninstalling the package, a user or system administrator dealing with the package may not want his or her configuration files removed. Running sudo apt-get remove sd-agent will remove all installed package files except for those listed in the DEBIAN/conffiles file. Here is what ours looks like:
/etc/sd-agent/config.cfg
/etc/init.d/sd-agent
If a user truly wants to remove everything including the configuration files, this can be done by using the purge command instead of remove: sudo apt-get purge sd-agent.
The md5sums file (DEBIAN/md5sums)
This file is a list of MD5 checksums for all files contained within the package that will actually be extracted to the system. This can be most easily generated using a combination of commands:
$ find . -type f ! -regex '.*\.hg.*' ! -regex '.*?debian-binary.*' ! -regex '.*?DEBIAN.*' -printf '%P ' | xargs md5sum > DEBIAN/md5sums
The postinst and prerm scripts, DEBIAN/postinst and DEBIAN/prerm
Many packages need to perform actions before or after specific events during the package installation or uninstallation process. Debian packages accommodate for this via scripts. For instance, after installation, our agent package installs its init script automatically; it also needs to byte-compile our Python libraries. Below is the script that is run after installation, postinst:
#!/bin/sh
python -m compileall /usr/bin/sd-agent/
update-rc.d -f sd-agent defaults
Similarly, the agent removes those byte-compiled Python libraries and init script from system startup after uninstallation. This is handled by prerm:
#!/bin/sh
if [ "$1" = "remove" ]; then
rm /usr/bin/sd-agent/*.pyc
update-rc.d -f sd-agent remove
fi
The rest of it
The remainder of the directory structure must resemble the resultant structure after installation of the package. For example, because the agent is installed to /usr/bin/sd-agent, there is a usr/bin/sd-agent directory within our package root.
Creating the package
When all of the above is in place, creating the actual Debian package, or .deb file, is easy:
$ dpkg -b pkg-debian/ sd-agent_1.4.2_i386.deb
$ dpkg-deb: building package `sd-agent' in `sd-agent_1.4.2_i386.deb'.
Mistakes made along the way
This was our first attempt at creating a Debian package, so, naturally, some mistakes were made along the way!
Our initial control file was wrong; specifically, our Installed-Size value was calculated incorrectly. I had originally read that this value was supposed to be expressed in bytes. However, after releasing our first package, I noticed that apt-get displayed a message notifying me that the agent would take up over 100 MB of disk space. This was obviously incorrect. This field’s value needs to be expressed in kilobytes, as outlined here.
Another mistake made was accidentally including Mercurial’s various files (.hg folder, .hgignore, etc.) in the first package version. This was kindly pointed out by one of our customers, and promptly fixed. If one wants to see a list of files currently “owned” by a given package, one can do so by using dpkg with the -L switch. For instance, to see the files that the Server Density agent is responsible for, one can run:
dpkg -L sd-agent
Other Linux packages
As mentioned, we also created a Red Hat package for the agent, and Debian and Red Hat repositories. My next article will outline how we created the Red Hat RPM for the agent.
We are excited to announce a new feature for our server monitoring service, Server Density – statistical analysis. Using the data we store based on the historical behaviour of your servers, we are able to make predictions about what we expect values to look like in the future. Where the actual data deviates, we highlight the anomalies so you can investigate further.
We start displaying anomalies 48 hours after you add a server but then analysis is performed every hour. If there’s no label on your charts then there are no anomalies detected.
This is available right now for trial and paid users.
Why is it useful?
Sometimes this will be nothing to worry about but often it will help detect situations that might not otherwise be discovered right away. For example, a sudden decrease in network traffic transmitted might indicate that your nightly backup job has failed. Or, an unusual increase in Apache requests could signify a robot downloading all your content.
Where can I see it?
Anomalies are highlighted on the graphs and you can click through to the server snapshot to see the actual values, and a few hints about what to do with that information. This is the first step towards providing you with more proactive information to help you manage your servers, and we have many other ideas about what we can do with the data.
Every server is different so our hints are quite generic right now. We hope to be able to offer more tailored suggestions as we work on improving the functionality in the future.
How does it work?
Using a modified Holt-Winters algorithm, Server Density uses past behaviour to predict future behaviour, future variability, and measure whether current behaviour is within the expected bounds, given the behaviour that could be predicted from the past.
The algorithm trains itself as it goes along – it will get more accurate at detecting anomalies the more history it has to work with. So after 48 hours it will start trying to detect anomalies, but it’ll carry on getting better after that.
You can find out more about how it works in our documentation.
Any questions or problems, just let us know.
Last week we announced integration into a number of popular cloud provider APIs for our server monitoring service, Server Density. This functionality helps with administration when adding lots of servers, particularly over multiple providers, but it doesn’t help with deploying the agent across lots of cloud instances, particularly when deployment is automated from an image. You would have to use our deploy script to register the agent against your Server Density account. That has now changed.
Auto deployment
You can now deploy the agent with the same config for any of your servers and we’ll automatically detect that it is a new server, create it within Server Density and copy all your alerts from the original server. This means you can create a single config as part of your VM image, and then when you boot from it, Server Density monitoring will start automatically.
This works particularly well with our OS packages for Debian / Ubuntu and Red Hat / Fedora as they also install init scripts so the agent starts on boot. With this new functionality, the agent will start on a new server and register itself in your account.
This will work on any cloud provider (e.g. Amazon EC2 AMIs or Rackspace Cloud backup images) as well as on any other server, virtualised or not. We detect the existence of a new server based on the hostname (which must therefore be unique).
Now, as your infrastructure changes and responds to demand with new servers and instances, Server Density will stay up to date so your monitoring never stops.
Note: This requires a new version of the agent, v1.4.2, which has also just been released, a minor bug fix only release.
Recommended setup
- Create a new server within Server Density and configure any alerts you want. These settings will be copied to any new server automatically detected.
- Install the agent onto your server using our OS packages for Red Hat/Fedora or Debian/Ubuntu. These include init scripts so the agent starts on boot.
- Configure the agent using the agent key (and any other settings you want) from the server you created in step 1.
- Create your OS image.
When you launch a new instance from your image, the agent will automatically start and register itself as a copy of the server created in step 1. This will include any alerts and will start monitoring immediately. Full documentation can be found here.
Every year Seedcamp runs an event for 20 companies selected from applications and interviews of hundreds to participate in a week of mentoring followed by an investment pitch, and subsequent seed investment in ~5 companies. However, they also run a series of smaller 1 day events around Europe called Mini Seedcamp. These involve a number of talks, mentoring sessions and may also lead to an investment or invitation to attend the full week later in the year.
Boxed Ice was one of the winners of Seedcamp Week 2009 but we also attended the Mini Seedcamp London on 20th April 2009.
Both Seedcamp events require an application and since the first Mini Seedcamp event (Zagreb) application deadline is coming up soon (27th Jan), I thought it would be interesting to post the Boxed Ice application from last year.
Things that have changed
A lot of things have changed since the application was written. These include:
- Originally it was just myself officially involved. The company had not been incorporated at the time and Server Density, our server monitoring service, was only in early testing as a concept to see if it was of interest to anyone. But the important thing was the product was available and working. Boxed Ice Ltd was formed on 6th April a few weeks before the actual event, although after the application, and we now have several staff.
- We now have our server monitoring iPhone application released, with the very popular push notification alerts.
- We didn’t ever release a self-hosted version of Server Density, and have no plans to do so.
Boxed Ice Seedcamp Application
These are the original questions and answers with no alterations. The questions may be different this year.
Education and work history (briefly!)
I am currently in my second year of a law degree at University of Birmingham, due to graduate in 2010. I work part time as Senior Technical Strategist at London based internet company, eConversions, where I advise management on technical issues. eConversions employs 25 people in search marketing and web publishing.
Last year we generated over £100 million in sales revenue for our clients, launched vouchercodes.co.uk which now has millions of visitors per month and sold social business directory welovelocal.com to GCap Media, the UK’s largest commercial radio group. I was lead developer on the welovelocal.com project and responsible for the technical handover to GCap.
Prior to that, I ran my own software development company which I started whilst at 6th form college in 2005. The company, Olate, employed 3 staff who worked on our 2 commercial PHP software packages before being acquired at the end of 2007, partly by eConversions.
Tell us about your completed projects
- cardsmart.co.uk – With eConversions overseeing the core development of the site, I was responsible for implementing the key functionality before handing over day-to-day development to one of our partners.
- welovelocal.com – As lead developer, I was responsible for the development of the site including working with large amounts of geo and business data to build a successful social business reviews site. This included setting up the server infrastructure and managing the technical handover when the site was acquired by GCap Media.
- olate.co.uk – The original website, olate.com, was started in 2003 as a project to learn PHP by writing my own and collecting other author’s web development tutorials in a central location. I developed an open source project (a download manager) then moved onto the first paid product, an ecommerce system that allowed other developers to sell and license their software.
Give us an impressive fact about yourself
During my first year of 6th form in 2004, I was asked to write a book by the then relatively new publishing company, Packt Publishing. The book, titled Invision Power Board 2: A User Guide, was published in 2005. It can be purchased on Amazon.
What are you creating?
We have developed a server monitoring application (written in PHP) that uses an agent (written in Python) installed on the remote server to report statistics such as load average and memory usage. This is then graphed and displayed through a web interface with the ability to configure e-mail or phone SMS alerts. Server administrators can therefore be notified when critical events occur and plan future capacity by comparing historical trends. The product is either hosted by us or can be installed on the customer’s own server. With the latter option, SMS alerts are still sent through our servers.
What gives you an unfair advantage and how will you sustain it?
Current server monitoring products have poorly designed interfaces, are complex to set up, do not allow easy phone (SMS) alerts and tend to be very expensive “enterprise solutions”. Our product is tackling all those areas to try and do the basics right to create a product that does the one job extremely well. Just because a system administrator works on a command line all day does not mean they do not want a well thought out interface and easy configuration of their monitoring tools.
Equally, just because you are monitoring the status of a server does not mean that you have many £1000s / $1000s to spend on “enterprise solutions”. We believe a good product can be created that does the required job, follows good usability guidelines and is reasonably priced.
How will you make money?
The product will be licensed in the same manner as Fog Creek’s FogBugz product
- Hosted by us for a monthly fee based on the number of servers being monitored; or
- Hosted on your own server with a license fee based on the number of servers being monitored with ongoing (annual) support/update contract In addition, customers will need to purchase SMS credits to be able to send SMS alerts to phones either from the hosted version or the installed version. Whilst the profit margin on these would be negligible, bulk purchases would add up.
Why is this team the right one for this company?
I believe I have a great deal of relevant experience both running my own software company and working within a larger organisation. This allows me to see things from several perspectives to effectively combine my business experiences with development skills.
If you are incorporated (as a company): who owns what, and what is the detailed funding history? If you are not yet incorporated: who will own what percentage of the company?
The company is not yet incorporated. Forming a company immediately just results in more costs, particularly if you have little or no revenue and still have to pay monthly overheads such as payment processing. We are currently in private beta testing and once that is completed and the product is ready to launch, that will be the right time to progress through the incorporation processes.
I will own 100% of the company.
We are really impressed by teams that get stuff done. Please provide a URL (with login details if necessary) to a prototype of your product, or failing that to a video of a prototype of your product.
http://www.serverdensity.com includes screenshots and a 2 min video demo.
To date, what specific progress have you made in building your product/company (e.g. development milestones, feature additions, customer sign-ups, etc.)?
The product beta was finished on 9 Mar and is now in invite-only beta testing at www.serverdensity.com. We have a small number of beta testers and just (18 Mar) conducted our first phone “beta feedback interview” with a user. Several more are scheduled for the coming week. Development started at the beginning of Feb 09.
What is the single largest competitive threat to your business that you can identify today?
Big Brother and Nagios are the classic, open source server monitoring systems. Commercial providers such as uptimesoftware.com and nimsoft.com also offer “enterprise” monitoring products. Hyperic (www.hyperic.com) could be considered the biggest competitor because they are starting to adopt more “web 2.0″ style marketing projects such as cloudstatus.com. Our product is much more lightweight when compared to these. Simplicity is important, which seems to have been forgotten with the current options on the market. We believe the necessary functionality can be implemented to do the required job without generating a bloated product.
Planning for the worst is a key to great success. Think hard: what might go wrong? How can you minimize those risks?
The most likely point of failure will be lack of revenue to allow breakeven. This is particularly the case if there are overheads such as monthly server costs or payment processing minimum fees. To avoid that, I have only spent a very minimum amount in order to develop and then test the product with beta testers before pushing ahead with incorporation and attempting to charge for use.
What do you hope to get out of the Seedcamp experience?
My primary goal is to use it to raise awareness of the product by meeting people in the same industry, who are the main target audience for the product. Any discussion and/or offers for funding will be secondary.
Who are your main current or potential competitors as well as identified potential new entrants?
See my answer to “What is the single largest competitive threat to your business that you can identify today?”
Does any founder have a conflicting future commitment? If so, what? Are any of you involved in other projects?
Being in the 2nd year of my Law degree in the UK, I plan to complete the final year in September 2009 – June 2010. However, I believe this will have no affect on my ability to work on the company. I ran my software development company – Olate – for 3 years, 2 of which whilst in full time 6th form college. I have also been able to develop the product so far whilst at university full time. That said, there is an option to take a year out or leave the course completely if that becomes necessary. University is great but if it is a choice between that and running a successful company, I will choose the latter.
Does any actual or potential legal restriction or limitation apply to any team member which we should know about (e.g., non-disclosure, non-compete)?
No
Apart from open source software, was any of your code written by anyone not on the team?
No
Let us say you have 15 seconds to pitch your business. Can you describe your business?
Easy server monitoring of your server’s health. Server Density tells you when things are going wrong.
Last week we pushed out our new graphing engine rewritten in JavaScript. It is very similar to the old Flash based graphs but included a few extra features such as the ability to toggle line series and a revamped server view with tabs for each metric. This is the first release of several – we wrote our own graphing because we have need for some additional functionality that was not possible with the Flash charts, plus it allows us to customise the experience to fit our own design.
Timezones are always a pain to work with. Full support for user preferences with timezones was added to Server Density, our server monitoring application, back in March 2009. We do all the timezone calculations server side and pass the Javascript graphs the data in JSON, with the timestamps for each point already converted.
However, it turns out that the JavaScript Date object does its own client-side timezone conversion based on the user’s system timezone settings. This means if the default date on the graph is 10:00 GMT and your local system timezone is Paris, JavaScript will automatically convert that 10:00 to 11:00.
This only works when the timestamp passed is always in GMT and so presents a problem when we have already done the timezone conversion server-side: the conversion will be calculated twice – first on the server, then again on the client.
We could let the JavaScript handle this but for every data point we pass a URL so you can click and be taken to the snapshot. This is provided in Unix timestamp format so even when the JS does the conversion, the snapshot timestamp would still be incorrect. To completely remove the server side conversion and rely only on the JS would require more changes and a lot more JS within the interface.
As such, we modified our getDate function to return the values in UTC, at least it is UTC as far as the JS is concerned but in reality we have already done the conversion on the server. This effectively disables the JavaScript timezone conversion.
This converts the Unix timestamp in JavaScript provided by the server into a date representation that we can use to display in the charts:
getDate: function(timestamp)
{
// Multiply by 1000 because JS works in milliseconds instead of the UNIX seconds
var date = new Date(timestamp * 1000);
var year = date.getUTCFullYear();
var month = date.getUTCMonth() + 1; // getMonth() is zero-indexed, so we'll increment to get the correct month number
var day = date.getUTCDate();
var hours = date.getUTCHours();
var minutes = date.getUTCMinutes();
var seconds = date.getUTCSeconds();
month = (month < 10) ? '0' + month : month;
day = (day < 10) ? '0' + day : day;
hours = (hours < 10) ? '0' + hours : hours;
minutes = (minutes < 10) ? '0' + minutes : minutes;
seconds = (seconds < 10) ? '0' + seconds: seconds;
return year + '-' + month + '-' + day + ' ' + hours + ':' + minutes;
},
All our production servers run Red Hat Enterprise Linux (RHEL) 5 with the system supplied packages for the majority of applications we run, with the exception of PHP which we have a custom compiled version. In the realms of gaining maximum performance then custom compilation of the likes of MySQL and Apache is beneficial but the advantage of using vendor supplied packages is that they are automatically maintained and updated. They are also included within the support SLA we have with Rackspace.
The problem is that the vendor will rarely update to new feature point releases and instead keep things up to date in terms of bug and security fixes only. This means we are stuck with Python 2.4 on RHEL, and we can’t upgrade it as many components will likely break due to specific dependance on Python 2.4.
We have recently deployed some new code that requires Python 2.5 or above and talking with Rackspace, we were able to install a separate Python 2.6 installation through their IUS Community project.
The IUS Community Project is aimed at providing up to date and regularly maintained RPM packages for the latest upstream versions of PHP, Python, MySQL and other common software specifically for Redhat Enterprise Linux. IUS can be thought of as, “A better way to upgrade RHEL” when you really need to.
This provides us with a yum repository we can access to install the latest versions of core packages such as Python, MySQL, Apache (and PHP if we were using it) and although they are not supported by Rackspace, the project is maintained and sponsored by them. Indeed, our Rackspace support team ran the installation of the new version of Python for us.
root@pan ~: wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/ius-release-1-2.ius.el5.noarch.rpm
root@pan ~: rpm -Uvh ius-release-1-2.ius.el5.noarch.rpm
root@pan ~: yum install python26
This installs Python into a separate directory so as not to overwrite the default system installed version:
root@pan ~: rpm -qil python26 | grep /usr/bin
/usr/bin/pydoc2.6
/usr/bin/python2.6
/usr/bin/python2.6-config
And they have repos available for:
RHEL/CentOS 4 i386
RHEL/CentOS 4 x86_64
RHEL/CentOS 4 Source RPMS
RHEL/CentOS 5 i386
RHEL/CentOS 5 x86_64
RHEL/CentOS 5 Source RPMS
Update 26th Jan 2010: Automatically deploying server monitoring across servers
We have just released extensive cloud provider support within Server Density, our server monitoring application. On the most basic level this allows you to automatically import your cloud server instances into Server Density ready to be monitored, but also includes some more advanced functionality where supported by the provider.
This is available right now for all trial and paid users, click the link in the new box on the right hand side of the “Add Server” page. If you wish to extend an expired trial to test it out, just let us know.
Basic functionality for all providers
- Pull in a list of all servers and choose which servers you want to import, automatically populating the fields within Server Density.
- Keep track of the status of cloud servers so when they are terminated, they will automatically be marked for deletion within Server Density. You then have 24 hours to undo the deletion before the data is permanently removed as with a normal server.
Extra functionality for Amazon EC2
If you enable Amazon CloudWatch monitoring on your EC2 instances, Server Density will automatically pull in the data, graph it and allow you to configure alerts. This can be instead of our own monitoring agent or used to supplement it.
With CloudWatch enabled, you’ll get CPU utilisation, disk activity and network activity stats pulled into your Server Density account; you do not need to do anything else – the monitoring will start right away. If you install the agent, our metrics will replace those of CloudWatch except for disk activity, which will be in addition to the disk usage stats our agent provides.
Note: CloudWatch data is a few minutes behind real time.
Supported providers
- Amazon EC2 (US and EU)
- GoGrid
- Linode
- Rackspace Cloud
- Rimuhosting
- Slicehost
- vCloud
- VPS.NET
Video demo – Amazon EC2
Video demo – GoGrid
Video demo – Linode
Video demo – Rackspace Cloud
