Funny as it may seem, I fell for it (yet again perhaps?). I’ve installed CentOS5 on top of VirtualBox 2.2.2 on my Ubuntu Hardy 8.04 for the sole purpose of testing out ASP.NET hosting using Mono, XSP, and Apache. And I was in for a surprise that I could not access my virtual machine’s Apache web server instance.

I was able to install VirtualBox 2.2.2 vanilla (not the official Ubuntu package) without any problems. I followed it up by installing CentOS5 as a virtual machine. I then proceeded and configured the network interface for the virtual machine on the VirtualBox Management panel, and set it up to use “Bridged” networking.

I proceeded by booting the virtual machine and watched every boot message zip by without a hitch. I then logged into the virtual machine as root and configured the IP address for the network interface. After which, I pinged the IP address and got the reply I want. I then tried to log in via SSH, ang was able to get in. “Hmm… everything seems to be in order. Might as well continue.” I said to myself. Boy was I in for a surprise.

I proceeded and configured the web server, enabling name-based virtual hosting, started Apache and tried to browse the test page. And then… nothing! ACCKK!!! I checked the IPTables rules if there’s something a-miss. So far everything seems to be in order (really?) . Tried a couple more times, and still get a failure from Firefox. Hmmm.. what could it be. Pondering for hours what could have been missed. A colleague suggested to flush the entire set of IPTables rules, which I did and tried accessing the web server. What do you know! I was able to browse the basic landing page. “Hmmm.. there must be something wrong with the IPTables rules” I said whispering.

I proceeded and checked again /etc/sysconfig/iptables and sure enough, I found the culprit. I mistakenly added the IPTables rule that opens port 80 AFTER the reject rule! No wonder port 80 doesn’t open up. I edited the /etc/sysconfig/iptables again, and place the port 80 rule on top of the reject rule, which will then allow it to take effect first, before the reject rule is activated. And then everything worked as it should.

Lesson? Sometimes the obvious things are really hard to find and double checking definitely will prevent the unnecessary debugging for when your system goes to production. I’m just glad this is a simulation system and not production.

I think it was stupid of me not to notice the order of the rules in the iptables file. What do you think?

Technorati linux, virtualization, virtualbox, centos5, apache, webserver, iptables
Site Search Tags: linux, virtualization, virtualbox, centos5, apache, webserver, iptables

Just a quick tip.

You’re using SuSE Linux Enterprise Server 10 and you are using virtualization with Xen with a couple of virtual machines (DomU) and you are quite happy with how everything turned out. SLES10 is running ok, Xen works fine, DomU’s are healthy and serving as they should. Then again, you need to do a maintenance task and will need to reboot your machine. Then suddenly you found out that you need to manually start all your virtual machines manually! ACK!

Here are some quick steps to follow to make sure that your VMs go up and running as soon as your host OS gets up and running too.

1. On SLES10 terminal, go to /etc/xen/vm

mybox:~ # cd /etc/xen/vm

2. All the definition files for your virtual machines are located there. You can then just copy all the files to /etc/xen/auto

mybox:/etc/xen/vm # cp * /etc/xen/auto/

This is the old way of making your virtual machines start up automatically. Novell experts recommend using the xm command to make your virtual machine automatically start up. Though it’s a bit tedious but it works on the latest SLES10 builds. And you have to repeat the steps for every virtual machine that you want to automatically start up.

Using xm, we will first export our existing (and running) config for one of our DomU (virtual machine) to a text config.

mybox:~ # xm list -l yourVM > yourVM_config

Make sure that you have a backup of the exported config before editing.

mybox:~ # cp yourVM_config yourVM_config.backup

Edit your VM config using vi and look for the following parameters:


(on_xend_start ignore)
(on_xend_stop ignore)


and change them to


(on_xend_start start)
(on_xend_stop shutdown)


Save your file, then let’s export it back to our Xen server using the following command:

mybox:~ # xm new -F yourVM_config

That’s all there is to it. However, if you have 5 other virtual machines running, you will need to repeat these steps for each.

What I did is I combined the former step (using /etc/xen/auto) with the latter steps. So far, my VMs are all up and about when the host SLES10 finishes loading.

Regards and safe journey. Enjoy!

Technorati xen, virtualization, automatic, start, linux, , sles10
Site Search Tags: xen, virtualization, automatic, start, linux, , sles10

The following article contains opinions and personal views of the author and will be taken as such. There is no guarantee to the accuracy, timeliness of some of the information that may be found within the article. The methods that are discussed here might not be applicable in your case. The author will not be held liable for any damage caused by using the method/(s) described in this article . Use the methods at your own risk. - hardwyrd

Here’s a quick and basic how-to in preparing Xen with multiple bridges with multiple NICs for DomUs on Xen in SLES10.

Objective:
Deploy networking on Xen DomU’s using multiple bridges on multiple NICs. Host OS will utilize two NICs for WAN and LAN connections. Guest OS will utilize two NICs also for WAN and LAN connections. Host OS and Guest OS are using different WAN connections and LAN connections.

Step 1: Verify Xen Presence
Make sure that you have Xen installed. If not, you can do:

1. Open up YAST.

2. Click on ‘Software’, then click on the ‘Filter’ parameters box, and choose ‘Patterns’.

3. Verify that ‘Xen Virtual Machine Host Server’ is checked/selected. If not, then check it. The required packages for Xen are shown on the right panel.

4. To make sure, you can check for software dependencies by click on the ‘Check’ button at the bottom of the YAST window.

5. Click ‘Accept’ and let YAST install the packages.

After installation, Xen’s tools will be located in /etc/xen.

Step 2: Prepare NICs for DomUs
By this time, we’ll need to identify which physical NICs we are going to allocate for the DomUs. For our example, our machine has 4 physical NICs labelled ETH0, ETH1, ETH2, and ETH3 respectively. ETH 0 and ETH1 will be used by the host SLES10 (Dom0), while ETH2 and ETH3 will be used by the guest OS (DomU).

To specifically restrict our host from using ETH2 and ETH3, we will need to only initialize the NICs and not declare an IP address nor do we configure them using DHCP. To do just that, we need to:

1. Open up YAST.

2. Click on Network Devices, then click on Network Card.

3. In the Network Cards list, select ETH2 and then set it to ‘None Address Setup’. This will initialize the NIC without an IP address and our host OS will have no use of the NIC which serves our purpose quite perfectly.

4. Click ‘Next’ then Finish.

Do the same for ETH3. Do not forget to setup ETH0 and ETH1 to connect to your desired network.

Step 3: Prepare Xen with multiple bridges
Before we can configure Xen for multiple bridging, we will need to let Xen restart. The optimal way will be to reboot the entire system, or we can just stop the Xen daemon and restart it back up. We can do a Xen daemon restart only if we have already logged into the Xen-enabled kernel of SLES10. If not, we definitely will need to reboot and log into the Xen-enabled kernel.

After booting via the Xen-enabled kernel, we will need to do some preparations before we install our guest OS (vm/DomU). We will need to prepare our network bridges first before our guest OS can use the physical NICs we allocated for our guest OS. We will need two bridges for our guest OS to connect to WAN and LAN. To prepare the bridges, we will need to stop the Xen daemon, and create a wrapper script that utilizes the network-bridge script that comes with the Xen package of SLES10. To stop the Xen daemon, do:

# rcxend stop

We will need to put the wrapper script at /etc/xen/scripts/ along with other Xen tools. The following is a sample wrapper script.

#!/bin/bash
dir=/etc/xen/scripts
“$dir/network-bridge” “$@” vifnum=0 bridge=xenbr0 netdev=eth2
“$dir/network-bridge” “$@” vifnum=1 bridge=xenbr1 netdev=eth3

Save the file as br-wrapper_script or whatever filename you specify. Chmod the file to executable using:

# chmod o+x br-wrapper_script.

After creating the wrapper script, we will need to modify Xen’s configuration to use our wrapper script instead of network-bridge directly. The file of interest here is /etc/xen/xend-config.sxp.

# vi xend-config.sxp

Look for the entry that contains (network-script network-bridge) and change it so that it will become (network-script br-wrapper_script). The config file call our own wrapper script instead of the default network-bridge script.

After the necessary modifications, restart the Xen daemon by entering rcxend start at the terminal. Check if our bridges were created by using ifconfig:

Once, you see xenbr0 and xenbr1 then you are good to go.

Step 4: Utilizing multiple bridges for the Xen DomU
Xen DomUs can be created through YAST using the virtualization tools.

If “Create Virtual Machines” and “Virtual Machine Manager” is not present, click on Install Hypervisor and Tools. However, if you’ve installed Xen beforehand, you’d have these tools already.

To utilize the multiple bridges, you’ll need to make some side steps in the workflow when you create your virtual machine. Make sure that when you reach the virtual machine summary, click on “Network Adapters”.

Create the necessary number of paravirtualized NICs. In our case we need two.

Make sure that each virtual NIC will be linked to the correct bridge (previously created). Your virtual NIC 0 must be linked to xenbr0, and virtual NIC 1 will be linked to xenbr1.

Exit the Network Parameters workflow and continue with your virtual machine installation.

More info at:
SuSE Linux Enterprise Server 10 VM Network Configuration Examples by Glen Davis (Novell)
NIC Bonding with Xen Virtualization by Joe Harmon, Jim Short
Xen Source Official Site

Technorati: xen,Xen, virtualization, Linux, SuSE, Enterprise, SLES10,multiple, bridge, network,
Site Search Tags: Xen, virtualization, Linux, SuSE, Enterprise, multiple, bridge, network,

In an enterprise environment, it is quite a challenge for administrators to be able to quickly and efficiently deploy a bunch of network services on top of Linux. Services like web(http), ftp, DNS, DHCP, SSH, and the like require some configuration time, proper planning, and discussion with the deployment team, auditing team, and helpdesk teams. Rolling out a set of physical servers is also another area where improvement in deployment speed is almost equivalent to a the success or failure of your business.

Choosing what platform or operating system to leverage on for your environment is also another key decision. Depending on an enterprise’s requirements, you may opt to go for Linux, pure Unix, Windows (yeah it too is an option by some standards), and even Mac OS X. You might ask, “How come Netware is never mentioned?” Well, it is quite obvious. Despite the strength and reliability of Netware, the low volume of applications that could be had on the platform has almost put it to near obscurity. However, those who are still using Netware continue to profess to its rigidity, solid performance, and reliability.

What will happen to Netware? Actually, Netware is not dead. It is alive and well, and Novell continues to nurture the still breathing, and would you believe it - growing, community of Netware users. Yes, yes, I’ve said Netware was put to near obscurity. Got it? N-E-A-R. It’s not obscure. It’s not dead. It is just low under the radar compared to other platforms like Windows, Linux, Solaris, and others. Again, its community is growing.

How on earth is it low on the radar and yet growing? Simple. Novell is slowly morphing Netware. From a pure Netware operating system, it is now a hybrid operating system. Novell called it Open Enterprise Server (OES). Open Enterprise Server is both a Linux system and a Netware system. On one hand you can install it as a Netware-kernel based server, offering the same traditional Netware services. On the other hand, you can deploy it as a pure Linux system, based on SuSE Linux Enterprise Server 9, offering traditional Linux services like any other Linux distribution and yet also offering the Netware services that you can only previously find on Netware. Services like Virtual Office, Edirectory, iFolder, and Netware Storage Services, are just a few of those services traditionally found on Netware.

Novell Open Enterprise Server 2 Public Beta
Recently, I have received an email from Novell’s Beta Management Team informing me (and others in their mail list of course) that Open Enterprise Server 2 is now available as Public Beta release. OES 2 will complete the transition of offering Netware services on top of a pure Linux system.

Solid Under the Hood
OES 2 runs on top of SuSE Linux Enterprise Server 10 SP 1 leveraging the latest stable enterprise SuSE build fused with the latest Netware 6.5 services on an easy to deploy Linux-cum-Netware distribution.

Notable Improvements
Like any recent Linux distributions, Open Enterprise Server 2 has full support for 64-bit dual-core and multi-core processors. And just like its SuSE Linux Enterprise brethren, it also comes chockful ‘o virtualization goodness thanks to the built-in Xen Hypervisor technology that allows it to provide both paravirtualized and fully-virtualized environments of Windows, Solaris, or other Linux distributions.

The most notable development to date that the Open Enterprise Server 2 may offer is the Dynamic Storage Technology introduced in this build. Dynamic Storage Technology eliminates seldom-used data from taking up valuable space on your most expensive and highest-performing storage devices. As Novell puts it:

“Dynamic Storage Technology allows administrators to create policies that dictate what data is considered active or inactive. With these policies, inactive data is relocated to lower-cost storage solutions and is backed up less frequently. Active data then resides on highest-performing storage environments, is backed up more frequently and is first to be restored in the event of a disaster. End users see no change in the way they access their information, but the data is automatically optimized based on policies and actual use.”

Another key development to this build is called Domain Services for Windows. In the good old days of Netware and the previous OES version, the only way for Windows workstations to authenticate to Edirectory will be via the Novell Client which must be installed on all machines. With Domain Services for Windows, workstations will no longer need to have Novell Client installed, and instead will communicate with Open Enterprise Server using native Windows protocols and authenticate themselves the same way they authenticate to Active Directory.

The same Domain Services for Windows also provided another way to manage OES on top of Windows — via the Microsoft Management Console. Netware and the previous OES version is managed via ConsoleOne or iManager. Now, administrators can perform certain file system and directory tasks, as well as centrally administer Samba shares via the MMC.

Me and my team are still currently evaluating the current beta build and it might be a month or so before the final stable release. However, we are very excited to see this thing run and look at what it can do. Who knows, this might just allow Windows Server 2003 make a run for its money.

Links:
Novell OES Product page
Novell OES 2 Public Beta Download page

Technorati: OES, Open, Enterprise, Server, Novell, Netware, Linux,
Site Search Tags: OES, Open, Enterprise, Server, Novell, Netware, Linux,

In a landmark accomplishment, the Fedora team has finally released Fedora 7 “Moonshine”.

What sets Fedora 7 apart from previous Fedora releases is that this latest release unified the two Fedora components — Fedora Core and Fedora Extras. The final public release of Fedora 7 yesterday, May 31, followed the traditional development freeze last May 17.

Other features that will be seen on this latest Fedora release are listed as follows (taken from the Fedora Wiki):

1. Merged Core and Extras - Fedora Core and Fedora Extras merged into a single source control system and use a single build system, thus creating a new package set that carries the already overloaded name “Fedora”.

2. Ability to spin a custom distribution and/or live CD - users can now create a custom Fedora-based distro or live CD. Custom CD spins on top of Fedora 7 can be both live and installable, or only installable only.

Courtesy of the Fedora Project. Click to enlarge.

“Fedora Prime” and “Fedora Everything”

Fedora Prime is basically a spin of the Fedora project that more or less targets various system deployment “profiles”. Some users would want to deploy Fedora as a server, others want to deploy it as a plain desktop, some want it to become a developer desktop, and some people want to deploy it with a little of anything. Creating different spin releases to fit certain deployment profiles are out of the question, therefore the Fedora board decided to create the Fedora Prime spin which will include packages that will allow users to deploy Fedora either as a server, desktop, or developer desktop.

Fedora Everything of course is self explanatory. It contains every package known to the Fedora Project. In essence, everything is like your own Fedora repository. Some packages that did not come with the Fedora Prime spin can be found in the Fedora Everything spin. Do you really need all of those things?

Final Release Spins

Fedora 7 “Moonshine has the following features incorporated in its final release:

- 2.6.21 kernel with integrated kernel-based virtual machine (KVM) managed through virt-manager and virsh.
- included Xen and QEMU for virtualization.
- kernel-based support for VMWare VMI interface
- separate bootable live CDs for GNOME and KDE
- a regular image for servers, desktops, and workstations (Fedora Prime)
- desktop uses GNOME 2.18 or KDE 3.5.6
- fast user switching
- Xorg Server 1.3
- packages for enhanced wireless networking
- NetworkManager installed by default either under GNOME or KDE
- new “Flying High” theme
- Firefox 2
- Python 2.5
- improved I18N support with SCIM working automatically
- enhanced number of localization and language packages in the GNOME-based live CD
- a graphical administration tool for SELINUX
- SELINUX troubleshooting tool enabled by default
- integrated FireWire Stack
- improved power management through “dynamic ticks”
- consolidated dictionaries
- experimental “noveau” driver integrated in Xorg and kernel (disabled by default). Noveau is a free and open source 3D driver for nVidia cards.
- improved performance for yum, Pirut, and Pup.
- support for Playstation 3

More Fedora 7 “Moonshine” features can be found at the Fedora Project Wiki. You can also take a tour of Fedora 7 at the Fedora 7 Tour site.

Release Downloads

Fedora 7 “Moonshine” is available for x86, x86_64, and PPC platforms.You can download Fedora 7 directly at the following:

Fedora download site.
FedoraTorrents
Fedora 7 x86/i386 ISOs
Fedora 7 x86_64 ISOs
Fedora 7 PPC ISOs

Summary

I hope to download the release either this week or by next week. For the first few days of the release, the Fedora servers will be flooded with downloads since mirrors are scrambling to sync with the new material. I might join in while I can (bandwidth permitting).

I hope to see this really to be really good.

Other links:
Fedora Mailinglist Announcement Email
Fedora Project Wiki
Fedora 7 Release Summary
Fedora 7 Release Notes
Fedora 7 Category of Features

Technorati : fedora 7, release, linux, open, source
Site Search Tags: Fedora, 7, release, linux, open, source