Friday 25 February 2011

Cloned Red Hat/CentOS/Scientific Linux Virtual Machines and “Device eth0 does not seem to be present” Message

Recently I was preparing some new virtual machines in VMware running Scientific Linux 6.  I encountered some difficulty with the virtual network interface after preparing clones of the machines.  In particular I was unable to get the virtual NIC on the newly cloned machine to be recognized as a valid interface.  Upon further investigation the NIC on the newly cloned machines was being registered as “eth1″.  We can check the currently registered “eth” devices here:

[root@sl6 ~]# ls /sys/class/net
eth1  lo  sit0

As it turns out there is a device manager for the Linux kernel named “udev” which remembers the settings from the NIC of the virtual machine before it was cloned.  I was not familiar with udev because it was not installed in my previous Linux VM install, which were mainly CentOS 5.
Since the hardware address of the network interface changes as part of the clone, the system sees the NIC after the clone as “new” and assigns it to eth1.  The simple way to move the interface back to eth0 is to edit the strings beginning with “SUBSYSTEM” in udev’s network persistence file.
Start off by removing the first “SUBSYSTEM” entry that represents the “old” eth0 interface.  Then edit the second “SUBSYSTEM” entry, changing the “NAME” parameter from “eth1″ to “eth0″.  Of course your config may vary from mine.  Keep in mind that the “SUBSYSTEM” line may be wrapped in the text below.
Old file:

[root@sl6 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:21", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x15ad:0x07b0 (vmxnet3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

New file:

[root@sl6 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Now verify that you have a properly configured network config file, the example below is for Red Hat/CentOS/Scientific Linux:

[root@sl6 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
HWADDR="00:50:56:87:00:25"
IPV6INIT="no"
IPV6_AUTOCONF="no"
NM_CONTROLLED="no"
ONBOOT="yes"
IPADDR="192.168.10.125"
NETMASK="255.255.255.0"
NETWORK="192.168.10.0"
BROADCAST="192.168.10.255"
Now reboot the system and the NIC should now be registered as eth0!

Tuesday 8 February 2011

ESX 4.1 install error on BL460c G7 - NIC driver fails to load

The HP BL460c G7 is on the VMware HCL list for ESX 4.1. However, when trying to install ESX 4.1 there's an error during install - it fails to load drivers for the network adapter ("No network adapters were detected"). It doesn't help to update all firmware to latest version (even though this should be done in any case...) (Update 2011.02.18: This problem persists on ESX 4.1 U1)

This is a known error and there's a fix for it. However, it seems strange that the G7 blade has made it to the HCL list...

The problem is that the Integrated NC553i Dual Port FlexFabric 10Gb NIC driver is not included in VMware's installation ISO for ESX 4.1. There are two ways to solve the issue. One is to load a custom set of drivers for the NIC and the other is to use an HP VMware install image. If you're using ESXi or scripted installation of ESX classic, then you have to use the HP image.
(Update 2011.07.19: Custom HBA driver should also be loaded during installation - simply load both ISOs)

Custom NIC driver from VMware can be downloaded here.
Custom HBA driver from VMware can be downloaded here.

(Update 2011.02.18: Apparently, the NIC drivers are updated quite frequently at the moment. Go to this main link and then 'plus out' Driver CDs to find the most recent one.)

HP image for ESX(i) can be downloaded from here.

The custom driver, when downloaded, is in an ISO format. To load it during installation, do the following:

  • Upload the ISO file to where you have the ESX installation image
  • On the Custom Drivers page in the wizard, choose Yes and click on Add. It will tell you to load the driver CD (see picture below)
  • Unmount the ESX installation CD and mount the driver ISO in stead. This can be done without interrupting the installation. You will be prompted to verify the custom driver package, click OK (see picture below)
  • That's it. at a later stage in the wizard, you will be prompted to reinsert the installation ISO. Do that when prompted.


Wednesday 2 February 2011

How to Mount and Access Files in an ISO image on Linux

Like anything else on Linux, it’s easiest to do things from the command line, and when we’re dealing with servers that’s probably the only thing we easily have access to. Luckily it’s trivial to mount an ISO image in Linux.
Open up a terminal window and type in the following commands, assuming that you are in the same directory as the ISO image, and adjusting the paths as needed:
sudo mkdir /media/iso

sudo modprobe loop

sudo mount filename.iso /media/iso -t iso9660 -o loop
You should be able to navigate to the /media/iso folder and see the contents of the ISO image. If you want to unmount the iso, use the following command:
sudo umount /media/iso
That’s all there is to it. Easy, right?

Tuesday 1 February 2011

How To Create Bootable USB



You do not have a CD / DVD and you want to try a  Live bootable CD via USB. 
Or say You want to make a bootable USB.
 
WinToFlash starts a wizard that will help pull over the contents of a CD or DVD or a disc image in ISO format and prepare the USB drive to become a bootable replacement for the optical drive.
  • It Supports Windows XP, Vista and Win 7.
  • Freeware
  • Easy to Use

How to use it:

1. Download and install and Run it.

2. Now choose any operation from the list. and press Run.


3. Select the Location of iso file in Source and also select Usb Drive's Location and press run.

Installing and Configuring Remote Desktop Services (Terminal Services) on Windows Server 2008 R2

In the latest release of Windows 2008 R2, Terminal Services has been renamed Remote Desktop Services (RDS).  There are many enhancements in this release including enhanced multimedia performance and the ability to publish custom applications sets to specific users through Remote Desktop Web Access.  The Web Access role as the name suggests allows users to access Remote Desktop applications through a web site.  This feature is official known as RemoteApp.  The new name for the core Terminal Server running in application mode for user sessions is Remote Desktop Session Host.
In my environment I will configure the Remote Desktop Session Host and Web Access roles on the same server.  I will also install the Remote Desktop Licensing role on a dedicated server so that any additional Session Hosts I add in the future can share this service.  The License Server role can be installed on your Session Host server if desired.  All of my servers are members of an Active Directory domain.
Install Remote Desktop Licensing Role
To start go into the Server Manager on the server that will host the Licensing role service.

Under Roles Summary select “Add Roles”.

Click Next.

Check Remote Desktop Services and click Next.

Click Next.

Check Remote Desktop Licensing and select Next.

Discovery scopes are no longer used for licensing with Windows 2008 R2 Remote Desktop, we can assign these to our Remote Desktop Session Host manually or through a group policy.  There is a 120 day grace period allowed for connections to a Remote Desktop Session Host before a license server needs to be activated.  Click Next.

Confirm the settings and click Install.  Then click Close once the install is completed.

Install Remote Desktop Session Host and Web Access Roles

Now switch to the server that will be our Remote Desktop Session Host and Web Access server.  Start Server Manager.

Select “Add Roles”.

Check Remote Desktop Services and click Next.

Check the RD Session Host and RD Web Access services.  When you add Web Access you’ll be prompted:

Click Add Required Role Services to accept to install the prerequisites.  Then click Next back at the Add Roles Wizard.

At this time I’ll select “Do not required Network Level Authentication”.  There are some issues using NLA if we have Windows XP SP3 clients, but there is a registry fix available.  Click Next.

I’ll choose Per User licensing mode and click Next.

Now we can add additional groups of users to have access to applications on the Session Host.  The local Administrator group on the server is included by default.  I’ll add additional groups later so for now I’ll click Next.

I’ll check all of the available check boxes to provide for an enhanced client experience on this Session Host.  This will allow for capabilities such as playing multimedia through the RD session and Windows Aero if we publish a full desktop on this server.  This all sound great, but be aware that these features will consume additional resources on your Session Host.  Click Next.

Click Next, then click Install at the confirmation screen that follows.  The server should prompt for a reboot when the installation is complete.

Configure Session Host to Use Licensing Server
After you reboot and log on to your Session Host and go to Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.

In the middle pane under Licensing double click “Remote Desktop license servers”.

Click Add.

Your license server should appear under known license servers.  If not, enter the FQDN or IP address of the server and click Add.  If you are not logged on as a Domain Administrator and the License server is on a different server in your domain it will give you a warning about being unable to verify, it should be okay to simply click through this message.  Click OK.
Add Users for Remote Desktop on the Session Host
Now we’ll go into Computer Management and add the additional users group(s) that we want to allow access to Remote Desktop sessions on the Session Host.  Go to Start > Administrative Tools > Computer Management.

Open up “Local Users and Groups” on the left pane, then highlight the Groups sub-folder.  Double click the “Remote Desktop Users” group in the center.

I’ll add the Domain Users group.  Click Add.

I will allow all of my domain users access to Remote Desktop sessions, so I’ll type Domain Users, click Check Names, then click OK.  Click OK through the remaining dialog windows, and close Computer Management.
Publish a Remote Desktop RemoteApp Program
Now it’s time to publish a test application.  Go to Start > Administrative Tools > Remote Desktop Services > RemoteApp Manager.  Click “Add RemoteApp Programs” in the right Actions pane.

Click Next.


I’ll test using the Calculator, so check that and click Next.  At the confirmation window click Finish.

Test Newly Published RemoteApp Program
Now I’ll log on to a client machine in my domain to test the newly published Calculator.  On the client open up Internet Explorer and enter “http://YourWebAccessServer/rdweb”.

Click “Continue to this website” in the browser window.

You may receive a warning about the ActiveX control not being installed.  I’ve generally only seen this on Windows XP clients.  To fix this reset your IE internet settings by clicking Tools > Internet Options.

Click the Advanced tab.  Then click the Reset button.  Click through the dialog boxes.  Once you’re back at the IE browser windows, close IE and reopen it.  Now you go back to “http://YourWebAccessServer/rdweb” and click through the certificate warning you should be presented with the RD Web Access log on screen.
When a user with standard privileges on the client accesses the RD Web Access site for the first time they will receive a warning about installing the Remote Desktop ActiveX Control.  Confirm that you trust the web site address you are contacting.  You probably will because you should be accessing your own server!

Click the warning message at the top and select Run Add On.

Now click Run.

Log on with a user you’ve given access to Remote Desktop sessions.  The administrator should automatically be given access.  Be sure and specify the domain first if you are using a domain account.

You’ll receive a warning about unable to identify the remote connection publisher, click Connect.

It will now ask for you to log on to the the RD session.  Enter the user name in the Domain\Username format.

And another warning will appear about identity verification, click Yes.  We’ll set up a new certificate from a trusted certificate authority later to eliminate this message.  The RemoteApp should now launch.

Eliminate Certificate Warnings (optional)

Now let’s work to eliminate the multiple certificate warnings we receive when accessing our Remote Desktops and RemoteApp programs.  In this example I will make use of an enterprise certificate authority configured in my AD domain, of which my RD Session Host/Web Access server is a member.
Note that this process will only eliminate the warnings if my clients and RDS server are members of the AD domain since they will automatically trust the AD enterprise certificate authority.  If you have non-domain clients that connect to your RDS server you’ll need to export and import your CA root certificate into the certificate store on these systems so the IIS and RDS certificates are trusted.  Page 1 of the post Configuring Non-Domain Windows IIS Servers has details on how to do this.
Eliminate RD Web Access/IIS Certificate Warning
First if you have not done so in your environment already, Install an Enterprise Certificate Authority in Windows 2008 R2.
Next, Configure a Server Certificate for IIS/RD Web Access.
These two steps should take care of the warning we receive when we access the RD Web Access web site.
Eliminate RemoteApp Certificate Warning
Now let’s remove the first RemoteApp certificate warning.  On the Session Host navigate to Start > Administrative Tools > Remote Desktop Services > RemoteApp Manager.

Under Overview click Change after the Digital Signature Settings heading.

Under the Digital Signature tab check the box for “Sign with a digital certificate”.  Then click the Change button.

Select the certificate published from our enterprise CA.  I’ll use the certificate I requested for my IIS/RD Web Access service.  Be sure and choose the certificate issued by the CA and not the self signed certificate.  Click OK.

Click OK back at the RemoteApp Deployment Settings box.
Once a certificate from a trusted certificate authority is configured, the RemoteApp session should pass through the authentication credentials entered on the RD Web Access page and the second log on to the Session Host will no longer be necessary.  Yes!
Eliminate Remote Desktop Connection Certificate Warning
I have noticed that this step is not needed with Windows 7 domain member clients, but for good measure I wanted to make sure that all of my potential clients are cleared of certificate warning messages.  On the Session Host go to Start > Admin Tools > Remote Desktop Services > Remote Desktop Session Host Configuration.

In the center pane under Connections double click the RDP-Tcp connection.
In the General tab under Certificate click the Select button.
Again I’ll use the certificate I published for the IIS/Web Access role.  Click OK.
Back at the RDP-Tcp Properties box click OK.  We should now be configured to access our RemoteApps without any more annoying certificate warnings!



Next previous home