In Defiance of Titles

Just another weblog

Posts Tagged ‘installation

Distributing Zend Framework Modules

with 8 comments

It’s been almost a month now since the release of Zend Framework 1.8, and although I was very excited about some of the new features, it’s taken me awhile to digest that excitement into something bloggable. As a result, I apologize if I’m a bit late to the party…but I’d like to take a moment nonetheless to discuss the implications of my favorite 1.8 feature: Zend_Application_Resource_Modules.

Zend Framework has provided what it calls a “conventional modular directory structure” for quite some time now: specifically, Zend Framework modules are supposed to “[allow] you to separate different MVC applications into self-contained units, and re-use them with different front controllers”. Unfortunately, up until 1.8, I have never found this to be entirely accurate. Based on module architectures I’d seen in full-stack content management systems, I’d always kind of hoped that installing a module would be as easy as this:

  1. Download the source code and copy it into your application’s modules directory.
  2. Hooray, it works now!

Now, this was true enough for modules that only provided a couple controllers and view scripts, but the second you introduced, say, controller plugins or models in the include_path, you’d have to modify your application-level bootstrap file, providing it with detailed knowledge of what the module provides. Because of this, the framework hasn’t really inspired a lot of distributable, reusable third-party modules; after all, the process for installing them would actually have looked something like this:

  1. Download the source code and copy it into your application’s modules directory.
  2. Adjust your application entry point (index.php) to include the module’s models folder in the include_path.
  3. Adjust your application-level bootstrap file to register the new modules directory with the front controller, if you haven’t configured it that way already.
  4. Adjust your application-level bootstrap file to register any plugins or plugin paths it might provide.
  5. Install any database schemas that might have come with the module.
  6. Hooray, it works now!

The problem here is that the parent application (and the person installing it) has to know all sorts of nitty-gritty details about how the module does its business. In my opinion, a truly “self-contained” module would be able to handle a lot of the above process all by itself, without any modifications to the parent application; otherwise, it’s not really self-contained, and not particularly easy to distribute to other developers.

Enter 1.8

However, as I mentioned earlier, this situation has changed dramatically in Zend Framework 1.8, due to a wonderful little component called Zend_Application_Resource_Modules. Among other things, it provides the following:

  • Modules can now provide their own bootstrapping logic; no more need to register module-provided plugins, paths, etc. in the application-wide bootstrap file.
  • Autoloading of common types of module-provided classes is now automatically set up for you; no more need to add modules to your include_path, or even to require_once your module class files before you use them.

See the benefit? All of the application-level configuration we used to have to do can now be encapsulated in a bootstrap process provided as a part of the module itself. This cuts the above workflow down to something like this:

  1. Download the source code and copy it into your application’s modules directory.
  2. Install any database schemas that might have come with the module.
  3. Hooray, it works now!

Suddenly, the prospect of downloading somebody else’s reusable module is a lot more appealing.

Some further issues

You’ll notice, however, that this still doesn’t quite match my first ideal workflow. Although Zend_Application_Resource_Modules provides a lot of assistance in getting your modules bootstrapped once they’re installed, it cannot yet provide much assistance with the installation process itself. As a result, if you’re trying to install a distributed module that involves database schemas, you’ll still have to install those by hand.

It’s also worth noting that Zend_Application_Resource_Modules does not yet provide a way to track and enforce module dependencies. For the most part this isn’t necessary; by the time everything is bootstrapped, all module-provided code is available through autoloading. However, there are a couple of situations in which it would be necessary:

  • If Module A needs to use a class provided by Module B during Module A’s own bootstrap, Module B must have been bootstrapped first…otherwise the autoloader for Module B’s classes won’t be ready yet.
  • If Module A provides a plugin that, for whatever reason, assumes that a plugin from Module B always fires before it, then Module B’s plugins need to be registered before Module A’s.

I’m working (in my copious spare time) on a distributable module of my own right now that could really benefit from both dependency tracking and database installation…but with how much better module architecture has already gotten in 1.8, I can only assume that future releases will be even more elegant. In the meantime, keep an eye out for my new module; I’d love the benefit of community review once it’s ready.


Written by jazzslider

May 21, 2009 at 7:43 pm

My Home NAS, Part 3

with 2 comments

Now that the hardware’s put together, the next step is installing the operating system.  As I mentioned earlier, my goal here is to install Debian Etch (actually, for reasons related to my backup policy, I ended up going with Debian Lenny; the install process is almost exactly the same, but you get slightly newer software) onto the onboard CompactFlash card without having to install an optical drive to do it.  I considered doing a PXE network install, but it looked pretty complicated given that I don’t have any other servers in my network setup…so instead, I set up a bootable SD card installer and worked from there.

I thought setting up the installer would be a bit easier than it actually was, given the simplicity of these instructions in the Debian installer guide.  However, despite my typically well-performing network setup at home, the process landed me right here:

DHCP fail: "Your network is probably not using the DHCP protocol. Alternatively, the DHCP server may be slow or some network hardware is not working properly."

Long story short, the network interface on the Wind PC is a Realtek RTL8111/8168B, and its drivers are either unsupported or unavailable in the Linux kernel version used in Debian Etch.  However, there is a slightly later version of Debian Etch (quaintly referred to as etchnhalf) that combines the stability of Etch with the later Linux kernel used in Lenny (the next Debian release). I initially tried to fix this by using the Debian “etchnhalf” distribution instead, but unfortunately I ended up needing a newer version of the backup utility duplicity than is available in any Etch distro. So, the following instructions will actually get you the appropriate install media for Debian Lenny. Christmas comes but once a year.  To get the SD installer working in this configuration, you can use the following script on any currently-functional Debian machine (I did it on a VM).  First, however, a couple of warnings:

  • This procedure will totally erase anything you’ve already got on your SD card.  Make sure you back it up first.
  • For safety’s sake, I’ve left it up to you to determine the device special file for your SD card (or, for that matter, any other USB device you’d like to use).  You can figure it out pretty easily:
    1. First, take the card out of the machine.
    2. Then, run tail -f /var/log/messages so you can see what new device shows up when you plug the card back in.

    In my case it turned out to be /dev/sdd …but don’t take my word for it, run the test yourself. You don’t want to overwrite the wrong device!

Once you know which device you’ll be writing to, you can copy and paste the following code into a file, make it executable (chmod +x filename), and run it with the device filename as its sole argument (e.g., if you save it as “createbootsd”, you’d run ./createbootsd /dev/sdd).


# The $1 argument should be the full path of the SD card's device special file.

# Download the Debian Lenny boot image file
cd ~

# Write the boot image file directly to the USB/SD device
zcat boot.img.gz > $USBDEV

# Mount the device onto the filesystem
mount $USBDEV /mnt

# Download the installer CD image to the device
cd /mnt

# Unmount the device so it's safe to remove it
cd ~
umount /mnt

When that’s finished running, you’ll have yourself a nice, working Debian Etchnhalf Lenny installer from which you can boot the Wind PC and start the process.  As you can see, DHCP configuration now works just fine:

DHCP success!

DHCP success!

The rest of the installation process was really quite uneventful.  On nearly every screen, you can just choose the defaults, especially when it comes to selecting a network mirror for the package manager. There are, however, a couple of settings worth noting:

  • You’ll need to give your machine a host name early on in the installation. You’ll probably end up using this host name a lot when you connect to the machine over the network, so pick something you’ll enjoy remembering.
  • It’ll also ask you for a domain name. In my case, I used a domain name I pulled from my router’s configuration page. In practice, I don’t know that this will matter too terribly much for a home network, and the installer says as much.
  • Since I didn’t yet have a working hard drive at the time of this installation, partitioning was very simple.  I just created a single partition taking up the full CompactFlash card and mounted it as the root filesystem.  No swap space is necessary here; the machine’s got plenty of memory, and swapping to the CF card could seriously reduce its lifespan. The steps for this, once you get to the “Partition disks” screen, are as follows:
    1. Choose “Manual”.
    2. Select the disk from the list; it should have “hda” in its name, since it’s the /dev/hda device.
    3. When asked about creating an empty partition table on this device, choose “Yes”.
    4. It’ll take you back to the first screen, but there should now be an entry right underneath the original “hda” entry, whose label ends with “FREE SPACE”. Select that entry.
    5. Choose “Create a new partition.”
    6. The default partition size should be fine, since we just want a single partition using up the entire device.
    7. Choose “Primary” when asked what type the new partition should be.
    8. The next screen gives you a variety of options for setting up the filesystem on your new partition. Here are the settings you’ll want to use:
      • Use as: Ext2 file system
      • Mount point: /
      • Mount options: check “noatime”
      • Label: none
      • Reserved blocks: 5%
      • Typical usage: standard
      • Bootable flag: on

      When you’ve got it configured, choose “Done setting up the partition.”

    9. Choose “Finish partitioning and write changes to disk.”
    10. It’ll warn you about how you haven’t set up a partition for swap space; don’t worry about this, as we definitely do not want a swap partition on the CF card. That’d wear it out pretty badly. Choose “No” to get past this message.
    11. One more warning screen; when you’re asked to write the changes to disks, choose “Yes”.
  • The Debian installer at one point asks if you want to install any of their various predefined collections of software; since I’d much prefer to install everything myself later, I just chose the “Standard system” option:
    Choose "Standard system"

    Choose "Standard system;" we'll install everything else manually later on.

  • And, of course, make sure to install the grub boot loader when asked.

And that’s the basic installation!  You can toss the SD card installer now if you like, since the NAS is ready to boot itself from CompactFlash, like so:

Ready to boot

Ready to boot

Next time I’ll show you what steps I took post-installation to secure the machine and make it run more efficiently; then, eventually, we’ll pop in a hard drive and get our RAID-1 array going.

Written by jazzslider

November 9, 2008 at 10:12 am

My Home NAS, Part 2

with one comment

Well, the hardware’s here…at least most of it.  Aside from the defunct Hitachi Deskstar I mentioned in Part 1 of this lovely series, everything else has arrived intact and ready to go.  So, I thought it might be a good time to post some notes on the assembly process.

First, I should mention that installing a CompactFlash card on the motherboard of the MSI Wind PC is like no other CompactFlash card installation I’ve ever experienced.  Given the amount of disassembly required, I’m glad I don’t intend on swapping it out that frequently.  Due to the small form factor of the machine and the position of the hard drive chassis, case walls, etc., it is pretty much impossible to install the CF card without completely removing the motherboard.

Some advice for those of you following along at home: the motherboard is attached to the case, not just via the obvious four screws at each corner, but also in another area:


Dont forget to detach the RGB connector when you remove the motherboard.

Don't forget to detach the RGB connector when you remove the motherboard.

Yes, I know, kind of stupid of me.  Anyway, once the four main screws and the RGB connector have been removed, the motherboard lifts out pretty easily.  Here’s the bottom of it, which I hope to never see again:

Once the motherboard’s out, installing the CF card is as easy as ever; just slide it right in.

You can also see in the picture up above that I went ahead and installed my 512MB RAM stick; that part didn’t require any major disassembly; just popped it right in.

The next major bit of assembly was the hard drive; at the time I didn’t know it was broken, so I went ahead and installed it.  This was quite a bit easier than the CF card, and only required lifting the drive chassis out for a short while to mount the drive properly.

I made sure to connect it to SATA port 1 (the blue cable) per the instructions.

And that’s it!  Had the hard drive not been broken, that would’ve been the end of the assembly process.  Very easy overall, I’d have to say.  However, as I’ll show you in my next post, installing the OS was a bit more interesting.

Written by jazzslider

November 9, 2008 at 1:00 am