Posts Tagged ‘Spacewalk’

Automated disk partitioning on virtual machines with Cobbler

Saturday, December 15th, 2012

The default Cobbler Snippets just do simple auto partitioning. For a more sophisticated partition layout you need to know what kind of VM you are going to install. KVMs and RHEVs device name is /dev/vda, Xen uses /dev/xvda and ESX /dev/sda.

Luckily this can be figured out automatically, those different virtualization vendors are using its own MAC prefixes. So we can add two nice small Cobbler snippets to do the job. In this example, I call them hw-detect and partitioning.

hw-detect

#set $mac = $getVar('$mac_address_eth0')
#if $mac
#set $mac_prefix = $mac[0:8]
#if $mac_prefix == "00:1a:4a"
# This is a RHEV virtual machine
#set global $machinetype = 'kvm'

#else if $mac_prefix == "52:54:00"
# This is a KVM/Qemu virtual machine
#set global $machinetype='kvm'

#else if $mac_prefix == "00:16:3e"
# This is a XEN virtual machine
#set global $machinetype='xen'
#
#else if $mac_prefix == "00:50:56"
# This is a ESX virtual machine
#set global $machinetype = 'esx'

#else
# #This is a physical machine
#set global $machinetype = 'physical'
#end if
#end if

partitioning

#if $machinetype == 'kvm'
#set $disk='vda'
#else if $machinetype == 'xen'
#set $disk = 'xvda'
#else
#set $disk = 'sda'
#end if
# Lets install the system on /dev/$disk
part /boot      --fstype ext2 --size=250 --ondisk=$disk
part pv.0       --size=1 --grow --ondisk=$disk

volgroup vg_${name} pv.0

logvol /        --fstype ext4 --name=lv_root    --vgname=vg_${name} --size=4096
logvol /home    --fstype ext4 --name=lv_home    --vgname=vg_${name} --size=512 --fsoption=nosuid,nodev,noexec
logvol /tmp     --fstype ext4 --name=lv_tmp    --vgname=vg_${name} --size=1024 --fsoption=nosuid,nodev,noexec
logvol /var     --fstype ext4 --name=lv_var    --vgname=vg_${name} --size=2048 --fsoption=nosuid,nodev,noexec
logvol swap     --fstype swap --name=lv_swap    --vgname=vg_${name} --size=2048

An additional “feature” of the partitioning Snippet is: It sets up the Volume Group name according to your systems name. This is the unofficial standard since quite some time. It also sets some more secure mount options. Review them carefully if they make sense for you and edit them as needed.

The next step is to configure your kickstart template.

Standalone Cobbler
On a standalone Cobbler server edit /var/lib/cobbler/kickstart/your-kick-start-template.ks

# Detect the used hardware type
$SNIPPET('hw-detect')
# Set up default partitioning
$SNIPPET('partitioning')

Bundled Cobbler
When using cobbler bundled with Spacewalk or Red Hat Satellite, you need to edit the Kickstart profile in the WebUI.


Navigate to Systems -> Kickstart -> Profile. Select the Kickstart profile to be modified -> System Details -> Partitioning.

Copy the two Snippets in /var/lib/cobbler/spacewalk/1, where 1 is representing your OrgId.

Alternatively you can edit them in the WebUI as well.

To check if all is working as expected, add a system to Cobbler using the Command Line Interface and have a look to the rendered Kickstart file. This can be easily done with cobbler system getks --name=blah.

Happy System installing….

Have fun :-)

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

Tuesday, 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

SUSE Manager based on Fedora Spacewalk

Thursday, March 3rd, 2011

SUSE announced the availability of SUSE manager. Having a closer look to it, one recognizes it is based on Fedora Spacewalk. It is a clone of the Red Hat Satellite.

A few weeks ago I was puzzled to see a post on the spacewalk-devel mailing list. SUSE was contributing some code. What the heck? Now it is clear, they are using Spacewalk as there source for its own product. Spacewalk is no longer just the upstream of RHN Satellite, but also a major tool for managing SLES systems.

The open source way
It is good practice to share knowledge and code between different distributions. SUSE profits from the work Red Hat has done before, and Red Hat profits from the contributions of SUSE. IMHO this is the right way how open source software should work.

The price tag
SUSE claims “SUSE Manager allows you to save up to 50 percent for Linux support”. Really?

Lets have a look to How to buy. The price is exactly the same as for RHN Satellite: USD 13,500. Really the same price tag? Lets dig deeper on features Click on Database support. One would read

"SUSE Manager provides a built-in Oracle XE database, but can also leverage existing 
Oracle 10g or 11g databases, to locally store all data related to the 
managed Linux servers."  

Means: With the free Oracle XE database delivered with SUSE you can manage just a few systems. If you want to manage more systems, you need to buy a very expensive Oracle License which, last least, doubles the price tag of SUSE Manager.

And Debian? There are some works going on, maybe I’m going to write soon about Spacewalk and what it can do for and with Debian.

Conclusion
Because SUSE was not in a hurry to release its new product, I can not understand why SUSE was not helping the Spacewalk project to get PostgreSQL production ready before releasing it. This would provide its customers (and the spacewalk community) a real benefit.

I hope that SUSE will sustainably contribute code to Spacewalk, it is now in the interest of users of both distributions.

Have fun!

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

Some impressive figures about Spacewalk and my two cents

Wednesday, December 22nd, 2010

Today, I saw a interessing post on the spacewalk-devel mailing list.

Lines of code
Spacewalk has 2,908,841 lines of code, created in estimated 843 person years. This means 843 developers are needed to rewrite Spacewalk from scratch in one year! That’s amazing.

Number of bugs fixed
As stated in the post, the Spacewalk-team fixed 1012 bugs in the year 2010. Some 1061 bugs are still due to be solved, the Spacewalk-team will not running out of work in 2011. See RHN Satellite bugs and Spacewalk bugs.

Contributions from outside Red Hat
96% of the contributions are from Red Hat people. Looks like my small contribution to the German translation is just about 0.0000001% ;-) . Seriously: This should be improved. More people outside of Red Hat should contribute. How? A good way can be a better support for Debian based distributions as well as for SLES/OpenSUSE and other distributions. I think this would attracting more Red Hat outsiders.

Another important thing: Instead of mailing list posts, Fedora should release its advisories similar to Red Hat. This would enable people to have the errata in its Spacewalk servers. This would lead into more people interested in Spacewalk in the Fedora community.

Communications
The IRC communication stats can somehow be a bit problematic. Is it really needed to log all IRC traffic? Its was stated that 24.1% have been questions, the mail list post also disclosed which are the most aggressive persons and so on. Privacy? For myself: I’m probably going to change my real name nick to something else…

Missing numbers
It would be interesting how many people are subscribed to the spacewalk and spacewalk-devel mailing lists and the number of posts to these lists.

Major achievements in 2010
This is just my point of view…

- PostgreSQL support reached a point where it is ready for broad testing.
- spacewalk-repo-sync allows to directly sync with yum repos.
- Staging of content
- Support for eliminating duplicate system profiles
- Performance improvements (felt, not measured)

Did I had fun this year?
I had a lot of fun with Spacewalk, for sure. I did not challenged Spacewalk with all the stuff that I need @work with the RHN Satellite.

Will I have fun in 2011?
With Spacewalk of course, it is a cool project. If the Fedora project decides to publish Spacewalk-like erratas I’m pretty sure that France will have a problem to produce the amount of Champagne needed. If it comes down to the RHN Satellite: Due to severe bugs, I only can manage RHEL6 systems with some workarounds but I am confident that this will change soon.

In short: Yes I’ll having fun :-)

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

Important RHN Satellite 5.4 bugs has been fixed

Wednesday, December 15th, 2010

Red Hat recently released some bugfixes for the RHN-Satellite version 5.4. They needed approx. one month to develop a fix for those serious bugs.

If you upgraded to sat540 before those bugsfixes have been released you will have a crippled database. The errata provides a way how to fix it. It needs some time, but it works perfectly. For “my” satellites it was taking about 48h for both satellites, about 12h for the master and 36h for the slave satellite.

This time, Red Hat’s QA also made a good job, it is now working like expected. The developers had a hard time too, according to the git log they worked on weekends too.

If you are new to sat540 or upgrading to it, please ensure that you do NOT take any action before applying the errara!

Have fun! (This time REALLY for sure)

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

Pulp, what is it about it?

Thursday, December 2nd, 2010

Thanks to Máirín’s posting I got aware of the Pulp project.

What is it? I had a brief look at it, it is a Red Hat sponsored project with a similar functionality like Spacewalk and RHN Satellite.

This brings me to the question: Is Pulp is intended to be a replacement of Spacewalk? It can make sense, it is written in Python as Cobbler is. Cobbler and Spacewalk are not really playing nice together. Spacewalk used Java, Perl and Python.

Anyway, Pulp seems to be in its early childhood, but it seems to be a really interesting project. What are the plans for the future? And what are the plans for Spacewalk and thus RHN Satellite?

Having fun? As soon as I get the time to install it and give Pulp a closer look….

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

Spacewalk 1.2 released -> PostgreSQL Support quite ready -> First analysis

Saturday, November 20th, 2010

Today, Spacewalk – the upstream project of the RHN satellite – released version 1.2. One of the promises the developers made was better support of PostgreSQL. It seems that lot of stuff is now working. As I promised, I’m going to examine whats working and whats not. I’ll file every single bug I’ll find, please do the same in a polite manner.

First impression
Installation and first sync of yum channels works like PostgreSQL support was there from the first second. Nevertheless, there is still a lot to test.

How to install Spacewalk with PostgreSQL?
It is straight forward:

  • Set up a PostgreSQL database as described here
  • Follow and exclude things that mentions Oracle
  • Go for the the instructions about PostgreSQL.

And enjoy your newly installed Spacewalk server w/o Oracle!

What I proofed working so far:

  • Installing with PostgreSQL went smooth and much faster than the stuff with an Oracle setup
  • Creating a CentOS5 Channel
  • Add a yum repository (i.e.mirror.switch.ch)
  • Linking the yum repo to a channel

Conclusion so far

  • Spacewalk feels (not measured) MUCH (very much) faster with PostgreSQL. (Feels like more than the tripple speed)
  • PostgreSQL support seems to be almost ready for production (the tested stuff)
  • As RHN Satellite 5.4 is out now and the ISS bug is fixed (in spacewalk-nightly, not yet with an erratum) Red Hat should and can now focus on the complete replacement of the Oracle embedded DB.
  • RHN Satellite 6.0 can and should be released w/o being bound to Oracle

More things to test

Since syncing repos is a time consuming task (seems to be much less time consuming with PostgreSQL), some tests are still pending. There is no single System yet subscribed, no deployment tests etc. I’ll test them later and let you know.

Some more words to say

The RHN Satellite and Spacewalk developer crew (once again) made an outstanding good job (I wish I could say the same on QA). At FUDCon 2010 in Zurich, Miroslav stated that nobody is willing to test the PostgreSQL support. No wonder it was not yet ready to test it at that time. Now, PostgreSQL enabled Spacewalk is ready for being tested by broad public , do it as I do it!

Having fun? Yes sure, I’m going to do some more intensive tests on the PostgreSQL support.

Cheers,

Luc

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

RHN Satellite 5.4, first analysis

Monday, November 1st, 2010

First of all: Where is the Red Hat Press release? Nada, nothing, nichts (yet)….

History
As I wrote in my previous post, I’ll keep you posted with my latest findings.

In another post, I was speculating about the upstream version. Now, Sat540 seems to be based on Spacewalk 1.2 which is not yet released. I was quite puzzled about that fact. Usually upstream (Fedora) projects are ahead of its commercial counterparts, this time it seems to be the other way round.

Major Features
I was quite guessing right on the expected new features:

  • RHEL6 Support (SHA-256 Checksums on RPMs)
  • Support for importing and syncing of external yum repositories
  • Find duplicate entitlements of systems
  • Oracle 11g support
  • Recording of the install-date of packages

Additionally the following features have been added:

  • Symlink Support in the configuration management
  • SELinux in configuration management
  • Flex Guests enhancements

In contrary to my expectations:

  • For the moment, Sat540 runs only on RHEL5, thus meaning Tomcat5

Cobbler
The included version of Cobbler is 2.0.7. In EPEL5 it is 2.0.3, in EPEL5-test as well as in Fedora 14 beta it is 2.0.5. At least in sat540 it is the same version as in EPEL6-Beta, 2.0.7. The cobbler git repository mentions cobbler 2.1.0. At FUDCon in Zurich I was talking to some Red Hat guys. They told me: The cobbler guy left Red Hat. Hmmm… What is going on?

Real tests and improvements
I was not yet able to install sat540 yet, I’m waiting for the certificate… Nevertheless I made some tests with Spacewalk 1.1 which have been very promising.

At work
Today @work, I just prepared the staging/test satellite for being upgraded from 5.3 to 5.4. I’m still waiting for the new certificate from the Red Hat support. This brings me to another question: Why the heck is a new certificate needed? That’s boring…

As soon as I get the certificate from Red Hat, I’m going to upgrade the Staging/Test Satellite @work, so you can expect more detailed reports soon.

Have fun? I guess yes ;-)

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

Spacewalk is moving further to PostgreSQL support

Tuesday, October 5th, 2010

The upstream of RHN Satellite – Spacewalk – is moving further to database indepedancy, with the scope of PostgreSQL compatiblity. How I come to this conclusion? Read the git commit logs.

At FUDCon 2010 in Zurich I was attending Miroslav’s talk. He was complaining that nobody gives the PostgreSQL-version a try. He is right, on one hand everybody expects PostgreSQL support ASAP, on the other hand nobody takes care about the PostgreSQL setup, and nobody helps neither with the development nor bug reporting.

Whats the reason for this? As I wrote in Managing CentOS with Spacewalk the roadmap of Spacewalk reads “ready” for PostgreSQL at Version 0.6. At the same time one could read at Milestone Release – 2.0 “??? Not sure – *maybe* PostgreSQL support”. And this statement is still there. At the moment Spacewalk is approaching version 1.2, and the goals for milestone 2.0 are still there.

No wonder that people tend to NOT testing PostgreSQL support. I’m a follower of the git commit logs of Spacewalk. In the past few weeks I have seen a lot of progress to a much better PostgreSQL support.

My personal opinion is: Wait for the release of Spacewalk version 1.2 and lets give it a try. As Miroslav pointed out, Spacewalk needs more commitment from the community. Let us help him and and the other Spacewalk developers with bug reports and possibly some corrections of the database scheme.

Have fun?

At the time when Spacewalk is stable with PostgreSQL support, I’m opening a bottle of champagne, at the time when Red Hat releases the first RHN Satellite release with “official” Support of PostgreSQL I’m opening a box a champagne!

We will have fun! Help debugging…

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

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