<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>botsko &#187; Hosting</title>
	<atom:link href="http://www.botsko.net/blog/category/hosting/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.botsko.net/blog</link>
	<description>continuing education</description>
	<lastBuildDate>Sat, 24 Jul 2010 21:42:29 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Correcting CGI Perl Module for Bugzilla 3.4.2</title>
		<link>http://www.botsko.net/blog/2009/12/30/correcting-cgi-perl-module-for-bugzilla-3-4-2/</link>
		<comments>http://www.botsko.net/blog/2009/12/30/correcting-cgi-perl-module-for-bugzilla-3-4-2/#comments</comments>
		<pubDate>Thu, 31 Dec 2009 00:27:07 +0000</pubDate>
		<dc:creator>Michael Botsko</dc:creator>
				<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Software]]></category>

		<guid isPermaLink="false">http://www.botsko.net/blog/?p=474</guid>
		<description><![CDATA[I was recently installing Bugzilla on a new server and ran into problems with the CGI perl module from CPAN being too recent. Apparently, version 3.47 has some issues, so I had to downgrade to 3.45. Bugzilla recommends that you use their installer when the checksetup.pl script spits out missing modules. However, if you encounter [...]]]></description>
			<content:encoded><![CDATA[<p>I was recently installing Bugzilla on a new server and ran into problems with the CGI perl module from CPAN being too <em>recent</em>. Apparently, version 3.47 has some issues, so I had to downgrade to 3.45.</p>
<p>Bugzilla recommends that you use their installer when the checksetup.pl script spits out missing modules. However, if you encounter problems or need older version, this won&#8217;t work.</p>
<p>However, their own script makes a copy of the CGI.pm file inside of the bugzilla libs/ directory.</p>
<p>In order to solve the issue, you need download and install the proper version, but then copy of the file to the bugzilla libs folder.</p>
<p><code><br />
$ wget http://search.cpan.org/CPAN/authors/id/L/LD/LDS/CGI.pm-3.45.tar.gz<br />
$ tar -xzvf CGI.pm-3.45.tar.gz<br />
$ cd CGI*<br />
$ perl Makefile.PL<br />
$ make<br />
$ make install<br />
$ cp /usr/lib/perl5/5.8.8/CGI.pm /var/www/vhosts/trellisdev.com/subdomains/bugs/httpdocs/lib/CGI.pm<br />
</code></p>
<p>Then, continue with your checksetup.pl process as usual.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.botsko.net/blog/2009/12/30/correcting-cgi-perl-module-for-bugzilla-3-4-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MediaTemple E-mail Logs&#8230;</title>
		<link>http://www.botsko.net/blog/2007/11/06/mediatemple-e-mail-logs/</link>
		<comments>http://www.botsko.net/blog/2007/11/06/mediatemple-e-mail-logs/#comments</comments>
		<pubDate>Tue, 06 Nov 2007 19:36:49 +0000</pubDate>
		<dc:creator>Michael Botsko</dc:creator>
				<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Tech-Tidbit]]></category>

		<guid isPermaLink="false">http://www.botsko.net/blog/2007/11/06/mediatemple-e-mail-logs/</guid>
		<description><![CDATA[I&#8217;m always forgetting this command so I&#8217;m posting it here. This is the location of the mail log on mediatemple dv servers. tail -f /usr/local/psa/var/log/maillog]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m always forgetting this command so I&#8217;m posting it here. This is the location of the mail log on mediatemple dv servers.</p>
<p>tail -f /usr/local/psa/var/log/maillog</p>
]]></content:encoded>
			<wfw:commentRss>http://www.botsko.net/blog/2007/11/06/mediatemple-e-mail-logs/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Tech-Tidbit: Checking a sendmail queue</title>
		<link>http://www.botsko.net/blog/2007/04/03/tech-tidbit-checking-a-sendmail-queue/</link>
		<comments>http://www.botsko.net/blog/2007/04/03/tech-tidbit-checking-a-sendmail-queue/#comments</comments>
		<pubDate>Tue, 03 Apr 2007 15:41:20 +0000</pubDate>
		<dc:creator>Michael Botsko</dc:creator>
				<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Tech-Tidbit]]></category>

		<guid isPermaLink="false">http://www.botsko.net/blog/2007/04/03/tech-tidbit-checking-a-sendmail-queue/</guid>
		<description><![CDATA[I recently had to research the source of some email issues which required me to check what may still be in a queue for sendmail. Since the source of the email was PHP, which was using the default mail method, the emails would be going through sendmail. To check the queue, I used: # mailq [...]]]></description>
			<content:encoded><![CDATA[<p>I recently had to research the source of some email issues which required me to check what may still be in a queue for sendmail. Since the source of the email was PHP, which was using the default mail method, the emails would be going through sendmail.</p>
<p>To check the queue, I used:</p>
<p><code><br />
# mailq<br />
</code><br />
(this checks /var/spool/mqueue, the primary queue)</p>
<p><code><br />
# mailq -Ac<br />
</code><br />
(this checks /var/spool/clientmqueue, which may or not be used on your server)</p>
<p>Unfortunately my queues were empty, but these commands will be very helpful to me in the future.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.botsko.net/blog/2007/04/03/tech-tidbit-checking-a-sendmail-queue/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Optimizing ProFTPD Login/Transfer Speed</title>
		<link>http://www.botsko.net/blog/2006/11/07/optimizing-proftpd-logintransfer-speed/</link>
		<comments>http://www.botsko.net/blog/2006/11/07/optimizing-proftpd-logintransfer-speed/#comments</comments>
		<pubDate>Tue, 07 Nov 2006 23:47:02 +0000</pubDate>
		<dc:creator>Michael Botsko</dc:creator>
				<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Tech-Tidbit]]></category>

		<guid isPermaLink="false">http://www.botsko.net/blog/?p=134</guid>
		<description><![CDATA[I run ProFTPD on both of my development machines &#8211; one is a Mandrake Linux 10.1 box and one is Fedora Core 5. The FC5 machine was recently setup as I needed a devoted PHP5 development machine, but the ftp server was taking up to three seconds per directory to perform an action. I needed [...]]]></description>
			<content:encoded><![CDATA[<p>I run ProFTPD on both of my development machines &#8211; one is a Mandrake Linux 10.1 box and one is Fedora Core 5. The FC5 machine was recently setup as I needed a devoted PHP5 development machine, but the ftp server was taking up to three seconds per directory to perform an action. I needed to transfer some client code and it took about ten minutes just scan through all of the directories &#8211; this was completely unaccpetable.</p>
<p>I was curious as to what the differences were between the two machines &#8211; one worked very quickly and one did not. After a bit of a searching I discovered a few tweaks that solved all of the problems:</p>
<p>Adding the following to the config file really sped up the login process:</p>
<pre class="brush: xml;">
IdentLookups off
UseReverseDNS off
</pre>
<p>However, my directory listings were still running slowly. When I added:</p>
<pre class="brush: xml;">

AllowOverride off
</pre>
<p>To the global config file, it told ProFTPD to stop looking for an .ftpaccess file in every single directory.</p>
<p>Once I restarted the server, things were blazing along. All it took were a few minor changes to be back in business!</p>
<pre />
]]></content:encoded>
			<wfw:commentRss>http://www.botsko.net/blog/2006/11/07/optimizing-proftpd-logintransfer-speed/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
