Adjusting your git email address per clone

I’ve been working a lot with git over the years. To that end, I commonly use my personal email address for projects I post on my github. Additionally, I have a project or two in which I participate. The email address I use there is just an alias to my personal email, but I want to use it instead of the email above.

Today, I came across an article that makes changing this value much, much simpler.  Try this:

$ git config --global alias.personal 'config "herlo@personal"'
$ git personal
$ git config
$ git config --global 'config "herlo@work"'
$ git work
$ git config

As you can see, it’s now trivial to switch between certain email addresses. Man, git aliases are very nice!



Posted in Bash, git, Passion, Tech, Tools | Leave a comment

Setting up a FreeIPA Replica

In my last post, I mentioned that I would show how to configure a client with sudo access. Well, I lied! Hopefully that will be the next post. Instead, I’m going to cover how to set up FreeIPA replica.

Replicating FreeIPA services is useful in many ways. Managing DNS, LDAP and Kerberos services, for one. Additionally, it makes sense to have replicas in different VLANs or network zones. Opening up only the ports needed for replication between the FreeIPA servers instead of for all hosts makes things more secure.

All Replicas are Masters

Save for things like running a Certificate Authority or DNS, all of the hosts which run FreeIPA are masters. They replicate using agreements. This means that when a new replica is setup, it will communicate with other FreeIPA servers and replicate to/from only the ones it is allowed to communicate. Further reading is available here.

Preparing for the FreeIPA Replica

Preparing the replica requires setting up the agreement documents on one of the IPA master servers.

$ ssh

$ su -
Password: centos

# ipa-replica-prepare --ip-address
Directory Manager (existing master) password: manager72

Preparing replica for from
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/
Adding DNS records for
Using reverse zone

Copy the Replica gpg Data to the New Replica

The data is now packaged and needs to be put on the replica. The simplest and most secure process is to scp the file directly to the replica. In some cases, this is not possible, and other methods may need to be employed.

# scp /var/lib/ipa/ root@

Install the Replica

Once the agreements are created and moved to the new replica, it’s time to perform the install.

$ ssh root@
root@'s password:

Ensure the replica can contact the master server. Additionally, make sure the replica’s ip address resolves locally. Modifying /etc/hosts is the simplest solution.

# cat /etc/hosts

Set the hostname properly. If it isn’t, correct it by modifying /etc/sysconfig/network.

# hostname

Once all of the above is correct, it’s time to perform the installation itself. Since a replica is just a clone of another master, installing the same packages makes sense.

# yum install ipa-server bind-dyndb-ldap -y

Next, perform the install. Consider options like –setup-ca and –setup-dns as optional, though very useful if those processes are going to be needed on the new replica.

# ipa-replica-install --setup-dns /root/ \
--no-forwarders --ip-address=
Directory Manager (existing master) password: manager72

Run connection check to master
Check connection from replica to remote master '':
 Directory Service: Unsecure port (389): OK
 Directory Service: Secure port (636): OK
 Kerberos KDC: TCP (88): OK
 Kerberos Kpasswd: TCP (464): OK
 HTTP Server: Unsecure port (80): OK
 HTTP Server: Secure port (443): OK
 PKI-CA: Directory Service port (7389): OK

The following list of ports use UDP protocol and would need to be
checked manually:
 Kerberos KDC: UDP (88): SKIPPED
 Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@CODEAURORA.ORG password: ipaadmin72

Configuring NTP daemon (ntpd)
Configuring directory server for the CA (pkids): Estimated time 30 seconds
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
Done configuring certificate server (pki-cad).
Restarting the directory and certificate servers
Configuring directory server (dirsrv): Estimated time 1 minute
Starting replication, please wait until this has completed.
Update in progress
Update succeeded
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
Done configuring kadmin.
Configuring ipa_memcached
Done configuring ipa_memcached.
Configuring the web interface (httpd): Estimated time 1 minute
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Using reverse zone
Configuring DNS (named)
Done configuring DNS (named).

Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files

Restarting the web server

At this point, the replica should start functioning. Since this is a FreeIPA server, make sure to allow successful logins. A reboot is a very good idea.

# authconfig --enablemkhomedir --update
# chkconfig sssd on
# init 6

Once rebooted, login with an existing user.

$ ssh
Warning: Permanently added '' (ECDSA) to the 
list of known hosts.
Creating home directory for herlo.
Last login: Fri Oct 22 12:27:44 2014 from
[herlo@replica ~]$ id
uid=151600001(herlo) gid=151600001(herlo) groups=151600001(herlo)...

Assuming all works well, replication should be working.

If all goes well, I’ll show how to install a client and enable sudo access in the next post.



Posted in FreeIPA, Tech | Tagged , , , , , , | Leave a comment

Introducing FreeIPA – Identity Management (IdM) Done Right!

It has been a while since I’ve posted anything on this blog. It is high time I get something useful up here. Lucky for you, dear reader, I have a series of posts to share. Each of them about a new technical passion of mine, Identity Management.

Many of you probably know of Active Directory. The all encompassing Identity Management solution from Microsoft. It’s is the most popular solution out there, and its got a good hold on the market, for sure. But with almost all things Microsoft comes closed source, GUI only management, and resentment among many.

I’m not saying that Active Directory does not do its job as an IdM solution. In fact, I think it’s a fine solution, if you want to have a proprietary solution, pay a ton of money yearly and not follow standards. In terms of Identity Management, however, it is a pretty good system overall.

The thing is, closed source systems historically have more issues and delays for fixes long term. Until recently, however, there hasn’t been a reasonable open source solution for IdM. Enter FreeIPA, Identity Management done right.

What is FreeIPA?

FreeIPA is a solution for managing users, groups, hosts, services, and much, much more. It uses open source solutions with some Python glue to make things work. Identity Management made easy for the Linux administrator.

ipa-componentsInside FreeIPA are some common pieces; The Apache Web Server, BIND, 389DS, and MIT Kerberos. Additionally, Dogtag is used for certificate management, and sssd for client side configurations. Put that all together with some python glue, and you have FreeIPA.

As you can see from the diagram, there is also an API which provides programmatic management via Web and Command Line interfaces. Additionally, many plugins exist. For example, one exists to set up trust agreements for replication to Active Directory. Additional functionality exists for managing Samba shares via users and groups in FreeIPA.

It’s probably a good time to setup a FreeIPA server and show its power.


Installing FreeIPA is simple on a Linux system. However, there are a few things needed. This installation is being performed on a fully updated CentOS 7.0 system. An entry in the /etc/hosts matching the server ip and hostname is useful. Additionally, make sure to set the hostname properly.

# echo ipa7 >> /etc/hosts
# echo > /etc/hostname

We’ll be installing the server at this time, but there is a client install, which we’ll show in later posts. It’s recommended to use RHEL/CentOS >= 6.x or Fedora >= 14. Simply perform a yum install.

(rhel/centos) # yum install ipa-server
(fedora) # yum install freeipa-server

Once the {free,}ipa-server package is installed. Run the install itself. Since FreeIPA can manage a dns server, a decision must be made. Here, we are going to choose to manage our internal dns with FreeIPA, which uses ldap via 389DS to store the records.

# yum install bind-dyndb-ldap
# ipa-server-install --setup-dns
The log file for this installation can be found in /var/log/ipaserver-install.log
This program will set up the IPA Server.

This includes:
 * Configure a stand-alone CA (dogtag) for certificate management
 * Configure the Network Time Daemon (ntpd)
 * Create and configure an instance of Directory Server
 * Create and configure a Kerberos Key Distribution Center (KDC)
 * Configure Apache (httpd)
 * Configure DNS (bind)

To accept the default shown in brackets, press the Enter key.

WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
in favor of ntpd

Existing BIND configuration detected, overwrite? [no]: yes

The installation explains the process and services which will be installed. Because we’re installing using DNS, some skeleton files exist. It’s safe to overwrite them and move forward.

Next, define the server hostname, and the domain name (for DNS).

Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form

Server host name []:

Warning: skipping DNS resolution of host
The domain name has been determined based on the host name.

Please confirm the domain name []:

The next section covers the kerberos realm. This may seem confusing, but kerberos is one of the big powerhouses behind FreeIPA. It makes registering client systems very simple. Kerberos realm names are always in upper case. Usually, they emulate the domain name.

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [EXAMPLE.COM]: EXAMPLE.COM

Next, configure the passwords for the Directory Manager (for ldap administration) and the IPA admin user.

Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: manager72
Password (confirm): manager72

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: ipaadmin72
Password (confirm): ipaadmin72

Finally, the installer follows up with a request for more DNS info.

Do you want to configure DNS forwarders? [yes]: yes
Enter the IP address of DNS forwarder to use, or press Enter to finish.
Enter IP address for a DNS forwarder:
DNS forwarder added
Enter IP address for a DNS forwarder:
DNS forwarder added
Enter IP address for a DNS forwarder: <enter>
Do you want to configure the reverse zone? [yes]: yes
Please specify the reverse zone name []:
Using reverse zone

Now that all of the questions have been asked and answered. It’s time to let the installer do its thing. A verification step prints out all of the values entered. Make sure to review them carefully.

The IPA Master Server will be configured with:
IP address:
Domain name:
Realm name: EXAMPLE.COM

BIND DNS server will be configured to serve IPA domain with:
Reverse zone:

Then, when ready, confirm the install and go grab a cup of joe. Installation takes anywhere from 10-30 minutes.

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring NTP daemon (ntpd)
 [1/4]: stopping ntpd
 [2/4]: writing configuration
 [3/4]: configuring ntpd to start on boot
 [4/4]: starting ntpd

When complete, the installation gives a bit of useful information. Make sure to open the ports within the firewall. This is beyond the scope here, and is left as an exercise for the reader.

Setup complete

Next steps:
    1. You must make sure these network ports are open:
        TCP Ports:
          * 80, 443: HTTP/HTTPS
          * 389, 636: LDAP/LDAPS
          * 88, 464: kerberos
          * 53: bind
        UDP Ports:
          * 88, 464: kerberos
          * 53: bind
          * 123: ntp

    2. You can now obtain a kerberos ticket using the command: 'kinit admin'
       This ticket will allow you to use the IPA tools (e.g., ipa user-add)
       and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password

Now that everything is installed. One last simple configuration will help. To ensure users can login correctly, use authconfig to ensure home directories are created. Followed by a quick reboot.

# authconfig --enablemkhomedir --update
# chkconfig sssd on
Note: Forwarding request to 'systemctl enable sssd.service'.
# init 6

Once the system has rebooted, point the browser to the newly installed FreeIPA service. Logging into FreeIPA can be done in two different ways; from the browser, or via kerberos. For now, login via the web browser as the admin user.


Once logged in, a useful configurations is necessary before adding users. Change the default shell for all users to /bin/bash. This is done by choosing IPA Server -> Configuration. Once modified, click Update.


Now it’s time to add a user. Choose the Identity tab. Then click Add.


Clicking Add and Edit presents the user’s data. This is useful for adding an ssh key.


NOTE: Don’t forget to click Update after setting the key.

This should now allow ssh into the FreeIPA server as the new user. To make this possible, make sure the new FreeIPA server is configured as a resolver. The simplest way is to update the /etc/resolv.conf file.

# cat /etc/resolv.conf

# host has address

Once the FreeIPA server is resolvable, ssh should now work.

[herlo@x220 ~]$ ssh
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is 42:96:09:a7:1b:ac:df:dd:1c:de:73:2b:86:51:19:b1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
Creating home directory for herlo.
Last login: Fri Oct 10 02:27:44 2014 from
[herlo@ipa7 ~]$ id
uid=151600001(herlo) gid=151600001(herlo) groups=151600001(herlo) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c102

Congratulations! The FreeIPA server is now configured. In the next post, I will cover how to configure a client system and setup centralized sudo.



Posted in DNS, FreeIPA, Tech, Tools | Tagged , , , , , , , , , , , , , , , | Leave a comment

Changing the IP range for docker0

Lately, I’ve been tinkering a lot with docker. Mostly, I’ve been doing it for work at The Linux Foundation. But I do have a desire to have docker instances on my local box for distros which I do not run.

While doing some testing for work on my personal laptop, I noticed that the network which docker uses for it’s bridge, aptly named docker0, was in the same network as one of our VPNs.

# ip a s docker0
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
 link/ether fe:54:00:18:1a:fd brd ff:ff:ff:ff:ff:ff
 inet brd scope global docker0

# ip a s tun0
    inet brd scope global tun0
       valid_lft forever preferred_lft forever

As you can tell, the docker0 network bridge covers all of the tun0 network. Any time I would attempt to ssh into one of the systems inside the VPN, it would time out. I was left wondering why for a few moments.

Luckily, it’s very easy to fix this problem. All that is needed is a defined bridge for docker0 and to restart the docker service. Here’s what to do:

First, stop docker:

# service docker stop
Redirecting to /bin/systemctl stop  docker.service

Next, create the network bridge file. You can choose any IP range you like. On Fedora 19, it looks like this:

# cat /etc/sysconfig/network-scripts/ifcfg-docker0 

Restart your network services.  NOTE: service network restart may be needed.

# service NetworkManager restart
Redirecting to /bin/systemctl restart  NetworkManager.service

The docker0 bridge should now be in a range outside the VPN.

# ip a s docker0
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether fe:54:00:18:1a:fd brd ff:ff:ff:ff:ff:ff
    inet brd scope global docker0

Starting new containers with docker should get IP addesses in the above range:

# service docker start
Redirecting to /bin/systemctl start  docker.service

# docker run -i -t herlo/fedora:20 /bin/bash
bash-4.2# ip a s eth0
141: eth0: <BROADCAST,UP,LOWER_UP> mtu 1412 ...
    link/ether fa:5f:e3:8d:61:f2 brd ff:ff:ff:ff:ff:ff
    inet scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f85f:e3ff:fe8d:61f2/64 scope link 
       valid_lft forever preferred_lft forever




Posted in docker, Fedora, Networking | Tagged , , , | 2 Comments

Fedora Ambassadors Update: February 2013

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in February:

Mon Mar 11 02:53:08 2013 | Accounts: 624 | Inactive: 81 (12.98%)



Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

Fedora Ambassadors Update: January 2013

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in January:

Fedora Ambassador Statistics

Thu Feb 7 12:29:06 2013 | Accounts: 619 | Inactive: 81 | % inactive: 13.09



Yes, the announcement is behind this month. Moving into a new home will do that to you!
Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

FUDCon Lawrence: Day 1 Session Videos and More

While you might have seen the barrage of posts from Fedora’s FUDCon Lawrence this weekend, you might not know that many sessions were streamed for your joy and enrichment.

Here’s a list with links to the videos (all of them are on youtube):



Posted in Fedora, FUDCon, Tech | Tagged , , , , , , , | Leave a comment

Fedora Ambassadors Update: December 2012

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in December:

Fedora Ambassador Statistics



Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

FUDCon Lawrence Hackfest: GPG SmartCard Configuration

As I’ve been working at my new job at the Linux Foundation, we have been implementing quite a bit of two-factor authentication. In fact, back in November, Fedora implemented two-factor authentication for sudo at the Security FAD. I was there and helped setup the clients and did some testing.

While I was there, I had another agenda item, creating a HOWTO for enabling a GPG SmartCard for use with SSH. Of course, the SmartCard can be used for both encryption and signing as well.

After finishing that HOWTO, I was talking about it with a few people within Fedora, and there seemed to be quite a bit of interest. It turns out there was quite a bit of interest, so I’ve decided to do a hackfest on Saturday at FUDCon to help move people over to GPG SmartCards. This is also going to be quite nice in that there will be a GPG key signing event after this hackfest.

Come Prepared – Equipment Required

It’s important you come prepared! If you have ever had interest in this sort of thing, there’s time to get equipment for the hackfest. Here’s what you need:

Both pieces are required. Order ASAP, it takes about 10 days to ship. Consider even shipping to the FUDCon hotel if you are concerned or late. I know Petra will work hard to deliver them as fast as possible.

Doing a Little Prep Work

If you get your Token and SmartCard before FUDCon Lawrence and have a few spare minutes, feel free to read through my HOWTO. If you get through it, come to the hackfest and help others who might not have had time.



Posted in Fedora, FUDCon, Tech | Tagged , , , , , , , | Leave a comment

Well, that didn’t work: GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) Now Available!

The hope was to make a Golden GoOSe available for Christmas, but it didn’t work. Oh well, here’s another release candidate!

GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) is now available for testing. Visit to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC5/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.


Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

Testing can be done by anyone. Please feel free to check our new testing wiki page for information on what tests need to be run and which have already passed. If you have interest in helping us test, thank you, thank you, thank you for the help!

GoOSe Beta-RC5 will be available for 1 week from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!



Posted in Fedora, GoOSe, Tech | Tagged , , , , , , , , | Leave a comment