Server path error in vSphere 4.1

First off, this is related to the post in VMware Communities here: http://communities.vmware.com/message/1576370

I recently updated a VMware Infrastructure to vCenter 4.1. All ESX servers were still on ESXi 3.5. This shouldn’t be a problem, you just can’t use some of the new features available in 4.1. That’s fine, except that I couldn’t view the managed paths in the ESX servers. I would get the error below. I would get the same error when trying to manually migrate a virtual machine to a different ESX server.

vmware error

You can see the error states Item has already been added. Key in dictionary: ‘Vmomi.Host.PlugStoreTopology+Path’ Key being added: ‘Vmomi.Host.PlugStoreTopology+Path’. And of course you can see that two entries are listed.

I tried multiple solutions, including completely reinstalling vCenter with a new database and reconfiguring. Restarting the ESX servers didn’t matter. The real solution was upgrading all of the ESXi servers to 4.1. This shouldn’t seem necessary, but the upgrade through Upgrade Manager (they got rid of the Host Update Utility after 4.0) was relatively easy and smooth. After having issues with vCenter 4.1 I was reluctant to move the ESX servers there, but so far everything is working great, including migrations and managed paths.

Latest and greatest Subversion on Debian Lenny

Debian has its own package for Subversion, but most of the time you want to use the latest Subversion package that’s out there. This explains how to build and use that over Apache and HTTPS.


Installation

This particular install does not use the Berkeley DB method of code repository storage, but rather the flat file system storage method. Both have their advantages, but the file is believed to be faster. Read more here.

First setup Apache and get all the Subversion dependencies.

apt-get install apache2
apt-get build-dep subversion
cd /usr/src
wget http://subversion.tigris.org/downloads/subversion-1.6.11.tar.gz
tar zxvf subversion -1.6.11.tar.gz
cd subversion-1.6.11
./configure --prefix=/usr/local

Then we get this warning, but FSFS is fine to use instead of Berkeley.

configure: WARNING: we have configured without BDB filesystem support

You don't seem to have Berkeley DB version 4.0.14 or newer
installed and linked to APR-UTIL.  We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end.  You can find the latest version of
Berkeley DB here:

http://www.oracle.com/technology/software/products/berkeley-db/index.html

Continue with the build:

make
make install

After install, this error comes up, but it can be ignored and the next few steps will fix.

apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..
make: *** [install-mods-shared] Error 1

Create the file /etc/apache2/mods-available/dav_svn.load with the following:

# Depends: dav
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so
LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so

Copy over the modules from source and install them in the Apache directories; also enable SSL since we want to push this over a secure channel:

cp /usr/src/subversion-1.6.11/subversion/mod_dav_svn/.libs/mod_dav_svn.so /usr/lib/apache2/modules/
cp /usr/src/subversion-1.6.11/subversion/mod_authz_svn/.libs/mod_authz_svn.so /usr/lib/apache2/modules/
a2enmod dav_svn
a2enmod ssl

Configuration

Create the file /etc/apache2/sites-available/svn so that Apache knows about the SVN repository:

NameVirtualHost svn.mysite.com:443

<VirtualHost svn.mysite.com:443>

DocumentRoot /var/svn

# SSL Definitions
SSLEngine on
SSLCertificateFile /etc/ssl/private/myserver_svn.crt
SSLCertificateKeyFile /etc/ssl/private/myserver_svn.key

# Subversion
<Location /svn>
    DAV svn
    SVNListParentPath on
    SVNParentPath /var/svn
    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /etc/svn/dav_svn.passwd
    AuthzSVNAccessFile /etc/svn/dav_svn.control
    Require valid-user
</Location>
</VirtualHost>

Now enable the site and start/restart Apache:

a2ensite svn
/etc/init.d/apache2 restart

Setup the initial repository with the svncreate command and make the user running the web service the owner, since they will be the user actually modifying the repository files.

mkdir /var/svn
svnadmin create /var/svn/myproject
chown -R www-data:www-data /var/svn/myproject

Now we can create the username/password files along with the access files.

mkdir /etc/svn
touch /etc/svn/dav_svn.passwd
htpasswd -mb /etc/svn/dav_svn.passwd myuser mypassword

Create the access file to your repositories.

touch /etc/svn/dav_svn.control

And now edit the file. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

[myproject:/]
myuser = r

[myproject:/trunk/base/code]
myuser = rw

Now reboot the server and test access; it should start up automatically.

Maintenance and Use

The best way to use SVN over HTTPS is with Tortoise for Windows or some other tool if using Linux, like RapidSVN.

Adding Additional Users

To add more users, just run the htpasswd command linked to your dav_svn.passwd file, same as the initial configuration for users.

htpasswd -mb /etc/svn/dav_svn.passwd newuser newpassword

And now edit the access file containing the other users and defined in the Apache configuration. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

[myproject:/]
myuser = r
newuser = r

[myproject:/trunk/base/code]
myuser = rw
newuser = rw

Backing Up the Repositories

To backup a repository, use the svnadmin dump command which will export the entire database and revisions. You can then tar up and gzip the dump file for compression, and back it up to tape or disk somewhere else. There are also incremental backups that can be done of disk/tape space is an issue.

svnadmin dump /home/svn/myproject > /home/backups/myproject_dumpfile

Restoring the Repositories

Restoring the SVN database is simply rewriting all the revisions from the dump back into a database. The restore process also works well for moving an older repository over to a new one since restoring the dump into a new SVN database will update it to that version.

svnadmin create /home/svn/restoredproject
svnadmin load /home/svn/restoredproject < /home/backups/myproject_dumpfile
chown -R www-data:www-data /home/svn/restoredproject
chmod -R 770 /home/svn/restoredproject

Duplicity Install and Backup Samples

Duplicity is a backup tool that works off of rsync and rdiff libraries to copy only changes to a backup location. It can use compression and encryption tools on the data and also has the ability to save to Amazon’s S3 service. More details can be found here.


Installation on OpenBSD 4.4

The 4.4 version was the most difficult to get working since the majority of the issues came from the given OpenBSD libraries. Even installing the Duplicity port from the packages didn’t function right.

First we need to add a few packages. You can use the pkg_add function with whatever mirror to obtain the following, some depend on others so there will be others in the file install list:

  • python-2.5.2p4
  • py-boto-1.3
  • gpgme-1.1.5
  • librsync-0.9.7
  • ncftp-3.2.1

When the main Python package is installed, it will ask you to create a few symbolic links, so create those.

ln -sf /usr/local/bin/python2.5 /usr/local/bin/python
ln -sf /usr/local/bin/pydoc2.5  /usr/local/bin/pydoc

Version 4.4 needs a separate Python XML package to work properly. If it’s not installed, you’ll get a series of errors when trying to send data to S3; I believe the XML error is when it tries to read the response. Something like this will error out:

Traceback (most recent call last):
  File "/usr/local/bin/duplicity", line 482, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 477, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 468, in main
    full_backup(col_stats)
  File "/usr/local/bin/duplicity", line 174, in full_backup
    col_stats.set_values(sig_chain_warning = None).cleanup_signatures()
  File "/usr/obj/ports/duplicity-0.4.12/fake-amd64/usr/local/lib/python2.5/site-packages/duplicity/collections.py", line 476, in set_values
  File "/usr/obj/ports/duplicity-0.4.12/fake-amd64/usr/local/lib/python2.5/site-packages/duplicity/backends.py", line 802, in list
  File "/usr/local/lib/python2.5/site-packages/boto/s3/bucketlistresultset.py", line 31, in bucket_lister
    delimiter=delimiter)
  File "/usr/local/lib/python2.5/site-packages/boto/s3/bucket.py", line 205, in get_all_keys
    xml.sax.parseString(body, h)
  File "/usr/local/lib/python2.5/xml/sax/__init__.py", line 43, in parseString
    parser = make_parser()
  File "/usr/local/lib/python2.5/xml/sax/__init__.py", line 93, in make_parser
    raise SAXReaderNotAvailable("No parsers found", None)
xml.sax._exceptions.SAXReaderNotAvailable: No parsers found

To avoid that, a separate Python XML package needs to be downloaded and installed:

cd /usr/src
wget http://downloads.sourceforge.net/project/pyxml/pyxml/0.8.4/PyXML-0.8.4.tar.gz
tar zxvf PyXML-0.8.4.tar.gz
cd PyXML-0.8.4
python setup.py install

Now we can install Duplicity.

cd /usr/src
wget http://code.launchpad.net/duplicity/0.6-series/0.6.06/+download/duplicity-0.6.06.tar.gz
cd duplicity-0.6.06
python setup.py --librsync-dir=/usr/local build
python setup.py install --prefix=/usr/local

If you run the Duplicity jobs as root in a cron job, there is something about OpenBSD (I’m sure a security issue) that causes it to fail. I would get the output below in my log only when it ran as a cron job:

Traceback (most recent call last):
  File "/usr/local/bin/duplicity", line 583, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 577, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 558, in main
    full_backup(col_stats)
  File "/usr/local/bin/duplicity", line 234, in full_backup
    bytes_written = write_multivol("full", tarblock_iter, globals.backend)
  File "/usr/local/bin/duplicity", line 148, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 240, in GPGWriteFile
    bytes_to_go = data_size - get_current_size()
  File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 232, in get_current_size
    return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory:'/tmp/duplicity-gM4CN9-tempdir/mktemp-iZknw0-2'

Odd that it can’t read the temporary folder that it created. Changing the folder location also did not work. The solution is to create a separate user for only backups. The can be an issue if you have files that cannot be read by all users and need backup, but I found in my case this worked for the specific files that needed to be saved.

useradd -m -d /home/dpbackup -c 'Duplicity' dpbackup
usermod -G nogroup dpbackup
mkdir /home/dpbackup/log

Make sure to add the new user to the deny list in SSH with DenyUsers dpbackup in the file /etc/ssh/sshd_config; there isn’t any reason for it to log in.

Now su as this new user. A GPG key needs to be created so that the compressed backups can be encrypted and signed. This way no one else that may have access to our S3 account (Amazon employees) can read the data.

su dpbackup
$ cd
$ gpg --list-keys
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf'
created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg'
created
gpg: /root/.gnupg/trustdb.gpg: trustdb created

$ gpg --gen-key

There will be a series of questions, most of the defaults are fine.

  • Choose option 1 for DSA and Elgamal (the default)
  • Choose the default key size of 2048
  • Leave the default that the key will not expire, option 0
  • Enter a User ID, Email address, and comment for the key.
  • Type O for OK to accept.
  • Enter a long passphrase for the key and allow it to be generated. I usually do at least 20 characters since the password will just sit in a script anyway.

Move the keys to some other safe place so that they can’t be lost. No key means the backups are worthless. Typically a second backup source is a good idea.

$ tar cf gpg_keys.tar .gnupg/
$ chmod 600 gpg_keys.tar

See sample scripts below for backup jobs.


Installation on OpenBSD 4.4

The 4.4 version was the most difficult to get working since the majority of the issues came from the given OpenBSD libraries. Even installing the Duplicity port from the packages didn’t function right.

First we need to add a few packages. You can use the pkg_add function with whatever mirror to obtain the following, some depend on others so there will be others in the file install list:

  • python-2.5.4p1
  • py-xml-0.8.4p8
  • py-boto-1.7a
  • gpgme-1.1.5p0
  • librsync-0.9.7p0
  • ncftp-3.2.2

When the main Python package is installed, it will ask you to create a few symbolic links, so create those.

ln -sf /usr/local/bin/python2.5 /usr/local/bin/python
ln -sf /usr/local/bin/python2.5-config /usr/local/bin/python-config
ln -sf /usr/local/bin/pydoc2.5 /usr/local/bin/pydoc

Now we can install Duplicity.

cd /usr/src
wget http://code.launchpad.net/duplicity/0.6-series/0.6.06/+download/duplicity-0.6.06.tar.gz
cd duplicity-0.6.06
python setup.py --librsync-dir=/usr/local build
python setup.py install --prefix=/usr/local

If you run the Duplicity jobs as root in a cron job, there is something about OpenBSD (I’m sure a security issue) that causes it to fail. I would get the output below in my log only when it ran as a cron job:

Traceback (most recent call last):
  File "/usr/local/bin/duplicity", line 583, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 577, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 558, in main
    full_backup(col_stats)
  File "/usr/local/bin/duplicity", line 234, in full_backup
    bytes_written = write_multivol("full", tarblock_iter, globals.backend)
  File "/usr/local/bin/duplicity", line 148, in write_multivol
    globals.gpg_profile, globals.volsize)
  File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 240, in GPGWriteFile
    bytes_to_go = data_size - get_current_size()
  File "/usr/local/lib/python2.5/site-packages/duplicity/gpg.py", line 232, in get_current_size
    return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory:'/tmp/duplicity-gM4CN9-tempdir/mktemp-iZknw0-2'

Odd that it can’t read the temporary folder that it created. Changing the folder location also did not work. The solution is to create a separate user for only backups. The can be an issue if you have files that cannot be read by all users and need backup, but I found in my case this worked for the specific files that needed to be saved.

useradd -m -d /home/dpbackup -c 'Duplicity' dpbackup
usermod -G nogroup dpbackup
mkdir /home/dpbackup/log

Make sure to add the new user to the deny list in SSH with DenyUsers dpbackup in the file /etc/ssh/sshd_config; there isn’t any reason for it to log in.

Now su as this new user. A GPG key needs to be created so that the compressed backups can be encrypted and signed. This way no one else that may have access to our S3 account (Amazon employees) can read the data.

su dpbackup
$ cd
$ gpg --list-keys
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf'
created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg'
created
gpg: /root/.gnupg/trustdb.gpg: trustdb created

$ gpg --gen-key

There will be a series of questions, most of the defaults are fine.

  • Choose option 1 for DSA and Elgamal (the default)
  • Choose the default key size of 2048
  • Leave the default that the key will not expire, option 0
  • Enter a User ID, Email address, and comment for the key.
  • Type O for OK to accept.
  • Enter a long passphrase for the key and allow it to be generated. I usually do at least 20 characters since the password will just sit in a script anyway.

Move the keys to some other safe place so that they can’t be lost. No key means the backups are worthless. Typically a second backup source is a good idea.

$ tar cf gpg_keys.tar .gnupg/
$ chmod 600 gpg_keys.tar

See sample scripts below for backup jobs.


Installation on Debian Lenny 5.0

The Debian install is a little bit simpler and can run the backup job as root inside cron. Get some install packages first:

apt-get install python python-dev librsync-dev python-boto

Install Duplicity:

cd /usr/src
wget http://code.launchpad.net/duplicity/0.6-series/0.6.06/+download/duplicity-0.6.06.tar.gz
tar zxvf duplicity-0.6.06.tar.gz
cd duplicity-0.6.06
python setup.py build
python setup.py install

Creating a user is optional, but good security practice for it not to be root.

useradd -m -d /home/dpbackup -c 'Duplicity' dpbackup
mkdir /home/dpbackup/log

Make sure to add the new user to the deny list in SSH with DenyUsers dpbackup in the file /etc/ssh/sshd_config; there isn’t any reason for it to log in.

Now su as this new user. A GPG key needs to be created so that the compressed backups can be encrypted and signed. This way no one else that may have access to our S3 account (Amazon employees) can read the data.

su dpbackup
$ cd
$ gpg --list-keys
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf'
created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg'
created
gpg: /root/.gnupg/trustdb.gpg: trustdb created

$ gpg --gen-key

There will be a series of questions, most of the defaults are fine.

  • Choose option 1 for DSA and Elgamal (the default)
  • Choose the default key size of 2048
  • Leave the default that the key will not expire, option 0
  • Enter a User ID, Email address, and comment for the key.
  • Type O for OK to accept.
  • Enter a long passphrase for the key and allow it to be generated. I usually do at least 20 characters since the password will just sit in a script anyway.

Move the keys to some other safe place so that they can’t be lost. No key means the backups are worthless. Typically a second backup source is a good idea.

$ tar cf gpg_keys.tar .gnupg/
$ chmod 600 gpg_keys.tar

See sample scripts below for backup jobs.


Sample Backup Scripts

The first portion of the script defines the variables we’ll need to use. The AWS keys are defined for you when you sign up for S3. Passphrase is the GPG passphrase set on the key generated from gpg –gen-key. The S3 bucket should be fairly unique, so I use the host name of the server. The others are pretty obvious but will be explained later.

#!/bin/sh

# Variables
export AWS_ACCESS_KEY_ID=ABABAB3333338888WWWW
export AWS_SECRET_ACCESS_KEY=BBBBBBBBBBTTTTTTTTTT8888888888VVVVVVVVVV
export PASSPHRASE=somelongpassphrase
DBHOST='dbserver1'
TIMESTAMP=`date +%m%d%Y%H%M`
FILE_PREFIX_DB='mydb_'
FILE_PREFIX_SVN_REPO='repo_'
GPG_PUB_KEY='AAEE66BB'
BACKUP_LOG_FILE='/home/dpbackup/log/s3_backup.log'
FULL_IF_OLDER_THAN='7D'
KEEP_MAX_SETS='2'
S3_BUCKET='serverhostname'
CURRENT_HOST='server-hostname'
TO_EMAIL='sysadmin@example.com'

Just some sample backup methods for MySQL or Subversion if needed.

/usr/local/bin/mysqldump -h $DBHOST -u mysql_admin -pmypass mydb > /home/dpbackup/mysql/$FILE_PREFIX_DB$TIMESTAMP.sql
/usr/local/bin/svnadmin dump /home/svn/repo > /home/dpbackup/svn/$FILE_PREFIX_SVN_REPO$TIMESTAMP.svnbk

This is only necessary on OpenBSD since it’s a security feature. We open it up now from 128 and close it back down later.

# Increase open file limit
ulimit -n 1024

Most of these options can be read in the man page of Duplicity, and there are many more to choose from. Basically this backup is going to do a full backup ever 7 days (from the $FULL_IF_OLDER_THAN variable), and use encryption with the highest bzip compression, before sending it to S3. It will write a fresh backup log to the defined file, which we’ll email out later.

# Backup to S3
/usr/local/bin/duplicity --s3-use-new-style --tempdir /home/dpbackup --full-if-older-than $FULL_IF_OLDER_THAN --encrypt-key "$GPG_PUB_KEY" --sign-key "$GPG_PUB_KEY" --gpg-options='--compress-algo=bzip2 --bzip2-compress-level=9' --include /etc/apache2 --include /home/dpbackup/svn --include /home/dpbackup/mysql --exclude '**' / s3+http://$S3_BUCKET > $BACKUP_LOG_FILE

This line just gives us some space in the log file; really it’s just for email formatting.

# Separate the log file a bit
echo -e '\n\n==== REMOVE OLD BACKUP SETS ====\n\n' >> $BACKUP_LOG_FILE

This command will check how many full backup sets are already on S3, and remove any more than what is defined in KEEP_MAX_SETS.

# Clean out backup sets older than variable sets
/usr/local/bin/duplicity remove-all-but-n-full $KEEP_MAX_SETS s3+http://$S3_BUCKET >> $BACKUP_LOG_FILE

Again, for formatting purposes.

# Separate the log file a bit
echo -e '\n\n==== CURRENT FILES IN BACKUP SET  ====\n\n' >> $BACKUP_LOG_FILE

This command lists out the current files in our backup set so they can be reviewed in the email, making sure everything is working out it should.

# List all files in backup set for verification
/usr/local/bin/duplicity list-current-files s3+http://$S3_BUCKET >> $BACKUP_LOG_FILE

Now we can mail out the log file. The -s flag is for the subject line, and the TO_EMAIL is defined in our variables. We’re just writing the log file as the body of the email.

# Mail out log to sysadmins for verification
mail -s "$CURRENT_HOST Backup Log for $TIMESTAMP" $TO_EMAIL < $BACKUP_LOG_FILE

Since we exported the keys and passphrases, we want to make sure we don’t leave those around any longer than we have to; set them null.

# Clear secret variables
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export PASSPHRASE=

Just a little clean up so we don’t waste space.

# Remove old and temporary files
rm /home/dpbackup/mysql/*
rm /home/dpbackup/svn/*

This is for OpenBSD only. Since we opened the open file limit up at the beginning of the script, close it back down.

# Put open file limit back to default
ulimit -n 128

End it.

# Exit
exit 0

Slackware 13 on Lenovo T61, Trackpad and scrolling

Out of the box the trackpad didn’t scroll or have “click” capability. Just creating these two files fixed the issue.

/etc/hal/fdi/policy/x11-synaptics.fdi

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
        <merge key="input.x11_options.SHMConfig" type="string">true</merge>
        <merge key="input.x11_options.TapButton1" type="string">1</merge>
        <merge key="input.x11_options.MaxTapMove" type="string">2000</merge>
        <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge>
    </match>
  </device>
</deviceinfo>

/etc/hal/fdi/policy/mouse-wheel.fdi

<match key="info.product" string="TPPS/2 IBM TrackPoint">
  <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
  <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
  <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge>
  <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
  <merge key="input.x11_options.EmulateWheelTimeout" type="string">200</merge>
</match>

Reboot and give it a try.

QuickBooks Enterprise Install on Debian

Operating System: Debian Lenny 5.0

This server needs an /opt directory for the package install, so the partitioning is a little bit different than a typical Linux setup. This is what mine ended up looking like:

Filesystem Size Mounted on
/dev/sda1 2G /
/swap X /swap
/dev/sda9 (rest) /home
/dev/sda6 2G /opt
/dev/sda7 1G /tmp
/dev/sda5 3G /usr
/dev/sda8 2G /var

Setup a few packages necessary for the server first.

apt-get install samba gamin alien

Now users and groups need to be added for permissions and the Samba folder share access.

groupadd quickbooks
useradd -d /home/user1 -g quickbooks user1
useradd -d /home/user2 -g quickbooks user2
useradd -d /home/user3 -g quickbooks user3
useradd -d /home/user4 -g quickbooks user4
smbpasswd -a user1
smbpasswd -a user2
smbpasswd -a user3
smbpasswd -a user4

Create the folder where the QuickBooks data files will be stored and set the appropriate permissions.

mkdir /home/qbdata
chown user1:quickbooks /home/qbdata/
chmod 775 /home/qbdata/

Now configure Samba by moving the built in configuration and writing your own.

cd /etc/samba
mv smb.conf smb.conf.orig
cp smb.conf.orig smb.conf
vi smb.conf

The configuration file should read:

[global]
   workgroup = WORKGROUP
   server string = %h server
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes

[qbdata]
   path = /home/qbdata
   comment = Quickbooks Enterprise database share
   valid users = user1,user2,user3,user4
   public = no
   writeable = yes
   printable = no
   create mask = 0765

Now restart Samba and test the permissions using a Windows client. You should be able to see the logs created by each client and who was accessing the share.

/etc/init.d/samba restart
tail /var/log/samba/log.smbd
tail /var/log/samba/log.rst-win-utl3

Using Alien, we’ll create a deb package from an rpm so it can be installed. Some other directories and files need to be created for logging purposes since Debian uses rsyslog and QuickBooks won’t create them on its own.

cd /usr/src
wget http://http-download.intuit.com/http.intuit/CMO/qbes/resources/qbdbm-20.0-5.i386.rpm
alien qbdbm-20.0-5.i386.rpm
mkdir /var/lock/subsys
dpkg -i qbdbm_20.0-6_i386.deb
touch /var/log/qbdbfilemon.log
touch /var/log/qbdbmgrn_20.log
touch /var/lock/subsys/qbdbfilemon
touch /var/lock/subsys/qbdbmgrn_20

We need to add a line to the syslog configuration in /etc/rsyslog.conf, just put it at the end.

daemon.*                        -/var/log/qbdbfilemon.log

Setup the QuickBooks binaries to startup automatically.

update-rc.d qbdbfilemon defaults
update-rc.d qbdbmgrn_20 defaults

Modify the file /opt/qb/util/qbmonitord.conf in include the directory where the QuickBooks data will live.

/home/qbdata

Restart the server and you should be able to run a ps -e and see the following processes running indicating the server is up. There also should be a /home/qbdata/qbdir.dat file created automatically.

 1987 ?        00:00:01 qbmonitord
 1994 ?        00:00:02 gam_server
 1995 ?        00:25:40 QBDBMgrN_20

Slackware 13 on Lenovo T61, Intel Wireless 4965

I had some trouble getting the wireless to function properly on my T61 with Slackware 13. I tried combinations of wicd (the wireless network manager) and DHCP clients, different drivers, but nothing seemed to work. I could see the wireless points, but they always showed up as “hidden” and appear to connect, but would dever be able to get an IP address.

At this point I moved to Debian to see if that would connect using wicd. Sure enough, wicd connected and authenticated fine, but a kernel panic in Lenny using that wireless adapter would only leave it connected for about 5 minutes and then lock. Enough of that.

Back to Slackware. One thing I noticed was that Debian used the latest wicd, version 1.6.2.2 where the Slackware extras includes the 1.6.2.1 Slackware package. Even the wicd site recommends using the included package in the extras.

Slackware also came with the same firmware for the 4965 wireless as Debian, so I know if I used that, I should be good to go on that end. First, enable the firmware as root:

modprobe iwl4965

Restart your computer and make sure the wireless adapter is loading properly on boot. You should be able to do an lsmod | grep iwlagn and see a few lines with the module enabled. Now grab wicd 1.6.2.2 from source; you can view them here: http://sourceforge.net/projects/wicd/files/. Unpack it and install wicd.

cd /usr/src
wget http://sourceurl/wicd-1.6.2.2.tar.gz
tar zxvf wicd-1.6.2.2.tar.gz
cd wicd-1.6.2.2
python setup.py configure
python setup.py install

You can check /etc/rc.d and find a rc.wicd executable. This means the daemon should start on it’s own when booting. Start the wicd daemon and then the curses version of the client.

wicd
wicd-curses

The curses GUI is pretty easy to understand and you should be able to configure the network no problem. When you hit Shift+C to connect to an AP, you can see that it will authenticate and grab an IP this time…finally. I’ve been able to connect to WPAv2 and WPAv1. Previously I could connect to neither, although I never tried plain old WEP. Others clamined WEP would work and WPA would not, but not being able to connect to a WPA network was a big show stopper for me.

Backing up Subversion to FTP

Handy little script for backing up Subversion to an FTP server.

#!/bin/sh

# Variables

HOST='server.local.com'
USER='unixbackup'
PASSWD='mypass'
TIMESTAMP=`date +%m%d%Y%H%M`
FILEPRE='egsvn_'

# Backup EG repository
/usr/local/bin/svnadmin dump /usr/home/svn > /home/me/svn_backups/$FILEPRE$TIMESTAMP

# FTP backup to tape server
cd /home/me/svn_backups
ftp -n $HOST > /tmp/ftp.worked 2> /tmp/ftp.failed
<<END_SCRIPT
quote USER $USER
quote PASS $PASSWD
binary
put $FILEPRE$TIMESTAMP
quit
END_SCRIPT

# Remove old files
rm /home/me/svn_backups/*

# Exit
exit 0

Configuring Sendmail

Operating System: OpenBSD 4.4

Sendmail is configured and enabled by default in OpenBSD, but it only allows you to send mail out from the machine itself (on localhost, as it should). These steps will allow you to relay from the server and set relay restrictions.

As root, make a copy of the original localhost config file to one of your own.

cd /usr/share/sendmail/cf
cp openbsd-localhost.mc openbsd-myconfig.mc

Open the file you just created and comment out the line:

FEATURE(`accept_unresolvable_domans')dnl

by adding dnl to the the front to read

dnlFEATURE(`accept_unresolvable_domans')dnl

Then modify this line so that Sendmail will listen on all interfaces rather than just local:

DAEMON_OPTIONS(`Family=inet, address=127.0.0.1, Name=MTA')dnl

to read…

DAEMON_OPTIONS(`Family=inet, address=0.0.0.0, Name=MTA')dnl

Now compile the configuration that you created and make it the default Sendmail config:

m4 ../m4/cf.m4 openbsd-myconfig.mc > /etc/mail/sendmail.cf

Open /etc/mail/relay-domains and add IP addresses/ranges that are allowed to relay through the server. The format used is: 192.168.1 which is equivalent to 192.168.1.0/24. This will allow other hosts on your network to relay mail through this server.

Modify /etc/rc.conf and replace:

sendmail_flags="-L sm-mta -C/etc/mail/localhost.cf -bd -q30m";

with…

sendmail_flags="-L sm-mta -C/etc/mail/sendmail.cf -bd -q2d"

This will tell the flags to use our newly created .cf file we compiled earlier. I usually change the q30m (which means keep things in the queue for 30 minutes) to q2d, keeping the queue active for 2 days before ditching it.

Do a clean reboot and make sure the correct configuration comes up. You can test access by using a server with the same subnet as in your “relay-domains” file and telnet-ing to port 25.

You can restart Sendmail quickly by killing the process first…

kill `head -n1 /var/run/sendmail.pid`

…and then restarting:

. /etc/rc.conf
/usr/sbin/sendmail $sendmail_flags

Subversion – Installation, Configuration, and Use

Operating System: OpenBSD 4.4


Installation

First grab the necessary compiled packages from OpenBSD.

export PKG_PATH=ftp://carroll.cac.psu.edu/pub/OpenBSD/4.4/packages/amd64
pkg_add db-4.6.21.tgz neon-0.26.2.tgz

Then get the Apache source code for the HTTP server, configure and install. Use a 2.2.x version.

cd /usr/src
http://www.gtlib.gatech.edu/pub/apache/httpd/httpd-2.2.x.tar.gz
tar zxvf httpd-2.2.x.tar.gz
cd http-2.2.x
./configure --with-included-apr --with-berkeley-db=/usr/local --enable-shared=yes --enable-dav --enable-so --enable-rewrite --enable-ssl
make
make install

Next get the newest Subversion source code, configure and install.

cd /usr/src
wget subversion-1.5.x.tar.gz
tar zxvf subversion-1.5.x.tar.gz
cd subversion-1.5.x
./configure --with-apr=/usr/local/apache2/bin/apr-1-config --with-apxs=/usr/local/apache2/bin/apxs --with-neon=/usr/local

Add the proper user to run the httpd daemon

useradd -u3690 -g=uid -c"Apache2" -d/var/empty -s/sbin/nologin _apache2

Configuration

Setup the initial repository with the svncreate command and make the user running the web service the owner, since they will be the user actually modifying the repository files.

mkdir /home/svn
svnadmin create /home/svn/myproject
chown -R _apache2:_apache2 /home/svn/

Now edit your main httpd.conf file in /usr/local/apache2/conf/ to read these changes. They’re not all in the same place, just scattered throughout the file. The first two changes should already be there after installing the Subversion source, just require slight modification. The last “location” change you’ll need to add manually. You’ll see the dav_svn* files in there, we’ll get to those next.

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
...
User _apache2
Group _apache2
...
<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath /home/svn
    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /etc/svn/dav_svn.passwd
    AuthzSVNAccessFile /etc/svn/dav_svn.control
    Require valid-user
</Location>

Now we can create the username/password files along with the access files.

mkdir /etc/svn
touch /etc/svn/dav_svn.passwd
htpasswd -mb /etc/svn/dav_svn.passwd myuser mypassword

Create the access file to your repositories.

touch /etc/svn/dav_svn.control

And now edit the file. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

[myproject:/]
myuser = r

[myproject:/trunk/base/code]
myuser = rw

Naturally you’ll want to lock this service down with SSL and possibly make it available outside the network. To simply create a self-signed certificate and add it to Apache, do the following.

openssl genrsa -out /etc/ssl/private/svnserver.key 1024
openssl req -new -key /etc/ssl/private/svnserver.key -out /etc/ssl/private/svnserver.csr
openssl x509 -req -days 365 -in /etc/ssl/private/svnserver.csr -signkey /etc/ssl/private/svnserver.key -out /etc/ssl/svnserver.crt

Now add the lines in the httpd.conf file in /usr/local/apache2/conf/ just about the Location setting.

Listen 443
SSLEngine on
SSLCertificateFile    /etc/ssl/svnserver.crt
SSLCertificateKeyFile /etc/ssl/private/svnserver.key

Edit the rc.conf.local file in /etc/ to turn on Apache.

apache2=YES

And then edit the rc.local file to auto start Apache.

# Apache2 Startup
if [ X"${apache2}" == X"YES" -a -x /usr/local/apache2/bin/httpd ]; then
   /usr/local/apache2/bin/apachectl start &amp;
   echo -n " apache2";
fi

As well as the shutdown file rc.shutdown to kill the process.

# Apache2 Shutdown
if [ X"${apache2}" == X"YES" -a -x /usr/local/apache2/bin/httpd ]; then
   /usr/local/apache2/bin/apachectl stop &amp;
   echo -n " apache2";
fi

Now reboot the server and test access; it should start up automatically.


Maintenance and Use

The best way to use SVN over HTTPS is with Tortoise for Windows or some other tool if using Linux, like RapidSVN.

Adding Additional Users

To add more users, just run the htpasswd command linked to your dav_svn.passwd file, same as the initial configuration for users.

htpasswd -mb /etc/svn/dav_svn.passwd newuser newpassword

And now edit the access file containing the other users and defined in the Apache configuration. You can set users using r and rw access writes. First you list the repository, and then the folder location after that for more fine grained permissions.

[myproject:/]
myuser = r
newuser = r

[myproject:/trunk/base/code]
myuser = rw
newuser = rw

Backing Up the Repositories

To backup a repository, use the svnadmin dump command which will export the entire database and revisions. You can then tar up and gzip the dump file for compression, and back it up to tape or disk somewhere else. There are also incremental backups that can be done of disk/tape space is an issue.

svnadmin dump /home/svn/myproject > /home/backups/myproject_dumpfile

Restoring the Repositories

Restoring the SVN database is simply rewriting all the revisions from the dump back into a database. The restore process also works well for moving an older repository over to a new one since restoring the dump into a new SVN database will update it to that version.

svnadmin create /home/svn/restoredproject
svnadmin load /home/svn/restoredproject < /home/backups/myproject_dumpfile

OpenVPN – Installation and Configuration

Operating System: Debian Etch 4.0


Install and Key Generation

First we just need to grab the primary packages from the repos and install. Make sure you’re root.

apt-get install openvpn openssl

Next find the easy-rsa directory, and copy those files over to the OpenVPN configuration directory so we can setup a certificate.

cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/

Now in the /etc/openvpn directory open up the vars file and make some edits that suit you. I only made changes to the very end of the file.

export KEY_SIZE=2048 export KEY_COUNTRY=US export KEY_PROVINCE=NA export KEY_CITY=mycity export KEY_ORG="My Company" export KEY_OU="Operations" export KEY_CN="CommonName" export KEY_EMAIL="sysadmin@test.com"

Save this file. Then run:

. ./vars

Yeah, there’s a dot, a space, and then another dot in there. Then these commands:

./clean-all
./build-ca

You’ll be asked the cert questions, but most of the defaults should be filled in for you since you manually entered them in the vars file. Now build the server key:

./build-key-server myserver

You’ll be asked the same type of questions, but for common name you need to enter something. “Server” is the default. Run this next command, which will take awhile.

./build-dh

Then generate your TLS-AUTH keys:

cd keys
openvpn --genkey --secret ta.key

Now create a key directory closer to the root folder to stay organized and copy the necessary keys there:

mkdir -m 0700 /etc/openvpn/keys
cp ca.crt ../../keys
mv dh2048.pem ta.key myserver.crt myserver.key ../../keys

Server Config File

My server configuration is located in /etc/openvpn/server.conf. It’s what worked for me. The 172.21.0.0 subnet is the virtual one used by the VPN. The 10.10.0.0 subnet is the LAN I’m trying to connect to.

dev tun
port 1194
proto udp
server 172.21.0.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 10.10.0.0 255.255.255.0"
max-clients 10
user nobody
group nogroup
duplicate-cn

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/myserver.crt
key /etc/openvpn/keys/myserver.key
dh /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0

keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 4

More info on configuration options is here: http://openvpn.net/howto.html. You’ll also have to enable packet forwarding so packets can flow from the VPN interface to the ethernet interface. Open the file /etc/sysctl.confand uncomment this line:

net.ipv4.conf.default.forwarding=1

Restart the server.


Setup the Revocation List

Now setup a revocation list so you can block certificates and users that you create. Execute your variables again.

cd /etc/openvpn/easy-rsa
. ./vars

I had to modify my openssl configuration and repoint to my openvpn directory.

cd /usr/lib/ssl
mv openssl.cnf openssl.cnf.old
ln -s /etc/openvpn/easy-rsa/openssl.cnf openssl.cnf

Edit the config file openssl.cnf at the end and comment out the pkcs11 section if you’re not using it, otherwise it will throw errors. Then create your CRL:

cd keys
openssl ca -gencrl -keyfile ca.key -cert ca.crt -out \ crl.pem

User Configuration

Now create your first user:

./build-key-pass user1

Answer the same prompts and give it a password. If you don’t want to use a password, just use build-key instead. Restart the OpenVPN server for it to read the config:

/etc/init.d/openvpn restart

Now, on the client machine run the same install commands (assuming you’re using an Ubuntu or Debain box) and create a keys directory:

apt-get install openvpn openssl
mkdir /etc/openvpn/keys

Copy the keys ca.crt, user1.crt, user1.key, and ta.key into the keys directory and then create a file called client.conf in the /etc/openvpn directory. Be sure you restrict access and lock down the keys directory, since compromise of these files will give someone else access.

Here’s my config:

client
dev tun
proto udp
remote myserver.site.com 1194
nobind
user nobody
group nogroup

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/user1.crt
key /etc/openvpn/keys/user1.key
tls-auth /etc/openvpn/keys/ta.key 1

comp-lzo persist-key
persist-tun
log /var/log/openvpn/openvpn.log
verb 4
ns-cert-type server

You can get more info on the configuration here: http://openvpn.net/howto.html. Now start up the VPN:

openvpn /etc/openvpn/client.conf

You can check the logs for errors, but in a few seconds, if you run an ifconfig, you can see a tun0 device has been created and has one of the virtual IP addresses. You can then ping the remote VPN server’s inside address for testing.


Routing Issues

In my situation, my VPN server was not the default gateway on my LAN, so I had to add some permantent routes to my clients so they could find their way back through the tunnel and to my remote client. For Linux boxes use:

route add -net 172.21.0.0 netmask 255.255.255.0 gw 10.10.0.5

And on Windows use:

route -p add 172.21.0.0 mask 255.255.255.0 10.10.0.5 metric 10

Adding and Removing Other Users

When you need to add new users or client certificates, simply run:

cd /etc/openvpn/easy-rsa
. ./vars
./pkitool client2

This will generate the keys for the new client to copy down to their machine, just the same as the initial client.

Removing users is easy as well.

cd /etc/openvpn/easy-rsa
. ./vars
./revoke-full client2

You may see a bunch of error 23′s at the end, but that’s normal and just testing that the certificate does not have access anymore.

Return top