Archive for the ‘SUSE’ Category

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!

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!

Epson scanners on Linux systems

Tuesday, January 11th, 2011

I’ve got a Epson Perfection 1260 Photo scanner.

Fedora like other distributions such as OpenSuse are recognizing the device since a long long time. The back end chosen for the device is plustek.

Unfortunately when using the default configuration one experience very strange effects with colours. The left and the right 50% of the picture have a colored background, even when scanning a empty page.

I had this problem with OpenSUSE since years and still got it with Fedora 1x. Since I only need the scanner for my yearly income tax declaration, I always forget about what I needed to change.

That’s what is needed to change:

Solution

[root@bond ~]# diff /etc/sane.d/plustek.conf.orig /etc/sane.d/plustek.conf
100c100
< option altCalibration 0
---
> option altCalibration 1
[root@bond ~]#

Since I do not have any other scanners I do not know if this is a bug specifically to this type of scanners, or if it is a general bug.

Using different search engines, the web does not disclose some solutions. That is one of the reasons why I’m blogging about it. The other reason is to find other people with the same problem.

At the end of the day, I’ll try to find out if this is a general bug of the Sane back end, or just specific to some Epson scanners. If it is specific to some Epson scanners, it may be worth to create a new specific back end for those scanners affected.

Having fun? Now I have, my stuff is successfully scanned.

Bye bye Suse, welcome Fedora

Saturday, September 25th, 2010

Successfully migrated my workstation @home from OpenSuse to Fedora13

After using SuSE and later OpenSuse since 1994 it was time for a change. I was stuck at OpenSuse because of its excellent multimedia support trough 3rd party repostitories from packman. Last evening another update brought the system down once again. Time for change.

Since a long time Fedora does not ship software any more which are problematic because of software patents, such as mp3, different video codecs etc. Since then Fedora was more or less a no-go for home-usage. In meantime there is a 3rd party repository available called RPM Fusion. RPM Fusion is as good as packman, this made the decision to switch easier.

Why I finally switched from OpenSuse to Fedora:

  • @Work, I’m mostly working with RHEL systems
  • Workstation @work migrated to Fedora long time ago
  • Novell is going to die, future of (Open)Suse is uncertain
  • Multimedia support is as good as for OpenSuse trough 3rd party repositories
  • Suse has a bad package management (zypper and friends) and its going worse with each new release
  • Fedora is more innovative
  • Bigger community
  • Better quality control (obviously)
  • If a Fedora update is going wrong, packages can be easily downgraded with a single command

Is the switch on my home workstation enterprise relevant?
Yes and no.

Yes, because people like me tend to use the upstream project of the two enterprise Linux distributions RHEL (with Fedora as upstream) and Suse (with OpenSuse as upstream). I know a lot of people who already switched to Fedora quite some time ago.

No, because for home usage for ordinary users Ubunu, Debian, you-name-it-distribution is good enough.

I’m quite convinced that (Open)Suse will die in the next time. One of the reasons is that Novell brought SuSE Linux AG back in 2003 and dismissed lots of developers. Then investment companies held the major part of Novell’s stocks. Investment companies are known to be interested to make money on the short term, not on the long term.

If Suse is really going to die, this is a bad thing for the Linux society. The only “Enterprise” Linux would then be Red Hat Enterprise Linux. As we know from Microsoft, a monopoly is always a bad thing. There is an urge for another Enterprise Linux vendor. How will kick in? Mandriva? They are nearly bankrupt. Ubunu/Canonical? They call five years of support long term support (LTS)? Gimme a break! Oracle Linux (Aka OEL)? Its a RHEL clone.

Your opinion?
Please leave a comment

Have fun? Unsure…

Rumors about Novell and Suse Linux

Thursday, September 16th, 2010

There have been a lot of rumors that Novell will be sold. Latest rumors are that the Linux parts of Novell (former SuSE) will be split off and sold separately.

Since that got public, there are even more rumors: Which company will buy the Linux part of Novell?

  • Red Hat: Very unlikely, since the Monopolies and Mergers Commission in the EU and USA will most likely disagree because RHEL and SLES are already some kind of “duopoly”.
  • Microsoft: No way that the Monopolies and Mergers Commission will agree on this. On the other hand, MS has enough manpower to get on market with “MS-Linux” if they want to do so.
  • VMware: Would make sense, they can position them as a counterpart of Red Hat with its KVM initiative. Since VMware is a Windows-Shop, it is unlikely.
  • Oracle: They already have OEL, a clone of REHL, very unlikely
  • Hewlett-Packard: Would make sense because HP-UX is dead and HP does not have a future proof operating system anymore
  • IBM: They have AIX and IBM is involved in business with both, RHEL and SLES and others. I’m unsure if it would make sense to take over Suse. AIX is one of the two Unix Systems that will survive (maybe the only one since most probably Solaris 12 will never appear).

My wild guess is: Hewlett-Packard. Why? Monopolies and Mergers Commission will not be concerned, and HP does not have any competitive Operating System in its assets anymore.

Depending on who is buying the Linux business of Novell, we will have fun or not…

Lets take a breath,

Luc

Ready to upstart?

Saturday, October 31st, 2009

upstart

It is time to replace the aged SysV init system with someting better

At the time when  SysV init (pronounced “System five”) appeared, hardware configurations have been quite static, no hot plug and similar fancy stuff.

SysV init is started after the kernel is loaded. The init process reads /etc/inittab and walks trough the runcontrol script and runlevels. This sequential walk-trough takes most of the time when booting a modern Unix system.

Upstart follows another approach: Starting daemons and services in parallel and event driven.  This will speed up the boot process beyond expectations.

A very nice feature of upstart is: All processes will be started in background, no more blocking of the boot process trough hanging run control scripts!

If a service unexpectedly dies, it will be respawned  automatically up to a configurable limit in times per period.

Upstart is event-driven, a event can be e.g. plugging in new hardware which ends up starting the needed service for it. There are also plans to replace cron and atd with upstart since this are basically time-triggered events. The developers also thinking about replacing the inetd, since a network connection can be considered as a event.

Transition

Since most of the software out there do not natively support upstart yet, transition methods are needed for a smooth transition from SysV init to upstart. Traditional SysV run control scrips are fully supported, even distributions slowly switch to the event/job model of upstart. E.g. one of the first distributions switched to upstart was Ubuntu 6.10, and now with Ubuntu 9.10 – three years later – they begin to ship its distribution with the first native upstart scripts.

Splitting Unix systems apart

Years ago there only have been two init systems: SysV init and BSD init, a sysadmin was comfortable to use them on whatever system. Now there are SysV init, Upstart from Ubuntu, lauchd from Apple, SMF (System Management Facility) from Sun Microsystems and possibly others. All of this SysV init replacements are working differently,  different commands, different architecture… This makes the job of a sysadmin not easier when managing a heterogeneous system landscape.

Linux distributions stay together

The good news: On the Linux side it looks like Upstart will be the future standard for system initialization, no balkanization of the Linux Landscape so far.

Linux Distribution with upstart

The following distributions are already shipping upstart:

  • Ubuntu
  • Debian
  • Fedora
  • Others?

Since Fedora 11 and 12 will be the upstream for the upcomming RHEL6 distribution it is most likely that RHEL6 comes with upstart. At openSUSE there are some discussions (see https://features.opensuse.org/305690 for details). Maybe there is a chance for openSUSE 11.3 and later on SLES12.

Further readings:

Upstart web site: http://upstart.ubuntu.com
Wikipedia article: http://en.wikipedia.org/wiki/Upstart

Have fun!


302 Redirects behind SSL-terminating proxies

Thursday, October 29th, 2009

Problem

You have a web site all with SSL. There is a reverse proxy or load balancer that acts as SSL termination point. Behind that reverse proxy you have an Apache web server running plain http.

Your application uses 302 redirects to announce new URLs or whatever the reason is for doing so. Since the web server does not know that https URLs should be announced, the response header is wrong and looks like following:

Location http://www.example.com/your-fancy-url

The browser interprets that location header and send a request to this non-SSL URL instead of https:///www.example.com/your-fancy-url

If your reverse proxy does not know how to handle this, a connection will time-out. How to circumvent this if you have access to the web server but not to the reverse proxy or load balancer? What to do if your load balancer (such as Blue Coat devices) are closed down appliances that are not able to rewrite response headers?

Search engines do obviously not know the answer or I simply did not asked the right question.

Solution

Since Apache version 2.2.4 mod_headers is able to rewrite response headers. Just add the following to your httpd.conf

Header edit Location ^http://(.*)$ https://$1

This configuration statement will solve your problem. Redirects triggered by your back end web servers will be re-rewritten to comply with your SSL terminating reverse proxy/load balancer.

Further reading: mod_headers

Have fun….