Where I went wrong is that I deleted the sp_timer account out of Active Directory before I removed it from Configure managed accounts. It seems that SharePoint should be able to handle this change, but it doesn't. Create the domain account that you removed in Active Directory again. Then open up SharePoint 2010 Management Shell, and be sure to open it As Administrator. The following commands will remove the account from the list of managed accounts:

Now you should be able to load the Central Administration web pages that were giving errors before properly. Feel free to remove the old account from Active Directory.

• mode=0 (balance-rr) Round-robin policy: Transmit packets in sequential order from the first available slave through the last. This mode provides load balancing and fault tolerance.
• mode=1 (active-backup) Active-backup policy: Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond’s MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides fault tolerance. The primary option affects the behavior of this mode.
• mode=2 (balance-xor) XOR policy: Transmit based on source MAC address XOR'd with destination MAC address. This selects the same slave for each destination MAC address. This mode provides load balancing and fault tolerance.
• mode=3 (broadcast) Broadcast policy: Transmits everything on all slave interfaces. This mode provides fault tolerance.
• mode=4 (802.3ad) IEEE 802.3ad Dynamic link aggregation: Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification. Ethtool support in the base drivers for retrieving the speed and duplex of each slave. A switch that supports IEEE 802.3ad Dynamic link aggregation. Most switches will require some type of configuration to enable 802.3ad mode.
• mode=5 (balance-tlb) Adaptive transmit load balancing: Channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed receiving slave. Ethtool support in the base drivers for retrieving the speed of each slave.
• mode=6 (balance-alb) Adaptive load balancing: Includes balance-tlb plus receive load balancing (rlb) for IPV4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the slaves in the bond such that different peers use different hardware addresses for the server.

Once you choose your team method, install the ifenslave package

Now open the file /etc/network/interfaces and add the bonded interface:

Note that bond_mode is the teaming option you selected above. You can restart the networking service, or just reboot the server to ensure the team comes up after shutdown.

• Apache Configuration
• Nagios Install
• Prerequisites
• Install
• Configuration
• Third Party Tools
• Plugins
• NRPE
• PNP Graphing
• General Use

Apache Configuration

First install the essential packages needed to compile and use Nagios.

Modify the file /etc/apache2/apache2.conf so that it's a bit cleaner.

Now create the Apache configuration file for Nagios so it can load the web interface. Create the file /etc/apache2/conf.d/nagios.conf with the following:

Modify /etc/apache2/ports.conf to have just one line to listen for SSL:

Modify /etc/apache2/mods-available/ssl.conf to clean up the SSL configuration, we'll enable this later.

Create the file /etc/apache2/sites-available/nagios-ssl for the virtual directory routing information.

Modify the file /etc/apache2/httpd.conf so it has just one line:

Now we can enable our modules and sites in Apache.

Now create a self signed certificate to use for the site, or a third party if necessary.

Nagios Install

Prerequisites

Setup our users and groups that will run Nagios. Note that the www-root user is specific to Debian since that user runs the Apache web process:

Now setup the initial directories and permissions where we'll keep the files. I chose to create /var/nagios because that's where I'll store the data files since it's the largest partition and meant for variable data.

Download the Nagios source and unpack.

Install

Configure and build Nagios for the proper directories and options.

Set Nagios to start on boot and set the password Apache file to authenticate users.

To add more users to the htpasswd.users file just type

since the -c is only for file creation.

Configuration

Edit the file /etc/nagios/cgi.cfg and modify any "authorized" line to include the users you created in the htpassswd.users file, for example:

Create a folder in /etc/nagios to contain all the configuration files. Typically the site name is a good choice. Once the folder is created, modify the file /etc/nagios/nagios.cfg and remove all the "cfg_file" entries and add the line:

Or whatever folder you created for your config files, site1 in this example.

Now add some images for icon view to the base install. These packs can usually be downloaded from the Nagios Exchange.

Third Party Tools

Plugins

The Nagios plugins are necessary to run checks on server processes and health. In the configure statement, be sure to use the same folder locations as when Nagios itself was configured. Plugins will be installed in the /usr/local/nagios/libexec directory.

NRPE

This install adds the NRPE plugin so that checks can be done on other servers securely and remotely. The NRPE client/server doesn't need to be installed on the Nagios server; it just needs the plugin to run the checks. The remote servers of course need the NRPE client installed. Again, take note of the configure directors and that --enable-ssl=yes is set to yes. This allows for a secure SSL handshake.

PNP Graphing

A couple packages are needed first as well as mod_rewrite for Apache:

Open /etc/php5/apache2/php.ini and make sure the following is set to Off:

Then restart Apache to have the setting take effect:

Download, configure and install PNP. Note directory locations in configure.

Setup the base configuration:

Edit /etc/nagios/nagios.cfg to turn on some switches and make performance data go to PNP. Typically these are commented out to start.

Add the new command to commands.cfg in /etc/nagios/site1 or wherever your commands for the site are stored:

Modify /etc/apache2/conf.d/pnp4nagios.conf to include the same password file that Nagios uses. This file is created by the install scripts.

Restart Apache for the changes to take effect. You can now navigate to https://hostname/pnp4nagios and see the install checklist. If all is complete, remove the /usr/local/pnp4nagios/share/install.php file.

General Use

For Nagios to function, it first needs to be started with this command:

If a configuration or syntax error in your configuration occurs, you can test the output and find out where it is by running this command:

Now you can try starting Nagios again. If you make configuration changes, the configuration must be reloaded. Do this use:

To access Nagios through the web, Apache must be started, or restarted if it already was running. This will also accept the new web configurations that may have been made:

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.

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.

• Installation
• Configuration
• Maintenance and Use

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.

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:

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:

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:

Configuration

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

Now enable the site and start/restart Apache:

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.

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

Create the access file to your repositories.

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.

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.

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.

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.

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.

• Installation on OpenBSD 4.4
• Installation on OpenBSD 4.6
• Installation on Debian Lenny 5.0
• Sample Backup Scripts

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.

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:

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

Now we can install Duplicity.

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:

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.

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.

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.

See sample scripts below for backup jobs.

Installation on OpenBSD 4.6

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.

Now we can install Duplicity.

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:

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.

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.

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.

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:

Install Duplicity:

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

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.

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.

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.

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

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.

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.

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

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.

Again, for formatting purposes.

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.

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.

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.

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

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

End it.

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

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

Reboot and give it a try.

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:

Setup a few packages necessary for the server first.

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

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

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

The configuration file should read:

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.

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.

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

Setup the QuickBooks binaries to startup automatically.

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

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.

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:

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.

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.

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.