Upgrading Fedora 8 to Fedora 9: lot of pains

Today I decided that I must upgrade to Fedora 9 (lazy day…), and I choose to do that in the proper way (i.e. not using Yum but with Anaconda: this requires burning a DVD, something I feel unappropriate from an environmental point of view, as I will use that DVD only once).

Update was some of a disaster. Altough the installer didn’t complain at all, the Fedora 9 kernel wasn’t installed, and grub.conf was altered with root (hd1,0) in the place of root (hd0,0), which result in a GRUB shell after the reboot.

I fixed it, restarted the system, ran grub-install, and then see that Python has been broken, so Yum doesn’t work (with the infamous “No module named _sha256″ error). As I’m accustomed with this problem, I manage to download Pyhton and Python-libs RPMs from a Fedora 9 repository, force the removal of the old ones and then install the brand new packages, and then I was able to run a massive “yum update -y”, that downloaded 1.2 GB of binaries (638 packages), requires to manually remove some conflicting packages (lirc and qt4) and then, after one hour of work give me a working system.

It appears that, somehow, the installer wasn’t able to remove all the Fedora 8 packages, this causes the Python/Pyhton libs version mismatch, and probably stops the upgrade processes.

I can accept the Python problems (it’s not the first time I encounter them, and they could be related to something I made maybe years ago on this system, leaving it in a unconventional configuration that the installer is unable to understand and manage properly) but I find completely unacceptable that Anaconda breaks GRUB configuration. Yes, I asked to do a new configuration of GRUB during installation time, but Anaconda should understand which hard drive is hd0 and which is hd1. At least, it should allow me to manually edit the configuration file, while in fact the entire installation process appears to me too much “streamlined”, i.e. we do it for you, we know what to do, and this was too optimistic an assumption.

These are for the pains, not sure about the gains. It seems to me that Gnome takes considerably more time to start, and Firefox 3 doesn’t seem so faster than Firefox 2.

Filed under: fedora, anaconda, fedora, rpm, upgrade, yum

Bonding, aliasing and natting

Scenario: you want to connect a LAN to another one. Connection should be easily enabled and disabled.

At work we have a training and examination classroom with its own IP addressing schema. This LAN should be disconnected from the rest of the infrastructure when exams are in place (people should not be allowed to access Internet to find answer to questions) but we need to be allowed to do client’s operating system update when needed.

To do so, we have a classroom server that act as a NAT, DHCP and DNS server for the computers in the classroom. As availability is critical, we have grouped the two NICs on it to give a bonding interface. We have defined a bond0 interface, with an address of the external LAN, and a bond0:0 alias, with an address of the classroom LAN.

Then we have these rules for iptables:

iptables -t nat -A POSTROUTING -o bond -j SNAT --to-source EXTERNAL_IP

EXTERNAL_IP is the IP by which every client of the classroom should appear out of it.

iptables -t nat -A POSTROUTING -o bond -j MASQUERADE

To allow for IP Forwarding, we need to do this:

echo 1 > /proc/sys/net/ipv4/ip_forward

(this could be make persistent across reboot by adding net.ipv4.ip_forward = 1 in /etc/sysctl.conf). Connection will be disabled with

service iptables stop

and enabled with

service iptables start

Note that iptables rules don’t deal with interface aliasing, they need just the bare interface, and that here we are doing bonding and aliasing, and it appears working

Of course, this configuration is no way complex, but it has the property that I always forget about it, so I write this on the blog to allow to find it easily when needed.

Filed under: rhel, aliasing, bonding, iptables, masquerading, nat

A web site that sucks, badly: now.netapp.com

Imagine you have bought a Net App filer, as we have done (online backups and document sharing for clients). Imagine that you want the documentation manuals, because you want to see how to install, configure and administer it. You will be disappointed when you don’t find any manual in the package shipped by Net App, on printed form or on a documentation CD.

Ok, but on some on the enclosed sheets, you read that you can go to now.netapp.com, register and have full access to the documentation. I have some difficult understanding why you must register to read documentation (which is one of your best marketing agent, if you are confident enough on your product), but I can live with that.

Are you on the Net App website? Ok, now you can create an account. Please choose the level of your account. Yes, you can be a guest, which means you can have very little access, or you can register your product (via serial number) and be a member of this hallowed community.

First, I register myself as a guest, believing that I can upgrade later. No way. As a guest, you can see the astounding home page, where every link you click gives you an “Anauthorized access” courtesy page. Included, the “Register my product” page. I’m sure that the home page looks astounding, because it will be the only thing from Net App that you can see, and they can’t be stupid to limit themselves in something less that astounding.

Net App web site is made with the philosophical assumption that “first impression counts”, so if you start as a guest ad then spend 1 million on their product you can’t upgrade. And we spent a lot less than 1 million, so I’m picturing myself Net App executives angry and furious for a guest that is trying to gain access to the support for the product it has bought: how would I dare?

Ok, let’s try another way. We start with a new account, and we immediately choose to register it, because as the web site states, you will have a shorter evaluation phase before being member of the hallowed community of the people that can see the documentation. Indiana Jones, as an example, he’s not, but I’ve heard about a fifth film of the saga, so hold on your breath.

After two working days, we still don’t have access. So we have this brand new filer that is sitting idly, because no one wants to try to configure it without knowing how it works (how strange, like we are engineers).

Now, dear Net App executives in charge of the web site, I’d like to address you directly with a quick recap:

1. You don’t know how to use a web site to market your product;
2. You don’t give access to your products documentations, which means that you don’t trust your product and/or your customers;
3. You are not helping your customers in getting the most out of your products, which is really, really, deeply irritating;
4. You are unable to process your customer requests according to the dadaistic workflow you have defined in your web site;
5. If you believe that this will force me, as a customer, to buy your technical services, you are a wrong, wrong way wrong.

I suggest you to see how IBM, Red Hat, VMware, HP (just to name some I know and profitably use in my everyday’s work) are dealing with this strange phenomenon called “web”. Some of them are even using public-accessible mailing list for their customers. They are fools, clearly.

In the meantime, please believe me: even a good product with a bad or zero documentation won’t be good enough. I was tempted to play around with the web interface as long as I would reach a “no more working” configuration, and then send the filer back to you asking for a manual to fix it. Don’t tempt me more.

Filed under: rant, fucked by design, net app, netapp, network appliance, web site