Building a wooden Lensboard for the Schneider-Kreuznach G-Claron 240/11 WA

I recently bought a nice little repro lens, the Schneider-Kreuznach G-Claron 240/11 WA. The Schneider-Kreuznach archive contains some more information on the G-Claron 240

So without a real plan, only a rough idea I went ahead and bought some materials to build myself a little lensboard. With a little wood, some glue and a few nails I quickly threw together that lensboard. Add some felt to make it completely light-tight and you're done.

There are a few slight problems though:

• Focusing on infinity seems very difficult since it's just a matter of a Millimeter wether that house or the horizon is in focus
• Fully open at f11 it's a little dark to work with. Since I can't manage to remove the front element I can't (try to non-destructively) modify the aperture to open up more which sucks quite a bit
• The rail of my little 4x5 sinar f is too short to focus on a close subject like a person's head, which is what I intended to do with this lens in the first place. Update: Just turning the rear stand by 180° would give me the leeway needed for now, for truly format-filling portraits I'd probably have to extend the rail.
  However, it's great fun to take some lamp, place it about 10cm from the lens and project the glowing filament onto a wall 5m away. I did a pretty cool 24x30cm direct print.

But I'll solve those problems too.

Here are the progress pictures:

Tanuki Software's Java Service Wrapper and your Environment Variables

This post has been updated

Here's an evil little gotcha I ran into when using the Tanuki Software Java Service Wrapper to run our company bamboo server. But first you need to know a little bit of context:

We had our bamboo agent running as root for a long time and about two months ago I changed that. I created a bamboo user and installed multiple agents. Each of these into its own folder along the lines of /home/bamboo/bamboo/java-agent-1 etc. Now in each of these is a wrapper script under bin/bamboo-agent.sh. Reading up a bit on the wrapper I found out I can change the script and set the variable RUN_AS_USER=bamboo and then simply create a symlink from /etc/init.d/java-agent-1 to /home/bamboo/bamboo/java-agent-1/bin/bamboo-agent.sh and then start/stop the service just like any other normal unix service.

Ok so that's the situation. Now what happend is, that our maven build (which also creates and signs a bunch of rpm files) suddenly tried to use the gnupg keys from /root/.gnupg instead of the usual /home/bamboo/.gnupg.

So what happened? The agents were initially started under the bamboo user and working fine, then later restarted as the root user and this is where the problems started happening. So it appears, that, if the service is started as root, it may well drop to the bamboo user and run as that, but the $HOME variable (probably the root user's entire environment) has survived and so gnupg didn't do anything wrong, the environment was just pointing to the wrong user. Pretty evil little bug we had there, glad I found it within reasonable time.

How to fix it? I haven't found any information on similar problems by other people let alone an option to force the wrapper to do a clean su/sudo so for now I just put the following snippet into each of the bamboo-agent.sh files let the user (usually me anyways) deal with (read: su - bamboo and then restart the service as bamboo).

Loading ....

Have you had this problem too? How did you solve it? I'd love to hear your solutions. And for everyone else I hope this will save you a few hours hunting down that same or similar problem with the same cause.

Update: 2013-01-07

Big thanks to the tanuki guys who wrote a comment below with the fix (tested and working on my bamboo server) for those affected. In the bamboo-agent.sh in the function checkUser, you need to change

su -m $RUN_AS_USER -c "\"$REALPATH\" $2"

to

su - $RUN_AS_USER -c "\"$REALPATH\" $2"

(instead of "-m" just "-"). And with that the check if we're running as bamboo becomes obsolete!