<?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>Memory Leak &#187; linux</title>
	<atom:link href="http://www.foobert.com/blog/tag/linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.foobert.com/blog</link>
	<description>That which fades into the ether.</description>
	<lastBuildDate>Sat, 26 Nov 2011 20:49:12 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
		<item>
		<title>On backups and the importance of testing them</title>
		<link>http://www.foobert.com/blog/2009/01/12/on-backups-and-the-importance-of-testing-them/</link>
		<comments>http://www.foobert.com/blog/2009/01/12/on-backups-and-the-importance-of-testing-them/#comments</comments>
		<pubDate>Mon, 12 Jan 2009 12:04:11 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[Geek-Stuff]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[RTFM]]></category>

		<guid isPermaLink="false">http://www.foobert.com/blog/?p=145</guid>
		<description><![CDATA[<p>I&#8217;d really like the last 18 hours of my life back.</p>
<p>Lesson 1) backups are only as good as your backup strategy.</p>
<p>Lesson 2) your backup strategy is useless if its never been tested to recover from bare metal.</p>
<p>Lesson 3) your ill conceived, unproven backup strategy will bite you. And it will not be for a reason that [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;d really like the last 18 hours of my life back.</p>
<p>Lesson 1) backups are only as good as your backup strategy.</p>
<p>Lesson 2) your backup strategy is useless if its never been tested to recover from bare metal.</p>
<p>Lesson 3) your ill conceived, unproven backup strategy will bite you. And it will not be for a reason that was beyond your control, like say, drive heads screeching on platters. No, it will bite you because of your own stupidity and failure to fully RTFM.  Beware: your ill conceived backup strategy is <em>cunning</em>!  It is most likely to bite you while doing something that might actually result in a more robust backup strategy.</p>
<p>While I&#8217;m not entire sure if this was my undoing, I&#8217;m unable to grok how doing &#8216;<em>grub-install</em>&#8216; on a disk that is not the first BIOS disk does bad things to the disk that *is* the first BIOS disk.  Doesn&#8217;t seam to matter that you told it to go work on /dev/sdX, where X != &#8220;first BIOS disk&#8221;. I&#8217;d like to compare notes if your mileage differs on this point.</p>
<p>No matter &#8212; something happened that really upset the boot-ability of the system. Of course, anaconda was useless in trying to &#8220;rescue&#8221; me. No, no! That would have been too simple.</p>
<p>OK, bed time.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.foobert.com/blog/2009/01/12/on-backups-and-the-importance-of-testing-them/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Notes on my postfix + sasldb + tls settings</title>
		<link>http://www.foobert.com/blog/2008/03/09/notes-on-my-postfix-sasldb-tls-settings/</link>
		<comments>http://www.foobert.com/blog/2008/03/09/notes-on-my-postfix-sasldb-tls-settings/#comments</comments>
		<pubDate>Sun, 09 Mar 2008 11:08:48 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[Geek-Stuff]]></category>
		<category><![CDATA[linux]]></category>

		<guid isPermaLink="false">http://www.foobert.com/blog/2008/03/09/notes-on-my-postfix-sasldb-tls-settings/</guid>
		<description><![CDATA[<p>There&#8217;s a great &#8220;how to&#8221; here.</p>
<p>Some of the key things that I always forget about my setup that haunt me later:</p>

I&#8217;m using sasldb2 (in /etc/sasldb2 )
When using sasldb &#8212; saslauthd daemon DOES NOT RUN. The simple DB file replaces the need for it.
The realm I&#8217;m using in sasldb2 passwords is &#8216;mail.foobert.com&#8217;
Thus, add a password is to [...]]]></description>
			<content:encoded><![CDATA[<p>There&#8217;s a great &#8220;how to&#8221; <a href="http://postfix.state-of-mind.de/patrick.koetter/smtpauth/index.html" target="_blank">here.</a></p>
<p>Some of the key things that I always forget about my setup that haunt me later:</p>
<ul>
<li>I&#8217;m using sasldb2 (in /etc/sasldb2 )</li>
<li>When using sasldb &#8212; saslauthd daemon DOES NOT RUN. The simple DB file replaces the need for it.</li>
<li>The realm I&#8217;m using in sasldb2 passwords is &#8216;mail.foobert.com&#8217;</li>
<li>Thus, add a password is to the db:</li>
</ul>
<blockquote><p>saslpasswd2 -c -u `mail.foobert.com` username</p></blockquote>
<p>Create /etc/sasl2/smtpd.conf</p>
<blockquote><p>pwcheck_method: auxprop<br />
auxprop_plugin: sasldb<br />
mech_list: PLAIN LOGIN</p></blockquote>
<p>Also, when setting up a new Centos or Redhat box, <em>smtpd.conf</em> is looked for in /usr/lib/sasl2/ and not in /etc/sasl2/smptd.conf where some of the &#8220;how-to&#8217;s&#8221; like to mention.  Thus, on my machines, I made a soft-linked to the etc version. Before realizing this, I was seriously befuddled by the following error.</p>
<blockquote><p>Nov 27 16:02:42 pluto postfix/smtpd[20307]: TLS connection established from unknown[166.205.134.32]: TLSv1 with cipher AES128-SHA (128/128 bits)<br />
Nov 27 16:02:43 pluto postfix/smtpd[20307]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory<br />
Nov 27 16:02:43 pluto postfix/smtpd[20307]: warning: SASL authentication failure: Password verification failed<br />
Nov 27 16:02:43 pluto postfix/smtpd[20307]: warning: unknown[166.205.134.32]: SASL PLAIN authentication failed: generic failure<br />
Nov 27 16:02:43 pluto postfix/smtpd[20307]: lost connection after AUTH from unknown[166.205.134.32]<br />
Nov 27 16:02:43 pluto postfix/smtpd[20307]: disconnect from unknown[166.205.134.32]</p></blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.foobert.com/blog/2008/03/09/notes-on-my-postfix-sasldb-tls-settings/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Network tar using SSH</title>
		<link>http://www.foobert.com/blog/2008/02/18/network-tar-using-ssh/</link>
		<comments>http://www.foobert.com/blog/2008/02/18/network-tar-using-ssh/#comments</comments>
		<pubDate>Mon, 18 Feb 2008 10:45:45 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[Geek-Stuff]]></category>
		<category><![CDATA[How-To]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[copy]]></category>
		<category><![CDATA[linux]]></category>

		<guid isPermaLink="false">http://www.foobert.com/blog/2008/02/18/network-tar-using-ssh/</guid>
		<description><![CDATA[<p>Never realized how easy it is to duplicate a directory tree from one machine to another through the network without building an intermediate tarball and finding room for it and the original files all at the same time. Simply pipe the tar command through ssh and untar it on the fly.</p>
<p>For example, suppose we have direcotry [...]]]></description>
			<content:encoded><![CDATA[<p>Never realized how easy it is to duplicate a directory tree from one machine to another through the network without building an intermediate tarball and finding room for it and the original files all at the same time. Simply pipe the tar command through ssh and untar it on the fly.</p>
<p>For example, suppose we have direcotry &#8220;pictures&#8221; on SRC_HOST machine and I want to replicate it over to DST_HOST, do this from the SRC_HOST machine:</p>
<blockquote><p>tar cvf &#8211; pictures | ssh user@DST_HOST &#8220;cat | tar xf -&#8221;</p></blockquote>
<p>Or, if you just wanted to create a compressed archive of &#8220;pictures&#8221; on DST_HOST:</p>
<blockquote><p> tar czvf &#8211; pictures | ssh user@DST_HOST &#8220;cat &gt; pictures.tar.gz&#8221;</p></blockquote>
<p>I&#8217;m ashamed to admit how many times I&#8217;ve jumped through hoops to find the free space on both machines due to making a compressed tarball, copying it over, unpacking it, then deleting the tarball.</p>
<p><strong>Update: </strong>While the above is functional, it&#8217;s all rather academic.  Not but a few days after writing this, I stumbled across &#8216;<a href="http://rsync.samba.org/ftp/rsync/rsync.html" target="_blank">rsync</a>&#8216;. Yeaeh, this is a little easier:</p>
<blockquote><p>rsync -avz  user@DST_HOST:pictures pictures</p></blockquote>
<p>And how to do it on a Mac and get all the resource forks to transfer to a non-HFS file system requires extra care and a <a href="http://www.quesera.com/reynhout/misc/rsync+hfsmode/" target="_blank">better version of rsync than Apple delivers</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.foobert.com/blog/2008/02/18/network-tar-using-ssh/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

