Make a RHEL 6 Bootable USB Installer

This posts outlines the steps required to make a RHEL 6 Installation USB Stick.  Effectively, this is nothing more than a USB stick version of the RHEL 6 DVD ISO.  The steps here will also work with any RHEL 6 based clone.

Note: There is a bug that prevents this from working on RHEL 6.4. However, RHEL 6.5 works properly. I have not tested this with RHEL 6.4 clones, so YMMV with those.

As always, use caution for running elevated commands; I am not responsible for any mistakes you make.

Having a USB stick to install RHEL 6 from is quite convenient, especially when making custom kickstart scripts.  The steps below provide a simple means to accomplish this task.  However, before moving forward, the following items are required:

  1. An 8GB or higher USB Stick that you want to dedicate for this
  2. The regular installation ISO’s for the version of RHEL 6 (or CentOS, Scientific Linux, etc.) you desire to install
  3. The minimal or “netinstall” ISO. This is crucial!

General Layout:
This is basically going to be setup as follows:

  • The USB Stick will have 2 partitions. One partition will be bootable, and be used to load the boot menu. The other partition will have the installation ISO’s (and any additional resources, like Kickstart files) on it.
  • The USB Stick will boot, and present the installation disk boot menu. You will select the option to install RHEL 6 from the ISO file stored on the second USB stick partition for installation.
  • Effectively, this is nothing more than a “Hard Disk” installation; meaning that the installer will look for an ISO file on an external HDD that contains all of the required files to install RHEL. However, we are going to “trick” the installer into thinking that our USB stick is the external HDD. This is actually a lot easier than it sounds.

Prepare Install Media:
Once the ISO’s are downloaded, some work will need to be done to make everything work as simple and fool-proof as possible. As mentioned above, download the net-install, or minimal boot ISO file. We are then going to extract the contents, and make a small modification to tell the installer where to find the installation source. This prevents you from needing to type in extra stuff to get an install going.

So, to do this, we will need to copy all of the contents from the ISO file to a directory that we can work with. Elevate to root and follow the following instructions in this order:

  1. Make a new directory in /tmp called rhelboot with the command:
    $ mkdir /tmp/rhelboot
    This is going to serve as a mount point for the minimal boot ISO file. For the purposes of this tutorial, I am using using the CentOS 6.5 net install ISO.
  2. Make another directory in /tmp called rhelmodboot with the command:
    $ mkdir /tmp/rhelmodboot
  3. Mount the minimal boot ISO file to the newly created directory:
    $ mount -o loop /location/to/downloaded/minimal-boot.iso /tmp/rhelboot
  4. Copy all files from the ISO file into the modification directory we created above:
    $ cp -pr /tmp/rhelboot/* /tmp/rhelmodboot/
  5. At this point, you can unmount the ISO:
    $ umount /tmp/rhelboot
  6. We are now going to add an entry to the boot menu. This entry will load the installer and tell it to select the proper ISO file as an installation source. To do this, we need to modify the file: /tmp/rhelmodboot/isolinux/isolinux.cfg
    This file lists all of the boot menu entries that will load the installer. This is what it looks like:

    default vesamenu.c32
    #prompt 1
    timeout 600
    
    display boot.msg
    
    menu background splash.jpg
    menu title Welcome to CentOS 6.5!
    menu color border 0 #ffffffff #00000000
    menu color sel 7 #ffffffff #ff000000
    menu color title 0 #ffffffff #00000000
    menu color tabmsg 0 #ffffffff #00000000
    menu color unsel 0 #ffffffff #00000000
    menu color hotsel 0 #ff000000 #ffffffff
    menu color hotkey 7 #ffffffff #ff000000
    menu color scrollbar 0 #ffffffff #00000000
    
    label linux
      menu label ^Install or upgrade an existing system
      menu default
      kernel vmlinuz
      append initrd=initrd.img
    label vesa
      menu label Install system with ^basic video driver
      kernel vmlinuz
      append initrd=initrd.img xdriver=vesa nomodeset
    label rescue
      menu label ^Rescue installed system
      kernel vmlinuz
      append initrd=initrd.img rescue
    label local
      menu label Boot from ^local drive
      localboot 0xffff
    label memtest86
      menu label ^Memory test
      kernel memtest
      append -
  7. Add a new label by copying and pasting one of the sections above with the necessary modification. The USB partition that will contain the ISO will be mounted as sda2 (during the installation process). This is important, as you will see later… To make a simple installer (without kickstart), add an entry similar to this:
    label usbinstaller
      menu label ^Install RHEL 6 from the USB Stick
      menu default
      kernel vmlinuz
      append initrd=initrd.img repo=hd:sda2:/

    Note: The label and menu label tags are customized. This particular entry is the default, marked with: menu default. If you copied and pasted, make sure you remove the other menu default entry. Also make note of append. I have added: repo=hd:sda2:/ to it. This follows the convention: repo=hd:device:/path. This will tell the installer that the installation source is located on a HDD (our USB stick in this case), and on the main root directory of it (this example). You can of course change which directory you want to place it in, for example: repo=hd:sda2:/workstation.

    For Kickstart: If you are using kickstart, it will be similar to above. The only difference is that you will need to have an append entry that follows this convention: ks=hd:device:/directory/ks.cfg. For example (keeping with the “workstation” convention earlier, and assuming that the kickstart script is located in the workstation directory):
    append initrd=initrd.img ks=hd:sda2:/workstation/ks.cfg (If you are using Kickstart, you don’t use repo=).

  8. Once done, save the file.
  9. The next steps involve the creation of the bootable ISO file that will be used to present the menu. You will need to run the following commands to generate the boot ISO file:
    $ cd /tmp/rhelmodboot
    $ mkisofs -o /tmp/bootmod.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -V "RHEL-6-USB-INSTALLER" -T .

    Don’t forget the last “.”, that is needed for the command to work properly!

  10. After the last command, an ISO file will be present at: /tmp/bootmod.iso. The next step is crucial for USB bootability. The ISO will burn to a CD/DVD fine, but it won’t boot from USB until you make it USB bootable. To make it USB bootable, simply run the command: $ isohybrid /tmp/bootmod.iso
  11. The ISO should now be USB bootable. The next step is to get the ISO onto a USB stick. This will involve erasing everything off of the USB stick, as it will be dedicated for this task. To make matters simple, delete all partitions off of the USB stick. To do that, insert a desired USB stick. Unmount all mounted partitions, and then run the commands:
    $ fdisk -cu /dev/DEVICE # Make sure you use the proper drive.  Typically, this is sdb, but could be something else. I take no responsibility for your mistakes...
    # Press 'D' until you see the message: 'No partition is defined yet!'
    # Press 'W' to save the partition table to the device.

    Once the partitions on the USB stick have been removed, you can copy over the ISO. This is accomplished with the dd command, as follows:
    $ dd if=/tmp/bootmod.iso of=/dev/DEVICE # Pick the proper device, typically sdb
    Please use caution when running the dd command!

Final Steps: Copying All Required Files Over:
Below are the final remaining steps needed to complete the task. Please elevate to root to complete all instructions.

  1. Create a new ext4 partition on the USB stick. This will be used to store the installation ISO’s and all other additional content (like kickstart files). To do this, you must have your USB stick connected. Next, follow the commands below to create the partition:
    $ fdisk -cu /dev/DEVICE       # Replace DEVICE with the actual device.  It will most likely be sdb, but please double check.
    # Press 'N'
    # Press 'P'
    # Press Enter three times.
    # Press 'W'
    $ mkfs.ext4 /dev/DEVICE(PARTNUMBER) # Replace the device and partition number with the proper one.  Typically, this will be /dev/sdb2.
  2. Create a new mount point for the newly created partition, and mount it:
    $ mkdir /tmp/rhelusb
    $ mount /dev/DEVICE(PART) /tmp/rhelusb  # Remember...
  3. At this point, we can now copy all files over. However, before copying files over, you need to understand how the directory structure of this works. Basically, Hard Disk installs look for a .iso file with the installation files (the standard ISO’s you download and use for installation). However, we need to copy a few files from the installation ISO which tells the installer which ISO files in the directory to use.
     
    So, we need to mount the installation ISO. Create another mount point, and mount the installation ISO:
    $ mkdir /tmp/rheliso
    $ mount -o loop /location/to/installation/iso /tmp/rheliso
  4. You must first create a directory on the flash drive called images: $ mkdir /tmp/rhelusb/imagesThe purpose of this directory is to contain information about the install media. The primary file that needs to be copied from the ISO’s images directory is: install.img. For official RHEL 6, you must also copy over product.img. Note: RHEL clones may not have a product.img file, and can be omitted.So, copy the files over:
    $ cp /tmp/rheliso/images/install.img /tmp/rhelusb/images/
    # REQUIRED FOR ACUTAL RHEL, (Clones may lack this file):
    $ cp /tmp/rheliso/images/product.img /tmp/rhelusb/images/
  5. At this point, we are done with the mounted ISO image. You can now unmount it: $ umount /tmp/rheliso
    Feel free to copy over any kickstart files, or additional content that you need.
  6. Finally: Copy over all installation ISO’s onto the flash drive. It doesn’t matter if there is more than one, the installer will see them and install the system properly.
    $ cp /location/to/iso/to/copy /tmp/rhelusb
  7. OPTIONAL? It may be best to change the permissions of files and directories on the flash drive. This may, or may not, be necessary. However, all files on the installation medium are of permissions: 444, and all directories are of permissions: 555. To do this, you would need to run the commands:
    $ cd /tmp/rhelusb
    $ find ./ -type f -exec chmod 444 {} \;
    $ find ./ -type d -exec chmod 555 {} \;
  8. Unmount the USB drive, and test it out! $ umount /tmp/rhelusb (Don’t forget to cd out of the directory if you perform the optional step 7.)

NOTES:
The installer will see the USB stick as HDD sda2. Therefore, if you are using Kickstart, please keep this in mind if you are doing automatic partioning, and clearing out disks.

Additional Reources:

Install Git 1.8.x on RHEL 5 and 6

If you are running RHEL 5, you may already know that Git is not located in the official RHN repositories. You can always install it from EPEL. However, EPEL contains an older version: 1.7.4.1 (at the time of this post). RHEL 6 has Git in the official RHN repositories, but, it’s based on Git 1.7.1. For most users, this might be fine, however, if you have a need or want to use the latest and greatest version (or have everyone using the same version), then you will need to build the newer ones from source.

The Problem:

Installing version 1.8.x might seem as simple as downloading the source and running make. (This post uses Git version 1.8.1 as the example.) Unfortunately, building Git v. 1.8.x isn’t that simple on RHEL5, and I will explain why below:

After you download and extract the source code, there is an INSTALL file that outlines instructions on how to build Git. According to that file, you would run the commands:

	$ make prefix=/usr all doc info ;# as yourself
	# make prefix=/usr install install-doc install-html install-info ;# as root

Running this command on RHEL 5 will fail…But not because of the Git binaries. It will fail when generating the documentation. The problem is that the documentation needs to be built with AsciiDoc. AsciiDoc is found in EPEL, but the version on EPEL is too old to properly build the Git documentation. Even if you build the latest version of AsciiDoc, it still won’t work because it depends on a newer version of DocBook XML files. Unfortunately, the DocBook XML files on RHEL 5 are really, really old (Source).

Thus, you cannot (easily) build the documentation on RHEL 5, BUT: you can still build Git and get the documentation!

The Solution:

The Git developers know that the documentation can be hard to install, so they provided a workaround to installing it. Per the Git installation documentation:

There are also "make quick-install-doc", "make quick-install-man"
and "make quick-install-html" which install preformatted man pages
and html documentation. To use these build targets, you need to
clone two separate git-htmldocs and git-manpages repositories next
to the clone of git itself.

I will explain how to make this work. But first, we need to build the Git binaries without the documentation packages. So, run the command below while inside of the Git source directory to build Git:

$ make prefix=/usr all
$ sudo make prefix=/usr install

**Notes for the above commands:

  • Do not run the first command as root. Run this as your non-root user.
  • Git is cool in that you don’t need to run the /.configure script, you just make it.
  • You ALWAYS need the prefix. Don’t just run make in this case! (This is also true in the installation.)

The above commands will compile and install Git. As for dependencies, you will obviously need the build tools, openssl, openssl-devel, libcurl, libcurl-devel, expat, and expat-devel. There may be one or two more, but this seems to work for me. You can use yum to install them. This works for both RHEL 5 and 6.

As of this point, you have the git binaries installed. You can verify this by opening a terminal and running the command: $ git version. It should return the version number of Git that you downloaded. You are missing the man pages for Git, as well as the HTML documentation files. I would highly recommend installing the man pages, but at this point, you can fully use Git.

Installing Documentation:

Having the man pages are very useful. We’ll also install the HTML pages as well. So, to install them, we are going to fetch the docs that are pre-made. These are just text and HTML files; there is nothing special about them, but we need to move them into the appropriate directories so that they are useful.

In the previous section, I pasted in instructions from the INSTALL file on how to do this. However, if you are like me, you will find that really confusing. In fact, I submitted a StackOverflow question about this. Fortunately, I figured it out and answered my own question. For convenience, I have pasted the instructions below:

  1. First, open a terminal, and cd to the parent directory of the directory containing the Git source code. Meaning, if you are inside of the Git directory, simply run the: $ cd ../ command.
  2. Once directly outside of the Git source directory, you need to Git clone the repositories containing the documentation files (remember, we just installed Git!). Do that by running:
    $ git clone git://git.kernel.org/pub/scm/git/git-manpages.git
    $ git clone git://git.kernel.org/pub/scm/git/git-htmldocs.git
    

    Now: Here is a REALLY GOOD QUESTION:WHY didn’t the author(s) of the documentation include these locations? Seriously, WTF? I’m not psychic. But whatever, I eventually found them…

  3. Once you have the files downloaded, cd back into the Git source code directory, and run the EXACT commands below to install them:
    $ sudo make prefix=/usr quick-install-doc
    $ sudo make prefix=/usr quick-install-html
    

At this point, you can test this out by running the command: $ man git, and you should see a man page for Git. If you can see the man pages, then congratulations! You are done!

!!SPECIAL NOTE TO RESTRICTED umask USERS!!
Many environments require the umask setting to be made more restrictive. This is typical in many secure production environments. This will cause a bit of a problem when installing the docs. The problem is that although the files are installed, their permissions are set such that standard users do not have permission to see the man pages. This can be fixed by running the following commands (as root!):

$ find /usr/share/man/man1 -type f -iname "git*" -exec chmod 644 {} \;
$ find /usr/share/man/man5 -type f -iname "git*" -exec chmod 644 {} \;
$ find /usr/share/man/man7 -type f -iname "git*" -exec chmod 644 {} \;

## If you installed the HTML docs as well, you need to do:
$ find /usr/share/doc/git-doc -type f -exec chmod 644 {} \;
$ find /usr/share/doc/git-doc -type d -exec chmod 755 {} \;

Remember, make sure those commands are run as root! That should fix any permission issues resultant from restrictive umask settings.

Specify the Virtual NIC Name for KVM Bridged VM’s

When working with KVM bridged interfaces, KVM will automatically name the virtual NIC that is spawned when the VM is started. This typically follows a naming convention of:

vnet0, vnet1, vnet2, ..., vnetN

The virtual NIC names are dynamically applied to each VM instance.  Thus, a spawned VM is not guaranteed to receive the same virtual NIC when it is restarted.  Generally speaking, this may not be a problem.  However, what if you *need* to have a script, or some function whereby it is important to know which virtual NIC is allocated to a specific VM?  There are ways of scripting this, but to avoid the headaches of scripting, it may be helpful to just specify a fixed, hard-coded name on the generated virtual NIC of the VM.  To do this, you must use the virsh command line utility.

To implement this, follow the steps below as a user that has rights to use the virsh command:

  1. Run the command: virsh
  2. At the virsh console, you need to type the command: edit <domain/VM Name> (substitute the name of your VM in here)
  3. This will open up a vi like interface to edit the XML entries for your VM. NOTE: I am making the assumption that you are using a standard bridged setup. I have not tested this with non-bridged setups, and especially not on libvirt managed bridged setups. Thus, your mileage may vary.
  4. Locate the XML entry for your network setup. It should look something like this:
    <interface type='bridge'>
          <mac address='00:11:22:33:44:55'/>
          <source bridge='br0'/>
          <model type='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>
    

    You need to add a line to the interface tag that looks like this:
    <target dev='the_name_of_your_nic'/>

    Note: the name of the NIC needs to be a valid interface name. All lowercase and underscores work. As an example, I named my VM’s virtual NIC’s to something like this:
    vm1_net, vm2_net, vm3_net, ..., vmN_net

  5. Once it’s entered, it should look something like this:
    <interface type='bridge'>
          <mac address='00:11:22:33:44:55'/>
          <source bridge='br0'/>
          <target dev='vm1_net'/>
          <model type='virtio'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
        </interface>
    
  6. Save the changes and start the VM.

Once everything is set, you should see something like this if you use the ifconfig command:

vm1_net   Link encap:Ethernet  HWaddr 00:11:22:33:44:55  
          inet6 addr: fe80::fc54:ff:fec7:11/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:468 (468.0 b)  TX bytes:468 (468.0 b)

vm2_net   Link encap:Ethernet  HWaddr 00:11:22:33:44:56  
          inet6 addr: fe80::fc54:ff:fec7:22/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 b)  TX bytes:468 (468.0 b)

This guarantees that the VM will always start with the virtual NIC name that you specify. In my case, I have VM1 using vm1_net, and VM2 using vm2_net.

Disable BitLocker Active Directory Dependency

Let’s imagine that you have a Windows 7 system that was imaged.  Let’s imagine that the image is designed to easily connect to your infrastructure’s domain.  Let’s also imagine that you don’t want to add this particular system to your domain; you just want to use this system for a separate purpose, but save time by using your primary Windows 7 image.  Let’s also imagine that you want this system to have BitLocker enabled.  Your system meet’s all of Microsoft’s BitLocker requirements, but when you try to enable BitLocker, you get a nasty: BitLocker could not contact the domain.  Ensure that you are connected to the network or contact your system administrator error.

At this point, you have done a ton of research on how to turn off the Active Directory dependency for BitLocker, but have yet to find a solution.  Before you jump off the roof of your building, read below as I have your solution:

  1. Open gpedit.msc
  2. Navigate to: Computer Configuration > Administrative Templates > System > Trusted Platform Module Services.
  3. Disable the setting: Turn on TPM backup to Active Directory Domain Services.  This is probably the evil setting that is causing you all the problems.  But, just in case, continue on to the steps below anyway.
  4. Navigate to: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption.
  5. Disable the setting: Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and Windows Vista).
  6. You may need to disable 1 more setting.  Navigate to: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.
  7. Disable the setting: Choose how BitLocker-protected operating system drives can be recovered.

Once all those Group Policy settings are disabled, your non-domain connected PC should have no (AD related) problems setting up BitLocker.

Beware of gedit

I love using gedit to make changes to config files in Linux. However, I have recently encountered some odd issues where config files that I edit using gedit just don’t work properly. However, making the exact same changes with vi or vim does not have any issues.

Looking at both files (one edited with gedit, the other with vim), they look exactly the same…so I thought. Apparently, gedit likes to add a \r (carriage return) to the end of some lines. This is a hidden character, so if you open the file with gedit, or vi/vim, you won’t see it. However, this hidden character can cause a very nasty side effect to your config files in that some applications will not properly parse the file. As a result, your application (or OS) will not work (talk about a great way to perform a nasty DoS attack).

This is the type of problem that will make you pull your hair out trying to solve. So, the solution? Either use vi/vim or nano. If you use gedit, make sure you do a find and replace where you want to find “\r” and leave the replace textbox blank. This will remove all instances of \r. Your file will “look” exactly the same, however, you eliminated that pesky hidden carriage return character causing all the problems.

You’re Welcome!

VirtualBox Bridged Networking Driver Problems

For most people this will not be an issue, however, there are a few individuals who are exhibiting network problems when using the VirtualBox Bridged Networking driver on the *host* machine.

The Problem:

The problem is that some systems running Windows 7 with the “VirtualBox Bridged Networking” driver installed will have network outage issues when resuming the system from hibernation.  The only way to fix this is the either reboot the machine, or disable/enable the NIC.

This bug has been reported here: http://www.virtualbox.org/ticket/4677, but it doesn’t seem like it will ever be fixed :(

The temporary solution:

Until Oracle gets around to fixing this bug, the following instructions below will correct the problem.  Do note, following the steps below will disable the bridged networking feature of VirtualBox.  However, utilizing this method gives you a simple avenue to re-enable it if you need to use it.

  1. Click the Start Menu / Start Orb.
  2. Type: “View network connections”
  3. Press Enter.
  4. A window should appear with a list of all the network devices attached to your system.
  5. Right click the adapter that is giving you a problem > Properties
  6. Uncheck “VirtualBox Bridged Networking Driver”
  7. Click OK, and you’re all set.

To enable the feature after it is disabled utilizing this method, follow the instructions above in reverse.

Alternatively, you can also just opt out of installing the VirtualBox Bridged Networking driver altogether.  However, doing so will not allow you to easily enable that great feature.

Solution for Viewing Blocked Media Content on Flash 10.1 Devices?

Recently, an increasing number of media companies have been blocking access to Flash 10.1 content on non-PC devices (i.e. Android Phones, Google TV, PS3, etc.).  The reasoning for this makes no sense as I can plug my laptop into my TV and watch sites like Hulu, Fox.com, and NBC.com content without any problems.  However, doing so on a game console, Google TV device, or even an Android Phone is somehow different in their view.  It shouldn’t be a DRM issue either, as that should be handled by the Flash player itself.

Oh well.  In the past, this could be worked around by simply altering the user-agent string on the browser.  In this case, the browser would basically lie to the server and trick it into thinking that it’s running on a PC web browser.  As a result, the content would play just fine.

However, that no longer works.  Instead of simply relying on the user agent string of the browser, they are now also looking at the version of Flash Player running on the device.  A string of the version of Flash you are running is sent to the server to check if you are using a “supported device.”  You can find out what your Flash version string is by visiting this page: http://kb2.adobe.com/cps/155/tn_15507.html.  Visiting that page should show you something similar to this:

Screenshot of the Flash Player version string

To verify that this string is actually being sent to the server, I opened up Wireshark and sniffed some traffic on Hulu.  While watching an episode of Hells Kitchen on Hulu, I sniffed for HTTP GET requests.  Below is a screenshot of the TCP Stream for the GET request:

TCP Stream of the GET Request

As you can see from the screenshot above, there are a lot of variables appended to the GET request.  The most interesting one is the: flashPlayer=WIN%2010%2C1%2C103%2C19. This tells the server which version of Flash Player the system is running. If you remove the delimiting characters from the GET request, you would see that the version string matches that of the string in the first screenshot above. If you were running Android, the version string would contain AND instead of WIN.

That is not the only GET request of interest.  Indeed, there are others which contain appended variables declaring the OS, and the browser being used.  All of this information together can identify the device accessing the service.  However, remember that because all of this code is coming from the client, it can be altered.

So, in theory, if we were to replace the Flash Player version (as well as any other string sent to the server that could reveal the identity of the device accessing the service) with known values that work (such as one from an ordinary PC), that device should be able to access the service, since the server thinks the device is just a regular, “supported” PC.

Unfortunately, modification of the packet on-the-fly is the problem.  I cannot find any suitable software that is capable of making these changes on-the-fly to the HTTP packets.  A proxy application would be best suitable for this purpose, as it can change the user-agent-string and potentially other variables within the packet before being sent out to the server.  Unfortunately, I cannot locate any software that would easily give me the granular control needed to make this work.

After looking into Squid, and Privoxy, the best application that I have tested so far is TcpCatcher (http://www.tcpcatcher.org/).  This is a great app that basically combines Wireshark with a proxy server for HTTP connections.  It can even perform find-and-replace functionality within the packet.  Unfortunately, as powerful as the application is, it does not have the ability to find-and-replace more than one variable at one time. For example, to make this work, I would need to change the user-agent string, as well as find-and-replace any instances of flashplayer=, flash=, and even os= with known values that work.  However, this application can only allow one or the other to be changed.  If I change the user-agent string, I cannot perform a find-and-replace on the packet.  Thus, it will not work to fix the problem, as we need to completely mask the identity of the accessing device and trick the server into thinking that it’s just an ordinary PC.

If anyone is able to locate software that can make this work, please post it in the comments.

Enable NIC Teaming/Bonding in Linux with Cisco Catalyst 6000/6500 Series Switches

Just about all new servers today have multiple NICs installed.  A great way to take advantage of those NICs is to team/bond them together.  NIC teaming/bonding is a great feature to add more availability/redundancy, and higher bandwidth to your server.

There are many different types of teaming that you can do.  This site lists all the available modes under Linux: http://www.linuxhorizon.ro/bonding.html **NOTE: NIC Bonding/Teaming on Windows is determined by the network driver.  Please consult your vendor’s documentation to enable the feature.**

Some of the NIC teaming modes will work without any additional switch configuration, however, other’s will not.  I will demonstrate how to perform NIC bonding on Ubuntu Linux 10.04 using mode 4: 802.3ad Dynamic Link Aggregation.  This mode will require switch configuration, as it will require the use of the LACP protocol.  I will demonstrate how to configure a Cisco Catalyst switch to support this feature, and setting it up is a lot easier than you think.  Despite these instructions being performed on Ubuntu, they should also work on other Linux distributions.  The switch configuration instructions are also applicable for Windows servers utilizing 802.3ad (LACP) NIC teaming.

Host Configuration (Linux):

The instructions that I used to set up NIC bonding in Ubuntu Linux 10.04.1 were very nicely outlined in this YouTube Video: (The video utilizes bonding mode 1: Round Robin. I would recommend mode 4: Link Aggregation)

For those who don’t have access to YouTube, follow the instructions below:

  1. Install ifenslave. On Ubuntu this can be performed by: sudo apt-get install ifenslave
  2. Create aliases for the bond.  To do that, a new file will need to be created at /etc/modprobe.d/aliases.  On Ubuntu, simply running the command: sudo nano /etc/modprobe.d/aliases will open a text editor and create the file.
  3. In the file, type the following and then save the file:
    alias bond0 bonding
    options bonding mode=4 miimon=100
  4. Modify the interfaces file to add the bond0 interface. To do that, first open /etc/network/interfaces. On Ubuntu, simply run the command: sudo nano /etc/network/interfaces.
  5. Comment out all existing network interfaces that are active.
  6. Add the following to the file:
    auto bond0
    iface bond0 inet static
        address <<insert ip here>>
        netmask <<insert netmask here>>
        gateway <<insert gateway here>>
        slaves eth0 eth1 # Place in the nic interfaces you are bonding
        # Place whatever other network info you need here.
    
  7. Save the file.
  8. Shutdown your server, and configure your switch. Once your switch is configured, turn your server on.

For troubleshooting issues, remember that your bond0 interface is seen by the OS as any type of ethernet interface. ifup and ifdown commands will work on that interface.

Host Configuration (Windows):

As mentioned above, this is dependent upon your drivers.  Please consult your driver documentation and software to enable this option.

Switch Configuration (Cisco Catalyst 6000/6500 Series [Running IOS]):

Log into your switch.  Once logged in, you must enter enable mode.  Next, follow the steps below:

  1. Configure your terminal: conf t
  2. Select the interface range you are using for the bonded/teamed interfaces: int range [starting interface] - [last interface number]
  3. Once you have the interface range you wish to modify, add in the following commands:
  4. shut
    switchport access vlan <<insert your vlan number here>> # All bonded interfaces must be on the same vlan
    channel-group <<insert the channel group number here (explained below)>> mode active # See below for more information
    # Place more interface configuration here (if needed)
    no shut  # Don't forget to turn on your interface
    
  5. Test the configuration, and then save it if you are happy with it.

In step three above, you need to make a channel group. A channel group tells the switch to treat the specified interfaces as one logical entity. You can have more than one, so pick the number corresponding to the host you are providing the nic teaming to. There are two modes that provide LACP functionality: active and passive. Cisco recommends that you enable active mode by default. I have found that this depends on the server. On the Windows servers that I have worked with, active mode worked just fine. However, on the Linux servers that I have tried this with, passive mode worked better.

That should be it. If I made any mistakes, or if you feel that more should be added, please feel free to leave a comment.

Fix Java apps not finding Java in 64-bit Windows

For Java apps to run in Windows, a JRE (Java Runtime Environment) must be installed.  If it’s installed, but your Java apps are throwing errors that it cannot find the JRE, then you will need to add an environment variable to point to the Java bin directory.

Here is a screenshot of such an error I received when trying to run the Android SDK:

AndroidSDK error showing that Java is not installed -- Even though it is.

(Also notice the typo in the above message: “Checking it it’s installed in …”)

Below are instructions for fixing this error on Windows 7 x64 with the 64-bit JRE installed:

  1. Click the “Start Orb”, and type: about system
  2. In the search results, you should see “System” appear.  Click on it, and you should have the “View basic information about your computer window” appear.
  3. In that window, on the left hand side, you should see a link to “Advanced system settings”.  Click it.  (Accept all UAC prompts)
  4. The “System Properties” window will appear.  Click the “Advanced” tab.
  5. On the “Advanced” tab, click the button towards the bottom of the window titled “Environment Variables…”
  6. The “Environment Variables” window should appear.  In this window, on the bottom half, you should see a section titled: “System variables”.  Scroll down that list for an entry titled: Path. Click the “Edit” button.
  7. The “Edit System Variable” window should appear.  In this window, select the textbox for “Variable value:”.  Scroll to the end of the entry, and add a semicolon (;) to the end of the line (assuming no semicolon is currently there).
  8. You will then need to locate where your Java bin directory is located.  For me, on 64-bit Windows 7 with the 64-bit JRE installed, it is located in the following path: C:\Program Files\Java\jre6\bin (This is the default location if installing the 64-bit JRE)
  9. Copy and paste the path to the bin directory after the semicolon we just added to the “Variable value:” textbox.
  10. Click OK to all the windows, and your application should work.

Copyright © /sarc All Rights Reserved · Using modified version of Green Hope Theme by Sivan & schiy · Proudly powered by WordPress