1. Download and install the krb5.client.rte package for AIX.
2. Download the pre-built AIX 5.2 (compatible with AIX 5.3) binaries from the SAMBA web site (http://us1.samba.org/samba/ftp/Binary_Packages/AIX/) to a temporary location.
   1. opt-samba-base.tar.gz
   2. opt-samba-3.0.28-AIX5.tar.gz
3. Use “gunzip” to decompress each of the files (eg: gunzip opt-samba-base.tar) in the same directory. The result will be a bunch of *.bff files. These are considered “backup files” in AIX, but, essentially, are the same thing as if they were archives.
4. Use either:
   1. installp -agYX -d. all
   2. Start up “smit” and navigate to “Software Installation and Maintenance”->”Install and Update Software”->”Install Software”
      1. Enter in the full path to the temporary directory that the .bff files are stored in and hit “enter”
      2. On the new menu, use the arrow keys to navigate down to the line for “ACCEPT new license agreements” and hit “tab” to change the value to “yes”. Hit enter to start the install.
5. Install the /opt/pware/samba/3.0.28/lib/smb.conf file which has all of the configuration necessary to properly join to the domain.
6. With the packages now installed, edit /etc/krb5/krb5.conf to look like:
   1. [libdefaults]
      default_realm = AD.DOMAIN
      default_keytab_name = FILE:/etc/krb5/krb5.keytab
      default_tkt_enctypes = des-cbc-crc des-cbc-md5
      default_tgs_enctypes = des-cbc-crc des-cbc-md5[realms]
      AD.DOMAIN= {
      kdc = ad.server.ad.domain:88
      admin_server = ad.server.ad.domain:464
      default_domain = AD.DOMAIN
      }

      [domain_realm]
      .AD.DOMAIN = AD.DOMAIN
      ad.server.ad.domain=AD.DOMAIN

      [logging]
      kdc = FILE:/var/krb5/log/krb5kdc.log
      admin_server = FILE:/var/krb5/log/kadmin.log
      default = FILE:/var/krb5/log/krb5lib.log

7. Run : kinit Administrator@AD.DOMAIN to get a kerberos ticket. You will be prompted to enter the domain administrator account password.
8. Join the computer to the windows domain: /opt/pware/samba/3.0.28/bin/net ads join -U Administrator , and enter the domain administrator account password when prompted.
9. Start winbind: /opt/pware/samba/3.0.28/sbin/winbindd
10. Confirm that you are able to see the active domain users via: wbinfo -u
11. To enabled command line login access, edit /etc/security/user. Look for the link that reads “SYSTEM =” in the default: settings. Change it to look like : SYSTEM = “WINBIND”.
12. To complete the process, edit /usr/lib/security/user to include the following code at the end:
    1. WINBIND:
       program = /usr/lib/security/WINBIND
       options = authonly
13. Copy the WINBIND security binary in to place: cp /opt/pware/samba/3.0.28/lib/security/WINBIND /usr/lib/security/WINBIND

At this point, without restarting any daemons or anything, you should be able to access and log in as any active directory user. Your home directory probably won’t mount, but you should be able to successfully log in anyhow:

]# telnet aixserver

Trying 10.10.10.75...

Connected to aixserver.

Escape character is '^]'.

telnet (aixserver)

AIX Version 5

Copyright IBM Corporation, 1982, 2007.

login: myadaccount

myadaccount's Password:

*******************************************************************************

*                                                                             *

*                                                                             *

*  Welcome to AIX Version 5.3!                                                *

*                                                                             *

*                                                                             *

*  Please see the README file in /usr/lpp/bos for information pertinent to    *

*  this release of the AIX Operating System.                                  *

*                                                                             *

*                                                                             *

*******************************************************************************

3 unsuccessful login attempts since last login.

Last unsuccessful login: Thu Sep  4 15:20:34 EDT 2008 on ssh from yourmachine.ad.domain

Last login: Thu Sep  4 14:23:23 EDT 2008 on /dev/pts/1 from yourmachine.ad.domain

3004-614 Unable to change directory to "/home/ADDOMAIN/myadaccount".

        You are in "/" instead.

-bash-3.00$

Edit cacti/lib/rrd.php and comment out line 1685:

// return “–font ” . strtoupper($type) . “:” . $size . “:” . $font . RRD_NL;

Store Your Recordings on a Separate Drive (or drives)

The installation of mythtv recommends storing your recordings on a separate partition from the rest of the operating system. This is done to insulate the recordings files from the key operating system files, and, in general, it is a Best Practice. However, for optimal performance, this should be taken a step further: Set up a separate drive or drives to hold your recordings. This will separate all of the disk interaction between the OS and its related files from mythtv and its recordings. The result will be a smoother end user experience.

An internal SATA drive is probably the best and least expensive solution. An external SATA drive is good, too, but more expensive. A PATA drive would work well, but it is best to keep that drive on a different controller than the drive that your OS is on.

Reduce The Size Of Your Guide

By default, MythTV will collect 14 days of guide data to get information about future shows. This is actually great for searching for shows, and performing other user-related options, but it can wreak havoc on the system performance. A dead give-away is in th mythbackend.log file:

2007-12-23 09:31:54.099 Scheduled 871 items in 12.4 = 0.20 match + 12.17 place

If the scheduled items creeps up too high (typically greater than 700), then your system is working pretty heavily to schedule a lot of shows based upon the 14 days of guide data. This can cause the database to become rather large and slow down all database queries, which, in turn, slows down the end user experience.

A happy medium is reducing the number of days of guide data from 14 to 9.

Optimize the IVTV Paramaters

The default kernel parameters for the IVTV based cards do not take advantage of the buffers on the cards. This means that you will see a lot of logged error messages referring to “application not reading fast enough”. This could result in choppy recorded video which is a Bad Thing(tm).

options ivtv enc_yuv_buffers=8 enc_mpg_buffers=32 enc_vbi_buffers=8 enc_pcm_buffers=8

Know Your Hardware

One of the largest problems is that the underlying nature of MythTV is to take full use of the hardware it has at hand. One cannot help but try to squeeze everything (and more) out of their hardware. However, keep in mind that if you have a single processor frontend/backend system, you don’t want to be recording too many shows at any one time or running too many concurrent commercial flagging processes because the single processor just cannot handle it.

The most optimal set up is to have a fully networked frontend/backend system:

• Have a frontend (client) system for each television in the house. It is probably best to have these as identical systems with minimal hardware requirements since they will only be acting as display systems.
  • NFS mounting of videos, mp3’s, photos, etc.
• Have a backend (server) system stowed away in a closet. This will be the system that you will end up beefing up. A dual-processor system is recommended since it will be performing all of the work (recording, streaming to the frontend processes, commercial flagging, etc).
  • SATA storage for recordings
  • Separate storage for video, mp3s, photos, etc.
• 100MB networking from the backend system to each of the frontend systems.

By having the same frontend systems, if you ever have a failure of a frontend, you can always easily shuffle them around while you repair or replace the failed components.

The same goes for remote controls. Although the temptation is to just reuse the multifunction remote you already have for your TV, cable box, Tivo, etc, it just isn’t worth the hassle. Simplicity in the setup will definitely improve everyone’s WAF (Wife Approval Factor). If each frontend has the same remote (although configured specifically for the equipment attached to that frontend), then, as a user (not the admin), you just have to learn the buttons on the one remote, and it applies to all of the frontends.

Grab yourself an inexpensive multi-function remote like the OneForAll (http://www.amazon.com/gp/product/B0000ALPBA) for each of your frontend systems. I was very hesitant at buying a remote I couldn’t test out since many multi-function remotes disable certain buttons based upon the mode you are in. However, this remote specifically has a PVR mode and you can move button functions from one mode to another.

Know What You Are Displaying To

The K.I.S.S. (Keep It Simple, Stupid!) Principle really helps when maintaining your MythTV systems. By having your frontend system as similar as possible, the level of administration needed on those system drops. In other words, if you tinker with one, you know you just have to make that same change on all of the others. Unfortunately, it is harder to control what types of televisions you are displaying to.

Remember: essentially, your expensive TV screen is just a simple computer monitor at this point. You are not using the internal tuner and you are not using all of the various input (DVD player, Antenna, Cable, etc) connections. You are just using the one input on the TV that is coming out from the computer. It is nice and simple.

IF it is possible, try to stick to the same kind of input, even though you will end up with different TV’s throughout your home. For example, if your TVs all have component input as the best quality input, then make sure that all of your frontend systems can output component video.

Try to avoid using any of the ‘PC’ inputs on TV’s. Component, HDMI, Composite, S-Video, and coaxial are all bound by TV broadcast standards. Once you start fiddling with the PC inputs, you have a lot of extra work to perform in order to get it to properly display the broadcast video on the screen. Stick with the standards, and you will be satisfied.

In my case, all of ours have HDMI connections on them. Some video HDMI as evil, but that’s another topic all together. I got away with purchasing some inexpensive DVI to HDMI cables (10ft, ~$10ea. on-line).

By keeping things similar or the same, the X configuration for each of the frontend systems will be the same.

Optimize the database

The MySQL database behind MythTV takes an enormous beating as shows are recorded, scanned for commercials, watched, bookmarked, and deleted, just to name a few causes. It does not take a very long time for the database to become more ‘fragmented’ and provide slower responses due to the increasing level of ‘fragmentation’. This has a direct impact on the user experience in a very negative way.

The solution to this is to periodically optimize the database. The problem with optimizing the database is that it is intensive and will only make things worse before it makes it better. So, it is much better to run this off-hours.

The easiest solution is to run a wrapper around mythfilldatabase which optimizes the database. But, because mythfilldatabase is run according to the grabber’s suggested schedule, this might end up running in the middle of the day.

What I found as the happy medium between the two was to craft the wrapper such that the database gets optimized only one day a week:

#!/bin/sh
# mythoptdb - Call this in mythfilldatabase’s place in
# mythtv-setup

if [ `date +%a` = "Sun" ]; then
optimize_db.sh
fi

/usr/bin/mythfilldatabase –remove-new-channels –quiet –max-days 9 $*

The “optimize_db.pl” script that comes as part of the contrib from MythTV has one shortcoming: it doesn’t always work properly. It worked for me for a long time, then started hanging on the optimization/repair when my database grew rather large. I ended up replacing it with optimize_db.sh which does the job more efficiently. Still, you must keep in mind that the database will be unavailable during the optimization/repair of all tables. The goal is to keep this (very) short.

Understand the order of your inputs

Setting up MythTV can be very confusing: there are so many options in the mythtv-setup screens that is can be easy to either miss an important option or be unable to find that elusive option later on. Add in to the equation the fact that there are easily just as many (if not more) options in the frontend setup menus, it becomes almost overwhelming.

One item that took a couple of emails to the mailing list to figure out is the ordering of the tuners. When recording, the backend server process is set up to select the first available tuner, and when you go to watch live tv (which I almost never do now-a-days), it also is set up to select the first available tuner. Additionally, if you are watching live TV and mythtv needs to record something, you get the expected warning that it needs the tuner for that recording.

All of that sounds normal, and it is. However, you can change the settings to have mythtv’s backend select the tuners in reverse order so as to avoid conflict

High Definition recordings vs Standard Definition recordings

Standard Definition (SD) recordings, when displayed via MythTV on that nice screen just don’t look as good as that old 4:3 tube television. The problem there is that SD is broadcast as interlaced video, and the computer (the mythtv box) only displays in progressive mode (see this great description of the differences). That, and the quality of SD is so low, many of the artifacts that you didn’t notice previously now show up amplified because of the larger screen size, the better screen quality, and the MPEG2 encoding. However, SD has one advantage: it is small. Typical hour-long shows run about 300-500MB.

High Definition (HD) recordings are an entirely different beast, and they come in many different flavors. Aside from an awesome increase in picture quality, they all have one important factor in common: they are huge. A typical 1 hour recording can run between 3 and 6 gigabytes.

PLAN YOUR STORAGE ACCORDINGLY.

My experience is limited to only Over-The-Air (OTA) HD transmissions from the local affiliate stations, but I definitely recommend the HDHomeRun for an OTA setup. MythTV supports it right out of the box, it is easy to configure, and you can get HD recordings set up within minutes.

Obtaining HD recordings off of your cable/satellite box is an entirely different beast, and, unfortunately, I have not gone down that route just yet.

BE PREPARED TO ADMINISTER THIS SETUP

MythTV is still in a beta phase, and, although there are a lot of people who are using it, it still is not entirely ready for prime-time; the system isn’t made to run entirely on its own and it does need some tlc. I cannot stress this enough: don’t go cheap on your backend system’s motherboard. Make sure that it is a solid board with well supported chips. Some inexpensive, and tempting, motherboards use chipsets that work well as windows systems, but perform with numerous problems under Linux (some Jetway, PCChips, MSI, and some via-based motherboards) which will only give you major headaches.

This is not to say that you couldn’t have a successful system that you don’t need touch for weeks on end, but it is likely that things may creep up that you, and no one else, expected. Besides, you will want to tinker with it over time to fully optimize the system.

A great example is the impact of cpu frequency scaling on a MythTV backend: don’t do it. If you have multiple cards and a couple of drives (OS and video), cpuscaling can wreak havoc on the system: ivtv drivers have been known to stop responding (requiring the backend to be shut down and the drivers unloaded and reloaded) and active/busy SATA interfaces have been known to falsely believe that there are ext3 journal errors which results in the drive being put in to read-only mode.

With all of the above said, you can create an excellent home-wide DVR system using COTS (Common Off The Shelf equipment) that is DRM-free, completely customizable to your liking, and extremely versatile.

Nearly two years and two employers have passed by, and I find myself going through a similar setup. Unfortunately, i discovered that the backup of the files I took when I left my employer did not contain some of the key files, so I had to start back at square one. The article was a great starting point, but I was worried that, since the magazine was now defunct, the article might not be around for much longer (although, as a subscriber, I received a CDROM containing all of the issues).

The article was also rather basic, and not very security conscious. Additionally, some key steps (such as managing client certificates) were completely left off. I’ve attached the original article for posterity.

The Server

To start off, the server needs to be set up and configured. Some key items to keep in mind:

• The standard OpenVPN port is 1194. However, there is nothing stopping you from running it at a different port.
• Decide between a “bastion host” setup versus a “completely integrated setup” (I’ll cover these in a moment).

On an RPM based distro, install the openvpn package. In addition to the core openvpn components, it will also install a series of SSL/cert management tools in a directory at /usr/share/doc/openvpn-<version>/easy-rsa. Copy that entire directory to /etc/openvpn/easy-rsa. Now, cd to /etc/openvpn/easy-rsa, and take a look at the README file to familiarize yourself with the steps. The general breakdown is:

• cd /etc/openvpn/easy-rsa
• edit the “vars” file to your liking. The only things I changed were the KEY_SIZE to make it 2048, and the KEY_ values to reflect the company’s information. Save the file.
• export KEY_CONFIG=/etc/openvpn/easy-rsa/openssl.cnf
• export KEY_DIR=/etc/openvpn/easy-rsa/keys
• . vars
• ./clean-all
• ./build-ca
• ./build-dh
• Build a key for the server: ./build-key myserver

Now that the certificate and keys have all been made for the server, there are a few additional steps to set up the directory structure and generate a server port key:

• cd /etc/openvpn
• ln -s /etc/openvpn/easy-rsa/keys keys
• openvpn –genkey –secret port1194.key
• useradd openvpn (if the account hasn’t been created already)
• echo 1 > /proc/sys/net/ipv4/ip_forward

At this point, all of the security components are set up and actual configuration of openvpn is necessary. I’ve attached a modified version of the sample server configuration file, but the highlights of the file include forcing out DHCP entries, setting routes, communicating via UDP only (UDP is much more efficient than TCP in this situation, so use it if you can), and logging.

Openvpn can handle multiple port configurations as it will read the /etc/openvpn directory and look for all files ending in “.conf”. In most cases, you will only be working with one, but it is nice to know it supports multiple.

Once the configuration file is in place (openvpn Port Configuration File) in /etc/openvpn, start up openvpn via /etc/init.d/openvpn start and check the log files in /var/log/openvpn for information. The server is up, and now on to the clients.

The Clients

The poor-man’s way of doing things is to create one client certificate and hand it out to everyone. While this works, the down side is that it makes it next to impossible to seamlessly deactivate any one person’s access. The best practice is to create individual certificates for each user, and provide them to the individual users. Since the server has a copy of the user’s certificate, you can easily (re)move a certificate to disable a given user.

Server Side Configuration

Create a user certificate via:

• cd /etc/openvpn/easy-rsa
• . vars
• export KEY_CONFIG=/etc/openvpn/easy-rsa/openssl.cnf
• export KEY_DIR=/etc/openvpn/easy-rsa/keys
• ./build-key clientname

At the end, there will be three files created:

• clientname.crt
• clientname.csr
• clientname.key

Remember these. We’ll need two of them (the .crt and the .key) for later use when they get copied over to the client.

Client Side

The article has some good coverage of the steps necessary on building the Windows client via NSIS, and, personally, I think it (NSIS) is awesome. After installing NSIS and downloading the openvpn gui (from the link in the article), I was testing the installer in no time. Now, I did have to tweak the nsi file a number of times, just to get the default version working since it seems that the NSIS plugins have been updated to conflict with some settings in the default NSI. So, I modified that NSI to get the final version of the openvpn.nsi file that is fully branded, installs our ca.crt (which was copied over from /etc/openvpn/keys/ca.crt), sets up all of the start menu items, and installs our client configuration file.

With the installer package built and tested, it can now be supplied to the user, along with the clientname.key and clientname.crt files and instructions as to where to place those two files.

Bastion host versus Complete Integration

Getting the user(s) access to the network via VPN is a good chunk of the battle, but you really have to decide how you want to support this new VPN network. Right now, the only access they really have is to the server running the openvpn process. The other machines on your network do not know how to communicate back to this new network you created (remember, you’ve just turned this server in to a router).

A bastion host is a host that sits within your network that your VPN user(s) can log in to, and, from there, jump around to the rest of the network. It is essentially a terminal server for those Windows folks out there.

However, if you would rather provide direct access from the machines coming in via the VPN, you would have to either:

• On each host on your network, add a route to your new vpn network with your openvpn server as the gateway, or
• On each router in your network, add a route to your new vpn network with your openvpn server as the gateway.

Branded VPN Deployment and Seamless Remote Management

Adam Olson

Bridging the gap between production network systems and remote users has always
posed challenges. Initial infrastructure design, access privileges, and client
software needs all must be addressed to ensure that network capacity and maintenance
issues remain manageable as the user base grows. Perhaps the most important
consideration is ease of use for the end user. Software, in general, is becoming
more and more intuitive and end users expect a certain level of usability and
aesthetic quality.

In this article, I will discuss a VPN system that overcomes these technical
challenges while also providing an easy-to-use, attractive interface to the
user. The solution is based on multiple open source tools. These open source
projects are OpenVPN, OpenVPN GUI, Nullsoft Scriptable Install System (NSIS),
and TightVNC (see Resources). TightVNC is added to provide seamless remote management
that is not provided by the VPN solution itself.

The result will be a company-branded Windows 2000/XP installer that not only
includes all client-side VPN configuration and key information, but also provides
an integrated VNC server for remote management and assistance upon starting
the VPN instance.

Open Source Tools

OpenVPN is a robust and flexible VPN solution that enables most Unix/Linux,
Windows 2000/XP, and Mac OSX platforms to securely build encrypted tunnels to
one another. These tunnels can be configured in a variety of ways, but in this
article, I will focus solely on a point-to-point network design that will be
one small or large hub and spoke deployment.

OpenVPN GUI is a very handy front end to managing VPN instances for Windows
2000/XP. This is usually the most prominent end-user operating system within
the organization, so an easy-to-use System Tray icon is a must. OpenVPN GUI
allows for easy VPN access for most users.

The Nullsoft Scriptable Install System (NSIS) is a great open source project
that enables you to create company-branded client installer packages. End-user
perception is greatly enhanced when the install process has an in-house look
and feel.

You may be familiar with Virtual Network Computing (VNC), and TightVNC is
another open source package based on Real VNC. I began using TightVNC over its
counterparts about five years ago, so I’ve stuck with it in this deployment.
It is very reliable and carries a small footprint. The same result could probably
be attained with a different VNC package if you want to experiment after reading
this article.

Data Center Requirements

This article is primarily focused on simplifying the end-user side of things,
but it would be incomplete if the data center needs were left unaddressed. In
your data center, you will need a dedicated and hardened server running a popular
Unix/Linux operating system. Please note the words “dedicated” and “hardened”,
because this is one machine that you do not want to be compromised. Any remote
nodes that require VPN access are inherently passing sensitive data, so take
extra caution in this area. Strip down the network services to nothing but SSH
and OpenVPN, if possible, and maintain strict firewall rules. For additional
information, check out the many online documents on this subject.

The following examples will be based on a system running Red Hat Fedora Core
2.

To compile OpenVPN, run the standard:

# gzip -d openvpn-2.0_rc6.tar.gz
# tar xf openvpn-2.0_rc6.tar
# cd openvpn-2.0_rc6
# ./configure
# make
# make install

If you have any problems compiling, make sure you have LZO compression libraries
installed. Please refer to the OpenVPN documentation for details on this.

OpenVPN Server Configuration

To begin, create a directory to house your VPN configuration files and keys:

# cd /etc
# mkdir openvpn
# chmod 700 openvpn
# cd openvpn

Here is a straightforward configuration file for your first server instance that
should be named port5023.conf:

### Start Config File Port 5023 ###

# local tun device
dev tun23

# interface addresses
ifconfig 10.23.0.1 10.23.0.2

# key location
secret /etc/openvpn/port5023.key

# port to listen on
port 5023

# user to run as
user nobody
group nobody

# options
comp-lzo
ping 15
verb 1

### End Config File Port 5023 ###

This file has very few options that require changing for each server instance,
mainly the tunnel interface on which to bind, the UDP port on which to listen,
the location of the key file, and the point-to-point addressing for the VPN connection.

Please note that the example configuration above instructs OpenVPN to switch
user and group IDs to the account “nobody”. This is ideal if your VPN server
is running only OpenVPN daemons as nobody. If the VPN server is running other
services under the user and group IDs of nobody, it is best to run OpenVPN as
a different user and group ID.

To create the static key for this VPN instance, run this command from within
/etc/openvpn:

# /usr/local/sbin/openvpn --genkey --secret port5023.key

At this point, don’t forget to add the necessary rule permitting UDP traffic destined
to port 5023 within IPTables or your respective firewall software. Also note that
a simple Perl script run via cron should be set up to monitor failed attempts
at making a connection to this port for security auditing purposes.

You should now be able to start your VPN instance by executing:

# /usr/local/sbin/openvpn --daemon --disable-occ --config \
/etc/openvpn/port5023.conf

The options passed to OpenVPN are as follows:

--daemon -- Run as a daemon.

–disable-occ — This option allows, among other things, two different
versions of OpenVPN to communicate. This is very handy when you are supporting
true telecommuters who don’t receive software updates on a routine basis.

–conf — Specify the location of the configuration file.

You should now have a basic VPN server instance listening on port 5023. If
you experience any problems, please review the OpenVPN documentation. It is
straightforward to configure, so any issues should be easily resolved.

Building the VPN Installer

VPN clients in this configuration need to know where the VPN server is located,
which port to connect to, which statically assigned key to use, and more. This
is all accomplished by providing a complete configuration file and key within
the company-branded VPN installer. End users will not need nearly as much assistance
in remotely accessing the more sensitive resources within the company with an
easy-to-use installer executable.

Because we are creating our own Windows 2000/XP installer, the opportunity
exists to introduce otherwise totally separate program binaries into the installation
process. Instead of simply installing a VPN client with a prearranged key and
configuration file, we will also be including TightVNC binaries for both the
client and server instance of the VNC protocol.

Download and install the NSIS package on a Windows XP development system at:

http://www.openvpn.se/files/nsis/nsis20b3.exe

Since the release of my production rollout, a newer version of NSIS has been released.
Make sure you are using the version linked to above for demonstration purposes,
but each principle covered here is applicable to the later versions. However,
I have noticed that the latest version of NSIS does require a little bit of tweaking
with the following install source zip file, so you will find it easier to use
the above version of NSIS anyway.

Next, download the installation source to the same Windows XP development
system at:

http://www.openvpn.se/files/install_packages_source/ \
openvpn_install_source-2.0-rc6-gui-1.0-beta26.zip

This file was put together by Mathias Sundman and includes all of the necessary
files for OpenVPN, OpenVPN GUI, and NSIS configuration to build the standard OpenVPN
Windows installer package. Unzip this file to your desktop and name the folder
“VPN Sources” for now.

To get an idea of what will result from the overall process, open the VPN
Sources folder, right-click openvpn-gui.nsi, and left-click “Compile NSI”. A
few seconds later you should see an OpenVPN installer executable in the “VPN
Sources” folder. If you were to execute this installer, the standard version
of OpenVPN would be installed. If you ran into any problems creating this executable,
please refer to the documentation located at:

http://openvpn.se/files/howto/ \
openvpn-howto_roll_your_own_installation_package.html

or:

http://nsis.sourceforge.net

Building the Company-Branded VPN Installer

We now have a basic VPN server instance and a standard Windows installer for
OpenVPN, but we want to make it custom built for easy deployment. We also want
to add TightVNC binaries for instant remote administration and assistance.

Download the complete set of TightVNC 1.3dev6 executables without the installer
at:

http://www.tightvnc.com/download.html

For now, unzip and save the included files to your desktop. We will be concerned
with the files VNCHooks.dll, vncviewer.exe, WinVNC.exe, and LICENCE.txt. Copy
these files to the openvpn folder within the “VPN Sources” folder.

Save the following client-side example configuration file to openvpn/config/VPN.ovpn
within your “VPN Sources” folder as well:

### BEGIN CLIENT SIDE CONFIGURATION FILE ###

# vpn server to contact
remote 192.168.10.10

# port to establish connection on
port 5023

# local tunnel device
dev tun

# interface addresses
tun-mtu 1500
ifconfig 10.23.0.2 10.23.0.1
route 10.0.0.0 255.0.0.0 10.23.0.1

# key location
secret "c:\\program files\\company branded vpn\\config\\key.txt"

# enable LZO compression
comp-lzo

# moderate verbosity
verb 0
mute 10

;fragment 1300
;mssfix

; ping-restart 60
; ping-timer-rem
; persist-tun
; persist-key
; resolv-retry 86400

# keep-alive ping
ping 10

# enable LZO compression
comp-lzo

# moderate verbosity
verb 4
mute 10

### END CLIENT SIDE CONFIGURATION FILE ###

You will see a number of options in the above example configuration, and I encourage
you to test different settings. For now, a reasonable number of options are enabled,
and the rest are commented out with a leading semicolon. The most important options
will be the IP address of your VPN server, the port number on which to connect,
the location of the key file, and the addressing assignments of the VPN interface.
Also, note the route command listed above. You have control over establishing
entries in the end user’s routing table upon successful completion of the VPN
tunnel creation. This comes in handy in a number of situations.

Before moving on, you will also need to copy the contents of /etc/openvpn/port5023.key
on your VPN server to openvpn/config/key.txt within the “VPN Sources” folder.
This step ensures the new VPN installer will have the correct key when establishing
the encrypted tunnel.

To wrap up the company-branded VPN installer portion, open the “VPN Sources”
folder and edit openvpn-gui.nsi. Replace the first section of code with this:

!include "MUI.nsh"
!include "setpath.nsi"

!define MASTER "x:\openvpn\exp\openvpn"

!define HOME "openvpn"
!define BIN "${HOME}\bin"

!define MUI_PRODUCT "Company Branded VPN"
!define OPENVPN_VERSION "2.0"
!define GUI_VERSION "2.0"
!define MYCERT_VERSION "0.3.2b"
!define MUI_VERSION "-"
;!define MUI_VERSION "${OPENVPN_VERSION}-gui-${GUI_VERSION}"

!define TAP "tap0801"
!define TAPDRV "${TAP}.sys"

Now find the line that starts with “OutFile” and replace it with:

OutFile "Company Branded VPN.exe"

Next, locate the line:

File "${HOME}\openvpn.exe"

And add directly below it (overwriting the identically named sections):

  SetOutPath "c:\program files\TightVNC"

nsExec::ExecToLog '"c:\program files\TightVNC\winvnc.exe" -kill'

File "${HOME}\vncviewer.exe"
File "${HOME}\WinVNC.exe"
File "${HOME}\LICENCE.txt"
File "${HOME}\VNCHooks.dll"

nsExec::ExecToLog '"c:\program files\TightVNC\winvnc.exe" -reinstall'
nsExec::ExecToLog 'net start winvnc'

SectionEnd

Section "OpenVPN GUI" SecGUI

SetOverwrite on
SetOutPath "$INSTDIR\bin"
File "${HOME}\openvpn-gui.exe"

SetOutPath "$INSTDIR\config"
File "${HOME}\config\VPN.ovpn"
File "${HOME}\config\key.txt"

CreateDirectory "$INSTDIR\log"

SectionEnd

Next, locate the following lines:

Delete "$INSTDIR\config\README.txt"
Delete "$INSTDIR\config\sample.${SERV_CONFIG_EXT}.txt"

and replace them with:

Delete "$INSTDIR\config\key.txt"
Delete "$INSTDIR\config\README.txt"
Delete "$INSTDIR\config\VPN.ovpn"

This step ensures removal of the key and configuration file in the event the user
uninstalls the company-branded VPN package.

Finally, in the “VPN Sources\openvpn” folder, rename openvpn-2.0_rc6.zip to
openvpn-2.0.zip and openvpn-gui-1.0-beta26.zip to openvpn-gui-2.0.zip. I do
this to keep the version of the primary application OpenVPN simple; feel free
to address this issue as desired.

Return to the “VPN Sources” folder, right-click openvpn-gui.nsi and left-click
compile NSI. If you made all the changes correctly, you will now see a “Company
Branded VPN.exe” in the “VPN Sources” folder. It will include a complete example
configuration, the appropriate key, and a company-branded look and feel to the
installer. It will also install TightVNC, register it as a Windows Service,
and start you on your way to easier remote user administration with secure remote
access.

Where You Can Go from Here

The general ideas outlined in this article enable systems and network administrators
to deploy a company-branded VPN solution for the Windows 2000/XP platform, which
can be extended to other client platforms with additional work. This solution
allows administrators to control what the end user’s workstation knows about
(routing table additions), what the end user is permitted to access (VPN server’s
firewall configuration), and utilizes open source tools, thereby allowing a
company to deploy cost-effective and branded solutions to its users.

Resources

NSIS Web site — http://nsis.sourceforge.net

OpenVPN Web site — http://www.openvpn.net

OpenVPN GUI Web site — http://openvpn.se

Real VNC Web site — http://www.realvnc.com

TightVNC Web site — http://www.tightvnc.com

Adam Olson lives in Northern California. He’s been active in network design,
systems administration, and systems programming for more than nine years with
various companies like MCI WorldCom and small Bay Area startups. He has now
co-founded a relatively new company serving the needs of small and medium-sized
businesses that is called Office Appliance (http://officeappliance.com).

Unfortunately, we had a user who absolutely needed to have the SMS messages copied from their 8830 to their new Blackberry Curve, and they wouldn’t give up the old phone until the messages were moved over.

Linux to the rescue!  Using the tool called barry, we managed to perform a full backup of the 8830 and successfully restore it to another 8830.  Unfortunately, we couldn’t restore it to the Curve because barry wouldn’t recognize the curve with the version of barry that we had (0.12).  Additionally, we couldn’t modify the backup file (a tar.gz file containing directories and binary files of the messages) in any way (not even a simple untar/uncompress and immediate tar and re-compress) since barry would immediately complain about the contents.

So.. here we had a backup, but couldn’t get it on to the curve.  Some browsing through the mailing list archives for barry turned up an obscure reference to the CVS repository for another fix, so we checked out the CVS repository, built and installed, and gave it a shot.

It worked to a certain level.. It transferred 78 of the 128 SMS messages, then hung.  A second attempt (after killing off barry) got to 108 messages before hanging, and the end user was happy with the 108 messages (they included the ones they wanted to save) and we left it at that.

Wiping the blackberry was easy:

1. Go To Options
2. Select Security Options
3. Select General Settings
4. Click the Menu key and select Wipe Handheld
5. Click Continue and follow the prompt by entering the word blackberry

The unit will then wipe itself and it will be back to factory defaults.