Blank Page when signing into Office 365 using Chromium (Fixed)

Symptom: A blank page when accessing,, or most other Microsoft sites.

Cause: An untrusted root certificate.

Solution: Add the proper Symantec root CA.

  1. Paste in the following into a new file called symantec-ca.cer
  2. -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

  3. Open Settings->Manage Certificates
  4. Browse to Authorities->Import
  5. Open the symantec-ca.cer file that you saved earlier
  6. That’s it! Now you should be able to access Office 365.

iOS 10 OpenVPN with Active Directory Authentication

With iOS 10, PPTP is out and IPSEC and L2TP are the main options now. PPTP uses a protocol that is neither TCP or UDP – it is GRE. And IPSEC uses yet another protocol called ESP. The problem with most VPNs is that they do not work when you need them to because many hotel and guest networks allow access to only specific protocols, such as TCP/UDP. This tutorial will show you how you can configure a simple OpenVPN server to authenticate your Active Directory users even through environments that are prone to blocking PPTP, IPSEC, and L2TP.

First, let’s download a copy of the very cool open source router, VyOS.

Now, we create a VM with a 2GB partition and we install VyOS. At the prompt, login with vyos/vyos and type:

install image

When asked, set your password of choice for the vyos username. Eject the CD, reboot, and you should get to the login prompt. Login, and let’s get started.

Type the following:

set system package repository squeeze components 'main contrib non-free'
set system package repository squeeze distribution 'squeeze'
set system package repository squeeze url ''
set system package repository squeeze-lts components 'main contrib non-free'
set system package repository squeeze-lts distribution 'squeeze-lts'
set system package repository squeeze-lts url ''
sudo apt-get -o Acquire::Check-Valid-Until=false update
sudo apt-get install krb5-config krb5-user libpam-krb5

Now you should have all of the packages that you need, so its time to start configuring kerberos. Type the following:

sudo nano /etc/krb5.conf

Here is a template for a simple krb5.conf file that you will need to modify to match your domain. The IP of your domain controller will be the IP for the kdc. Take note of the case changes for the domain name. Match the example for the case for your domain.

        default_realm = MYDOMAIN.LOCAL

        MYDOMAIN.LOCAL = {
        kdc =

        .mydomain.local = MYDOMAIN.LOCAL
        mydomain.local = MYDOMAIN.LOCAL

        forwardable = true
        pam = {
            minimum_uid = 1000
            MYDOMAIN.LOCAL = {
                ignore_k5login = true

Now that /etc/krb5.conf is configured, we should be able to do the first test. Let’s run kinit and see if we can login. Here is an example:

kinit myuser

After you type in the password, you should be able to check if you are logged in with the klist command.


If all worked, type the following.

reboot now

Now it’s time to configure OpenVPN.
First, let’s copy over the template easy-rsa folder to the config folder so that it persists upon upgrades.

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /config/easy-rsa2
cd /config/easy-rsa2
source ./vars
./build-key-server  server
cp keys/ca.crt /config/auth/
cp keys/dh1024.pem ../auth/
cp keys/server.key ../auth/
cp keys/server.crt ../auth/
./build-key company

Phew! Ok, now we’re done with the prerequisites to configure OpenVPN. Let’s start configuring VyOS so that it uses all of these new settings.

set interfaces openvpn vtun0 mode server
set interfaces openvpn vtun0 openvpn-option --username-as-common-name
set interfaces openvpn vtun0  openvpn-option "plugin /usr/lib/openvpn/ login"
set interfaces openvpn vtun0 persistent-tunnel
set interfaces openvpn vtun0 protocol udp
set interfaces openvpn vtun0 server domain-name mydomain.local
set interfaces openvpn vtun0 server subnet
set interfaces openvpn vtun0 server name-server
set interfaces openvpn vtun0 push-route
set interfaces openvpn vtun0 tls ca-cert-file /config/auth/ca.crt
set interfaces openvpn vtun0 tls cert-file /config/auth/server.crt
set interfaces openvpn vtun0 tls dh-file /config/auth/dh1024.pem
set interfaces openvpn vtun0 tls key-file /config/auth/server.key

We are almost there. Now we just need to create the .ovpn file. Replace the sections between , , and with the contents of the files /config/auth/ca.crt, /config/auth/company.crt, and /config/auth/company.key. Hint: You can get the contents by typing something like: cat /config/auth/ca.crt.

remote 1194
proto udp
dev tun
resolv-retry infinite





Install OpenVPN Connect on your iOS 10 device.
Copy your .ovpn file onto your device and open it.
Enter your username/pass and you’re ready to go.

Note: It is not imperative that each person has a unique certificate because they need to authenticate their user/pass in order to connect (and we use their username to register instead of their certificate name). If you are not happy with the security risk of re-using certificates, you can generate a new certificate for each person by using the ./build-key script in the /config/easy-rsa2 folder.

The Fastest and Easiest Way to Clone a PC on a Network

This is a guide for using the automated clone assistant on RestartOS to clone a PC over a network. We have a source PC and a target PC. The source PC has the content that we want, and the target PC’s disk will be overwritten with the data from the source PC’s disk. In this guide both PCs have a single disk drive to keep the instructions simple. If you have more than one disk, you can repeat the steps for each disk.

Target PC

First, we launch the software on the target PC.

Then we choose the disk that we want to overwrite and confirm our selection.

Source PC

Next, we launch the software on the source PC.

We choose the disk that we want to clone and then we wait for the system to find the target PC automatically.

We confirm the IP address of the target PC (as is seen in step #2 above) and just press enter (or type “y”) to proceed.

That’s it! The cloning starts. No IPs to type in. No hassle of copying over MBRs. And it’s very fast.. like 15 minutes for a Windows 10 install fast.

How To Change a Xenserver VM Type

Here is a quick and dirty script to change the VM type of an existing Xenserver VM. This can be useful if you are, let’s say, using Linux-based cloning software to clone a Windows VM and you want it to run as fast as possible. You may realize that the system runs very slow. That’s because the Windows VM handles paravirtualization differently than the Linux environment will. You have to change the device type, and this script will help. I added a layer of abstraction to simplify the whole process of switching VM types.

Here are examples of how to run the script:
./change-type myvm This will print out the current VM type as either “windows” or “linux”. A numerical ID is printed in [] that designates the current device_id, for your information.
change-type myvm linux This will change the device type from whatever it is now, to linux.
change-type myvm windows This will change the device type from whatever it is now, to windows.
change-type 00000000-0000-0000-0000-000000000000 linux This will change the device type for the machine with the UUID specified.

# /usr/bin/change-type
# Written by Pete Lombardo
# This script can change the type of hardware for a VM in a Xen Pool(for example, from Linux to Windows or visa versa).
# It can also be used to resolve a blue screen issue after upgrading the tools inside a Windows VM.

if [ ! "$1" == "" ]; then
        uuidtest=`echo $1 | sed -e 's/\-//g' | egrep "[0-9a-f]{32}" | wc -l`
        if [ $uuidtest -eq 0 ]; then
                uuid=`xe vm-list | grep -i ": $1" -B1 | grep uuid | cut -d':' -f2 | cut -d' ' -f2`
                name=`xe vm-list | grep "$uuid" -A1 | grep name | cut -d':' -f2 | cut -d' ' -f2-`

if [ "$1" == "" ]; then
        echo "Usage: change-type [machine-name] [type]"
        echo "Available Types: linux,windows"
elif [ "$2" == "" ]; then
        echo "Checking the device type for $name"
        if [ "$uuid" == "" ]; then
                echo "ERROR: System $1 not found."
        type=`xe vm-param-get uuid=$uuid param-name=platform param-key=device_id 2>/dev/null`
        case $type in
                        echo "linux [$type]"
                        echo "windows [$type]"
                        echo "linux [$type]"

case $2 in

if [ "$uuid" == "" ]; then
        echo "ERROR: System $1 not found."

xe vm-param-set uuid=$uuid platform:device_id=$device

type=`xe vm-param-get uuid=$uuid param-name=platform param-key=device_id`
        case $type in
                        echo "linux [$type]"
                        echo "windows [$type]"
                        echo "linux [$type]"

Prepping VyOS + OpenVPN for use with a Chromebook

First, you need to create the certificates. Use EasyRSA for this. Follow the instructions at the OpenVPN site for that.

To build the CA certificate, use the command:
./easyrsa build-ca

To build the server certificate, use the command:
./easyrsa build-server-full server

To build a client, use the command:
./easyrsa build-client-full client

You may want to remove the password for the private keys for the server and client certificates. To do that, use these commands.

cd private
openssl rsa -in server.key -out server-nopass.key
openssl rsa -in client.key -out client-nopass.key
cd ..

Now copy the ./issued/server.crt, the ./ca.crt, and the ./private/client-nopass.key to the VyOS server. Create a new folder called /config/auth/openvpn and store them there.

The OpenVPN connection for VyOS should look like this:

 openvpn vtun0 {
     local-port 1194
     mode server
     openvpn-option --persist-tun
     protocol udp
     replace-default-route {
     server {
         max-connections 10
         topology subnet
     tls {
         ca-cert-file /config/auth/openvpn/ca.crt
         cert-file /config/auth/openvpn/server.crt
         dh-file /config/auth/openvpn/dh.pem
         key-file /config/auth/openvpn/server-nopass.key

Now we have to prep the Chromebook certificate.

openssl pkcs12 -export -out client.pfx -inkey private/client-nopass.key -in issued/client.crt -certfile ca.crt

Now upload the ca.crt and the client.pfx files to the Chromebook (You can use the SCP addon for the file manager to transfer them there.)

Navigate to chrome://certificate-manager.
Click on Authorities and then click Import.
Navigate to the ca.crt and import it.
Now click back to “Your certificates” and click “Import and Bind to Device”.
Navigate to the client.pfx and import it. When it asks for a password, hit enter without one if you did not set one.
Now navigate to chrome://settings and click “Add Connection”. Choose OpenVPN.
Set the “Provider Type” to be OpenVPN.
Set the CA certificate to be the one that we uploaded.
Set the client certificate to be the client.pfx. Note: It will show up with the common name of the certificate, not the file name.
Now type in any username and password. It doesn’t matter since we are using certificate based authentication. Save the user/pass so that you do not have to type it every time. Again, it does not matter what you type here.

Now you should be able to connect!

XenCenter Storage Repository Rescan Issue – Solved

When clicking rescan on a storage respository in XenCenter, you may encounter an error like the one below.


The problem is usually due to a foreign file in the storage repository. To find out what the offending file is, turn to the power of the command-line. Login to the master server and run the following command.
tail -n 100 /var/log/SMlog

Review the log and find the offending entry. It might look something like this.
***** VHD scan error: vhd=/var/run/sr-mount/3219ad4f-242e-1744-6d38-78e17efdce69/9411b73c-7a3a-4812-b64b-edfe8f04ee70.vhd scan-error=-32 error-message='opening file'

In this case, the file /var/run/sr-mount/3219ad4f-242e-1744-6d38-78e17efdce69/9411b73c-7a3a-4812-b64b-edfe8f04ee70.vhd could not be opened. After taking a quick look at that file, I quickly recognized that it was a 0 byte file. It did not create properly. I moved it out to the /tmp folder and tried to rescan. This resolved my issue.

FreePBX 13 – MySQL Performance – RESOLVED

I resolved the performance issue by running the following commands in MySQL:

use asterisk;
alter table kvstore engine=MyISAM;

My new FreePBX 13 server was causing disk IO contention with my other VMs, so I had a look at the disk writes to the MySQL database. The MySQL databases are the ONLY thing on the VDB disk. Notice anything strange? So did I. The disk usage ramps up over time, so it looks like that periodic Cron job of theirs to refresh the Dashboard has some build up of data that makes the system more and more sluggish as time goes on.


No known fix yet. Fixed by using the MyISAM engine for the kvstore table instead of InnoDB. Disabling cron is a temporary workaround. Restarting FreePBX (fwconsole restart) may be another workaround.

VPN Passthrough for DD-WRT

For a long time, I had enabled VPN passthrough with DD-WRT from an IPSEC endpoint running inside the network with the SPI firewall disabled. The VPN was mostly reliable, but every once in a while I would need to reset the tunnel on both sides. I did this until I discovered the magic of enabling the SPI firewall. Just as with a Cisco router, the DD-WRT router needs to inspect the packets to know what to do with IPSEC. So, if you want IPSEC passthrough support, you really should enable both the option in step 1 AND the option in step 2 (below).



Tuning Ext4 for MythTV

When using an ext4 filesystem for MythTV, here are a few tricks to help improve speed.

First of all, always create a separate partition for your recordings! Here’s how to ensure that it is optimal.

Let’s say that you create a partition on device /dev/sdb.

    mkfs.ext4 -T largefile /dev/sdb1
    tune2fs /dev/sdb1 -o journal_data_writeback
    echo “/sbin/blockdev –setra 4096 /dev/sdb” >> /etc/rc.local

In the first step, we tell ext4 to format tuned to use large files. This reduces the number of inodes, maximizing the available space and (unconfirmed, but hypothesized) minimizing the journal size.
In the second step, we enable writeback mode for the filesystem as a default mount option. This is normally not a safe step, but we are only protecting TV content that is already very robust at working in the face of errors. Setting this option allows the OS to write to the disks without 100% lock-step synchronicity.

Now add these options to /etc/fstab.


This option in the fstab tells the OS not to change the last accessed times on the files and folders every time a file is accessed. This reduces unnecessary writes, which improves overall performance.

Your fstab might look something like this:

UUID=2a59a579-9779-455c-bfed-d7e69c5ec533 /shared/recordings ext4 defaults,nodiratime,noatime 0 0

That’s it! Happy watching.

Xenserver Heterogeneous CPUs in Pool

I have been working to get some Xenservers setup in the same pool that have different CPU versions. With different features, I get the error message that the CPUs are not homogeneous. To help rectify this, I created the following script and then followed the instructions below.


if (exists $ARGV[1]) {
} else {
        chomp($FEATURES1=`xe host-cpu-info | grep " features:" | cut -d':' -f2 | cut -d' ' -f2`);

if (!exists $ARGV[0]) {
        print "\nUsage: ./get-cpu-features [features-key1] [features-key2]\n\n";
        print "Local CPU Features: $FEATURES1\n";

sub dec2bin {
    my $str = unpack("B32", pack("N", shift));
    $str =~ s/^0+(?=\d)//;   # otherwise you'll get leading zeros
    return $str;
sub bin2dec {
    return unpack("N", pack("B32", substr("0" x 32 . shift, -32)));

print "Local : ".$FEATURES1."\n";
print "Remote: ".$FEATURES2."\n";

foreach $GROUP1 (split(/\-/,$FEATURES1)) {
        my $GROUP1BIN=dec2bin(hex($GROUP1))."\n";
        my $GROUP1BINPADDED = sprintf("%033s", $GROUP1BIN);


foreach $GROUP2 (split(/\-/,$FEATURES2)) {
        my $GROUP2BIN=dec2bin(hex($GROUP2))."\n";
        my $GROUP2BINPADDED = sprintf("%033s", $GROUP2BIN);


print "\nMerged: ";
for ($i=1; $i<=4; $i++) {
        my @bin1=split(//,$GROUP1ARRAY[$i],33);
        my @bin2=split(//,$GROUP2ARRAY[$i],33);
        for ($j=0; $j<32; $j++) {
        if ($i < 4) {
                print "-";

print "\n";

On server 1


The output will look something like this:

Usage: ./get-cpu-features [features-key1] [features-key2]

Local CPU Features: 0000e3bd-bfebfbff-00000001-20100800

On server 2, run the script again, but this time specify the key from server 1 as an argument to the script.

/root/get-cpu-features 0000e3bd-bfebfbff-00000001-20100800

Now the output will look like this:

Local : 0098e3fd-bfebfbff-00000001-28100800
Remote: 0000e3bd-bfebfbff-00000001-20100800

Merged: 0000e3bd-bfebfbff-00000001-20100800

The compatible feature key for all nodes is the one labeled merged, in this case, 0000e3bd-bfebfbff-00000001-20100800.

On each of the two nodes, we now need to set the feature key. We can do this by running this command on each node:

xe host-set-cpu-features features=0000e3bd-bfebfbff-00000001-20100800

Now reboot the nodes and then join them to the same pool.

Note: If you have more than two nodes, then you will need to add a second argument when running the script on nodes 3+. That second argument should always be the "Merged" key from each previous server that the script was run against. This will ensure that all nodes are accounted for in the final merged key. On the last node, the merged key that is produced will be the one that you need to use for every node.