openshift and some php app debugging

This morning I was trying to help figure out why a slick new Mediawiki skin was working just fine on an OpenShift-hosted Mediawiki instance, but was totally borked on a second Mediawiki instance, running on a VPS server.

Both the VPS and OpenShift run on the same OS: Red Hat Enterprise Linux. Both were running the same version of Mediawiki, 1.19.2, both had the same version of PHP: 5.3.3.

I compared the php.ini file from the VPS machine with the php.ini from OpenShift, which is findable at ~/php-5.3/conf/php.ini in your OpenShift gear. (You can ssh into your OpenShift instance at the remote “origin” location in your APPNAME/.git/config file).

I found a handful of differences in the ini files, including the promising-looking “short_open_tag” boolean. In my OpenShift app, this was set to “on” and in the VPS, it was set to “off.”

I wanted to fiddle with this setting on OpenShift, to see if I could make the skin break in the same way it was breaking on the VPS, but you can’t modify your app’s php.ini directly in OpenShift. You can, however, change these settings in your .htaccess file.

In my app repo, I created the file “php/.htaccess” including the line ‘php_value short_open_tag “Off”‘ to match the VPS server. After pushing this change up to OpenShift, my Mediawiki instance broke in just the same way that it was breaking on the VPS machine. Broken instance FTW!

After swapping the value to “On” and pushing the change again, my test Mediawiki instance was back up and running.

 

engine-iso-uploader wrinkles

I’ve been installing oVirt 3.1 on some shiny new lab equipment, and I came across a pair of interesting snags with engine-iso-uploader, a tool you can use to upload iso images to your oVirt installation.

I installed the tool on a F17 client machine and festooned the command with the many arguments required to send an iso image off through the network to the iso domain of my oVirt rig. The command failed with the message, “ERROR:root:mount.nfs: Connection timed out.”

I had an idea what might be wrong. The iso domain I set up is hosted by Gluster, and exposed via Gluster’s built-in NFS server, which only supports NFSv3. Fedora 17 is set by default to require NFSv4, and when I changed /etc/nfsmount.conf to make Nfsvers=3, I got around that NFS error — only to hit another, weirder error: “ERROR: A user named vdsm with a UID and GID of 36 must be defined on the system to mount the ISO storage domain on iso1 as Read/Write.”

Vdsm is the daemon that runs oVirt virtualization hosts, so vdsm needs to be able to read and write to the storage domains. I was surprised, though, that the client machine I was using to upload an iso had to have its own vdsm user to do the job. Anyway, I created the vdsm user with the 36.36 IDs, and the command worked.

Engine-iso-uploader does its business with NFS by default, but there’s another option to upload via ssh, which, I imagine, would avoid the need for that vdsm user. I gave it a quick try, hit a new error, ERROR: Error message is “unable to test the available space on /iso1”, and shelved further messing around w/ the tool, for now.

My favored method for getting iso images into my iso domain remains mounting the NFS share and dropping them in there. What I’d really like to see is a way to do this straight from the oVirt web admin console.

 

reinstall

I reinstalled Fedora 17 on my main work machine yesterday — I was having weird issues with gnome-boxes and virt-manager, and thought my problems might have stemmed from the weird libvirt machinations I undertook to get oVirt running on my laptop w/o disabling NetworkManager.

I always keep my home directory in a separate partition to allow for easy clean installs w/o losing my data, but this time around I copied my home directory off to a separate drive to start completely fresh — I’ll ferry needed files and folders back as needed.

One thing I had to go recreate on my new install was a set of tweaks for providing decent font rendering on Fedora. Without these steps, fonts render pretty poorly. I follow the steps in this blog post to mimic Ubuntu’s font rendering options, and then create the .fonts.conf file described here to cajole Google Chrome into obeying the rules laid out in the former step.

I hereby remind myself to look into exactly why it is that the patent fear fairies that prompt Fedora to ship with a crappy-looking font config don’t equally menace Ubuntu. I realize that my employer, with its relatively deeper pockets, presents a more attractive lawsuit target compared to Ubuntu’s sponsor, but if Fedora were to shun every piece of potentially patent encumbered software, there’d be no Fedora at all.

Where to draw the line?

stuck, volume 1

So, I’m working my way through the OpenShift Origin BYO PaaS wiki page, but I’m stuck right now near the finish line.

On Saturday, I was cranking through the howto, highlighting and middle-click pasting my way to BYOP nirvana, until I hit an authentication issue when it was time to create a domain on my newly-minted PaaS.

After taking a break for a couple days, I realized that I’d simply forgotten to point my rhc client at the right host — rhc defaults to openshift.redhat.com, and if there’s an account on the Red Hat hosted server with the user name “admin” I can confirm that that user’s password is not “admin” as well.

Cinch. I’d be up and running in no time. Except I hit another issue — my host complained about: “Permission denied – /var/www/stickshift/broker/Gemfile.lock” and there was no such file on my host. With I bit of help from #openshift-dev, I got past the error by running “bundle install” in the broker directory and then chown-ing Gemfile.lock apache:apache.

But I hit another error message: “Failed to authenticate user ‘stickshift’ on db ‘stickshift_broker_dev’.” Word in #openshift-dev is that this is a mongo issue that someone else following the BYO instructions recently encountered as well.

I’ll circle back to this, but for now I’m going to proceed using the OpenShift Origin image I installed from the LiveCD. I’m copying that image from my notebook, where I’ve been running it on KVM using virt-manager, to my newly-assembled oVirt rig (which I mean to blog about soon) using the handy virt-v2c utility. [dang, stuck there, too]

More to come…

[UPDATE 5/20/12]

Another weekend, another shot at the BYOP. I restored my host back to a “fresh install” snapshot, followed all the directions, and am stuck again at the end of the directions. Getting the error: /usr/lib/ruby/gems/1.8/gems/uplift-bind-plugin-0.8.3/lib/uplift-bind-plugin/uplift/bind_plugin.rb:8: uninitialized constant StickShift::DnsService (NameError).

more test

In general, I prefer Google+ to Twitter. I like posting more than 140 characters, and I like editing my posts if I need/want to (there are other things I like about G+, but this test post is about those first two). I noticed, recently, how people who post wp.me links onto Twitter get their posts, or a portion of their posts, attached to the tweet behind a little photo-style view media link. I’m messing with that right now.

I should say, though, that I’ve been feeling increasingly grumbly about Google+ and its RW API-lessness, and I do like Twitter nonetheless, and, uh, yeah.

Introduction to Theory of Literature — Open Yale Courses

I started in on this course, via podcast, today during my bus ride.

Introduction to Theory of Literature with Professor Paul H. Fry

About the Course

This is a survey of the main trends in twentieth-century literary theory. Lectures will provide background for the readings and explicate them where appropriate, while attempting to develop a coherent overall context that incorporates philosophical and social perspectives on the recurrent questions: what is literature, how is it produced, how can it be understood, and what is its purpose? view class sessions >>

via Introduction to Theory of Literature — Open Yale Courses.