One year in Berlin, one year at Red Hat

July 1st, 2012

In March 2011, I signed my contract with Red Hat and moved from Zurich to Berlin, as posted here in April 2011.

After one year it is time for a review of my “new life”. At once, a lot of things changed in my life: New Country, new City, new Appartment, new Job. Quite a lot of stuff.

At my former job, I had a notice period of three months which gaves me some time for the planing of the move. A lot of burocracy was waiting for me, both in Switzerland and in Germany.

Getting an appartment
The first challange was to get an appartment in Berlin. I went to Linux Tag 2011 in May to have a look to quite a few appartments. It was not that easy as I was told from different people. Gentrification is not only a problem in Zurich, but also in Berlin.

The chicken and egg problem. In order to get an appartment, you need a “Schufa-Auszug”, a paper that “certifies” your creditability. Usually it is only possible to get this paper when beeing a resident in Germany. How to get a resident without an appartment when you need a Schufa-Auszug to get an appartment when you need a residency in Germany and therefore need a Schufa-Auszug?

So I went to a Schufa-Shop and it took me 30min of explaining the clerk that the processes at real estate brokers ar completly idiotic but I need the paper. So I finally got the Schufa-Auszug with my old address in Zurich.

Finally I was able to sign a contract with a land lord. The appartment and its location is very nice and very close to the excellent public transport (although, Berliners grumble about the S-Bahn trains, it is excellent compared .i.e to Munich).
As you can see in the picture, it is close to Alexanderplatz, the new City center of Berlin, just two underground train stations away to the west. Two underground stations to the east, and I find myself in the Party Neighborhood (Kiez in Berlin-Speak) at Simon-Dach-Strasse. Walking south, crossing the Spree river and I find myself in the vibrant Berlin Club scene.

A special feature of the appartment is the roof top terrace where neighbors meet for partying. Quite uncommon for Germany: There are washing machines available, so I dont need to buy one. Also quite uncommon in Germany: The appartment has a kitchen, no hassle to buy the stuff.

Preparing the move
The usual stuff like getting rid of old stuff and putting the rest into moving boxes is straight forward, as well as finding the movers. More complex is the coordination of the due dates for all the stuff.

Paper work part one
Since Switzerland is not in the customs union of the EU, it adds more complexity. I need two papers: The stamped registration form of Berlin, and the stamped levaing form of Zurich.

Getting the first form is straight forward: Just do a online-reservation at the registration office (Meldeamt at Bezirksamt), getting there and walk out after 10 minutes. Myth busted: German bureaucracy is always complex

The latter one cost a shitload of money. You get it from the Zurich tax office, but only if you pay the guesstimated taxes upfront, in cash!. Of course this means you need to fill out a lot of forms upfront, what an annoyance. Myth busted: Swiss bureaucracy is alwas easy.

The next task was then to get a health insurance. Since a lot of Germans are living in Switzerland, I just some good advices upfront, easy stuff. Now it was time to cancel all contracts such as Internet access, mobile phone contract, insurances and getting new contracts in Berlin.

Emigration
I had a early start at Red Hat, so I left Switzeland on 26th of June, went to a training in Farnborough, UK spending the weekend in London and getting straight to Munich for another training and finally arrived in Berlin on 05. July 2011. In fact I was homeless for 1.5 weeks, sleeping in hotels. The first two days my furniture has not yet arrived, sleeping on the floor in a sleeping bag.

Paperwork part two
Soon after the registration in Berlin, I got my tax payer ID number. I also needed to fill out a form with a rather complex title “Antrag auf Bescheinigung für den Lohnsteuerabzug” (something like application for a certificate for the income tax deduction). I needed to show up at the Finanzamt (Tax Office) and unlike the forms title suggests, it was painless.

Another important task was the application for change my Swiss driver license into a German one. The pitfall is that one needs to apply in the first six months after immigration or to jeoppardize the whole licese. Well I had to wait more than two months to get the license exchanged.

Assimilation
Left wing politicians do not like the word. From my point of view, foreigner should assimilate them reasonably. For me that was very easy since Switzerland and Germany has a lot in common. The same political and cultural values and – for northern Swiss people – the same language (well, kind of). Of course I needed to adapt my German getting rid of typical helvetisms which are not understood in Germany or understood in the wrong way which can annoy some Germans.

In meantime I got assimilated even better: I watch soccer matches ;-)

The foreigner
Everyone is a foreigner, nearly everywhere (unknown quote). So yes, I’ living as a foreigner now.

Almost everyone welcomed me in Berlin and other German cities where I was working and I quickly got new friends. The average German is generally more open minded and cosmopolitan than the avarage Swiss (especially when comparing Berlin with Zurich)

When I’m looking back to Switzerland and see how some people treat Germans: Its a shame! I wish that this mind will change in Switzerland and Germans are treated the same friendly way as I’m treated in Germany.

Living in Berlin
The crazy thing about my working contract with Red Hat is: I got offered to be based on a choice of four locations where Red Hat has offices: Munich, Stuttgart, Frankfurt and Berlin. I have already visited the first three cities multiple times, but I was never in Berlin before, just heared its a nice city. Well, Munich is beatiful but expensive and the Airport is only reachable by air. Stuttgart is a bit boring, Frankfurt hmm… So I was taking the risk and choose to move to Berlin without much knowledge about the city.

Well, I’m now living in Friedrichshain, just north of Kreuzberg.

Berlin is cool! I mean: Really cool! I guess you can not find any other europeen metropolis which offers a greater diversity of culture, food and of course people. Going to clubs in Berlin on weekends is a delight. You can find clubs for almost every style of music.

Culinary: Well, the Currywurst and Döner Kebap was invented in Berlin, but this are not the real highlights. In the Simon-Dach-Kiez as well as near Alexanderplatz one will find restaurants with food from allover the planet. Thai, Vietnamese, Bulgarian, Chinese, Russian, Korean, Japanese, Italian… you will find them all. There are even Swiss restaurants, but I never made it yet.

Public transport: Awesome! A S-Bahn train every two to five minutes, same applies to underground trains. During the weekends, S- and U-Bahn are operating the whole night, without any idiotic night-surcharge, and of course there is a train every approx. 15min. From my point of view the public transport in Zurich looks like a really bad (but expensive) joke.

Long distance high speed ICE Trains are also awesome. Berlin-Hamburg (approx 300km) in 1:39h. Zurich-Geneva (approx 300km) in 2:43h

home sickness
The first few weeks have been very hard for me. Yes, I had home sickness. I left all my friends in Switzeland and I miss the beautiful old towns of Zurich and Winterthur as well as the mountains. What I really miss is the “third dimension”, it is all flat here, the highest elevation in Berlin are the Müggelberge (Berg means mountain, what a fool) with 114,7m above sealevel. Before I left Switzerland I was not aware about how beautiful the Alpes are, it was just a matter of course to always have them in sight.

In the last 12 months I have been visiting Switzerland three times. I have enjoyed those trips, visting my old frieds, having a BBQ country side and strolling trough the old towns of Winterthur and Zurich.

Whats the better country for a living? Germany or Switzerland?
This is a question I hear all the time. My answer is always the same: Neither of them are better, those countries are just different, but not that much.

My job as Senior Linux Consultant at Red Hat
When Red Hat approached me, I first was surprised, then I got a contract and I got it very fast :-)

It is a very interessing and challenging job. As a consultant I’m visiting a lot of customers to help them with particular technologies in their projects. Every customers has its own processes and infrastructure, so I need to adapt very fast.I also travel a lot, customers are usually located in central europe, mostly in Germany. Somethimes it happens that I can travel a bit further, for example, my customer engagement in Kuala Lumpur, Malaysia was an impressive experience.

Travelling means to see a lot of different locations, that makes it even more interessting. The drawback is being only at home for the weekends.

At the end of the day, Red Hat was the best that could happen to me, a open source guy. Lots of nice and very competent and open minded collegues in a international team and the possibility to always get in touch with the latest and greatest technology in the open source world.

Having fun? Yes, sure…

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

FUDCon 2012 Kuala Lumpur, Malaysia

April 4th, 2012
FUDCon 2012 Kuala Lumpur

FUDCon 2012 Kuala Lumpur

Since I’ll be in Kuala Lumpur anyway, I take the chance to visit the upcoming FUDcon (Fedora User and Developer Conference) which will take place May 18th to 20th at the Asia Pacific University College of Technology & Innovation. I dont know yet if I can be there all three days, but at least days 2 and 3.

I’m really glad to meet the Fedora people from another continent. I’ve been visiting Malaysia back in 2009, it is a very beautiful country with nice people. So this time my visit is different, combining vacation and some nice Linux stuff.

Looking at the list of talks, it will be interessting to join those sessions. Unfortunately it is too late for me to prepare a talk. The only thing I miss is the annoucement of a social event, maybe I have overseen it?

See you there… Have fun!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

Retrospection to FOSDEM 2012 Brussels, Belgium

February 6th, 2012

This year I made it, It was my first time at FOSDEM, the Free and Open Source Developers European Meeting. I was amazed about the crowd of people and the amount of talks. It was simply impossible to visit all interesting lectures, because lots of them has been held in parallel.

It was also a pleasure to meet again all those people I know from the open source communities. The Friday beer event was very nice, as well as chatting with people between and after the lectures.

From my pint of view, the most important talks have been the inside views to oVirt and the presentations about the Deltacloud project. It was also important to get more informations about Aeolus . Most of the for me important talks are bound to cloud and/or virtualization projects. This is because I’ll hit those project sooner or later on my job as Linux consultant.

Lessons learned
I’ll try to get to Fosdem 2013 if time allows. But next time I’ll be better prepared for the inconveniences of the venue.

  • If the weather will be the same as this year, three layers of clothes are not enough, in some auditoriums the temperatures have been close to the freezing point.
  • If it is heavily snowing, touch screens of smart phones are going berserk, navigation not possible, taking a old style navigation device with me as well a paper city-map
  • If you wait for the bus, you need to wave hands if the bus approaches or it will simply pass you and letting you wait for another 20 min at -15°C
  • Having a hotel near “Gare Central” is a big plus, it is near the Delirium Cafe where the Friday beer event happens as well as on the route of Bus Nr. 71 to ULB
  • SMS messages in Belgium obviously have usually a delay of a few hours and are not reliable, calling friends costs much more but does the job
  • Mobile internet access is not always reliable in Belgium, since I dont know the city very well, I’ll take a off-line navigation Phone with me (my old Nokia E72)

A huge thank you
I would like to thank all the volunteers who organized the event and made it an unforgettable event, as well as the countless speakers sharing their knowledge with the world

Upcoming events
The next upcoming interesting events in Europe:

  • Chemnitzer Linux-Tage 2012 March 17th and 18th
  • LinuxTag 2012 in Berlin (my new home town) May 23th to May 26th.

If I missed an event to mention here, let me know.

Have fun!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

Identity Management with IPA Part II – Kerberized NFS service

December 25th, 2011

In part one I was writing how to set up an IPA server for basic user authentication.

One reason NFSv4 is not that widespreaded yet, is it needs Kerberos for proper operation. Of course this is now much easier thanks to IPA.

Goal for the part of the guide

  • Configure IPA to serve the NFS principle
  • Configure NFS to use IPA
  • Configure some IPA clients to use Kerberos for the NFS service

Requirements

  • A runing IPA service like discussed in Part I of this guide.
  • A NFS server based on RHEL6.2
  • One or more IPA-Client

Lets doit
First you need to add the NFS server and its service principal to the IPA server. On ipa1.example.com run:

[root@ipa1 ~]# ipa host-add nfs.example.com
[root@ipa1 ~]# ipa service-add nfs/nfs.example.com

Next, log on to you NFS server, lets call it nfs.example.com and install the needed additional software packages:

[root@nfs ~]# yum -y install ipa-client nfs-utils

You need to enroll you NFS-server on the IPA domain. Run the following on nfs.example.com:

[root@nfs ~]# ipa-client-install -p admin

The next step is to get a Kerberos ticket and fetch the entries needed to be added in the krb5.keytab

[root@nfs ~]# kinit admin
[root@nfs ~]# ipa-getkeytab -s ipa1.example.com -p nfs/nfs.example.com -k /etc/krb5.keytab

Before you proceed to your clients, you need to enable secure NFS, create an export and restart NFS:

[root@nfs ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@nfs ~]# echo "/home  *(rw,sec=sys:krb5:krb5i:krb5p)" >> /etc/exports
[root@nfs ~]# mkdir /home/tester1 && cp /etc/skel/.bash* /home/tester && chmod 700 /home/tester1 && chown -R tester1:ipausers /home/tester1
[root@nfs ~]# service nfs restart

Assuming you already have set up one or more IPA-client(s), it is stright forward to enable kerberized NFS on your systems. Log in to a client and run the following:

[root@ipaclient1 ~]# yum -y install nfs-utils
[root@ipaclient1 ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@ipaclient1 ~]# 

Lets have a look if you have been successful. First look up the users UID.

[root@ipaclient1 ~]# getent passwd tester1
tester1:*:1037700500:1037700500:Hans Tester:/home/tester1:/bin/bash
[root@ipaclient1 ~]# 

Lets mount that users home directory manually on a client:

mount -t nfs4 nfs.exmaple.com:/home/tester1 /home/tester1

To check if is working as expected, issue

[root@ipaclient1 ~]# su - tester1

Fire ls -lan and see if the UID matches the UID you got from getent. If you see UID 4294967294, then something went wrong, this is the UID for the user “nobody” when using NFSv4 on 64 bit machines.

Whats next?
You will figure out when I post part III of this guide :-)

Have fun!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

Identity Management with IPA Part I

December 17th, 2011

Red Hat released RHEL 6.2 on December 6th. From my point of view, the greatest news in the release is that IPA (or now called Identity Management) is now fully supported and available in the RHEL 6 base channel without additional subscription costs.

Upstream project is freeIPA and is available trough the default Fedora repos.

About central Identity Management
IPA stands for Identification, Auditing, Policy. The focus in this article is on identification of users.

In the past, there have been a lot of solutions available to centrally manage users and its access to services. Just to name a few: LDAP, Kerberos, PAM, MS Active Directory, Novell Directory Server and countless others. All of those solutions have one in common: They are very powerful and very complex to set up and maintain. Because they are so complex, a lot of system administrators just do not use them and distribute SSH-keys, user credentials etc. by script without real central management, the nightmare of every security officer.

What is IPA?
The missing solution was a glue of LDAP and Kerberos which is easy to install and maintain, redundant and scalable from small office environments up to large enterprise installations. here it comes: IPA, which makes system administrators and security managers friends again.

IPA comes with a powerful CLI and a web interface for people that are afraid of a shell.

One of the cool stuff in IPA is its multi-master replication feature and automatic fail over facility. The clients are able to look up IPA servers with SRV DNS records, which are – of course – handled by IPA.

Lets do some stuff
One thing is just writing about how cool IPA is, but lets set up a high available centrally managed identity management system. This guide is written for RHEL 6.2 IPA-Servers and clients but should also work with freeIPA and Fedora 15 and later (Let me know if you have some issues).

Requirements
Requirements are straightforward:

  • 1Gbyte of RAM
  • approx. 6Gbyte of disk (including operating system)
  • NTP
  • DNS entries for all IPA servers (including PTR records)
  • Fully updated RHEL 6.2 GA
  • Firefox on the IPA servers if you want to use the web interface

NTP is very important since Kerberos is quite picky about synchronized system time. Ensure it is configured and running on all involved servers.

Assumptions

  • IP network is 192.168.100.0/24
  • Domain is example.com
  • Kerberos realm is EXAMPLE.COM
  • IPA-Server 1 is ipa1.example.com
  • IPA-Server 2 is ipa2.example.com
  • IPA-Client 1 is ipa-client1.example.com
  • IPA-Client 2 is ipa-client2.example.com
  • All passwords used are “somepassword” (needles to tell you to choose your own passwords
  • Main DNS is at 192.168.100.1
  • IPA-Clients are using ipa1.example.com and ipa2.example.com as there DNS servers.

Installation of the first IPA Server

yum -y install ipa-server bind-dyndb-ldap firefox xorg-x11-xauth

You are now ready to set up IPA. There are just a couple of questions, the non-default answers for this example are in red.

[root@ipa1 ~]# ipa-server-install --setup-dns --forwarder=192.168.100.1
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.

Existing BIND configuration detected, overwrite? [no]: yes
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
.
Example: master.example.com.


Server host name [ipa1.example.com]:

Warning: skipping DNS resolution of host ipa1.example.com
The domain name has been calculated based on the host name.

Please confirm the domain name [example.com]:

The IPA Master Server will be configured with
Hostname:    ipa1.example.com
IP address:  192.168.100.227
Domain name: example.com

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]:
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: somepassword
Password (confirm): somepassword

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

IPA admin password: somepassword
Password (confirm): somepassword

Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [100.168.192.in-addr.arpa.]:
Using reverse zone 100.168.192.in-addr.arpa.

The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server for the CA: Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
done configuring pkids.

Lot of output omitted

Configuring named:
  [1/9]: adding DNS container
  [2/9]: setting up our zone
  [3/9]: setting up reverse zone
  [4/9]: setting up our own record
  [5/9]: setting up kerberos principal
  [6/9]: setting up named.conf
  [7/9]: restarting named
  [8/9]: configuring named to start on boot
  [9/9]: changing resolv.conf to point to ourselves
done configuring named.
==============================================================================
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
[root@ipa1 ~]#

You now need to get a Kerberos ticket:

[root@ipa1 ~]# kinit admin
Password for admin@EXAMPLE.COM:
[root@ipa1 ~]#

Fire up firefox and point it to https://ipa1.example.com and follow the link provided in the error message. You will see the instructions needed to use Kerberos as authentication method. When importing the cert into Firefox, REALLY check all three boxes!

Afterwards you are automatically logged in, if you got your Kerberos ticket before (kinit admin)

Setting up a Recplica
For now, we one IPA server. If it failes, no one can log in to any system anymore. This is of course unacceptable and needs to be changed. So lets set up a replica to add high availability to our central identity management system.

Log in to ipa1.example.com and fire up ipa-replica-prepare to collect the data needed for the replica.

Non-default answers are coloured red

[root@ipa1 ~]# ipa-replica-prepare ipa2.example.com

Directory Manager (existing master) password: somepassword

Preparing replica for ipa2.example.com from ipa1.example.com
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/replica-info-ipa2.example.com.gpg
[root@ipa1 ~]#

/var/lib/ipa/replica-info-ipa2.example.com.gpg keeps all the information needed to set up the replica. You need to copy it by i.e scp to ipa2.example.com.

Now log in to ipa2.example.com and fire up ipa-replica-install

[root@ipa2 ~]# ipa-replica-install --setup-dns --forwarder=192.168.100.1 replica-info-ipa2.example.com.gpg

Directory Manager (existing master) password: somepassword

Run connection check to master
Check connection from replica to remote master 'ipa1.example.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK

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@EXAMPLE.COM password:

Execute check on remote master
Check connection from master to remote replica 'ipa2.example.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server: Estimated time 1 minute

Lot of output omitted

Using reverse zone 100.168.192.in-addr.arpa.
Configuring named:
  [1/8]: adding NS record to the zone
  [2/8]: setting up reverse zone
  [3/8]: setting up our own record
  [4/8]: setting up kerberos principal
  [5/8]: setting up named.conf
  [6/8]: restarting named
  [7/8]: configuring named to start on boot
  [8/8]: changing resolv.conf to point to ourselves
done configuring named.
[root@ipa2 ~]#

On ipa2, you need a Kerberos Ticket as well:

root@ipa2 ~]# kinit admin

Some adjustment
Unfortunately the default shell for new users is /bin/sh, which should probably be changed.

ipa config-mod --defaultshell=/bin/bash

Testing the replication
Log in to ipa1.example.com and add a new user:

ipa user-add tester1
ipa passwd tester1

You now can check if the user is really available on both servers by firing a ldapsearch command:

ldapsearch -x -b "dc=example, dc=com" uid=tester1

Compare the results of both servers. If they are the same, you have been successfully set up you two-node replicated high available IPA server.

What if ipa1.example.com is not available when I need to add a new user?
Simple answer: There is one way to find out….

Shut down ipa1.example.com
Log in to ipa2.example.com and add a new user:

root@ipa2 ~]# ipa user-add tester2

Start up ipa1.example.com again and run a ldapsearch again:

ldapsearch -x -b "dc=example, dc=com" uid=tester2

Set up a IPA-Client
Whats a centrally managed Identity Management server worth without a client? Nada! Lets set up a RHEL 6.2 server as a client:

[root@ipaclient1 ~]# yum  install ipa-client

After installation the setup program needs to be fired up. Non-default answers are coloured red

[root@ipaclient1 ~]# ipa-client-install -p admin
Discovery was successful!
Hostname: ipaclient1.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ipa1.example.com
BaseDN: dc=example,dc=com


Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Password for admin@EXAMPLE.COM: somepassword

Enrolled in IPA realm EXAMPLE.COM
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm EXAMPLE.COM
Warning: Hostname (ipaclient1.example.com) not found in DNS
DNS server record set to: ipaclient1.example.com -> 192.168.100.253
SSSD enabled
NTP enabled
Client configuration complete.
[root@ipaclient1 ~]# 

Testing the login
Log in to your client, you will need to change your password first:

[luc@bond ~]$ ssh 192.168.100.253 -l tester1
tester1@192.168.100.253's password: 
Password expired. Change your password now.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user tester1.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Connection to 192.168.100.253 closed.
[luc@bond ~]$ ssh 192.168.100.253 -l tester1
tester1@192.168.100.253's password: 
Last login: Sat Dec 17 19:40:10 2011 from bond.home.delouw.ch
Could not chdir to home directory /home/tester1: No such file or directory
-bash-4.1$ 

In this case we do not have a home directory for the user tester1. NFS automount of home directories will be discussed in Part II oder III of this guide.

Now log out of ipaclient1.example.com and shut down ipa1.example.com to check if it is working when one IPA server failed. Needless to say that it is working… (okay, there is a delay of a few seconds)

Drawbacks
IPA is not that powerful like MS Active Directory or Novell Directory. There is no support (and most probably there will never be) for multiple and or custom LDAP schemata to keep it simple and easily maintainable, this actually makes the drawbacks into a feature . If you need such features like custom LDAP schemata, you may have a look to RHDS.

Conclusion
Never in the past of information technology is was easier to set up and maintain a centrally managed identity management system. In just a few minutes of work you will have a basic set up of a highly available fault tolerant and scalable identity management server.

Outlook to Part II of this guide
IPA does not only allow users to be authenticated, but also to restrict them to use particular services only an particular systems. Thanks to Kerberos, it also provides single-sign-on capabilities without providing a password.

As soon as I get some time I’ll write about the following topics:

  • Passwordless (and key-less) SSH logins
  • Kerberized web applications
  • Centralized sudo management

Having fun?
Yes definitively , I have fun with IPA, and as a Linux consultant I expect a lot of work waiting for me.

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

Cross distribution system management with Spacewalk

May 24th, 2011

In a perfect world, all systems in a data centre are running the same Linux operating system, a homogeneous system landscape. In real life things are working differently. Windows systems are out of focus in this post, lets concentrate on Linux systems.

Most companies with a large Linux base are either RHEL shops or using SLES. A lot of RHEL users have some SLES systems running and so are SLES users running some RHEL systems. Some companies have additional systems running Debian.

How to handle those heterogeneous system landscapes? Those real world scenarios? Lets assume a company runs 500 RHEL systems, 20 SLES systems and some 10 Debian systems.

At the moment, for the base software management subscription such Linux users are spending a lot of money for RHN Satellite and SUSE Manager. Additionally there are per-system costs for management, provisioning and other modules. The Debian systems are handled manually. A lot of additional costs for a few out-of-strategy systems.

The solution is Spacewalk, the upstream project of the RHN Satellite which is at the same time the upstream for the recently released SUSE Manager. While SUSE offers support for RHEL systems, Red Hat does not (yet) offer support for SLES systems for RHN Satellite.

In Spacewalk Version 1.4 code contributions from SUSE are included and a student at Brno University of Technology contributed Debian support for Spacewalk as part of his master thesis.

While the support for SUSE is already quite stable, the Debian related code still have some rough edges. No wonder, SUSE is using RPM for its packaging wile Debian has its own packaging system. This makes it much easier for SUSE to get Spacewalk ready for its distribution.

At the moment, one can call the Debian support still as experimental, but the goal for the Spacewalk project is to have it fully functional in future releases.

The goal should be that both of the management system from the major enterprise Linux vendors, Red Hat and SUSE should support each others distribution for its Spacewalk based products. Debian is a niche player in the enterprise Linux environment and should also be supported by both products, RHN Satellite and SUSE manager. Nobody does expected to get system support for those distributions by the competing distribution, but having support for the management of it.

Further readings:
Registering Clients
Deb support in Spacewalk

Have fun!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

Implement a high available Cobbler provisioning system

April 24th, 2011

A not so well known feature of Cobbler is its replication facility. It allows you to create a high available system provisioning system. The whole set up is straight forward.

Background
Today people tend to NOT backup systems, only data is being backed up. In the case of a system failure, they just re-provisioning the system and automatically configure it with configuration management tools such as Puppet, CFengine or RHN Satellite.

You not only need to have your configuration management system(s) to be redundant, you also need to replicate your Cobbler provisioning systems.

It even works in a set up where you have multiple datacenters for disaster recovery, having one or two Cobbler servers at each site.

Luckily, Cobbler comes with that feature out-of-the-box.

Assumptions

  • Both Cobbler servers are in the same network
  • Your master cobbler has a DNS-entry cobbler-master, your slave is cobbler-slave

Lets do it

Unfortunately, Cobbler replication, at the moment, does not work when SELinux is running in enforcing mode. You need to turn it off on both Cobbler servers.

setenforce 0

Hopefully this will change soon.

For a initial replication just run:

cobbler replicate --master=cobbler-master --sync-all

On the slave server. It is recommended to run this command nightly by a cronjob to ensure you have the latest RPM-packages of your distros in sync. Feel free to run this command manually at every time if you think it is needed to immediately sync the whole Cobbler system.

Update on-the-fly
You can use a Cobbler trigger script that automatically connects to the slave and triggers a replication with the master whenever a system is added or deleted.

I’m using the following script to do so:

#!/bin/bash
#
# This is a Cobbler trigger script that triggers a replication on the slave
# server. You need to create a private/public key-pair on the master and 
# add the public key to ~/.ssh/authorized_keys on the slave

SLAVE=cobbler-slave

ssh $SLAVE "cobbler replicate --master=cobbler-master --systems=* --prune"
ssh $SLAVE "cobbler sync"

Put this script in /var/lib/cobbler/triggers/add/system/post and create a symlink in /var/lib/cobbler/triggers/delete/system/post on your master server.

Security
Cobbler handles the file /etc/rsyncd.conf. So far so good. You need to be aware that EVERY host can rsync your distros, kickstarts, snippets etc unless you take some security measures with some firewall and/or other restrictions.

Possibly the simplest way is configuring xinetd.

A sample /etc/xinetd.d/rsync, where 192.0.2.2 is the IP of your slave, would be:

# default: off
# description: The rsync server is a good addition to an ftp server, as it \
#       allows crc checksumming etc.
service rsync
{
        disable         = no
        only_from       = 192.0.2.2
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID
}

DHCP redundancy
You also need to operate a dhcp server on both Cobbler servers. If you have both Cobbler servers on the same subnet, you may have a look how to configure ISC dhcpd. A good guide (untestet) is at http://www.madboa.com/geek/dhcp-failover/. The lazy ones just turn off dhcp on the slave and activate it as needed.

Conclusion
As I wrote before, Cobbler is just great. Not only “batteries are included”, high availability, disaster safety and other cool stuff is included as well and can be quickly implemented.

Having fun? I rarely needed to re-provision systems because they went foobar and hopefully I will never experience a disaster such a burned-down, exploded or whatever datacenter. Cobbler does not protect you from such disasters, it helps you to recover.

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

I got employed by Red Hat

April 21st, 2011

This is pretty cool: End of March I signed a contract with Red Hat as a senior Linux consultant. It is not just “another new job”. It is cool for (at least) two reasons: First reason is that Red Hat is not “just another company”, it is Red Hat which is not very comparable to other employers, it is THE Linux and open source company, for me as a open source guy, this is perfect. The second reason is: I’m moving from Zurich in Switzerland to Berlin in Germany.

So, two major changes in my life at the same time. I’m looking forward to the challenges that are waiting for me.

I’ll continue to work at Siemens IT Solutions and Services AG until approx. mid of June and start working at Red Hat at 1st of July.

From May, 09 to May 15. I’ll be the first time in Berlin to have a look at the city and its different suburbs. I’ll also be there to organize some stuff required to settle in Berlin. In the same time, Europe’s biggest Linux conference will be held in Berlin, the “Linux Tag”. I guess I’ll have a lot of fun, and maybe meet some of my future workmates.

It is hard for me to leave my country, I have a lot of friends here. On the other hand, Berlin is just about 1.5h away by plane. As a consultant, I’m travelling a lot. Because of that, it would not be that easy to build up a social network (I mean real-life-stuff, not Facebook) in Berlin.

It also is not easy for me to leave Siemens, I’m involved in a very cool project with the Swiss government (all Systems will be RHEL6) and I also have friends and nice workmates at work which I’m going to leave.

I already know quite some people at Red Hat, they are all nice and I guess some of them will get good friends over the time.

Having fun?

Absolutely guaranteed!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

I voted for beefy miracle

April 7th, 2011

Beefy miracle

 

There is a open poll on voting for a name for Fedora 16. I gave my vote to Beefy Miracle. Why I voted for Beefy Miracle? Because it is cool, geeky, freaky, I’m loving hot dogs and it is something new.

The Fedora distribution is geeky, freaky and open to new stuff.

Having fun? Of course!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx

How to harden RHEL systems

March 27th, 2011

Some time ago, the NSA released an excellent guide how to harden RHEL5 systems.

Despite of being written for RHEL5, it partially also applies to RHEL6 and newer versions of Fedora. It is also worth looking at it for users of non-RH breed distributions. To be mentioned: Its clearly focused on server systems, not desktops.

Some of the topics are really basic stuff which is already in place as industries “best practices”, other methods are not that well known.

Most of the items can be implemented very easy, others should be reviewed if the complexity is worth the gain of security.

Minimize Software to Minimize Vulnerability is a good starting point. RHEL5 is quite bad on this point, a default installation comes with a complete desktop environment. RHEL6 made a lot of progress on this issue as I wrote about it in a earlier post.

The default file system layout of most Linux distributions is suboptimal. At least /var, /tmp and /home should be on separate file systems. You can enhance the systems security by setting mount options such as noexec, nodev and nosuid where appropriate.

Always set SELinux to Enforcing mode where possible. Since tools like audit2allow and selinux-polgengui enables users to easily create basic policies, its no more rocket science. For further readings and hints about SElinux, have look on Dan Walsh’s Blog.

Check if only needed daemons are running. I. e if you are not using NFS, disable portmapper and friends.

Other things things disabling rhnsd is IMHO not a good idea. Enabling a warning banner for pre-login texts is just clueless.

Conclusion
NSA provides a nice guide which is really worth reading for server administrators. Some topics described in the guide are maybe overkill and complex, while others are easy to implement and maintain. Hopefully NSA will soon update its paper to RHEL6.

It also shows that Linux distributors have room for improvements to provide a better default security.

Have fun!

Share and Enjoy:
  • Twitter
  • Facebook
  • Slashdot
  • del.icio.us
  • Technorati
  • Digg
  • Google Bookmarks
  • Add to favorites
  • MisterWong
  • Reddit
  • Yahoo! Buzz
  • BlinkList
  • Mixx