Around the time I was hired by Zend, I was asked, along with Mike Naberezny, to fill in for a tutorial session entitled 'Setting up PHP' for the upcoming Zend/PHP Conference and Expo. The basic premise of the session is to give a step-by-step tutorial on how to setup and configure PHP for various scenarios, such as development, testing, and production.
Mike and I have been working in parallel developing ideas and outlines for the session, and I'm fairly excited to have the opportunity. However, if you're attending the conference and, in particular, this session, I'd love to hear any input you might have -- any tricks you'd love to learn, configuration settings you don't understand, use cases you might need. Leave a comment!
Life is in transition for me now. Two weeks ago, we got to bring our handsome baby boy home, and I haven't been sleeping much since (though more than Jen). On top of the sleep deprivation, however, comes more exciting news: I've been hired as a PHP Developer by Zend Technologies!
I was approached by Daniel Kushner in late July regarding another position at Zend, and was flown out at the beginning of August. While I felt the interview went well, I harbored some doubts; work got fairly busy shortly thereafter, and then, of course, Liam was born, and the interview went completely out of my head. Until about three days after Liam's birthday, when Daniel contacted me again about the PHP Developer position.
Work started yesterday, and I was flown to Zend's offices in Cupertino, CA, for orientation and to sit down with both Daniel and others to prepare for the projects on which I will be working. Thankfully, the job will not require that I move, and I will be working out of the 'home office' in Vermont when I return later this week.
The decision to leave NGA was difficult, but the opportunity to work with Zend is just too good to miss. I am honored to be selected by them, and hope this is the beginning of many good things to come.
I've been cobbling together a system at work for the last couple months to allow a single place for changing all network passwords. This includes a variety of database sources, as well as passwd files and smbpasswd files. I've been making use of PEAR's File_Passwd and File_SMBPasswd, and they've greatly simplified the task of updating passwords for those types of systems. However, I've encountered some issues that I never would have expected.
I have the web user in a group called 'samba', and I have the smbpasswd file owned by root:samba. I then set the smbpasswd file to be group +rw. Simple, right? The web user should then be able to update the smbpasswd file without a problem, right? Wrong.
I kept getting errors, and on investigation continually found that the smbpasswd file permissions had reverted to 0600 -- i.e., only the root user could access it. I tried using 'chattr -i' on the off-chance that the file had been made immutable (which didn't make sense, as I was able to see the permissions change). No luck.
Based on observations of when the permissions reverted, it appears that the various SMB processes will reset the permissions! An example is when someone attempts to mount a resource from the server; this accesses the smbpasswd file to perform authentication -- and at this point the file permissions change. I can find no documentation to support this; these are simply my observations.
So, to get around the behaviour, I created a script that will set the file permissions to what I want them, and then gave sudo privileges to the samba group for that script. This script is then called via system() in the update script just before processing.
It's a hack, and could be made more secure, but it works.
Last week, we performed a long needed upgrade to the company file/print/intranet server. Basically, we'd been on a Redhat 8 system, and there were upgrades we were wanting to perform, and couldn't due to lack of libraries. We could have possibly compiled from source in some occasions... but that would likely have shuttled us into a similar dependency hell as using Redhat in the first place.
So, we decided to re-install the OS, and switch to Gentoo in the process. We've found that Gentoo is a great distro for servers -- it allows us to tailor the install to the server purpose, and simultaneously provides a clean upgrade path via portage.
Things went primarily without a hitch. We lost a few databases due to a bad DB backup (argh! there went the wiki!), but that was the primary extent of the damage.
When investigating the sytem post-install, I discovered some connectivity issues with Samba. Basically, when connecting via a *nix-based machine, we were getting symlinks reported as being local to the connecting machine, not the server. This meant that symlinks on the server weren't being followed -- which caused major issues for those connecting via FTP, Mac, or Linux.
Those who follow my blog may remember an earlier entry on form validation. I looked into some of the possible solutions those who commented provided, but other than Solar_Form, each was either trying to generate HTML, or not generating HTML was considered a plugin type of behaviour (i.e., the HTML generation was the norm, and not generating HTML typically added layers). Discouraged, I continued plugging away on my own solution which was incorporating Solar_Valid for validations, adding some filtering, adding the ability to load definitions from a file, and adding the ability to use callbacks for either filters or validation rules.
I got some code together, tried it out, and felt that either something was missing, or I was doing something a little wrong. I posted the code source, and asked Paul Jones for feedback.
After some initial flurries of emails with Paul asking for more detail, me providing it, Paul asking questions, me attempting to answer... Paul had me look at the source for Solar_Form. In doing so, I discovered what he was suspecting, namely, that we were trying to build something similar. Rather than continue on parallel courses, I decided to jump in and help in this aspect of the Solar project.
This past year, Maeve had a month-long unit on Safaris and jungle animals at daycare. One day, she came home singing:
On Safari, on Safari,
In a jeep, in a jeep,
I can see a lion, I will take a picture,
Click, click, click. Click, click, click.
On Safari, on Safari,
In a jeep, in a jeep,
I can see a tiger, I will take a picture,
Click, click, click. Click, click, click.
And so on.
There's a place just over the Quebec border called Parc Safari that we've been hearing about, and today we went up there on a family outing -- one of the last that we'll have with just the three of us (before little Liam is born).
Not long ago, as Maeve and I were en route to Jen's work one evening, Maeve was being very insistent that certain things were a certain way, and was very adamant even as I used a placating tone with her. I asked her, jokingly, "Why are you so contrary today?" Her reply?
"Because I'm so smart, and because I'm so right."
I almost wrecked the car as I guffawed. Kids. They're so dang cute. And so right!
Changes since the proposal include the addition of a static method for retrieving a random fortune from a list of files, the addition of a DocBook tutorial listing several usage examples, renaming the exception classes to conform to PEAR CS, some minor bugfixes, and some streamlining of the package definition.
Included in the release is an example script, phpFortune, that can be used on the command line to get random fortunes from one or more fortune files. Usage is:
$> phpFortune fortunes $> phpFortune fortunes simpsons hitchhiker $> phpFortune
What a way to start the day -- I had an email from PEPR letting me know that my File_Fortune proposal had been accepted!
File_Fortune is a PHP OOP interface to reading and writing fortune files. It is loosely based on the perl module Fortune.pm, but modified significantly to better work with PHP file access methods, as well as to add writing capability.
I will be uploading my initial release shortly, probably as a beta or RC.
So, go fetch those Simpsons, Hitchhiker's Guide, and Star Wars fortune cookie databases and prepare to add random quotes to your site!
I've been doing a lot of thinking on form validation recently. Among other things, I want to be using a standard set of tools for validating form input at work; I'm also rewriting the family website in PHP, and want to have consistency there as well. Finally, I truly buy into Chris Shiflett's top two security practices: filter input, escape output. Validation should always be done, and should be done rigorously; don't allow anything more than is necessary to get the work done.
I flirted briefly in the past month with HTML_QuickForm. Being an observer on the CGI::Application mailing lists, HQF looks like PHP's answer to perl's Data::FormValidator. HQF has a high frequency of posts on the php-pear-general lists. A lot of people seem happy with it. I decided to try it out as an example plugin for Cgiapp for the latest release.
My problem is that I want to be able to define form validation in a file outside my script. The reason for this is that as I extend and reuse classes, I often find that I can use the same general run-modes for a method... just so long as the form validation logic is separate. This allows me, for instance, to decide that in one application instance I will require fields A-M, but in another, I only need A-E (or vice versa). But it requires no changes to the actual application logic, as the validations are kept separately, and I have the application instance indicate which validation file to utilize.