Posts Tagged ‘System Management’

rhn satellite 5.4 release in sight

Tuesday, September 7th, 2010

When analyzing recent Bugzilla-reports and mailing list posts, we can expect a RHN Satellite release quite soon. Why? The main reason for this is the lack of SHA256 support in sat530. Since RHEL6 packages having SHA256 checksums, the release of Satellite 5.4 is a prerequisite for releasing RHEL6. As always there will also be a large load of bugfixes included.

Expected new features

  • yum repository syncronising
  • Support for SHA256 checksums
  • Maybe support for SHA384 checksums
  • Support for Oracle 11g databases (on external servers)
  • Improved preformance
  • Orphaned profile elimination to prevent wasting entitlement
  • Runs on RHEL6 (and thus Tomcat6?)
  • Recording of the install-date of packages

Of course, this list can be wrong. Because lots of bugzilla entries are not open to the public this list also tends to be incomplete. Lets have a closer look to the new features that most probably will hit rhn satellite 5.4

yum repository syncronising
This feature allows to sync custom channels with an external yum repository. Lot of people are mirroring EPEL and IUS repositories with the help of wget and push the packages into the satellite with the help of rhnpush. In future there will be a command like spacewalk-repo-sync –channel you-name-it-custom-channel (maybe the command will be renamed to rhn-repo-sync). This new feature will not only safe some GB of disk space, it will also speedups the process of getting new packages from external repos.

In Spacewalk 1.1 there were a lot of improvements made on repo handling. Hopefully sat540 will have them too. Since I was not able to figure out which Spacewalk version is the upstream for sat540, I can only hope that it will be version 1.1.

Support for SHA256 checksums
RHEL6 packages are all coming with SHA256 checksums. Those are not supported with the current release 5.3 and older. This means version 5.4 needs to be released close to the GA of RHEL6, otherwise customers are not able to manage RHEL6 systems internally.

Support for Oracle 11g databases (on external servers)
Right now, only Oracle 10g databases are supported on external servers. This is annoying for customers that already ditched Oracle 10g and upgraded all Databases to 11g. This new feature allows to have a homogeneous database landscape in the datacenter.

Orphaned profile elimination to prevent wasting entitlement
Today when re-provisioning a system, the system gets registered and entitled twice, the old system-profile needs to get deleted manually. Often this gets forgotten and wastes entitlements. In RHN Satellite 5.4 there will be a function to detects those duplicate system registrations.

Runs on RHEL6
The upstream project Spacewalk runs fine on Tomcat6, which will be included in RHEL6. It is quite unlikely that the Sat distribution comes with an own Tomcat5.5 server, so it means that the support for Tomcat6 was backported from Spacewalk.

Recording of the install-date of packages
This small feature is quite important for a lot of users. In some industries there are regulations to know when a particular package was installed. Of course you can get this information out of the systems /var/log/yum.log, but now you will have this information handy on your Satellite server.

Open Questions
There is a Bugzilla tracking bug for RHN Satellite version 5.3.1. What is it good for? Will there be support for RHEL6? My guess is not having RHEL6 support and 5.3.1 will be ditched even before its got released.

Will RHN Satellite 5.4 will also run on RHEL5? Maybe the distribution comes with Tomcat6 packages for RHEL5? Maybe Sat540 will be able to run with Tomcat5.5? We will see…

Upgrade scenarios: Will it be easy to upgrade from 5.3? Is it needed to refresh the OS from RHEL5 to RHEL6? If it is that easy as upgrade from i.e. Spacewalk 1.0 to Spacewalk 1.1 then we all will be happy :-)

Release Date
As always, Red Hat does neither publish a roadmap nor release dates. All we know for RHEL6 is “later this year” and thats also true for the release of RHN Satellite 5.4.

Conclusion
The gap between Spacewalk 1.1 and RHN Satellite 5.3 is quite huge. Lots of new and interesting features have been introduced, lots of bugs fixed, much better performance. With the upcoming release of version 5.4 this gap will be much smaller.

In contrary to the release of 5.3 which was quite buggy on GA, I do not expect the same for 5.4 because Spacewalk seems to be very stable at the moment. This makes me confident that 5.4 will be a very stable version from GA on.

Have fun!

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

Spacewalk 1.0 released

Sunday, May 2nd, 2010

spacewalk-1-0-release

Spacewalk 1.0 has been released

Spacewalk is the upstream project for Red Hat’s RHN Satellite software, one of the best systems management software available for Linux Systems.

In the past few weeks one could see a lot of git commits on the source repository of spacewalk. There is no changelog available yet. The road map mentioned compatibility with Apache Tomcat 6.0.x to be able to install spacewalk on Fedora12 and RHEL6.

There should have also been several enhancements in the phyton API and long awaited feature enhancements such as host-renaming (confirmed). Further repository synchronization should be much faster now (Announced in a earlier feature note).

Sorry folks, a lot of “should”, “maybe” etc. I just have been reading the git commit logs and the announcement of the 1.0 release. As long as there is not official changelog available we only can speculate on the precise enhancements.

I’ll install this on my test system soon. If something really uncommon happens or an astonishing new feature appeared, I’ll let you 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

Writing trigger scripts for cobbler does not work at the moment

Sunday, May 2nd, 2010

Cobbler Logo

At the moment, shell scripts as triggers wont work with cobbler. This is due to a bug. Unfortunately the developers wont fix it in the next few weeks or even months.

Triggers are a very welcome and powerful method to automate things before, during after installation of a system. At the moment it only works with python scripts. Since not every sysadmin knows python, but everyone knows to write bash scripts, this is a major drawback.

Cobbler is included in RHN Satellite 5.3 but in a quite old version. People tend to use a standalone cobbler install server installed from EPEL. Out of the box Cobbler is only usable on RHN Satellite servers with “deployment” entitlements which are quite expensive. Post-Install triggers can help admins to automate configuration management in RHEL and CentOS environments. For automating configuration with the RHN Satellite you need to have brought the “configuration management” entitlements too. With cobblers triggers you can partially replace the configuration management offered by RHN Satellite. Is this the reason why Red Hat developers are not very keen to solve the issue? I’m talking about ~USD 250 p.a/system.

I’ll keep you posted on the issue….

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

Ubuntu 10.04 LTS released

Sunday, May 2nd, 2010

End of April 2010, Ubuntu 10.04 was released. As always it is based on Debian’s Testing-Release. Canonical “stabilizes” the testing tree of Debian and adds its own look.

This time, Ubuntu radically changed its look. From my point of view it looks ugly, very ugly. Strange colors, low contrasts in menus, orange icons in Nautilus… window buttons on the left side… At the end of the day an usability-horror.

Under the hood Ubuntu is a very stable distribution with recent software. Ubuntu 10.04 is a LTS (Long Term Support) version and is thus suited as a enterprise server. Support for the server variant of Ubuntu is five years. Ubuntu is – like Debian – capable to upgrade to a new major release w/o service interruption.

Managebility

You “can” mirror Debian and Ubuntu repositories locally but it is difficult if you to not like to mirror all architectures available. Unfortunately there is (AFAIK) no software available such as Spacewalk/RHN Satellite to manage your servers.

The best method is to allow each single system installed to talk directly or via proxy to the mirror servers. This is a nightmare for firewall administrators.

To my knowledge there is no convenient way to install Ubuntu over the net. There are rumors that spacewalk and cobbler is going to get Debian/Ubuntu support at some time.

Reliability

Debian and thus Ubuntu has an evidence to be reliable. This also  seems to be true for the current release 10.04. The software came from Debians testing repository but was stabilized during months. Canonical (The sponsor of Ubuntu) has a reputation for its quality management. To use Ubuntu as a server operating system is sane.

Conclusion

As a desktop operating system I’ll avoid Ubuntu, since the usability is focused on dummy-users and not professional Linux users. For server usage you need to ask yourself about your needs. If you are operating Oracle DB’s or other commercial applications you probably want install Red Hat Enterprise Linux (RHEL). For a web server Ununtu is very well suited, even better than RHEL. In two years there will be another LTS variant available and you are free to upgrade online. Reliability is very good, manageability is poor, especially when used in larger companies.

In short: Ubuntu for web servers, RHEL/CentOS for other servers.

As always: Feedback is welcome…

Have fun!

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

Set up a Red Hat Directory Server and Kerberos Part I

Thursday, November 5th, 2009

Kerberos and LDAP are today’s way of single sign on. It is platform independent and supported by a wide range of applications.

Together with the Red Hat Directory Server (also available as CentOS Directory Server and 389 Directory Server from Fedora) you can build a neat identity management infrastructure.

Setting up the Directory Server
However there are some pitfalls when installing such a integrated solution. Installing redhat-ds is quite easy, just ensure you define your planned LDAP Namespace and default LDAP Suffix before running setup-ds-admin.pl. If you plan to setup a replica, run the script with the -k parameter: setup-ds-admin.pl -k. The servers configuration will be saved as /tmp/setup*.inf and can be used to setup the replica after changing the FullMachineName and ServerIdentifier.

In my example I used the DN “cn=Directory Manager. As base I used dc=ldap,dc=example,dc=com. This is the Internet Domain Suffix style of naming an LDAP space. The older X500 style should not be used anymore.

Have a look to man openldap.conf to see how to shorten your CLI entries such as ldapsearch -x.

Setting up Kerberos
After setting the right configurations in your /etc/krb5.conf (the sample content is self-explanatory) and its distribution, you need to initialize your key store database. This is to be done with kdb_util as follows:

[root@server]# kdb5_util create -r EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
[root@server]#

Keep in mind! Kerberos Realms are all uppercase to distinguish them from DNS names!

In the config file for the Key Distribution Center /var/kerberos/krb5kd/kdc.conf add the following in Realm Stanza: default_principal_flags =+ preauth. This will enhance security or your Kerberos Infrastructure. Also change the example Realm to what you are going to plan to use. In /var/kerberos/krb5kd/ kadm5.acl you can define the ACLs for e.g. admins or service desk employees etc. Also check the correctness of the Realm.

Feed the keystore

Now it is time to feed the database with the first principal: root. We also can create our first host principal at the same time.
Fire up kadmin.local. The kadmin.local app accesses directly the DB files on the server. Its should only be used on initial setup. Later on you will have kadmin which also works on the net, of course with Kerberos authentication.

[root@server ~]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM":
Re-enter password for principal "root/admin@EXAMPLE.COM":
Principal "root/admin@EXAMPLE.COM" created.
kadmin.local:  addprinc -randkey host/server1.example.com
WARNING: no policy specified for host/server1.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/server1.example.com@EXAMPLE.COM" created.
kadmin.local:  q
[root@server ~]#

After starting the kadmin and kdc services you can access the admin server with the normal kamin tool.

service kadmin start
chkconfig kadmin on
service krb5kdc start
chkconfig krb5kdc on

Now we need to create a host principal for each to be kerberized host and store it in its keytab.

End of Part I

What comes in Part II?

  • LDAP Service Principal
  • Getting Kerberos and LDAP working together
  • Migrating users from /etc/passwd to LDAP
  • Playing with PAM

Have fun!

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

Managing CentOS with Spacewalk

Monday, November 2nd, 2009

spacewalk

Red Hat RHN Satellite

In 2003 Red Hat released its RHN Satellite server as a closed source management tool for RHEL and only for RHEL (okay, a legacy support for managing Solaris is available). The satellite is very useful tool for managing systems. Unfortunately it has a quite expensive price tag on it. According to the Red Hats RHN FAQ the bill is USD 13,500/year.

Additionally to the RHN satellite subscription fee you need at least a subscription for the management module which costs another USD 96/year and system. Assume you have a farm of 100 RHEL boxes it costs you about USD 23,100 every year. All prices are list prices.

RHN Satellite comes with an embedded Oracle Database which is from my point of view completely overkill and the driver for the high cost of the subscription. If Red Hat witches to PostgreSQL, I see some chances for lower price tags…

The alternative

In 2008 Red Hat open-sourced the RHN Satellite and named it  “Spacewalk” (a pretty cool name :-) ). Since then the development team already released six versions. The release cycle is quite short in a fast pace.

Release 0.6 is PostgreSQL “ready” whatever that means, I do not know how reliable it is. Full support for PostgreSQL is scheduled with version 1.0 due in Q1/2010. However, for a smaller farm of CentOS systems the free Oracle express edition is good enough.

Installation

The installation is straight forward: Just follow the Instructions how to set up Oracle XE and spacewalk. After the a little tricky installation and configuration of Oracle, you just need to add some yum repositories and run the set up script.

Uploading packages

There are basically to methods to put your RPMs to the Spacewalk server. Either trough yum repository synchronization or via rhnpush. The first method is great if you want to pull a CentOS repository, the second for additional own packages.

Bootstrapping clients

After you installed a new system, you need to add the rhn-client packages to your CentOS system. Unfortunately CentOS removes those packages from the upstream RHEL versions. I hope they will rethink about this.

If you set up your systems by provisioning with Spacewalk, you can automate this task. However I did not got the time yet to test the provisioning stuff with cobbler and kickstart files, its on the to-do list.

Manual bootstrapping works similar to the method like you bootstrap RHEL clients to a RHN Satellite.

Updates and Errata

At the moment this is the tricky part. How to get the upstream errata into Spacewalk? You can use Script that imports digests from the centos-annouce mailing list. Afterwards applying erratas to your systems works fine.

Integrate Spacewalk with other applications

Spacewalk, like RHN Satellite comes with a XML-RPC API which allows you to trigger actions from scrips or (web-)applications. I think about reporting an similar to-be-automated stuff.

Conclusion

If you do not need support from Red Hat, Spacewalk and CentOS can be an alternative for your server farm. If you like more up-to-date systems (e.g. for desktops), Fedora is also supported as a client platform.

Since Red Hat does not provide some kind of Test-Licenses of its products, Spacewalk and CentOS  are also a very nice playground for people managing RHEL systems on a daily base either to familiarize them self with the Satellite or doing some tests without bringing the production Satellite into danger.

Further readings

Unfortunately, beside of Red Hats documentations and the Spacewalk Wiki no books and other resources are available. Maybe I should start writing a book? ;-)

Spacewalk Wiki:
https://fedorahosted.org/spacewalk/

Red Hats Spacewalk homepage:
http://www.redhat.com/spacewalk/

Red Hat RHN Satellite documentations:
http://www.redhat.com/docs/manuals/satellite/

Have fun!

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