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.
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.
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.
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
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.
Always look at the top error message in the spew that comes out from the compiler. This is usually where the problem is triggered. Junk after that is often spurious, especially if the first problem is a syntax error.
Use a revision control system like Git or Mercurial, and make a checkpoint of your code when ever you have made a significant addition. This way, you don’t get into the situation where you had it working, you broke it, and you can’t get it running again. Git has a little bit of a learning curve, but it rocks. If you are comfortable posting the code where other people can see, you can push your changes to github, and then if you have a catastrophic machine failure, you don’t lose your work.
The binary search is your friend. If you know that the error is somewhere between lines 10 and 20, Comment out lines 15-20 and see if you still have the problem. If so, comment out lines 13 and 14, and so on. A binary search means that you can search 1000 lines of code in 10 comparisons, and save yourself a metric shit-ton of time. A metric shit-ton is an industry term.
Step through your code in a debugger, line by line, to make sure you know what it is actually doing, not what you think it is doing. Very illuminating. If you don’t have access to a debugger, make liberal use of trace statements. In gcc I often use:
#define TRACE() printf (“%s:%s:%d\n”,__FILE__,__FUNCTION__,__LINE__)
There is something comparable in most languages.
Always work from success. When I start a new C program, I start from
#include
int main(){ printf (“Hello, World.”);}
And compile and run between each minor change.
Don’t be afraid to ask for help. A second set of eyes will often quickly see what you missed. Even more so, when you explain the code to someone else, you often solve the problem yourself. This is known as “verbal debugging.”
The planning meeting was held in Massachusetts. When brainstorming project names, someone mentioned that most New England of activities: Candlepin Bowling. Thus, the project is named Candlepin.
When describing a project, especially something fairly abstract like an entitlement system, you can clarify communication by using a strong metaphor for the system. So, to explain entitlements, I am going to use a bowling alley as my metaphor.
One way to think of an entitlement is this:
An entitlement is contract that you can hook up your computer system to my content stream.
But for our metaphor I’m going to say:
An entitlement is kinda like getting a lane a bowling alley.
To which you say:
Huh?
Think about it. When you go bowling, you pay money, but you don’t get a good, and you don’t get a service. What you get is access to a resource for a limited time. Say a small company wants to do a team building activity:
We’re going bowling!
This company has 18 employees. So, we go over to Westgate Lanes (A nod to the local Candlepin Alley of my childhood. Indulge me) and we walk to the main desk. We’ve self organizaed ourselves into six teams of three people each. We get our shoes, and our group gets three lanes assigned to us. We go, and each team pairs up with another team, the two teams select a lane from the three available, and they bowl. After each game, the teams re-shuffle the match ups, switch lanes and play another game. When each team has played against all the other teams, we return our shoes and go home.
Here is how the analogy maps to entitlement management.
The Data Center is the Bowling Alley.
The lanes are the physical machines that the virtual machines will run on.
The company is still the company paying the bills.
The front desk is the assignment system where you buy slices of time on the machines of the data center.
The three lanes that our company is assigned has a communication network due to the fact that we all need to coordinate our games. This is the VPN and VLAN setup that lets you specify a cluster of machines can all work together.
The pin setter and the ball retrieval and the scoring projector are analogous to the resources required to run the programs.
The score card is the backing store for the database instance that your applications talk to.
We can extend the metaphor to a larger world, too. Say we have a bowling league that spans multiple towns and multiple bowling alleys. This league is composed of teams. The league sets the schedule, the games are played at the various alleys through out the district. At the end of the season, the lead team from our league actually plays against the lead team from another league.
This reflects the hierarchical structure of resource management. You can see that the bowling alley doesn’t really care about leagues except as a way to generate traffic through the alleys. From the Alley’s perspective, the league is just another customer, paying for lane time. Perhaps in some cases, the league pays for the time, in others, the individual teams do. Authority to use a specific lane may have to be cleared not only through the clerk at the desk of the alley, but through the league official that is managing a tournament. Just like if my company buys a chunk of virtual machines on a cloud somewhere, and then delegates them for internal usage.
Note that the metaphor works for internal clouds as well. At the Really Big Company (RBC) campus, they take their bowling so seriously that they have a series of lanes installed into a building on their campus. Now, the scheduling and resource management have been brought in house, but the rest of the rules still apply.