I have Fedora running smoothly on my macbook pro hardware as the only os. Its lovely. Little different to switch TTY if you need to hit the console when your desktop takes a turn for the worse.

fn control option F# 

I’m studying for the RHCA exam 423, and one of my tasks is to setup TLS for Directory Server. I know RedHat like to follow standards, and am guessing that I will have to use a CA signed cert when setting this up. So in the name of doing things right, I’m going to setup a little CA that I can work with.

Setting up OpenSSL as a Certificate Authority

I set this CA up on Fedora 16, the official AMI on EC2.

Right out of the box OpenSSL is ready to act as a CA, so this was not that crazy. There is a perl script that does most of the heavy lifting for you.

The Prereqs

Install the CA.pl with the package openssl-perl

[root@ca ~] yum install openssl-perl

The Setup

First I looked to see what the default CA configuration was in the /etc/pki/tls/openssl.cnf.

[ CA_default ]  
dir = /etc/pki/CA # Where everything is kept  
certs = $dir/certs # Where the issued certs are kept  
crl_dir = $dir/crl # Where the issued crl are kept  
database = $dir/index.txt # database index file.  
#unique_subject = no # Set to 'no' to allow creation of  
new\_certs\_dir = $dir/newcerts # default place for new certs.  
certificate = $dir/cacert.pem # The CA certificate  
serial = $dir/serial # The current serial number  
crlnumber = $dir/crlnumber # the current crl number  
# must be commented out to leave a V1 CRL  
crl = $dir/crl.pem # The current CRL  
private_key = $dir/private/cakey.pem# The private key  
RANDFILE = $dir/private/.rand # private random number file  

x509_extensions = usr_cert # The extentions to add to the cert  

# Comment out the following two lines for the "traditional"  
# (and highly broken) format.  
name_opt = ca_default # Subject Name options  
cert_opt = ca_default # Certificate field options

So it looks like the default area for CA stuff is /etc/pki/CA. I saw a ton of guides out there doing things differently, but I find its generally nice to stay to the default the application maintainers steer you to, until you know why it should be different.

Looking in CA.pl I can see that they hard coded that path as well.

$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};  
$DAYS="-days 365"; # 1 year  
$CADAYS="-days 1095"; # 3 years  
$REQ="$openssl req $SSLEAY_CONFIG";  
$CA="$openssl ca $SSLEAY_CONFIG";  
$VERIFY="$openssl verify";  
$X509="$openssl x509";  
$PKCS12="$openssl pkcs12";  

$CATOP="/etc/pki/CA";  
$CAKEY="cakey.pem";  
$CAREQ="careq.pem";  
$CACERT="cacert.pem";  

$DIRMODE = 0777;  

$RET = ;

In that default directory there are already a few things that were created by default in Fedora, the script will create some directories of its own as well.

[root@ca ~] ls /etc/pki/CA/  
certs crl newcerts private

Change into the PKI directory that has the perl script, /etc/pki/tls/misc, and run the script

[root@ca ~] cd /etc/pki/tls/misc  
[root@ca misc] ./CA.pl -newca  
CA certificate filename (or enter to create)  

Making CA certificate ...  
Generating a 2048 bit RSA private key  
......................................   
...................................................................................................................................   
writing new private key to '/etc/pki/CA/private/cakey.pem'  
Enter PEM pass phrase:  
Verifying - Enter PEM pass phrase:  
\---|--  
You are about to be asked to enter information that will be incorporated  
into your certificate request.  
What you are about to enter is what is called a Distinguished Name or a DN.  
There are quite a few fields but you can leave some blank  
For some fields there will be a default value,  
If you enter '.', the field will be left blank.  
\---|--  
Country Name (2 letter code) [XX]:US  
State or Province Name (full name) []:Arizona  
Locality Name (eg, city) [Default City]:Phoenix  
Organization Name (eg, company) [Default Company Ltd]:Makewhatis LLC  
Organizational Unit Name (eg, section) []:CA  
Common Name (eg, your name or your server's hostname) []:ca.makewhatis.com  
Email Address []:david@makewhatis.com  

Please enter the following 'extra' attributes  
to be sent with your certificate request  
A challenge password []:  
An optional company name []:  
Using configuration from /etc/pki/tls/openssl.cnf  
Enter pass phrase for /etc/pki/CA/private/cakey.pem:  
Check that the request matches the signature  
Signature ok  
Certificate Details:  
Serial Number:  
b8:24:1e:f0:87:a0:79:2a  
Validity  
Not Before: Apr 8 04:33:15 2012 GMT  
Not After : Apr 8 04:33:15 2015 GMT  
Subject:  
countryName = US  
stateOrProvinceName = Arizona  
organizationName = Makewhatis LLC  
organizationalUnitName = CA  
commonName = ca.makewhatis.com  
emailAddress = david@makewhatis.com  
X509v3 extensions:  
X509v3 Subject Key Identifier:  
AF:CE:10:A2:B9:EE:6F:1B:F9:67:B0:11:23:DD:C7:02:20:45:E6:1B  
X509v3 Authority Key Identifier:  
keyid:AF:CE:10:A2:B9:EE:6F:1B:F9:67:B0:11:23:DD:C7:02:20:45:E6:1B  

X509v3 Basic Constraints:  
CA:TRUE  
Certificate is to be certified until Apr 8 04:33:15 2015 GMT (1095 days)  

Write out database with 1 new entries  
Data Base Updated

The previous script kicks out cacert.pem and private/cakey.pem, which make up your root certificate/key pair.

This is looking good. Now we can actually do some signing!

Client generates their key

[root@ca ~]# openssl genrsa 1024 > www.example.com.key  
Generating RSA private key, 1024 bit long modulus  
................................   
........   
e is 65537 (0x10001)

Then they generate their CSR (Certificate Signing Request)

[root@ca ~] openssl req -new -key www.example.com.key -out www.example.com.csr  
You are about to be asked to enter information that will be incorporated  
into your certificate request.  
What you are about to enter is what is called a Distinguished Name or a DN.  
There are quite a few fields but you can leave some blank  
For some fields there will be a default value,  
If you enter '.', the field will be left blank.  
\---|--  
Country Name (2 letter code) [XX]:US  
State or Province Name (full name) []:Imagination Land  
Locality Name (eg, city) [Default City]:Up Top  
Organization Name (eg, company) [Default Company Ltd]:Make it So LLC  
Organizational Unit Name (eg, section) []:We dont  
Common Name (eg, your name or your server's hostname) []:www.example.com  
Email Address []:me@myownmind.ee  

Please enter the following 'extra' attributes  
to be sent with your certificate request  
A challenge password []:  
An optional company name []:

Make their certificate

Once the client has generated their CSR and sent it to us, we can actually sign a .crt file for them.

[root@ca ~]# openssl ca -policy policy_anything -out www.example.com.crt -infiles www.example.com.csr

So the client would need to make sure that they import the cacert into whatever application they are using this with. Again remember, this will throw errors if you try to just use it on the world wide webs, since your CA isn’t known by anything.

[root@ca ~] mkdir www.example.com.ssl  
[root@ca ~] cp www.example.com.crt www.example.com.ssl/  
[root@ca ~] cp /etc/pki/CA/cacert.crt www.example.com.ssl/makewhatis-ca.crt  
[root@ca ~] tar cvzf www.example.com.ssl.tar.gz www.example.com.ssl/

Now you can send that file over the the client computer, and they will have a nice signed cert.

(Of course update all this so you arent using my domain)

I’ve decided to take the first of 5 exams to get my Red Hat Certified Architect Certification. The first exam I am going for is the EX423, Red Hat Enterprise Directory Services and Authentication Expertise Exam, which focuses a lot on LDAP.

According to the exam objectives they will be focusing primarily on implementing authentication with Red Hat Directory Server, which is an add-on that is available with a RHEL subscription. Fortunately, like the OS itself, there is an open source version that ships with Fedora, 389 Directory Server.

I’ve never actually had to set this up before, most companies already have this setup when you join. At the company I am with now, there is a whole department that does nothing but ldap/user administration, so we don’t get to touch the internals at all.

Setup Fedora 16

I am using VirtualBox, and just installing F16 fresh. Nothing special, just installing a base server install. Not going into the actual setup here, if you are reading this I assume you can install Fedora, being engineers and all.

Install 389-ds and dependencies

Once my installation is complete, and my box is all updated, I installed the 389-ds package

]# yum install 389-ds

Create non-privileged user

Its recommended to create a seperate user for this, rather than use nobody, since nothing should really be owned by nobody.

]# useradd -s /sbin/nologin ldapuser

Run setup script

Once thats all ready to go, I had to run the setup script:

]# setup-ds-admin.pl

which consited of answering a number of questions about setup, most of which I left default. I did modify the hostname, using an actual domain name I configured for this setup. Seems like it was doing a dns lookup as part of the setup (I could be wrong).

Note: One major difference is that 389-ds has some small changes in the way it works, since its moved to systemd and out of chkconfig. So to start, its no longer:

]# service dirsrv start

instead its:

]# systemctl start dirsrv.target

And to configure start at boot use systemctl instead of chkconfig:

]# systemctl enable dirsrv.target

More to come… I’m done for today

Was running tests this week with Jenkins and Nose on a number of tests in my “tests” directory. For some reason one of my test files kept getting passed up when I ran nosetests on the entire directory. When consulting the google, I only found one other complaint of this, on a google code issue now ported over to github issues.

https://github.com/nose-devs/nose/issues/108

While this doesnt tell how to deal with it, or give any resolution whatsoever, it lets me know that this is something that has yet to be resolved. I got around it by just running a for loop in the shell area in the Jenkins job.

for file in `ls | grep '^test.*.py$'`; do   
       nosetests -v --with-xunit --xunit-file=$file.xml $file;  
done

Had to name the xml files dynamically or they get overwritten, but that shouldn’t matter as long as you just glob the target *.xml in the config section of the Jenkins job.

Sublime Text 2 is constantly getting updates for the dev builds, and not so much on the stable. For those of you who like to live on the bleeding edge, I added a “sublime2-dev” repo. This will contain all of the builds as they are released, which seems to be every few days.

http://www.sublimetext.com/dev

Also added a symlink “/usr/bin/sublime” to make calling files from the command line easier.

To use the new repo just redownload the new repo file and yum upgrade:

~$ sudo wget -O /etc/yum.repos.d/sublime2.repo http://repo.cloudhike.com/sublime2/fedora/sublime2.repo

I was building an rpm for today, and ran into a little issue when packing jar files. After building the .jar file, and packaging it in the rpm, I noticed (actually someone else noticed…) that the .jar files were about half the size when extracted from the rpm, compared to in the sources dir after build.

This seems to be information that is kept in the dark corner of the internet, so after finding the answer, figure I would shine one more light on it.

rpm runs a series of repack commands at the end of rpmbuild, one being “brp-java-repack-jars”

/usr/lib/rpm/redhat/brp-compress  
/usr/lib/rpm/redhat/brp-strip /usr/bin/strip  
/usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip  
/usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump  
/usr/lib/rpm/brp-python-bytecompile  
/usr/lib/rpm/redhat/brp-java-repack-jars

These final commands cause the jars to turn out a different size due to compression, which may cause someone who is not familiar with this function to question the integrity of the package. This was the case for me, and the person for whom I was building the package wanted to see the same jar file that they were building in development.

This is one of those dark corners of the internet, that not too much information exists about, at least not easy to find information. Being a professional googler, eventually I found a solution deep in the RHN.

%define _\_os\_install_post %{nil}

Add the above to the spec file, and bam! no more unwanted commpression. Doesn’t seem like it would, from the look of that line, but it does.

We recently started using Sublime Text 2 at Cloudhike to make magic happen, and I have to say, I’m impressed.

One bummer is that there was no package for Fedora, just a general linux tar file with a compiled binary. This makes installing, updating, and setting up menu items all a pain with Gnome 3. I went ahead and built rpms for the latest version 2139, for Fedora 15/16 both i386/x86_64. These can be found in our repo. We will update these packages as the next versions come out.

To use this repo just download the repo into your /etc/yum.repos.d/ directory. Keep in mind this repo is only for  Fedora 15/16 w/ Gnome3.

~$ sudo wget -O /etc/yum.repos.d/sublime2.repo http://repo.cloudhike.com/sublime2/fedora/sublime2.repo

NOTE: Dev repo is disabled by default, to enable edit the .repo file and change 0 to 1

I love new things, especially new software. As soon as F15 hit, I jumped onto the live cd and was pretty pleased. I installed the alpha as my main OS, with a mean backup solution of my home dir ! of course. I really enjoy the updates Gnome as done in the jump from 2 to 3, I just hate how they come with a cost of gnome-shell crashing frequently. This time I waited until the beta for 16, since there weren’t enough benefits to justify going with the alpha release.

A lot of people I talk to just flat out hate Gnome 3 altogether, which I dont get. I am hoping that Gnome 3.2 will have a lot of the bugs worked out, as they have had a good amount of time at this point to work on that.
So far there doesn’t seem to be too much different, aside from the cool underwater background image. Most of the changes I am hoping to see in performance of Gnome 3, as the first release was a bit buggy.

Kernel 3.1 is installed by default, along with Gnome 3.19 (hopefully soon to be 3.2) and Firefox 7.0, which puts this distro at the bleeding edge of its core components and add-ons. This may come with the cost of some hardships and crashes, but all worth it to try out this new version.

I couldn’t find a decent python wrapper for the dnsmadeeasy rest api, so I fired one up. It covers most of the basic operations that they support.

The functions should be laid out clearly, and just in case I added an example.py file to show usage of most of the functions.

Instantiate the class:

dns = dme("API KEY", "SECRET KEY")

List all of your domains:

domains = dns.list_domains()  
for d in domains:  
    print(d)

Its hosted on github. Get it.

I came across this blog post that explained how to setup cloudfuse on Debian based systems. Cloudfuse allows you do mount your Cloud Files container to a mount point on your server. This could come in useful for backup, restore, etc. Ill go through how to achieve this on Centos/RHEL as its a bit different that Ubuntu/Debian.

1) Install cloudfuse

$ wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm  
$ sudo rpm -ivh epel-release-5-4.noarch.rpm  
$ sudo yum install fuse fuse-devel curl curl-devel gcc git make libxml2 libxml2-devel  
$ git clone git://github.com/redbo/cloudfuse.git  
$ cd cloudfuse  
$ ./configure  
$ make  
$ sudo make install

2) Setup your auth info for Rackspace Cloud Files. These can be set either as mount options or in a file named /root/.cloudfuse

username=[RS CF username]  
api_key=[RS CF api key]

3) add your user to the fuse group

$ sudo usermod -a -G fuse username

4) Get the gid for the fuse group and hold onto it, you need it in step 6.

$ cat /etc/group | grep fuse

5) Create the mount point for cloudfiles

$ mkdir /media/cloudfiles

6) Add the following into /etc/fstab (remember to replace values as they exist on your server, mount point, gid= )

cloudfuse /media/cloudfiles fuse defaults,gid=101,umask=007,allow_other  

7) Finally run the mount -a command to mount the your cloudfiles container.

$ sudo mount -a

At this point you should be able to navigate into that directory and view all the files that are in your cloudfiles account. Have fun.