Amazon just announced a new instance type for High Performance Computing - relevant stats:
* 23 GB of memory * 33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture) * 1690 GB of instance storage * 64-bit platform * I/O Performance: Very High (10 Gigabit Ethernet) * API name: cc1.4xlarge Pricing is coming in at $1.60/hour It is with great pride, I am announcing that we will be a bronze level sponsor for the Debian Developer conference coming to NYC from August 1-7. This is the first time DebConf has come to the US.
A number of Brandorr team members, myself included, are also part of the local organizing team for the conference. If you are coming please drop me a note, and let’s try and meet up. If you are attending come check it out. We will be presenting in Room 200 at 11:10am. We will be demoing spinning up a Drupal instance, and reviewing Amazon's services. Check out the full summary here.
For one of our clients, we use Ubuntu for most of the infrastructure and customer application environments. While the quality of most packages in Debian and Ubuntu is very, very high, we do occasionally come across a package that has minor issues. In this post, I’m going to try to document some of the more common workarounds – these are fixes for corner-cases where the packaging system is doing “almost the right thing”, but where we need to coerce it into doing something a little bit different. Backing up installed packages when you need to test a new package version dpkg-repack is one of the handiest things in the sysadmin’s arsenal, when dealing with an installed system that may be somewhat out of date. The most common usage is this: take an installed package, and use the binaries and metadata that are installed on the system to reconstruct what the installed package file (the original .deb) must have looked like. So if I do: Example
I should wind up with a php5-common_versionnumber-$arch.deb in the current working directory. What’s this good for? Well – if you have to upgrade a package to try out a new version – you can work safely. Even if the version you have installed is no longer in the debian reposito ries – or available anywhere in the distro’s pool-dirs – you can still back up what you’re currently using. Dealing with package file conflicts that prevent package installs or package upgrades It happens fairly frequently that two packages will “disagree” about which package “owns” a particular file. This metadata about files is a fairly important part of a working Debian system, as it lets the dpkg tools figure out what files to upgrade, delete, overwrite, etc, when you upgrade or install a new package. Essentially, one package owns the files and new package installations should not be able to casually overwrite filepaths that they do not own. Usually, this is no big deal – it tends to happen when a package maintainer decides that a file belongs in one package rather than another, or when an older and a newer package (let’s say – libmysqlclient15 and libmysqlclient-dev) both “claim” a file. When this happens, one has two choices as an end user: either wait for the package’s maintainer to release a new point release of the package, and fix the bug, or force dpkg to do the right thing. In the latter case, we might do this: On our system (which we’d been upgrading piecewise from an older Ubuntu (Gutsy) to a newer one (Jaunty, for the benefit of a newer mysql…) ) this overwrites a bunch of header files that libmysqlclient15 had owned.
Odds are that this situation might work itself out with the next release of the package – this is one of those situations where people generally get irritated, and where bugs get filed. If you don’t file bugs on package upgrades, *please do so – you’re helping the maintainer catch a bug that an average user might not know how to resolve, and which increases the overall quality of the package. This is a big win for users, and for other system administrators! These are only a couple of useful tips – there are many features to dpkg, and many different ways in which you can put the packaging system to work for you, or tame it if necessary. If you have suggestions along these same lines, let us know! Cloud Computing Expo March 30th - April 1st in NYC. (and CloudCamp NYC the evening of the 1st)3/27/2009
Wanted to let everyone know that next week is Cloud Computing Expo in New York City. Tickets are still available and I have a line on low price tickets (IE: Free). Please feel free to email me at brian.gupta@brandorr.com if you need tickets.
CloudCamp NYC on the other hand is sold out. (If you really want to go I suggest getting on the waiting list). I am really looking forward to both events, and plan to post my thoughts afterwards. One note of interest. The controversial Cloud Computing Manifesto, has been posted three days early. |
AuthorBrandorr Group LLC is a one-stop cloud computing solution provider, helping companies manage growth and ship new projects using cloud and scalability best practices.
Recent Posts
June 2019
|