Blog

There's been a widely held notion for some time now that IT departments should be "run as a business" and focused on  serving internal customers. But according to this thought provoking article, that may not be the best approach after all.

The trend is not always necessarily your friend.

As is the case with cloud computing, there is still plenty of debate as to what exactly constitutes a tablet. Don't expect this to be cleared up any time soon.

Liquids that flow smoothly until subject to shear forces look (at least to my eyes) to be a very interesting technology for motorcycle riding armor applications. The only question is, how long until someone tries this commercially?

When I first set up my latest CentOS server, I expected to experience the same near-bullet proof reliability I've enjoyed on all of my other RHEL and CentOS installs.

However, that was before I learned that the Xen (a virtualization system that allows you to host multiple virtual servers on a single phyical machine) had problems playing nice with Realtek-8169 ethernet cards.

Early on the Xen-enabled kernel I installed had no problems. But when I recently upgraded to the latest and greatest CentOS Xen kernel, I noticed immediately that something was wrong--the server stopped responding to the network after I rebooted.

What to do?

Doing major surgery on the operating system can be quite a headache. However, following some research I applied the following fix:

1) Manually edit /etc/sysconfig/networking-scripts/ifcfg-eth0. If your server had a fixed IP, chances are you'll find that your IP address is gone. Add all the necessary info back in (IP, Netmask, etc.). If you have nothing to reproduce it from, it should look something like:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=<your.broadcast.ip.address>
HWADDR=<your_MAC_address>
IPADDR=<your.i.p.address>
IPV6ADDR=
IPV6PREFIX=
IPV6_AUTOCONF=yes
NETMASK=<your.netmask>
NETWORK=<your.network.address>
ONBOOT=yes

2) service network restart

3) verify your network connectivity has been restored.

4) yum install kernel

5) yum remove xen kernel-xen

6) edit /etc/grub.conf and make sure that:

a) only the new non-xen kernel is showing up as a boot choice

b) default=0

At this point, you should be able to reboot into your shiny new non-xen kernel, and have any xen related headaches fading fast.

Now you can get back to the zen of reliable servers!

As exploits and their authors continue to evolve in approaches and methods, life online gets evermore challenging. For example, imagine an exploit that sends an ongoing twitter-like update stream of everything you do on your PC to a third party. Even more motivation (as if that should be needed) to keep your antivirus and anti-malware utilities up to date.