Mike Willbankshttp://blog.digitalstruct.com
Getting inside the mind of a php developer.Thu, 22 Dec 2011 04:04:16 +0000en-UShourly1http://wordpress.org/?v=4.1RPM Packaging – Building and Deploying your own PHPhttp://blog.digitalstruct.com/2011/12/21/rpm-packaging-building-and-deploying-your-own-php/
http://blog.digitalstruct.com/2011/12/21/rpm-packaging-building-and-deploying-your-own-php/#commentsThu, 22 Dec 2011 03:54:46 +0000http://blog.digitalstruct.com/?p=199I’ve been building all sorts of RPM’s lately, from vim 7.3 to mirroring the zend server repository and building pecl extensions. In the PHP world, one might ask why not just build it from source? Well, an RPM IS built from source and then distributed to many servers – we can ensure that we have the same packages on each, we can maintain the same versions and if you’ve read my previous post on Pirum you will know that I also like mirroring PEAR packages. It allows us to simply maintain our versions on each server and lower the maintenance in a larger environment. Not to mention, since it is on the inside of our network, it is insanely quick for the downloading of the packages and maintaining our servers.

If you are not doing packaging, I hope this entices you to start doing some packaging. I will show you an example of building a PHP RPM based on the distribution (as it is actually how I ensure this server is versioned appropriately and I don’t lose my build from source scripts). Oh; and I’ve only been promising this blog post for approximately 6+ months – so those expecting it; here it is!

Overview

To build an RPM is fairly easy, however, there are a few tools that you will need in order to build everything out:

rpmbuild

rpm-devel

rpm-libs

Once you have these packages, you have everything that you will need to start building out your package.

The Mechanics of a Package

There are a few parts of an RPM package that you will need to know in order to build it.

A Specification File

The Source

The specification file will explain to the rpmbuild utility how we are going to be building out the package and the source is what we are going to be building from. Pretty plain and simple, right?

Specification File

When we are building out an RPM specification file, there are many components that we need to think through as well as a large amount of macros. We will be avoiding many of the macros as they do sometimes change the path as to where we may be installing from. Let’s start with the full spec file and we will explain from there. This file needs to be in “/usr/src/redhat/SPECS”.

There are several items here that are fairly self explanatory. However, I would like to point out 3 of the items just for clarity on what they do. As you can also see we use these as variables inside of themselves.

Source0: the base path of this is what the actual file is at /usr/src/redhat/SOURCES. It should also be the same as where you are downloading from.

BuildRoot: the directory where all of the RPM building should happen, this is where we actually do a build and install into that directory.

Obsoletes: should be used if this package overrides existing packages in the distribution.

Macros

RPM specifications contain several macros that automate much of the behavior for you in order to get everything packaged and up and running. These are a bit out of scope of this blog post, however, you can see the ones that are being utilized from the % sign followed by the actual command. See the Inside the Spec file page to see what some of these mean.

Making the RPM

Now, making an RPM is much like compiling from source code. There are macros that will help you with this such as %prep, %setup, %build and %install. It may seem intimidating at first; but actually far easier than you might originally think.

%prep: is really just a container prior to %build and %setup; which contains the very important %setup! The %setup macro is used to unpack the sources. Generally you might not use the options but in our specific case we want to ensure the directory that it is extracted to. The -n creates the name of the build build directory where these sources will be extracted. Don’t worry about the other param.

%build: this parameter is basically anything that that you would like to be executed by sh prior to %configure this can also be said for the previous sections. In PHP our extremely important variable is our EXTENSION_DIR which is utilized for where our extensions will be placed. We also have a %configure macro which is a short-hand for essentially running ./configure for our configure from source folks. If you seriously need an explanation of this; well google is your friend.

Then we run the make command (remember we are really just talking with the sh shell at this point in time. Don’t worry again about the macro contained in there… it is really just some semantics for jobs running simultaneously. Now you should be ready for all of the installation!

%install: is simply installing everything to our build root (aka “make install”). Since I am using php-fpm and we have a init.d in file we can simply handle that through the install command. As an additional note; if you want PHP to actually build to an RPM there is a single parameter that YOU MUST utilize: “INSTALL_ROOT”. In many other cases this variable is different or not relevant. However, we must use it for PHP to put it into the build root. Miss this parameter and well; forget about it. And we have %clean which simply cleans up anything in the build root.

RPM Installation

Finally; the good stuff. We need to define how to install this on our systems. This includes %pre, %post, %preun, %postun, %files and %changelog. Which simply defines %pre = pre-install, %post = post-install, %preun = pre-uninstall, %postun = post-uninstall, %files = the files to install and %changelog = what we’ve simply changed. Seriously all of these are fairly self definable if you read the RPM documentation. However, we should talk about %files… Insideo %files, you MUST define every single file that will be built; if you do not… well then your RPM build will fail.

The Source

Whenever you define the source in the specification it MUST live inside of the “/usr/src/redhat/SOURCE” directory. If it does not then it will simply not work. Ensure you’ve downloaded the source prior to executing the build.

Execution

In order to execute the build you need to execute “rpmbuild -ba php.spec” within the “/usr/src/redhat/SPECS” directory. After all of this you should have a RPM inside of the “/usr/src/redhat/RPMS” directory which you can install on the platform architectures that follow the current platform architecture. Hope this article serves you well and happy building!

]]>http://blog.digitalstruct.com/2011/12/21/rpm-packaging-building-and-deploying-your-own-php/feed/3Building and Maintaining a PEAR Server with Pirumhttp://blog.digitalstruct.com/2011/02/09/building-and-maintaining-a-pear-server-with-pirum/
http://blog.digitalstruct.com/2011/02/09/building-and-maintaining-a-pear-server-with-pirum/#commentsThu, 10 Feb 2011 04:04:41 +0000http://blog.digitalstruct.com/?p=193Pirum is a simple PEAR channel server manager that was built by Fabien Potencier. The Pirum project allows you to easily setup a PEAR channel and publish your own packages quickly. This quick blog post / article will get you going with it in no time.

Getting Started

There are a few things that you must have already to get going on this exercise (besides PHP and a Web Server *Note: you can do it without these):

PEAR

SSH access

Installing Pirum

To install Pirum we are simply going to be running a few commands against PEAR:

Pirum should now be installed, we now need to setup the pirum.xml file to describe your server.

Creating the PEAR Structure for Pirum

Pirum requires a pirum.xml file that is a very simple XML file. You place this into the directory that you would like your pear server to live. Let’s say for the sakes of this post that it is /var/www/pear. We create a file /var/www/pear/pirum.xml file that contains the following XML (to be explicit you will change the XML values to your liking)

We now need to attach a web server to simply be able to access this directory. In your virtual hosts file or dedicated server add an entry to /var/www/pear that can be accessed from the uri we created in the pirum.xml file. You should not be able to see the index.html file for the packages that are installed in the repository (which is none at this point

Creating a Package

In order to create package, you should have some form of reusable code that is able to be deployed into a PEAR channel. This might be a private or public repository – either way, it is the same exact process. You must first create a package.xml file for the individual package in a top level before your package. Don’t worry, this is not needed on the same environment as we are going to create a .tgz package from it (tar gzip). Once you have completed the package.xml file and have created your .tgz file, we are moments away from being able to add a package into pirum.

Once the package is up on server with pirum – utilize the following command:

pirum add /var/www/pear package.tgz

This will add in the package and now you can install it through the pear repository you have just finished creating. This same exact process is utilized in upgrading packages.

Advanced Topics

Sometimes the main PEAR channel is not going to do it for you. For instance, I have had the need to locally create a PEAR package in our own repository to maintain versions between web servers as well as being able to quickly download and install the package locally. This helps to maintain our versions and upgrade when we need to, not when a new web server is provisioned.

Cloning a Package

Cloning a PEAR package is as simple as downloading the package and modifying the channel in the package.xml file to match the channel of your package. I have made this more simple and submitted a push request – however I currently have no response. The clone command works under linux only at the moment but can be found in my github fork of Pirum. To install it you simply need to replace the pirum file with the one provided in my repository. This adds a new command “pirum clone-package” which allows you to clone an existing package and add it into your repository.

Note: this does not mean it will handle dependencies for you, it will simply clone the package that it was asked to and not modify any dependencies. Seeing as this is how it works, you cannot download two packages that require each other and expect them to be downloaded from the cloned packages without modifying the package.xml file again.

Cloning Packages

A simple package that we have utilized in the past and continue to is Zend Framework. To add it to our repository we simply run:

Under the hoods, this will download the package by utilizing file_get_contents for the download, executing tar command, running simple xml to locate the element in PHP do a string replace on the channel then re-package it and add it into your repository.

Once this is done your package is read to be installed by running:

pear install mydomain/ZF

Conclusion

Pirum makes it easy to control your own PEAR server. Now that you understand how to get it going, utilize it. It is a great tool and makes it far easier to continue adding new packages to your environment or publishing them to the world.

]]>http://blog.digitalstruct.com/2011/02/09/building-and-maintaining-a-pear-server-with-pirum/feed/0Android C2DM with PHP and Zend Frameworkhttp://blog.digitalstruct.com/2010/11/21/android-c2dm-with-php-and-zend-framework/
http://blog.digitalstruct.com/2010/11/21/android-c2dm-with-php-and-zend-framework/#commentsSun, 21 Nov 2010 06:17:19 +0000http://blog.digitalstruct.com/?p=165Update: For the latest please see my github implementation, the code for the underlying Zend Framework implementation has been updated and is maintained there.

So you’ve got a new fancy Android application and you want to be able to send push notifications to the phone. Either for synchronization purposes or for notifications. Since C2DM is fairly new and is currently in the labs it is rather difficult to find code that already handles sending out the notifications correctly.

This article will go through sending a push notification (or message) through the Android C2DM server utilizing PHP in the fashion of a Zend Framework component.

Overview

Sending a message through C2DM can be rather complex as there are fairly strict requirements that Google puts into place. There are several areas that you need to be aware of as well as changes that may happen during the processing of a response. I attempt to encapsulate some of this work in the class handling the sending, however, it is up to the code that sends the notification to properly handle the exceptions thrown. This allows for extremely high flexibility and the ability to hook your own code into this feature.

Requirements

Before we begin there are a few requirements that you will need to have in order to utilize this code to be able to send information to the Android device and create your notification server.

Implementing the C2DM Third-Party Application Server

In order to implement the C2DM Third-Party Application Server we will be utilizing PHP and the Zend Framework. Since Zend Framework already has built-in support for getting the authentication token we will make re-use of that component and simply provide a method for setting the token.

Next we need to ensure that we are properly handling the variances that are coming back from the C2DM server. This can be login based, message based or based on what our user has done on their device. Lets get to the code so we can dissect what needs to happen.

The Library

This library does not have includes in it as we utilize autoloading, if you need includes it is fairly easy to add them all in. This is going to be a lot of code – beware.

Conclusion

This is an easy way to send notifications to an android device. I realize that this is a lot of code and not a lot of detail in text, please ask any questions in the comments and I will get back to them. There is also a wide range of items that you can do on the device through c2dm, this is not just limited to showing a notification or synchronizing data.