…why you should never, never, *never* patch code that you do not understand fully…
And that is why you report bugs to upstream and let those that know what they are doing, sort them out. Not someone with a half-wit for a brain.
Random patching and “improvement” of code is evil. End of story.
“Given enough eyeballs, all bugs are shallow”, my ass. Look at all the debian, and debian related (hello, Ubuntu people!) users squirrel around to change every single bit of crypto that they created in the last two years. Repeat after me: TWO YEARS.
Who of them freedom lovers ever bothered to look at the patches that this oh-so-trustworthy distribution provider has put into a package. Speaking of “single vendor lock-in”: How many distributions call themselves “free and open” just because they recompile or just ship the debian packages verbatim.
That is as good as shipping an OEM Windows, folks! And now you got burned. Bad for you. Good for community health in the long run. Keeps you on your toes.
bug debian linux opensslLinux networking sucks. XEN Networking sucks.
Yes, it does. For a while I started to move stuff away from physical machines onto XEN-virtualized servers. Using CentOS, this works reasonably well, except…
… well, when you use the regular xen network-bridge and vif-bridge scripts to set up and tear down your virtual interfaces, suddenly other services start to scream:
Jan 24 19:45:33 shirley kernel: xenbr0: port 1(vif0.0) entering forwarding state
Jan 24 19:45:33 shirley ntpd[4806]: sendto(192.53.103.104) (fd=18): Network is unreachable
Jan 24 19:45:33 shirley ntpd[4806]: sendto(131.188.3.221) (fd=18): Network is unreachable
Great. The bridge setup changed the network topology and the ntpd (which is bound to eth0 for multicast) doesn’t get it. But wait, there is more.
Jan 28 22:47:04 plucky kernel: xenbr0: port 2(peth0) entering forwarding state
Jan 28 22:47:04 plucky snmpd[2278]: error on subcontainer ‘’ insert (-1)
Jan 28 22:47:04 plucky last message repeated 12 times
So the snmpd chokes on topology changes?!? But hey! Who would run stuff like time sync and network monitoring on a production system? Well, just about, everyone???
The whole xen network setup and changing magic is pretty much useful for your little at-home-boot-every day box. Not for serious production needs (Well, I’m sure that lots of people will scream now in anger, that their production boxes work perfectly with the scripts. If you a) run snmpd and ntpd, b) check your log files on a regular base and c) don’t find the bugs described above, please let me know. Else, don’t. Because without time sync and monitoring, you are not running in production mode.).
So what to do? Don’t let xen setup the networking. Let the OS do it!
Because it has a marginally better understanding of what it is doing. And the scripts are written by people who are paid to think about more complex setups than the one-person, one-interface PC at home.
Setup a bridge for dom0: /etc/sysconfig/network-scripts/ifcfg-br0:
DEVICE=br0
ONBOOT=yes
BOOTPROTO=none
IPADDR=1.2.3.4
NETMASK=255.255.255.0
GATEWAY=1.2.3.1
NO_ALIASROUTING=yes
TYPE=Bridge
Now connect your physical interface to the bridge: /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
BRIDGE=br0
HWADDR=22:44:66:88:aa:cc
The last line should be the HW address of your physical interface. (If you don’t know what this is, please use the XEN supplied networking scripts and don’t bother…)
You must enable ip forwarding on your box. Add the following line to /etc/sysctl.conf:
net.ipv4.ip_forward = 1
Poof! Instant, stable, bridged networking when booting up.
However, starting xend produces a set of ugly veth
options netloop nloopbacks=0
to your /etc/modprobe.conf file. Do it. As long as the module is loaded, XEN is able to create its needed netloops on the fly. You really don’t need to have four more dangling around.
Almost there. Now edit your virtual host definitions in /etc/xen/auto and change the bridge name in the vif= lines from xenbr0 to br0. E.g. like this:
vif = [ ‘mac=ee:cc:aa:88:66:44, bridge=br0′, ]
And finally, open the /etc/xen/xend-config.sxp file and comment out all lines beginning with (network-script …). Really. You don’t need these any longer. Because the networking is already set up correctly. Keep the (vif-script vif-bridge) line.
==> Working, stable and reliable networking with XEN. And even snmpd and ntpd are happy.
linux networking xenHorray! Drag and Drop on Linux!
2007 is definitely a good year, if the product with the longest development cycles ever finally has an official major release.
And now I can finally drag a file out of the IDE into the one true editor!
Imagine that! Working drag and drop between two major applications on Linux! In 2007! (Only ~ 10 years after another operating system got it right)
Why is it that things that one is so used to on every other mainstream OS are sort of a revolution on the Linux desktop?
desktop eclipse emacs linux open sourceThe magic “upgradeany” switch
I finally decided to move the backoffice systems from Fedora to CentOS. Not because it is better, but because I am bored with the insane update cycles that Fedora has. CentOS offers me five years of fixes, so I do not have to do the yearly upgrade shuffle just to keep my systems up.
I like doing upgrade installations, because it keeps the setup information and I do not have to start from scratch. When doing Fedora -> Fedora updates, this is no problem. The installer (I run this through PXE) finds the existing system and offers updating.
CentOS does not. Googling around also does not really help. However, in the depths of the Fedora Wiki, there is a list of additional options for the installer. And as CentOS is based on RedHat Enterprise Linux, which in turn is based on Fedora, you can add upgradeany to the installer command and voila: CentOS upgrades a Fedora installation. Took me just half an hour to find.
centos fedora linux upgradeanyArgh. Matrox.
So I upgraded to Fedora Core 5 for my workstation. Which comes with the Xorg 1.0.1 server. For those of you who are blessed enough to use a system where video drivers are a non issue (because every card is well supported: Windows or only a few cards are actually available: Mac), let me tell you that every version change of the X Window System on Linux is a cause for concern.
As I have a Matrox G550 in my computer which drives two LCDs using digital (DVI) protocol, this certainly is. (I have a Matrox card because I wanted an open source driver. Fat luck. If you want to use DVI or dual display, you something called mgaHALlib.a which contains the magic to turn on these features on Matrox boards. Probably some sacred bit shuffling in there. Whatever.
S0 Xorg-1.01, which is the X11R7 release. Cool new stuff. However, my screens stayed dark. Some googling told me that this configuration is unsupported and the advice from the Matrox support people is downgrade to 6.8.2. However, there are a number of success reports on that board, too.
In the end, I built a zombie from the Fedora Core 5 driver, the mgaHALlib.a and (no joking here) a module stolen from the 6.8.2 driver which the mga driver tries to load but does not find it. It seems that this module just contains a few stubs.
So if you want to use Fedora Core 5, the mga driver and digital output, just get that driver from my download site. It works for me (I’m currently writing this blog entry with it), YMMV.
closed source fedora g550 linux matrox xorg