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.

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.

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.

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!

One way to present the login banner is to create a pop-up dialog box with the login banner text inside of it. This dialog will appear as soon as the X-Server loads and before the user is prompted to enter in a username and password. Thus, it meets the requirement of the user seeing the dialog before login.

How to do it:

For this, we will make use of zenity. Zenity is a console command that displays popup messages. However, before we display the popup, we need to create a file with the login banner text.

1. Create a text file to hold the login banner text. To demonstrate this, I have created a text file called “login_banner.txt” with some sample login banner text:
   
2. Once you have created your login banner text file, you should move it to some global location where anyone can read the file. I would suggest /opt.
3. The next step is to tell GDM to show the banner before a user logs in. To do this, you will need to (as root) modify the /etc/gdm/Init/Default file. Towards the bottom of the file (before the exit 0), paste in the command:

   ## Display a login banner:
   zenity --text-info --filename=/PATH/TO/LOGIN_BANNER_FILE.TXT --width=NUM --height=NUM --title="LOGIN WARNING"

   For example, here is what my /etc/gdm/Init/Default file looks like:
   

4. Save the file, and you are done!

If done properly, you should see something like this when you try to log in:

As a sidenote, if you “switch user”, the banner is also properly displayed. There are several other options you can use for the window’s size, buttons, etc. You can just play around with the zenity command in the Init/Default file to find the options that best suits your needs.

This should really be documented on Red Hat’s site, since RHEL is an industry standard OS, and login banners *are* an industry requirement.

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.

Manufacturer Android Skins

Android device manufactures, such as Motorola, HTC, Samsung, and LG (henceforth known as “the OEM’s”) all modify the version of Android that come pre-installed with their phones. They all put their own UI on top of Android to “enhance the experience of Android”, “add more features”, and lastly (but most importantly), “differentiate themselves from the competition”. The OEM’s all have their own unique skins, such as MotorBlur, Sense, and TouchWiz.

The Problem:

On the surface, these look like simple, flashy skins. However, they have become much more than that. Originally, that’s all they were, skins/launchers. If you wanted to “remove” MotorBlur, or Sense, etc., you would just install a different launcher app (such as Launcher Pro). However, they have since evolved to be more than just a skin. They now deeply embed hidden background processes into Android that consume RAM, CPU, and worse yet – battery life. Thus, simply installing Launcher Pro will not fix the problem.

But how can they differentiate themselves if they are all running the same OS?

Simple…by making great hardware. When someone buys a phone, one of the first things they look at is the hardware. They look at the size of the screen, the thickness, the build quality, the presence (or lack of presence) of a physical qwerty keyboard, the weight, the color, the carrier the phone is on, the battery life, the call quality, the screen quality, internal storage, SD card availability, camera quality, presence of front-facing camera, etc. Those are all *incredibly* important factors of a device. 100% of those are areas that the OEM’s have the complete expertise on innovating and differentiating themselves on. You can pretty much look at any Android phone and immediately tell who makes it by just looking at the way it’s built. *THIS* is where they should be differentiating themselves on.

The OEM’s are not software experts. If they were, they wouldn’t be using Android. They would instead have made their own OS from scratch. Google made a great mobile OS; one that can compete with the iPhone. That is why they are using it. In my very honest opinion, the OEM’s lost their ability to differentiate themselves in the software space by adopting an external OS. How many people do you know say “I can’t wait to get that MotorBlur phone!”? The answer is 0. People want an Android phone. They want to own a device that is part of the Android ecosystem, not a device that tries to invent its own platform.

The quicker the OEM’s realize that, the better off they will be.

Study Materials:

To study for the Security+ exam, I used the following three resources:

1. CompTIA Security+: Get Certified Get Ahead: SY0-201 Study Guide
2. Mike Meyers’ CompTIA Security+ Certification Passport, Second Edition (Mike Meyers’ Certification Passport)
3. MeasureUp Security+ Practice Test Questions

Unlike my A+ exam, I did take a 1-week bootcamp training course.  I simply read the materials and reviewed all the practice questions.  Really, that was it.

The first book mentioned above is very good.  It covers the primary areas of the exam very nicely.  The language of the book is well written, and very descriptive.  There were a few errors in the text; however, there is an errata page online with the corrected information.  The book also contains a lot of practice questions, which are always very helpful.  Unfortunately, the practice questions are not on an accompanying CD-ROM, so you will be doing a lot of page-flipping back and forth between the answers and the original questions when you do your review.  This is certainly not a deal breaker, but just something to keep in mind.

The Passport book mentioned in item number 2 above was only used as a quick review.  I didn’t read the whole thing, since the first book covered most of the material very well.  I would recommend doing the practice questions in the book and reviewing any answer you get wrong in the residing chapter.  I found that to be very helpful at reviewing material you may have missed.  This book also contains an accompanying CD-ROM with extra practice questions, and allows you to obtain 50 more free questions if you register on the publisher’s site.  The questions are pretty good and are helpful in your review.

The last study aid was the MeasureUp test questions.  I also used their practice questions to study for A+, and I found them to be very effective.  The same is also true for Security+.  Generally speaking, practice questions are perhaps the best study tool for taking a certification exam, as they help you get a feel for the type of questions you will encounter.

The Test:

The test itself was quite fair.  Many questions were easy, but many were also tricky.  In the end, I did very well on the exam and the material referenced was of great assistance.

Unfortunately, the one area that the material above did not cover as much as I would have liked it to was Digital Forensics.  Make sure you know the process of responding to a security incident and also inform yourself on some of the tools used.  That is fair game for the test.

Good Luck!

Study Materials:

I used several methods to study for the exam.  Luckily, my employer paid for me to take a 1-week A+ Training Bootcamp course.  This is simply a 1-week classroom course with an instructor who goes over the main areas covered in the A+ exam (you can Google search for the objectives, or purchase a training book which will usually list them).

With the course, we were provided some book materials.  In particular, we were provided with Element K A+ study materials, as well as Mike Meyers’ A+ Certification Passport, Third Edition (over time, the editions will change).  In addition to the book materials, we were also provided with access to sample questions.  We had access to both Kaplan and MeasureUp test questions.

In the end, I felt that the classroom course was not needed.  Yes, you can pass the A+ exams without the classroom course!

What you need to pass:

Honestly, the book materials and sample test questions are all you really need.  Of the two books, Meyers’s book was the best.  In fact, for me and my colleagues who also took the exam, the Meyer’s book was outstanding.  The best part about his book was that it contained exactly what you needed to know.  Everything was nicely explained and to the point.  The accompanying CD with the book also contains very good test practice questions.

The Element K books basically just contain a lot of information.  They will teach you a lot about computers; however, as extensive as those books are, they simply will not help you pass the exam.  They don’t really help you tackle the questions that are asked on the test.

Passing the exam is more than just knowing a lot about computers.  You need to understand how to answer the questions they ask.  By and large, the questions asked were very straight-forward.  However, there are some questions that can easily throw you off if you are not careful. The only real way to familiarize yourself with the test questions is to do lots of sample questions, over and over again.

With regards to test questions, I highly recommend MeasureUp’s exam questions.  They were up to date, realistic, plentiful, and mostly accurate (more on this below).  I can’t say the same for Kaplan.  Kaplan’s sample questions were unrealistically difficult, very outdated, and worst of all, contained a lot of obviously incorrect answers.  Did I say outdated?  One of the Kaplan questions was in regards to the upgradability of Windows 3.1x!  (You will not get questions older than XP)

Unfortunately, not all sample questions are accurate.  MeasureUp’s were pretty good, but you may find a small hand few that are wrong.  Kaplan had way too many mistakes to keep track of.  Obviously, if the answers are wrong, you can’t rely on them for help.

In Short:

Completing practice questions repeatedly along with reading Meyers book for me was enough to successfully pass both exams.

P.S. Make sure you know the full operation of laser printers.  They are fair game on the exams!

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:

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:

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.