Older blog entries for skvidal (starting at number 431)

things I’ve learned today

1. @ IN CNAME someserver.org

is REALLY not allowed and won’t work anytime soon – despite it being reasonable that it should.

2.  [[ $a == something* ]] – is a nice shorthand in bash for ‘startswith’ for string comparison

3. [[ requires you use && and || instead of -a and -o

4. A way to use the git pre-receive hook to bludgeon certain kinds of checks everytime (zone files anyone?)

5. how much about dnssec seems to be somewhat ‘magical’ and not in a good way.


Syndicated 2012-06-13 07:27:04 from journal/notes

mockchain grows a couple more options

mockchain has grown a couple more options:

-r chroot

originally the chrootname was the first argument – but that became an annoyance and limitation for some other plans so I just made it -r. This is now required to make it work

I also made it so the pkgs you specify can be local pkgs or they can be http[s] urls to pkgs. mockchain will fetch and build them for you. This is in order to achieve some other evil plans I have.


Syndicated 2012-05-03 17:12:04 from journal/notes

spherical cow

I wanted to make sure people knew the background on spherical cow:


having worked as a sysadmin in a physics department this was a bit of a running gag so the name amuses me.

It was good to be amused by things while working in the physics dept :)


Syndicated 2012-05-02 16:21:03 from journal/notes

mockchain use cases and examples

I’ve mentioned mockchain a few times here. An interaction with averi today on irc pointed out that I should give some examples of how to use it.

Use case #1:

I have a big pile of srpms – I’m pretty sure they all build, but not sure in what order, I want them all built against fedora-16-x86_64.

 mockchain fedora-16-x86_64 -l /tmp/myrepo –recurse *.src.rpm

That will produce a dir at /tmp/myrepo which has a config and results dir filled with: resulting pkgs and the logs from the build process in a subdir per package.

Inside the results dir there will be a fedora-16-x86_64 dir which is a yum repository and can be referred to in a yum repo configuration like:


name= my repo I just built with mockchain



It will also try to build each and every package and any failures will be tried again after everything else has been built – and this will continue in a loop until either all the packages are successfully built or the failures are identical on two loops.

Use Case #2:

I have a bunch of src.rpms, I want to build them, one at a time. After each package build I want to rsync my packages up to fedorapeople immediately for everyone to use.

for pkg in ~/pkgs/*.src.rpm


mockchain fedora-16-x86_64 -l /tmp/myrepo $pkg

rsync -avH -e ssh /tmp/myrepo/results/ fedorapeople.org:public_html/myrepo


Use Case #3:

I have some new pkgs I want to build for fedora-16-x86_64. I have a remote repository that contains additional pkgs which provide some of my build dependencies for these new pkgs.

mockchain fedora-16-x86_64 -a http://servername/path/to/my/remote/repo -l  /tmp/myrepo -c *.src.rpm


This will give you a repo in /tmp/myrepo/results/fedora-16-x86_64


Just a few examples of how you can use mockchain in your daily operations.

Syndicated 2012-04-20 22:16:07 from journal/notes

mockchain.py –recurse

On a suggestion from kevin – I added a –recurse option to mockchain. It builds all the pkgs it can and records the failures. When it gets to the end of the stack it tries to build the failures again and keeps trying until either: everything succeeds or the set of failures is the same – twice in a row.

Works pretty well to build a giant pile of pkgs and walk away.

I also talked to clark about mockchain and mock and he’s going to pull it in as a script in mock itself once I get it ready.

Here’s the latest version of things:


Try it out and let me know what it needs.


Syndicated 2012-04-19 04:25:28 from journal/notes

mockchain.py update

I added:


 -a url - add this repo url to the yumconfig for the buildroot. This can
          be specified multiple times. Let's you point to multiple
          paths beyond the default to pull build deps from.


Syndicated 2012-04-15 04:24:27 from journal/notes


Talking to halfline today and yesterday I decided to spend a little time playing with this for another project.


mockchain.py [options] chrootname file.src.rpm [file1.src.rpm] [file2.src.rpm] ...

Builds a series of srpms in mock one at a time. After each successful build
of a package it adds the resulting packages to a local repo which
are available to the next package to satisfy buildreqs.

 -c - continue on package build failure - by default it will exit if
      a package fails to build. set this if you wish it to try and continue
      for the rest of the packages.

 -l path - set the path to put the results/repo in. This path needs to be
    somewhere accessible to users other than you for reading as the
    mock process doesn't run as you.

This does not try to sort the packages by build order b/c that is too much 
effort and not obviously doable with the buildreq information we have.

The build process when you use -l is idempotent so a package which has
already been successfully built will not be built again.
If you want to force the rebuild of a package which has been built 
successfully simply remove the 'success' file from the dir with 
the package results in it.

Syndicated 2012-04-13 20:28:06 from journal/notes

ansible basic operating theory explained

Talking on irc tonight pointed out a lacking in the docs of ansible. Specifically, explaining the dirt-simple nature of how it works.

0. ansible has modules – modules are just executable code/scripts in any language you want – there are only 2 requirements:
a. that whatever language you want to write them in is available on the remote system(s)

b. that the modules return json as their results.
1. ansible connects to a host(or many hosts) using ssh

2. ansible shoves across the module(s) you want to run

3. ansible shoves across the arguments you  want to pass to the module(s)

4. ansible runs the modules with the arguments

5. ansible gets back json from the modules and sends it to the calling script/program to be handled and/or displayed.


Now – for a lot of people the only module they really care about it is the ‘command’ or ‘shell’ module – which just lets you run a command directly on the system and it returns the results to the calling program. Pretty handy for any number of things. However, you can write a custom module – which is really nothing more than a script that ansible runs remotely. Ansible just handles the communication/execution part to multiple systems at the same time and return the results back to you, sensibly.

So that’s the dead-simple version of what ansible can do.

How do you as an admin wanting to test it out get started?

git clone https://github.com/ansible/ansible.git

cd ansible

echo “somehost-i-have-root-on” > ~/ansible-hosts

. ./hacking/env-setup

If you have a root ssh key setup then you can run:

bin/ansible all -i ~/ansible-hosts “uptime”

if you don’t have a root ssh key setup then run:

bin/ansible all -k -i ~/ansible-hosts “uptime”


it will prompt you for the root password

Add more hosts to ~/ansible-hosts to talk to more at the same time.


Syndicated 2012-04-11 05:29:40 from journal/notes

playing with ansible more

I’ve been working with/on ansible off and on for a couple of weeks now. I’ve got a simple reinstall playbook created and the basics of how we create new builders.

I was also working on using ansible as an api to port over some tools from func. After getting a bit sidetracked getting it to have a optparser function so I didn’t have to duplicate all those options in ever script I ported the func-host-reboot script over and improved it a bit:

The advantage of using the python interface is I don’t have to write things using the playbook language when I really want to do something more involved and I like the idea of being able to do multiple commands BETWEEN hosts and interplay their results.

I’m thinking that, coupled with kickstart, we should be able to streamline all of our provisioning. Additionally, I’m thinking that the api (esp for the playbooks) should let me play with more ad-hoc builder creation and package build submission.

I’m trying to figure out where this fits.

We have pieces that can do all of these things, mostly, but all of them require some other kind of setup to make work. I have 3 f16 hosts, 1 el6 box and 1 el5 box that I’m testing these against. I run against all of them at the same time and, other than sshd and python none of them have any specific installed on them for ansible to be able to run.

Is a lightweight “clientless” mgmt system a good idea? Is it enough of a feature to make it worth pursuing?

It feels like it helps overcome the pain-in-the-ass quality that is setting up most systems-mgmt infrastructure.

Syndicated 2012-04-11 03:53:32 from journal/notes

fedorapeople.org upgrade

The outage today was to move fedorapeople to a new guest on a machine with more disk space and bandwidth. Things seemed to have gone smoothly. The big change is we made a space for projects that is outside of the normal quota’d userspace on fedorapeople. If you need a project space that’s web accessible (or even not web accessible) file a ticket or let someone in fedora infrastructure know and we can get the space set up for you lickety-split.

Syndicated 2012-03-27 00:21:45 from journal/notes

422 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!