s3cmd will complain about configs…

s3cmd will complain about configs if you’re running it as a different user than the one you have the configs saved as. Makes sense, right?

The setup

I’ve got a launchctl set up that runs a bash script I’ve done up (with some awesome Internet help, which I think I found on a PostgreSQL community site).

This bash script goes through each PostgreSQL database on the server, zips it up and saves it where you want. I use it as a daily dump of what’s on our server.

The problem and the solution

Since the launchctl was running as root, it didn’t have automatic knowledge of the administrator account’s s3cfg file (which is stored under ~/.s3cfg). It would run, backup the database, but not upload it to S3. Looking under the system logs gave me my answer, as s3cmd was complaining about not finding that config file, which had my S3 secret key and things like that (you know, all the important stuff a connection to S3 would need). Declaring the —config /path/to/.s3cfg argument to s3cmd (as you can see in my updated script above) fixed it.

KreegerStudios.com is up

I’ve put up my personal portfolio site — and for the most part, everything looks and functions like it should (the JavaScript-based slideshow bit gives me some problems so I’m taking a look at it).

This marks a pretty landmark moment in my life — actually finishing something I planned to do a long time ago. I bought KreegerStudios.com… maybe 3 years ago now? I don’t know for sure, but it either always redirected to this site here, or to a placeholder page saying my site is coming soon.

Okay, so I enjoy punching myself over being a slacker. You’d enjoy it, too.

Etcetera: nearing 1.0 release

As I’ve been punching away at building Etcetera, I seem to have lost sight of versioning and building anticipation and what-not… and it really doesn’t matter that much to me (nor does it matter to those that are using the system), but in thinking about it, I’ve realized that I probably should have some sort of milestone that I’m building towards, as it gives me a good outline of where I should be headed in terms of features and capabilities. I’ve decided that milestone is the 1.0 release. Once it’s in place, only minor feature revisions will be added to the code base (as well as fixes and things) unless something totally drastic happens (like a mandate from the heavens).

I’m getting closer and closer to the feature goal, and this is a brief overview of what I’ve gotten done so far.

• Actions menu: while this used to be along the ‘headline’ of the page, I’ve moved it to a more expandable box on the right-hand side of the page with a fixed width. I’d like to get it looking better (perhaps at the same height of the whole heading section), but for now, it’s there and it’s easier to add commands to without the concern of running out of room.
• Expanded model fields: in the Checkout model, I’ve added an activation feature (in the form of a datetime form field) that drives the organization of tickets between various sections of the Checkout application. Now the equipment technicians can toggle when they’ve delivered a ticket and it gets timestamped. Better for record-keeping, too. The WorkOrder model in the Service app has a modified department field — instead of a basic text charfield, it’s now a foreignkey mapped to our organizational unit table. There’s an additional department_text field that assumes the old functionality for the public’s benefit.
• Better date/time input: per this post, I’ve implemented something that easily tops the built-in admin date/time picker widget functionality of Django, and it’s a set of form subclasses that use python-dateutil for date/time string validation, and it’s damn good at handling a regular user’s interpretation of the date and time. For most of our public form users, the time picker led to the most confusion, so I used a touch of CSS to hide it temporarily. This serves as the fix in shining armor for that problem. Besides… who in the States likes to use (let alone understand) 24-hour time?
• Per building/department/equipment quick reports: the feature I’m currently working on implements a display of the open checkout and workorder tickets per department or per building on campus. I’ve also added this per equipment; instead of open tickets, it shows everything prior. And I think it’s a paginated list. Can’t remember.
• Google Charts API integration: a cool thing that I was working on but kinda put on the backburner. Google’s got a great easy-to-use charts API that I’ve learned how to use. There’s even Python bindings available for it. Problem is there’s not a whole lot of good documentation on using it, so I’ve had to do a lot of tinkering with it. I’m hoping to have it ready with the 1.0 release, but no promises there.

You can track my progress on Etcetera’s GitHub page, if that’s your thing. If not, I should be posting more updates soon about things as I gear up for that 1.0 release!