Building Custom RPM Packages in CentOS
While I'm sure there are plenty of *nix hackers out there who like building open source packages from source, I'm not one of them. I'm a fan of using a package manager, and since CentOS is my server distro of choice, RPM it is. While CentOS (well... RHEL) has a vast array of packages available and EPEL adds even more, not every package under the sun that you might want to use is available or as up to date as you'd like.
Guru Labs has an excellent write up on creating RPMs. I can't recommend it enough. But, in the "Enough to be Dangerous" spirit, here's a brief guide to how I create custom RPM packages.
Create your environment
While I have a nasty habit of doing a lot of things I shouldn't do as root, creating RPM packages isn't one of them. One of the problems I have with the whole untar, configure, make, make install as root process is that you don't really know where things are being put. Building RPMs as a regular user should prevent any unintentional intrusions into your nice, stable, OS.
I start by creating a bin directory in my home directory. Then I put in a file named cleanrpm with commands from the Guru Labs guide.
cd ~
mkdir bin
vim cleanrpm
Here is the contents of my file.
rm -rf ~/rpmbuild
rm -rf ~/.rpmmacros
mkdir -p ~/rpmbuild/{BUILD,RPMS,S{OURCE,PEC,RPM}S}
mkdir ~/rpmbuild/RPMS/{i386,i586,i686}
echo "%_topdir $HOME/rpmbuild" > ~/.rpmmacros
echo "%debug_package %{nil}" >> ~/.rpmmacros
Make your script executable and run it to create your directory structure.
chmod +x ~/bin/cleanrpm
You'll also need to install the Development Tools package group. Yes, you're going to compile some code here, but it will be done in a controlled environment.
sudo yum groupinstall "Development Tools"
Going to the source
Where you go from here depends on what kind of resources you can find for the package you want to work on. The best case scenario is to find a source RPM package. Often, you'll find the package you want, but it's source RPM is intended for Fedora or an older version of RHEL. Sometimes these packages will work fine if you just rebuild the RPM. Things will usually work best if you use a source RPM package intended to something close to your target. Packages for RHEL or Fedora will work better on CentOS than ones for SuSE or Mandriva.
I'm sure there's an easier way to do this, but this is how I do it. Install the source RPM in the environment you just set up - not as root.
rpm -ivh somepackage.1.2.3.src.rpm
This will, at the very least, put a .spec file into ~/rpmbuild/SPECS. It will most likely put a tarball into ~/rpmbuild/SOURCES and possibly some patch files.
Often, from here it's simply a matter of building the package.
rpmbuild -ba ~/rpmbuild/SPECS/packagename.spec
If you go through all the compile process and such and end up with an exit status of 0 and you see that some RPM files got written, you're probably golden. If you get errors, you might have to edit some things in the .spec file or take more drastic steps. See the Guru Labs guide mentioned above, or Google it if you're feeling lucky.
The next best senario is that the source tarball you download contains a .spec file. Typically, from here its a matter of copying the .spec file in the ~/rpmbuild/SPECS directory, and the source tarball into ~/rpmbuild/SOURCES. Once again try to build the package with the rpmbuild command. Again, if you run into errors, refer to Google or invest the time to read and Guru Labs guide.
The last scenario I'll mention is when you're faced with no source RPM and no .spec file. Sadly, there is no easy path from here. You'll simply have to invest the time in doing the deep dive into RPM creation. The oft mentioned Guru Labs guide has an example of this very scenario. If I reach this point I tend to look for another solution to the problem I'm trying to solve because, well, my time is just too valuable for this. (That should read as, "I'm lazy.")
Enough talk. Let's do this thing!
Recently, I found myself with a need for a package named sendpage. I couldn't find a ready-made package for it, but was delighted to find that the source tarball contained a .spec file. The README mentions that it's intended for SuSE, but we're going to give it a shot.
I already have my RPM creation environment ready so, I'll download the latest stable version of the package.
wget http://sendpage.org/download/sendpage-1.000003.tar.gz
I'll untar the package...
tar -xzvf sendpage-1.000003.tar.gz
And, I'll copy the .spec file and the source tarball into the right places.
cp sendpage-1.000003/sendpage.spec ~/rpmbuild/SPECS
cp sendpage-1.000003.tar.gz ~/rpmbuild/SOURCES
And, throwing caution to the wind, let's try and build this sucker.
rpmbuild -ba ~/rpmbuild/sendpage.spec
OK, we've run into a snag. It looks like the .spec file is referencing a version number different from what we've got.
error: File /home/dstoliker/rpmbuild/SOURCES/sendpage-1.tar.gz: No such file or directory
Don't panic! Let's fire up our trusty text editor and see if we can't coax it into working. It looks like all we need to do is update the version number of the package to match the filename. Change this line:
%define pkgversion 1.000003
OK, give it another try. On my particular system, RPM complained that it needed some additional packages installed. So... install them.
sudo yum install perl-Device-SerialPort perl-Net-SNPP perl-MailTools
On my system, I ran into one more snag - I was missing a needed package that wasn't listed in the .spec file's "Requires" list, so I added it.
Requires: perl perl-Device-SerialPort >= 1.0.2 perl-Net-SNPP perl-MailTools perl-DBI
If you already have the package installed, you won't get this error. On my third attempt, I was met with success! We could be done now, but one last thing to do now that we have a successful build would be to update the changelog on the .spec file. Edit your .spec file one more time and add something like this to the top of the list following the %changelog section:
* Thu Jan 12 2012 me@mydomain.blah - Updated version to match source file - Added perl-DBI to Required installed package list
This will help you keep track of when you last modified the file, and also the changes you had to make to get it working.
OK, build it one more time.
rpmbuild -ba ~/rpmbuild/SPECS/sendpage.spec
You'll find the RPM(s) in the ~/rpmbuild/RPMS directory structure - depending on the architecture you're using. This particular package (since it's written in Perl) is in the noarch subdirectory. Now, you can copy your package somewhere for safe keeping and install it.
sudo rpm -Uvh sendpage-1.0.0-1.noarch.rpm
If you'd like to see what files got put where, use this handy command:
rpm -qil sendpage
Be sure to tuck a copy of the source RPM away as well. You'll find it in the ~/rpmbuild/SRPMS directory. It will contain not only your modified .spec file, but the all the source files that go with it. If you need to make changes or updates, you won't have to start from scratch.
When you're all done with this packaging adventure, clean up after yourself by running the cleanrpm script you created earlier.
That's it! You've built a custom RPM package for your system. Hopefully this inspires you to take on more daunting packages - like something not written in Perl. Happy Packaging!
Unobtrusive Magento Modifications
As much as we all love Magento, there are times when we need it to do more for us. Fortunately for us, the good folks that bring us Magento had the foresight to open source the code, so we aren't held captive by the vendor hoping they'll implement a feature we crave. However, having access to the source code is a double-edged sword. Sure, we could just go in the code and change whatever we want. But, once we go down that path, upgrades become a nightmare and we risk compromising the quality of the overall core. Therefore, we want any customizations we make to be unobtrusive.
There are 3 basic ways to properly modify Magento code. Properly modifying simply means that we will not be changing any of the core files.
Override - create the exact same folder structure as the class you are trying to override in app/code/local/Mage. This file will be called instead of the one from the core folder.
Rewrite - redirect a specific core class to another class.
Observer - create a custom listener to handle events generated by the core.
Let’s take these one by one and describe the pros and cons.
Override
This will completely replace the core file with your own version of the file. This is useful for those parts of Magento that are incredibly hard to get to. The downfall to this is that when the core file is upgraded, you get none of the upgrade functionality and often times will find that you have to manually figure out how to get your override to work with the new core functionality.
I tell our developers only to do this as a last resort and it has to be approved before it’s placed into production.
Rewrite
This works somewhat like overriding. You can create your module with your own class and then setup a rewrite telling Magento that you would rather the core file be found in this other class. The key here is to only include functions that you want to overload and have your class extend the core file. This will allow you to just replace one function from the core code leaving it a bit more manageable when time for an upgrade. This is my preferred method if using an observer is not possible.
Observers
If your situation allows it, using observers is the best way to go. This is the least obtrusive way to modify code. The core code will fire off an event of some kind. Your custom code will listen for that event and do what’s needed. Read more on using observers...
Using Observers to Modify Magento
Using observers is really quite simple. Let's jump in and see an example of setting up an observer.
Our simple observer will process additional information when a customer submits an order. I recently used this type of observer to add a "source" field on an order.
Identify the event and necessary parameters
First, we will need to identify the event that will trigger our observer. In our case, the event name is sales_order_place_before. We found this observer in the dispatchEvent function in app/code/core/Mage/Sales/Model/Order.php. Typically, we'll only need to find the event in the Magento core code, this is just to reference what the event will be passing.
The dispatchEvent function takes 2 parameters. First, the name of the event as we are defining it. Second, an array of objects or values to pass to the observer. In our case, the order object is passed as "order".
Mage::dispatchEvent('sales_order_place_before', array('order'=>$this));
Build the function
Next, we'll write the code.
class Irps_ModuleExample_Model_Observer{ public function processOrder(Varien_Event_Observer $observer){ $order = $observer->getEvent()->getOrder(); //extract the order object that was passed from the event $order->setSourceCode('some source code'); return $this; } }
Configure Magento to use the observer
The only thing left to do now is to tell Magento that we are listening for an event and that we want to run our new function when we see it.
app/code/local/Irps/ModuleExample/etc/config.xml:
<global> <events> <sales_order_place_before> <observers> <irps_moduleexample> <class>Irps_ModuleExample_Model_Observer</class> <method>processOrder</method> </irps_moduleexample> </observers> </sales_order_place_before> </events> </global>
Note: This is not all of the config.xml file
That's it! We've identified the event we want to listen for. We've created our custom function that we want to execute when the event occurs. And, we've configured Magento to allow us to handle the event.
I have used observers many times to modify functionality in Magento and it is, by far, the most friendly method when you upgrade Magento. Of course, you will still want to test all of your functionality before pushing out an upgrade.
Share with us some of the ways that you have used observers in the comments.
Email Hosting with Google Apps – Fantastic and Free!
Maybe I've been living under a rock. I've heard a lot about Google Apps for Business but it wasn't until recently that I learned about the free alternative - Google Apps Standard. It's pretty amazing what you get.
- Up to
5010 users (Google reduced the number of accounts in May of 2011) - Each mailbox has the standard Gmail capacity (about 7.5GB and growing)
- Shared Calendars
- Fully functional mobile e-mail for smart phones (depending on what you have)
- Google Docs, Site, Video, and Groups
This has to be the cheapest way to establish a business class Internet presence out there - just pay for your domain and you're pretty much set. On top of that you get a great set of collaboration tools. But, first things first - let's get email up and running for a domain.
Before you begin
For this to work, you need a domain (or you can buy one from Google) and the ability to alter your domain's DNS records. That's it.
Let's get started
First, go to the sign up page (opens in a new window) and click on the Get Started button.
Enter your domain name and click the Get Started button (another one).
On the next page, you'll be asked to fill out some personal information.
Next, select a username, enter a password, decipher the captcha, and accept the legal stuff. If you get Google's notoriously difficult to read captcha right on your first try - congratulations, you're my hero!
Sign in, Please
You'll be redirected to a login screen. Use the username and password you just entered. Accept the privacy agreement. Now we need to prove that we own the domain we're signing up for. There are two ways to do this. You can either post a web page or set a CNAME record in DNS.
If you already have a web server up and running, the web page is probably the easiest option. On your web server, create a file named googlehostedservice.html. Or, create the file on your local machine and upload it to your server. Make sure you have it in the root of your web directory. The file should contain the code Google provides you. It will be something like googlefffffffff0a1b23c. You don't need any HTML tags or anything else in the file. Once you've got your file in place, test it. Google provides you a link on the page to do so. (Thanks, Google!) Click the button indicating that you have your file ready for Google to check.
Google says it can take up to 48 hours to verify your domain. In my experience (three domains so far), it's taken a couple of hours. Your mileage may vary.
Activate Email
You'll be taken to a page and offered to launch the Setup Guide. If you don't feel like reading up on it, you can skip it for now. You'll start off in the Dashboard. Since the whole goal of this write up is to get email up and running, we'll go ahead and click on the Activate email link.
This is where you'll need to make sure you can edit your DNS records so that you can point your domain's MX records at Google's servers. This will probably be the most tedious part of the process - depending on the pain your DNS tool inflicts upon you. Google is kind enough to supply instructions on how to edit your DNS for several providers.
Once that's done, Google will need to verify your MX records. They say it can take up to 48 hours, but again, my experience so far has been about two hours. Take into consideration that it might take time for DNS to fully propagate.
Once Google verifies everything, you're good to go!
Five Things Apple Could Learn From Dell
I’m a Mac switcher. All my computers at work had been Dell branded. But, then a 17″ MacBook Pro entered our department for testing purposes and I kind of adopted it. I’ll admit I was drawn to it by its looks at first. The display is spacious and gorgeous. The all silver appearance with that glowing Apple logo is just plain cool looking. The trackpad is so much better than any other I’ve used. The keyboard that lights up in dark – brilliant. But, what really won my over was OS X. A *nix terminal at my fingertips was the biggest selling point for me. So, I released my Dell D630 back into the pool and made the MBP my primary machine at work. But, a few years later down the road, there are some things I miss.
Dell Complete Care
Dell, from the admittedly very little research I’ve done, seems to be the only major player to offer a comprehensive warranty. They have “Complete Care” which covers accidental damage. If someone looses one of the little rubber feet on the bottom of their laptop, Dell will replace it. If someone drops their notebook and cracks the display, busts a few keys off the keyboard, and mangles the outer plastics Dell will replace it. Most of the support reps aren’t stingy at all about it. They’ll even ask if there’s anything else wrong with the machine that needs to be replaced even if its cosmetic.
Shortly after adopting my MBP, I was riding the train home and a strap on my backpack broke. Much to my relief, my Mac still worked just fine but the ugly dent on the side is a stinging reminder of the incident. I’m not sure how to spin this. On the one hand, it’s nice that it was tough enough to survive the fall. On the other hand, does Apple really want people going around with scratched and dented MBPs? I’m almost certain that part of the reason Dell offers to repair cosmetic damage is that they don’t want people (potential customers) seeing Dell notebooks in bad repair. You’d think that Apple, with their seeming obsession with appearance, would be all over this.
There are a couple of things I should point out. I’m sure the Apple fan boys are hyperventilating over the fact the Dell equipment tends to require more repairs than their Apple counterparts. There. I said it. You can relax now.
While Dell technical support reps are usually very happy to get the repair set up for you, I absolutely dread making the phone call. I know I’ll be on the phone for a minimum of 30 minutes while the tech troubleshoots with you for a while, determines what (if anything) needs to be replaced and – this is the part I hate – repeatedly put you on hold while they get the repair set up. Note: If you don’t buy the Gold support, expect to talk to someone overseas.
Update:
One of my co-workers sent his MBP in for repair since it had a faulty DVD drive. The LCD panel had some problems, it looks like it had been subjected to some pressure. As it turns out, if you get a piece of equipment serviced with AppleCare, they won't do a partial repair. They were not going to replace the defective SuperDrive without getting paid to replace the LCD panel. They ended up replacing everything at no cost anyway since the repair had got off to rough start. (FedEx delivered the shipping box to the Apple Store instead of our office. The Apple Store lost the box.) I believe our Apple sales rep got involved and pushed it through.
On-Site Service
Dell offers next-day on-site service. If one of our Macs needs repair, it has to be shipped in for service and you’re down a machine for a week or more. If one of our field people drops their Dell and busts the display, Dell will send a tech out to fix it on-site usually the next day.Apple, why can’t you offer something like this? We asked our sales rep this very question. His suggestion is that we get some of our staff Apple repair certified. So, I’ll give that a shot and that might work out for our people in the office, but our field people are still out a computer for a few days.
Modular Hardware
Another nice thing about the Dell notebooks is that they’re modular. Need to replace a hard drive? Two screws release the hard drive and four more screws free it from the bracket. I replaced the hard drive in my MBP (it’s out of AppleCare coverage by now anyway) and it was like minor surgery. DVD drives are hot-swappable and can be swapped out for an extra battery. If the Superdrive in your MBP breaks, you have to ship it away for repair.
While maybe not “modular”, Dell notebooks have the option of internal cellular broadband cards that are accessible either under the keyboard or via an access panel on the bottom. On my MBP, I have a USB modem that hangs off the side. I just know one day it’s going to get snapped off by someone sitting next to me on the bus. It’s clunky.
Complete Keyboards
While I really enjoy the feel of the keyboard on my MBP, it’s far from perfect. If I want to use the home, page up, page down, end, or forward delete keys, I have to hold down the “fn” key. Dell keyboards (and probably the rest of the world) has discrete keys for these functions. If I’m running a Windows VM and happen to need the Insert key… I guess I’m out of luck. Apple keyboards only have the “crtl” and “alt/option” keys on one side of the keyboard. And what’s with the separate “enter” and “return” keys? It must be a throwback to days of yore like the scroll lock key on PC keyboards. I have yet to find a use for it. Steve was all for scrapping the Firewire port, but has to hang on to the “enter” key?
Consistent Function Keys
Every time a new version of the MBP comes out, Apple has to switch around what the F-keys do. Make up your mind! How on earth is switching these around all the time improving usability? On a Dell, Fn-F8 has toggled the display mode for as long as I can remember. Enough said.