I finally found a few minutes to write up a short how-to on getting your Chinese Xiaomi Mi3 Smartphone rooted, westernized, and cleaned up!

To make your life much easier, I have actually written a couple of scripts that can be used to remove all of the Chinese bloatware from the phone, install the Google Play Store, and a separate script if you want to root your device.

Now, there are already several pre-packaged roms available that come somewhat cleaned up and with the Play Store pre-installed and are even rooted… however these are all based on development (dev) releases of roms from Xiaomi. In my experience, the dev roms tend to be a bit unstable and a bit sluggish compared with Xiaomi’s production releases. I have also found that the primary method Xiaomi promotes for flashing ROM’s, while very easy, isn’t the best and tends to result in bugs and issues. However there is another Xiaomi supported method using a feature called “fastboot” which is very easy and results in a solid install of Android.

A ROM is simply a type of software/firmware that is installed on special Read Only Memory. In this case the ROM files contain the operating system, Android, and other pertinent files that are required to make the phone work. The installation process is called “flashing” and the terms ROM and Firmware and usually interchangeable.

So the beauty of my method is that you get to use a production rom from Xiaomi which is stable and fast, but you get the advantages of a cleaned up dev rom in that it is totally stable, with a working, minimalist install of the Play Store and you can even root the device you choose. I am not a big fan of the MIUI launcher, nor will many western users be who are used to the advantages that come with using the Google Now launcher and its variants on other phones. Once you are finished with this tutorial you will have the latest features that Google is offering in Kit-Kat including voice actions (saying “OK Google” to your phone which tells it to listen to you and then you can ask for stuff or give commands).

So here is a high-level of what I will be walking you through in more detail. (more…)

Update 3/31/2016PBIS doesn’t work well as of late and this method has been superceded by this article here: http://www.kiloroot.com/add-ubuntu-14-04-server-or-desktop-to-microsoft-active-directory-domain-login-to-unity-with-domain-credentials/

Update 5/18/2014I created scripts to automate 90% of this process. I still recommend you read this post before just jumping in and using the scripts so that you know what exactly it is you are doing. However the scripts can save you a lot of time. You can get them by clicking here.

If you are like me and work in a mixed environment then the above topic is probably quite important to you. Especially if you also happen to be a security person for your organization and centralized account administration is a big deal.

In this tutorial, I will be walking through how to join an Ubuntu 14.04 LTS Server to a Windows Active Directory Domain. Furthermore, we will be adding a new domain group to the “sudoers” group on the box so that our Domain Admins will automatically have the ability to use sudo to administer your Ubuntu Servers as needed.

Additionally, we will also be making it easy for them to login (no appending of the domain onto their user account name) and giving them the more user-friendly BASH shell, rather than the default SH.

All commands reference the fictional domain “CONTOSO.COM” to make the syntax easier to understand. The Domain Controller (DC) for the domain will be at “”. The domain controller is assumed to be running DNS services as this is tightly integrated with Active Directory. The name of the domain admin in the Windows domain is “admin”

The Heartbleed bug is what I would professionally classify as seriously scary stuff. Basically there is some kind of heartbeat functionality built into OpenSSL. Often, in tech talk, this kind of thing is used for remote service monitoring (i.e. if I have a pulse my service is at least up). In this case, I am not sure the specific application. What was discovered was that this feature could be exploited by a remote hacker to gain access to information stored in the servers memory in 64k chunks at a time… and it was undetectable. Pretty much anything could have been leaked, including the SSL private keys themselves. This means a person could then decrypt in-transit information between the server and client and have access to all kinds of goodies like usernames and passwords. (you can read more here)

This is a veritable nightmare and affects pretty much all of us running websites on linux hosts that make use of SSL. So, I highly recommend you dive in quickly and fix this issue, fast. The first step…

Test your site to see if is vulnerable to the heartbleed bug. You can check it using the tool here:


Okay… don’t flip out if you are vulnerable. Pretty much all of my SSL sites were as they use OpenSSL like the other 2/3rds of all internet sites. I have since patched them all.

I host hosted on pretty much all Ubuntu 13.04 servers running Apache 2. My instructions for fixing the bug are geared towards Ubuntu.

Second step… back your SSL keys up!

We are going to be completely wiping your current SSL install OUT on your web server. This means you need to backup your cert files. Here is how I did mine on one particular server. (later on it is a very good idea to regenerate your server’s private key and replace all of your SSL keys anyhow, but it isn’t a bad idea to keep what you have around…)

First, make a directory tree where you can copy all of your certs to.

sudo -s
mkdir /sslbackup
mkdir /sslbackup/private
mkdir /sslbackup/certs

Next, if you are running Apache, which I am, you can determine where the SSL cert files are that you need to backup by doing the following (this is for apache2, running on Ubuntu 13.1, your site config files may be somewhere else):

cd /etc/apache2/sites-enabled

On Ubuntu and Debian this folder is usually used to house the “running config” files for each of your websites. Any of your sites that use ssl (i.e. the url is httpS://whatever.com) need to be checked. In my example lets say I have a site called contoso.com and it has a config file named contoso.com-config… Run the following command against that file:

egrep -wi --color 'SSLEngine|SSLCertificateFile|SSLCertificateKeyFile|SSLCertificateChainFile' contoso.com-config

Run that command for each of your site config files and note the output. You should get something like this:

SSLEngine on
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/ssl/certs/contoso.crt
        SSLCertificateKeyFile /etc/ssl/private/contoso.key
        #   Point SSLCertificateChainFile at a file containing the
        #   the referenced file can be the same as SSLCertificateFile
        SSLCertificateChainFile /etc/ssl/private/contosoint.crt

There are three files in the above case. Public and private keys and the chain file. You can now back those files up to your backup directories. Example:

cp /etc/ssl/certs/contoso.crt /sslbackup/certs/contoso.crt
cp /etc/ssl/private/contoso.key /sslbackup/private/contoso.key
cp /etc/ssl/private/contosoint.crt /sslbackup/private/contosoint.crt

That should backup all of your cert files safely so that when we totally wipe-out OpenSSL we don’t have to worry about losing our cert files.

Next, it is time to remove OpenSSL. In my case I am on Ubuntu so I use the ‘apt’ package manager. Your distro may vary.

apt-get update
apt-get purge openssl     #This is where your certs may get wiped if you didn't back them up above
apt-get purge libssl-dev
apt-get autoremove && apt-get autoclean

Next we need to update to the latest version of openSSL. I was running Ubuntu 13.04 on my server though and this was an issue because it is no longer support. To fix this problem, I upgraded to 13.10 by doing the following:


If that works for you, GREAT… I, however, am hosting on Media Temple and had no such luck. To work around I had to do this:

apt-get install update-manager-core python-apt
cd ~
mkdir tmp && mkdir vartmp && mount --bind ~/tmp /tmp && mount --bind ~/vartmp /var/tmp

The upgrade then ran…

Afterwords I did the following

apt-get update
apt-get install openssl libssl-dev
service apache2 restart

Now… after this was done… I had all kinds of additional personal hell. This came particularly from the upgrade of Ubuntu to 13.04 to 13.10. I did this on two separate servers and it broke all kinds of things. More on that in my next post!

Assuming you didn’t have to upgrade Ubuntu then you can go back to the heartbleed vulnerability checking site:


And test your site again. Once I resolved my other issues and had my sites back up again, this showed the vulnerability to be remediated!

Now… the HOLE has been closed. Which is great. However the particularly scary thing about this portal of doom is that there was no way to detect if anyone had ever exploited it. Yep… people could have stolen stuff and there is no way to know. They could have stolen your SSL private keys… hence… the recommendation now that we have slammed the door shut is to:

-> Regenerate new private keys.
-> Submit new CSR to your CA.
-> Obtain and install new signed certificate.
-> Revoke old certificates.
(information taken from discussion here)

I will not be going into the details of how to do all of that in this post.


Here is the scenario – You are an IT Admin for a business that is large enough or handles data of a particular type such that you have to worry about security more than the average Joe. Furthermore, you get audited from time to time. However, people want an IM (Instant Messenger) solution and… they want to be able to talk to their friends on AIM and ICQ and Yahoo, etc… and management rather than just killing the idea says “Fine… Mrs. IT Person – you go figure it out…”

After a bit of digging via the worlds most useful IT Encyclopedia — GOOGLE — you discover there are a Myriad of option for IM — but the list narrows as you start realizing that most don’t meet the following security and operational requirements:

  • No File Sharing
  • All messages must be audited and stored for XYZ period of time
  • All messages must be encrypted/secure from eavesdropping
  • You users must login using their already corporately managed Microsoft Active Directory Credentials
  • Your users want access to AIM, ICQ, etc… which also must be audited if they are using these accounts from work
  • Your users want access to corporate IM from their mobile device

That is an exhausting list. Luckily, there is one solution out there that is incredibly slick… AND it meets all of these requirements… AND… it just so happens to be COMPLETELY FREE.

Enter OpenFire Chat Server – it is going to make you look like an IT Superhero to your colleagues and to the budgeting department (you, know, if those folks actually pay attention to IT :)… more and more they do these days.) Yes, it runs on Linux. But it is very lightweight, and if you are in a Microsoft environment and have an under worked server with a decent amount of storage and some extra ram (running at least Server 2008 R2), you can convert that machine into a Hyper-V host and build your Chat server in virtual at little or no direct cost. You can also use old or cheap hardware if your organization just isn’t ready to virtualize something. This is worth jumping on the Linux bus for :).

If you still aren’t fully persuaded, OpenFire does have a Windows Distribution now available. Based on the experience I have had in the past with running software developed on Linux, for Linux then ported to Windows… I suggest you stick with Linux. It might be absolutely fine on Windows (I didn’t try it), but my general experience with getting other Linux-ported software to run on Windows has not been pleasant.


What is a Ram Disk you ask? Simply put, you carve out a piece of your system’s RAM and use it as a normal file system. But you probably have some more questions…

Why would I want to do this?

Simply put, RAM is very fast. Faster than most (any?) SSD drive. So if you have an application that would benefit from being able to access data very quickly, a RAM disk makes a lot of sense.

That’s amazing… why don’t I just load everything into a RAM disk all the time?

Two primary reasons… First… RAM is expensive and therefore quite scarce compared with conventional hard drive space. So your system probably has a fairly limited amount to work with. Second, and perhaps more critical, RAM is erased whenever power is lost. So if you do a system reboot, or lose power, everything stored on your RAM disk, even the RAM disk itself, is completely lost.

Oi’ that’s bad… when exactly would I want to use a RAM disk then?

Some applications, like MySQL for example, write “temporary” files to disk. These are usually pretty small files that are built on the fly for normal operations. Think of them like a scratch-pad you would use when doing a long equation in Algebra class. These files are built on the fly to store some temporary data (perhaps a specific view of the database as requested by a website page). Often they are used for “cache” as well, i.e. rather than taking the CPU through the task of building as special table from existing tables again and again, it caches the special table so it can serve it the next time it is requested.

Ultimately, if your system gets rebooted, you really don’t care if you lose this kind of data. Furthermore, having this kind of data written to and pulled from a RAM disk, could really improve application performance depending on your use case.

In this article, I am going to talk about building a RAM disk on the fly, and telling MySQL to use it. Furthermore, we are going to create a few scripts to make sure our RAM disk is created at every boot so that MySQL can consistently take advantage of it.