Linking Launchpad and Bugzilla

While the Bugzilla command line tool does a lot of useful things, one feature it is missing is the ability to link a bug to an upstream bug in a remote tracker. Working with the Web UI can be slow. Martin Kozek, of FreeIPA fame, wrote a simple Python program to link them together for me using direct XML-API calls. Thanks Martin:

#!/usr/bin/python
#
# Authors:
#   Martin Kosek: mkosek@redhat.com
#
# Copyright (C) 2013  Red Hat
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see http://www.gnu.org/licenses/.

import bugzilla
import sys
import xmlrpclib

URL = 'https://bugzilla.redhat.com/xmlrpc.cgi'
USER = 'user@redhat.com'
PASSWORD = 'bar'

try:
    bz_id = int(sys.argv[1])
    launchpad_id = int(sys.argv[2])
except Exception:
    sys.exit("Usage: bz_lp_link bz_id lp_id")

proxy = bugzilla.RHBugzilla3(url=URL, user=USER, password=PASSWORD)
proxy.connect(URL)

LAUNCHPAD_TRACKER_ID = 29

try:
    proxy._proxy.ExternalBugs.add_external_bug(
        {'bug_ids':[bz_id],
         'external_bugs': [{'ext_type_id': LAUNCHPAD_TRACKER_ID,
                            'ext_bz_bug_id': launchpad_id}]
        })
except xmlrpclib.Fault, e:
    sys.exit(e.faultString)

Who holds the keys to the Kingdom

During the years I worked as a Web application developer, it seemed like every application had its own authentication mechanism. An application developer is thinking in terms of the domain model for their application whether it be eCommerce, Systems management, photography, or weblogs. Identity Management is a cross cutting concern, and it is hard to get right. Why, then, do so many applications have “user” tables in their databases?
Continue reading

Read Only LDAP in Keystone

Organizational data is held in publicly accessible directories accessed via the Lightweight Directory Access Protocol(LDAP).  In general, the end applications have the ability to query via  LDAP, but not update it.  Up until Grizzly the OpenStack Identity management Service, Keystone, has required write access to the backing store if you wanted to be able to manage authorization from within OpenStack.  This mismatch has been addressed in Havana

Continue reading

Autoregistering an OpenStack Virtual Machine with FreeIPA

FreeIPA offers many benefits to an OpenStack deployment: Single Sign on and DNS-as-a-Service among others. In order to take advantage of freeIPA, the new host needs to be registered with the FreeIPA server. Here’s how to automate the process.

I started out with a FreeIPA server deployed in an a virtual machine inside out teams OpenStack based cloud. The server manages a domain that I have taken the liberty of calling openstack.freeipa.org. This is a non-public deployment, so don’t expect to resolve the DNS records yourself. However, IPA likes to work with Fully Qualified Domain Names, so I created one that is self documenting.

For my virtual machines images, I am using the Fedora 19 Cloud image. This is a very bare bones virtual machine.

The general steps to take in order to deploy are:

  1. Allocate a Floating IP address
  2. Generate an One Time Password (OTP)
  3. Create a Host entry in FreeIPA, using the IP Address and OTP
  4. Generate a user-data script
  5. Boot the virtual machine
  6. wait until the machine is running
  7. Allocate the Floating IP address to the Virtual Machine

Once the virtual machine is running,  the user-data script performs the following tasks:

  1. Sets the hostname of the virtual machine to match the VM name and the domain name of the IPA server
  2. Sets the FreeIPA install as the DNS server
  3. install freeipa-client via Yum
  4. register the host using the OTP

Here is the code:

#!/bin/bash
. ./keystone.rc

#These values should also come out of a configuration file:
#they are specific to your deployemnt

PUBKEY=ayoung-pubkey
IMAGE_ID=94d1dbba-9e65-471e-97d0-eb7966982c12
FLAVOR_ID=3
SECGROUP=all
DOMAIN=openstack.freeipa.org
NAMESERVER=10.16.16.143

OTP=`uuidgen -r | sed 's/-//g'`

#this should be initialized if does not yet exisit: 
#the index is an integer.
#it provides a way to keep each VM unique

INDEX=`cat index.dat`
VM_NAME=$USER-$INDEX

#get first floating IP
FLOAT_IP=`nova floating-ip-list | awk ' $4~/None/  {print $2 ; exit }' `

ipa host-add $VM_NAME.$DOMAIN --ip-address=$FLOAT_IP --password=$OTP

#increment  the index for next time
echo $(( $INDEX + 1 )) > index.dat


#Generate the user-data for postboot configuration
cat << END_HEREDOC > $VM_NAME.dat
#!/bin/bash
echo $VM_NAME.$DOMAIN > /etc/hostname
hostname $VM_NAME.$DOMAIN
echo nameserver $NAMESERVER > /etc/resolv.conf
yum -y install freeipa-client
ipa-client-install -U -w $OTP
END_HEREDOC

nova boot   --image $IMAGE_ID --flavor $FLAVOR_ID --key_name $PUBKEY --security_groups $SECGROUP  --user-data $VM_NAME.dat  $VM_NAME

#wait until the VM is out of the BUILD state before continuing
#otherwise, adding the floating IP might fail
while [ `nova show $VM_NAME | awk ' $2~ /status/ { print $4 }'` = BUILD ]
do
sleep 1
echo -n .
done
echo
echo  adding floating IP address $FLOAT_IP to $VM_NAME

nova add-floating-ip $VM_NAME $FLOAT_IP

There is more work do be done, here. DHCP integration would be preferable to this manner of munging resolv.conf. Without that, the image need to be modified to prevent DHCP from updating the resolv.conf if the VM is ever rebooted.

Care must be taken when deleting the host entries allocated to virtual machines. Since they have DNS A records, IPA will complain if you attempt to reuse an IP address without first cleaning up the DNS A record. To delete a VM, remove it from both IPA and nova like this:

nova delete ayoung-31
ipa host-del ayoung-31 --updatedns

Special thanks to Jamie Lennox for editing support.

IPTables rules for FreeIPA

I end up editing this so much, figure I’d post it here for all to use.  This is the standard IPtables config file augmented with those rules required to let through the protocols supported by FreeIPA

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

#TCP ports for FreeIPA
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 88  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 464  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53  -j ACCEPT

#UDP ports for FreeIPA
-A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT