Adam Young’s Web Log

I’m working through the issues getting the unit tests to run cleanly. Here’s my setup:

Continue Reading »

For the past couple of months, I’ve been heads down working on the UI for the FreeIPA project.  Since FreeIPA is designed to be the cornerstone of a companies security management infrastructure, it is designed to do everything “right” as far as cryptography, certificates, Kerberos, SELinux and the like go.  If something is not configured correctly, it shuts down, doesn’t start, breaks, and so on.  We, the developers, deal with the pain of getting it configured correctly so that, hopefully, the end users get an experience that is both smooth and secure.  So, if you are sharing some of that pain, here’s an analgesic:

Continue Reading »

One of the benefits of web APIs is that we can use command line tools to call them. FreeIPA is no different, but perhaps a hair trickier, as it combines the use of Kerberos with a strict JSON format. Getting it right took a little trial and error.

Continue Reading »

(If you can’t guess the tune, get off my lawn!)

Are you posting a Sys Admin’s Req
telnet, CUPS, Sendmail,  and BIND
Consider her I worked with  at DEC
She once was an admin of mine

Have her crimp me a crossover cable
telnet, CUPS, Sendmail,  and BIND
Bridging hub and subnet unstable
And then she’ll be an admin of mine

Have her build me a server of web
telnet, CUPS, Sendmail,  and BIND
Without virtualized overhead
And then she’ll be an admin of mine

Have her craft me a Kerberos Key
telnet, CUPS, Sendmail,  and BIND
But not based on code writ at MIT
And then she’ll be an  Admin of mine

Have her write me a recovery plan
telnet, CUPS, Sendmail,  and BIND
With servers unconnected to SAN
And then she’ll be an  admin of mine

expect is one of the old UNIX tools that people seem to continually rediscover. It is a hole plugger, linking together other tools to do things that you just can’t do any other way, or at least, not without some serious coding.

I am continually deploying and undeploying IPA Server as part of my development. Installing requires, amongst other things, typing in a password at least four times. I was sick of typing it, and decided to turn to expect.

I’m lazy. I didn’t want to learn another Domain specific language. So, while procrastinating by reading man pages and such, I cam across a tool that made my life much easier.

autoexpect

It is basically a macro recorder for the bash shell.  I ran

autoexpect

ipa-server-install –uninstall

And ran through the install process. When I was done, typed exit, and there was a beautiful expect script all ready for me in script.exp.  renamed it t ipa-uninstall.exp.  Same thing for the install process.

I should rarely, if ever have to type those passwords again.

As of today we are in early stages of development on a new UI approach for FreeIPA.  Since the “bits are very fresh” we want to keep from breaking the existing code base.  The policy for the upstream Repo for FreeIPA is that code must pass a fairly strenuous review process before getting checked in, and our code isn’t that way yet.  However, there are two of us  doing UI development, and we need to share our code back and forth prior to checking it in to the main repo.

This is a situation where git shines, and really can redefine your approach to development.  I realize I am a late comer to git.  I’m a bit of a Luddite, and slow to pick up on technologies in general, so this should come as no surprise.  Here’s our approach.

Continue Reading »

With the release of Fedora 13, I have a new target OS for software. In order to deal with the vagaries of installs, I have come to the pattern of creating one VM per target OS, which I get to the starting point, and then clone that for any actual work.

I recently created a minimal F13 VM.  I booted it, and then brought up the network.

This is a minimal install, as I said, which means that it does not have an X install, nor any of the Graphic utilities. In Fedora systems, networking is performed via Network Manager, a User level graphical tool. In order to bring up the network, I was using the “Old School” command

ifup eth0

When I cloned it, and then tried to bring up eth0 from the command line, I got the error message “eth0 does not seem to be present”.

On  Red Hat style systems like RHEL and Fedora, ifup eth0 gets its config info from

/etc/sysconfig/network-scripts/ifcfg-eth0

However, there is a new twist: dev – dynamic device management.  The udev subsystem, when I first booted the “clean” or prototype F13 installed VM, recorded the mac address in:

/etc/udev/rules.d/70-persistent-net.rules

Specifically, the line looks something like this:

# Networking Interface (rule written by anaconda)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:aa:bb:00:dd:01″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″

When I cloned the machine, the clone got a new mac address for the network interface.  Looking in dmesg, I saw a message that eth0 has been renamed to eth1.  When I looked into the rules file above, I saw a second line, with NAME=”eth1″.

When I cloned the machine, the clone process did not know about the subsystem in /etc/sysconfig/network-scripts, so there was not ifcfg-eth1 file created, and thus no networking for the clone.

The solution was to delete the first line, and to change the second line to NAME=”eth0″ and then reboot the machine.  In order to make sure that it has network enabled, I also ran

chkconfig network on

Which should re-enable the old style networking on reboot.

To the Tune of “We’re Ready” by Boston.
Lyrics by Me, idea by Cousin Chris,

Spaghetti galore
Its filling up the void inside you
We’ll make up some more
The garlic bread will have to tide you
You’ll be cleaning the sauce off your clothing tonight
And you know that your pants will be feeling too tight
It builds cellulite
SPAGHETTI!

Gluttony
Who needs a reason
This pasta is great, what is the season–
-ing I feel like I’ve never have tasted before
Don’t worry about what you dropped on the floor
I’m ready for more
I’m ready for more
SPAGHETTI!
With bolognaise

Spaghetti now
Spaghetti for me to chow down
Steady now
Our kitchen will need a hose down
You’ll be cleaning the sauce off your clothing tonight
And you know that your pants will be feeling too tight
It builds cellulite
SPAGHETTI!

XML is not a pretty programming language. I suspect this fact is at the heart of many peoples frustration with maven as a build system for Java projects. I know that it was one of the reasons the Candlepin team decided to use buildr in stead of Maven as the build and package system.

Continue Reading »

If you get the above mentioned error while building an RPM, here’s what it means.  rpmbuild has executed the script:

usr/lib/rpm/check-buildroot

This looks through the files that are set to be installed in your rpm to see if any of them contain the embedded path used to build or install them in the rpmbuild process.    For example, I have my ~/.rpmmacros file set to up with the following entry:

%_topdir %(echo $HOME)/rpmbuild

which means that I build in  /home/ayoung/rpmbuild.  Underneath this directory, I see, amongst other things, the subdirectory BUIOLDROOT.  The current wisdom says that an RPM should use BUILDROOT as the target for any installs.  This is the set of files that get packaged up for the final RPM.  The files here then get checked to see if they have this path embedded in them.  For example, when building rubygem libxml, I see:

+ /usr/lib/rpm/check-buildroot
Binary file /home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64/usr/lib/ruby/gems/1.8/gems/libxml-ruby-1.1.4/lib/libxml_ruby.so matches
Found ‘/home/ayoung/rpmbuild/BUILDROOT/rubygem-libxml-ruby-1.1.4-1.young.x86_64′ in installed files; aborting

There is a simple work around.  in ~/.rpmmacros, add the line:

%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

Which is,  think, a typo, but it shuts off the check.  However, I wouldn’t advise doingthis.

In the case of libxml, the paths are there as an artifact of the build process.  The .so carried the full path to the directory in which it was build as a way to link to the source files, for debuggins.  I can see the path by running:

objdump –dwarf libxml_ruby.so

I don’t have a final solution, because I need to work through the gem install process, but the end effect will be

1. Remove an non-essential files that have this path in them
2. rewrite the path in the remaining files to be the correct location in the final installed location in the rpm

Update:  Since this is a ruby binary RPM, the correct thing to do is to move the gem install into the %build stage and then copy it into ${BUILDROOT}.  It currently happens in the %install stage.  RPM is wise enogh to do much magic in the BUILD stage, such as producing the debuginfo rpm and so on.