2011/02/23

Setting up the atftpd server on Debian Squeeze

I have recently had some issues trying to use tftpd server in conjunction with some of my Cisco equipment.  I kept getting these errors regardless of actual permissions on the system:

%Error opening tftp://192.168.130.6/c1841-ipbase-mz.124-1c.bin (Permission denied)

So I uninstalled that and installed the atftpd server package.  That seemed to do the trick.  I did have to change the default directory as I did already have a directory full of IOS files that I was just too lazy to move where the maintainers think I should put it.  So here are the steps I took to get things working.

1. Install the atftpd package from the repository.

apt-get install atftpd


2. Add this line into /etc/inetd.conf:

tftp dgram udp4 wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /tftpboot


3. Create /tftpboot directory and change permissions to allow writing to the directory.

mkdir /tftpboot
chmod 777 /tftpboot

4. Restart the inetd server.  To restart the server on Debian run:

/etc/init.d/openbsd-inetd restart


After I followed those steps I was able to connect to the server from my Cisco equipment and transfer files both ways.  

You may want to disable the server when you are not actively using it.  To do this comment out the line you added to /etc/inetd.conf and restart or stop inetd.


2011/02/09

Changing umask setting for all users

In order to have the umask setting change for all users at login the umask setting in /etc/profile needs to be changed.

1. Use text editor to edit /etc/profile. *Note: You need root access to edit this file.

sudo nano -w /etc/profile

2. Edit the umask line located at the end of the file. *Note: This example is setting the umask to allow the owner and group have read/write while others have no permissions.

umask 007

3. Type in Crtl-XY, and hit the Enter key to save and exit.

2011/02/08

Changing Subversion revision times

Occasionally revision entries in Subversion will not have a time/date included in the entry.  In my experience they are not entered when filtering information from other repositories or converting other types of version control data to Subversion.  If you are using Apache2 to handle the authentication errors will appear on the server's /var/log/httpd/error_log that look like this one:

[Thu Jan 13 07:31:32 2011] [error] [client 192.168.13.89] Could not access revision times.  [500, #0]

*Note* This only appears to be an issue for users and systems that use SVNKit as their Subversion client as most people will still be able to connect with Eclipse and other clients to check in data.  Hudson will usually have the most problems with this.


In order to correct the problem the entries with the missing dates will need to be located.  This is easily done with the following command string which needs to be run on the Subversion server itself.

svn log --xml -v -r {2010-12-01T00:00:00Z}:{2011-01-13T15:00:00Z} file:///svn/repo


If there is any issue related to the time on a revision then the following error will be shown when you run the above command.

<?xml version="1.0"?>

<log>

svn: Failed to find time on revision 34534


The first step in making the necessary corrections is to edit the /svn/repos/mosaic/hooks/post-revprop-change file so that it contains the following information.

#!/bin/sh
exit 0


If the previous steps had not be performed the hook files would have prevented this step from actually occurring. So to make the change to the revision entry the svn command is used on the server itself using the propset subcommand. When entering the date try to select a date that is in between the dates that proceed and follow this revision entry.

svn propset -r34534 --revprop svn:date '2010-11-29T19:55:44.000220Z' file:///svn/repo


If the command is successful then following message will appear.

property 'svn:date' set on repository revision 34534


After that re-run the svn log command to verify there are no further entries that will cause errors. If there are none that the Subversion server are registering then you should see all of the log entries for that time period displayed.  This is not always a positive indication. It has been my experience that Subversion does not always register an error for all missing date entries. The best way to find out if there are any missing date entries is to copy the output of the svn log command to a searchable text document where <date></date> can be searched for.  If there are no other missing dates in the log then the final steps are to reverse the changes made to hook files and return them to their previous state

2011/02/07

Setting InnoDB as the default MySQL Engine

In order to set InnoDB as the default storage engine in MySQL version 5.0.x the process is simple.

Open the my.cnf file in a text editor such as vi.  If the following line is in the config it should be commented out or deleted:

skip-innodb

Add this line under [mysqld] to make InnoDB the default engine:

default-table-type=innodb

Save the file and restart mysqld.

To verify that the default has been changed from MyISAM  to InnoDB login to MySQL and run the following:

show engines;

You should see that InnoDB is now the default.

+------------+---------+----------------------------------------------------------------+
| Engine     | Support | Comment                                                        |
+------------+---------+----------------------------------------------------------------+
| MyISAM     | YES     | Default engine as of MySQL 3.23 with great performance         | 
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      | 
| InnoDB     | DEFAULT | Supports transactions, row-level locking, and foreign keys     | 
| BerkeleyDB | YES     | Supports transactions and page-level locking                   | 
| BLACKHOLE  | NO      | /dev/null storage engine (anything you write to it disappears) | 
| EXAMPLE    | NO      | Example storage engine                                         | 
| ARCHIVE    | NO      | Archive storage engine                                         | 
| CSV        | NO      | CSV storage engine                                             | 
| ndbcluster | NO      | Clustered, fault-tolerant, memory-based tables                 | 
| FEDERATED  | NO      | Federated MySQL storage engine                                 | 
| MRG_MYISAM | YES     | Collection of identical MyISAM tables                          | 
| ISAM       | NO      | Obsolete storage engine                                        | 
+------------+---------+----------------------------------------------------------------+

2011/02/06

Increasing VMware virtual disks in Linux

The process of increasing a VMware virtual disk in Linux is fairly straight forward.  I have VMware Workstation 7 installed and it comes with the tool vmware-vdiskmanager which is what I will use to grow the virtual disk.  To perform a size increase of 300GB run the following command:

vmware-vdiskmanager -x 300GB virtual-disk-name.vmdk

Manually installing Sun JDK in Debian/Ubuntu

In order to manually install the JDK .bin file and change the default Java directory you need to do the following.

1. Download the jdk-****.bin installer (I am using jdk-1.6.0_20-linux-i586.bin) to your download directory (I am using /home/myaccount/downloads)

2. Run:

cd /opt
sudo sh /home/myaccount/downloads/jdk-1.6.0_20-linux-i586.bin

3. Hit the spacebar a few times and type yes when prompted.

4. Run:

update-alternatives --install /usr/bin/java java /opt/jdk1.6.0_20/bin/java 500

update-alternatives --set java /opt/jdk1.6.0_20/bin/java
OR
update-alternatives --config java

**Note: The --set option will not prompt you while the --config option will present you with a list of option.


Changing Hudson Context Path on CentOS

I have recently had to setup Hudson running on a CentOS server as well as some other web based applications.  I found that in order to get Apache to proxy Hudson I had to change the context path for Hudson.

Now I simply used the Hudson repository for RedHat/Fedora/CentOS (http://hudson-ci.org/redhat/) so I didn't just unpack Hudson on the system and go from there.  That being said the installation files were spread across the file system.  The file that needs to be edited in order to change the context path is: /etc/sysconfig/hudson 

To change the context path simply add --prefix=/hudson to the value of that variable like this:

HUDSON_ARGS="--prefix=/hudson"


For more information on setting up Apache to proxy Hudson here are a couple of links that I found helpful though geared toward Ubuntu: