Apparently even the venerable Brits, inventors of the original Mini, aren’t immune to the effects of the new MINI craze. Take the quiz at Make Sure It’s a MINI Adventure to make sure you can tell the difference between the MINI and mere pretenders!
I had to migrate a couple of subversion repositories to a new server this morning and ran into some SELinux-related problems. I haven’t figured out why everything worked fine on the old system, but I don’t really care at this point, either… Both systems seem to be completely up to date (according to yum), but the new system didn’t work without tweaking some SELinux-related settings.
All subversion-related stuff is in /opt/local/subversion, with repositories under the “repos” directory. Apache runs as the apache user, and all of the subversion paths were writable by that user.
I was seeing the following in my system logs when trying to access the svn repository:
> /var/log/messages <
kernel: audit(1121779659.741:0): avc: denied { write } for pid=10915 exe=/usr/sbin/httpd name=__db.001 dev=dm-0 ino=655388 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
kernel: audit(1121779659.742:0): avc: denied { write } for pid=10915 exe=/usr/sbin/httpd name=__db.001 dev=dm-0 ino=655388 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
This was after following the SVN FAQ on setting repository permissions (ie. I’d already run the chcon command). A fair bit of googling finally turned up a post to fedora-list advising running this command:
This allowed browsing and committing to the repositories. I’m finding, now, however, that my pre-commit script (and presumably all hook scripts) are failing, with this message in /var/log/messages:
I supressed the impulse to just turn the sumbitch (SELinux) off, but it turns out that the httpd_sys_script_exec_t context was needed in order to allow execute on those scripts. My hook scripts live in the “conf” directory under the subversion directory, so I did the following to make them executable:
I had to do the same thing to allow my viewcvs scripts to run, too.
Grrrrr….
I’ve been going crazy with the Google Maps API over the last few days. After seeing the googlegpx tool (for viewing GPX tracklogs), I got to thinking again about the things I’ve been wanting to do to visualize my own tracklogs. I finally broke down and stuffed them all into a MySQL database and have been able to display them dynamically on the map. AJAX (aka XmlHTTPRequest) rocks. More on that later.
I’ve gushed about the API to a couple of people in the last couple of days, and today had a chance to put my money where my mouth is. Ian posted today about the distribution of his auto-up window circuits for the MINI. He’s been using Tiger maps to render a map of where the circuits are being sent around the country, and in relation to the various MINI dealers in the US. He made some remark about not being able to figure out how to get Hawaii and Alaska on there, and my little brain got to thinkin’. Never a good thing, I know. Ian offered up his data, and in a few minutes, I was able to display his data on the map. I worked for another couple of hours on sorting and selectively displaying points that are only visible in the current viewport and I’m very happy with the results. I’ve gotta work on the filtering algorithm that only displays the first point in a calculated radius, and that radius should change with zoom level, but for now it works. See it in action!
It’s pretty zippy in Firefox, but Safari chokes for quite a while, and then starts responding properly again. I think it may be the sorting that’s a problem, and there’s really no need to sort the data on the fly, as I’m reading it in from a separate file; it should be pre-sorted.
Whee!