Updated more posts

43 files changed, 3781 insertions, 0 deletions

diff --git a/html/files/00-desktop.jpg b/html/files/00-desktop.jpg
new file mode 100755
index 0000000..ac8d307
--- /dev/null
+++ b/html/files/00-desktop.jpg
diff --git a/html/files/01-xfce-settings.jpg b/html/files/01-xfce-settings.jpg
new file mode 100755
index 0000000..4377f13
--- /dev/null
+++ b/html/files/01-xfce-settings.jpg
diff --git a/html/files/01_Open_Test.jpg b/html/files/01_Open_Test.jpg
new file mode 100755
index 0000000..6b46fb5
--- /dev/null
+++ b/html/files/01_Open_Test.jpg
diff --git a/html/files/02-xfce-user-actions.jpg b/html/files/02-xfce-user-actions.jpg
new file mode 100755
index 0000000..50688a1
--- /dev/null
+++ b/html/files/02-xfce-user-actions.jpg
diff --git a/html/files/02_Edit_Test_Run_Configurations.jpg b/html/files/02_Edit_Test_Run_Configurations.jpg
new file mode 100755
index 0000000..9659ba9
--- /dev/null
+++ b/html/files/02_Edit_Test_Run_Configurations.jpg
diff --git a/html/files/03-xfce-window-resize-hot-edge.jpg b/html/files/03-xfce-window-resize-hot-edge.jpg
new file mode 100755
index 0000000..30ca230
--- /dev/null
+++ b/html/files/03-xfce-window-resize-hot-edge.jpg
diff --git a/html/files/03_Select_Controller.jpg b/html/files/03_Select_Controller.jpg
new file mode 100755
index 0000000..e9600b9
--- /dev/null
+++ b/html/files/03_Select_Controller.jpg
diff --git a/html/files/04_Answer_Prompt.jpg b/html/files/04_Answer_Prompt.jpg
new file mode 100755
index 0000000..b9cbc3a
--- /dev/null
+++ b/html/files/04_Answer_Prompt.jpg
diff --git a/html/files/Cc-sa_88x31.png b/html/files/Cc-sa_88x31.png
new file mode 100755
index 0000000..f0a944e
--- /dev/null
+++ b/html/files/Cc-sa_88x31.png
diff --git a/html/files/MgmtStudio1.jpg b/html/files/MgmtStudio1.jpg
new file mode 100755
index 0000000..7385d42
--- /dev/null
+++ b/html/files/MgmtStudio1.jpg
diff --git a/html/files/MgmtStudio2.jpg b/html/files/MgmtStudio2.jpg
new file mode 100755
index 0000000..6862f91
--- /dev/null
+++ b/html/files/MgmtStudio2.jpg
diff --git a/html/files/pathauto-alias-strings0.jpg b/html/files/pathauto-alias-strings0.jpg
new file mode 100755
index 0000000..bea7a49
--- /dev/null
+++ b/html/files/pathauto-alias-strings0.jpg
diff --git a/src/About.ascii b/src/About.ascii
new file mode 100644
index 0000000..18ce3f0
--- /dev/null
+++ b/src/About.ascii
@@ -0,0 +1,92 @@
+About
+=====
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+link:https://iohq.net/[Iohq.net] is my attempt at contributing back to the
+world's largest knowledgebase in history: the internet. Here I document my
+various experiences with technology and anything else I care to blog about.
+
+link:https://github.com/nullspoon[GitHub page]
+
+
+== Who Am I
+
+How dramatic does that sound? My name is Aaron Ball, and as per my Twitter
+page, I am a nix engineer, Android tester, open source fanatic, and regional
+champion of rock paper scissors lizzard spock (but only with my left hand). I
+thank God routinely for all the engineers He has put on this Earth to discover
+and make all the great things that have been made. The world is a complex and
+interesting place and there's nothing like poking at something to figure out
+how it works.
+
+
+== Contact
+
+You can send me an email at my username (nullspoon) at iohq.net (isn't
+obsfucation great?).
+
+If you are particularly concerned with security or just want to add a fellow
+PGP user to your list of security-minded friends, my public key is...
+
+Brace yourselves, it's the public for a 4096 bit private (hehe)...
+
+----
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v2.0.22 (GNU/Linux)
+
+mQINBFKjiVgBEADJ9jRiw9rT6r61eo432GRPCUAacYgCYrT8W8d8SY1DTUy16qyZ
+5mOqlVA1DN12n/pnPB7mgeD4csYstzl4k9dcG5206XC239JJbFB3ezB1P8VRI8VO
+k2iavV1ysYA1e/b4JMvzhQp/i9/JjeoJycLCDJz2ENl31hAsATCOQ+NjQ3Lk2c4R
+qNUJuxoapUn7NwxeY3zWx2nMlTcBVuSuzactnc62zMrB0fNfC13P59e6xiA0KZ2G
+Pbqi1L3Hk38biFLQvEXjAmx77FVpkiWfppuduavBrCXdBLukYeMv9PHR2cxriNWc
+QbZ2Df5Y2z0PrVkSOWSXOF81uNKP/9cJHoRvVOlRT4mejawaOQnrebTjy6xhGT37
+6Ve2eOJOgrTza16gHcysrePWemC0XQG25G1ZlaxYJarIGX7KrHh9pFCz51C29Eh9
+Bm6YS7S6+QmtIVpoMjfEpWZhwjWjYloPNzLiN3x37XUP231M4bJElXeEhOGZjMoG
+ltfPIheY+mWi7UozHdz5o6Kzubzc0xCkGANxIIvYs3Btj9e4n9lChNOS9eAspEoA
+iphYr09afyd/+y3qXotjGow1vmy7FdemZk0Z5MwuIj68W24TZQHPpdJBnFS9gSa4
+0YggSZEdLStMczujqeBXSL+Rznkyp+2XHaG4sn46BSsfVnlNiMgaBzyV8QARAQAB
+tDZOdWxsc3Bvb24gKFByaW1hcnkgbnVsbHNwb29uIGtleSkgPG51bGxzcG9vbkBp
+b2hxLm5ldD6JAjkEEwECACMFAlKjiVgCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIe
+AQIXgAAKCRCHxh4JWkQTntI7D/9iPju0cG38YEMIzKJs9MXHvU9dzh8AdycxsRXy
+pJcQ12nb5RAAWrX8sM31US8V2BpuP/WI3HguzUYVomSPAWf3cjBjpioTA6oG24nW
+jfmoIzTmskrOvS5H4ulM9mSCe1n5UqoMFe/rKwN5wKpQDWKvEns9LEVmsRJ9i8dK
+o5lcIeZF963STKEUllAnPcNhLiaoGIjRScIb+CpUlerxSGFOivN2ksmnsOkTDmCf
+mbXsskqFVZBtO0vuCXsXaM/hcqnK/2PT+jxcaSAoAjPBrx07XQpJbs+Xq78OnVzt
+Xl9tLRsyG2QYxa+rPsZHqxvKyl8CP8oLPWuwTmny0+wXCA1jMhoGlPrJmAnXQiH+
+huyPdhZJZutZQ+aiEHT6Uvd3QKJsMQfZFBdJlyFWuA7k73Rg1zaBGIvPOKCIL71Y
+JqKd7VKAQtk97Tc6KcPE31FzDeFtE65LIj7Q9vW4qi2PI5QIs022aQdezLTFovsI
+y5Tvziq0war34YrmLmVb0R6IF5uNg9WKP7GL5njk2+Fpf9J8uYA49pqtR85Jymhn
+5GlUoi7opiCo/4PBdIBcYUF7DCaUQl5z8wHXGEuHssSjjOlT9EHMGVmVVGxC/yGJ
+TAiLEAFH0+cMlN1pzxZPcK/zDRzwkdwsdvdvNgqZorXH/I7zDc0ROg4vp/Q0Iwkz
+U4Gdf7kCDQRSo4lYARAAyl6iY6VOR/Amwmeu5j5gmZZ4T+ic0oyQ9ZyCzvGoL3KU
+IDrkIzzemyOnE92xfq9NgdNa+ITNHHTXXsp9Ayey8/h1W/twkJprAr9tP73tWraG
+swqnm+C3hs7k9ntkcXkHSonewHoK9Ro4Pki/MfW6YwwssNlmpPPz08Tnn/R8x+RK
+ApNmBjx7yRwmiyQlxXAaK/LSlVM62DwLEt24n+gcN7ukp+nGx63HaxpXGMmkDXIQ
+9AzidTnoKO2KpvYkkBkd/cF0XgXKJPqU1KV/gbb4uQ21Upiht+Stuqp0Zawq9F2u
+GUEFzviMqlT5dhh0T48YzJyCdeKxpkd5XLyOKnzCW2oXlvY5lBieIHjRBil7NkMy
+ezkgsy+S1+eQDtAdAVgQi+MeeXpI5k+o1nF0rl1ivnhJPYvQ8/4oOOwuK6FwWua4
+Sd057X53Bgp7xvZKxOlEYhskgyz9W0uocgX8DhhB49rfw9c3PgqagUrDuDGQW12l
+HkxYuLMtcc7N2jpI11VXfsGCnTxmFNWXSQjzbKh50egPp4d1C6osvwWMNDWCu3ry
+GMVYj5hdDqwLQtcGD1+9uw9IYEDO+pXvdRMrPvEdPfFDvsIWXKKMM4CH4fKuMZpL
+y4esJFy15ARLcrDhD2ceN5xVaPYuz374tAWngcn44GFt9B5H1ayxRRgV/ydV3S0A
+EQEAAYkCHwQYAQIACQUCUqOJWAIbDAAKCRCHxh4JWkQTnrPIEACP0ravu0uIVyg0
+21T9k+khF7nWBRgc3e8bX1uKOqC800RePXyu96wl7DA5agvf3271NtXFFfALwkzg
+NZ2d5+KNKzoz9zrz7txmEHcgNHrWeXY220YmhgEyDD/rDS6sjGn9O/Obb+f8mEoY
+XhWrSQkGWIgtY3Qb+wZnA6gA7VzmVgHxiKcM4XH6QhJol9mgCWZs7zxcHVz0mMNf
+fffyRuf4/JkyZ6WohsMPXL0vsSX9j49n3f7N/G1TBICTQ6qDvMeRMhaJpkliVsHR
+kVy/Oo+LWQ7wEy1OJB9Ey/KUIAKP481xcCIEquV7LHFzRuNf/hPE6A9iKGgAAN1z
+FAdCwe+8BDvybW8+xt+WdHULNnPcaEIIEJAeoRWg5yomJ5ObAkrcz/F+1VxUPTle
+t5X+P7KWk0pai2GBCKhyACHN7WKqxM8BE8qg+d5Xpg4RVkerFtEIKB1PwHcsFGXX
+9mFxHblNYJ/xxxX5MK1qKIKJoyFFhNR7sw8+SKg9gCrv8nwOz15gC+4cV0LHm7mg
+1CgwS4qiAmomWLogal7O+iV960usfSFEE4BSPq7JMIDn9ICfOYjeIAQ8wCw7ZjcN
+ykOycANTpIp7O7gnSNm2V9i1JTK4M9hX9DWtse7lA1YZiYqfRHWdKE6UCapiVKl+
+Ldfv23c2sRAxPA27rFmsgcOGz9iV8w==
+=OITG
+-----END PGP PUBLIC KEY BLOCK-----
+----
+
+// vim: set syntax=asciidoc:
diff --git a/src/Btrfs:RAID_5_Rsync_Freeze.ascii b/src/Btrfs:RAID_5_Rsync_Freeze.ascii
new file mode 100644
index 0000000..bcdcb84
--- /dev/null
+++ b/src/Btrfs:RAID_5_Rsync_Freeze.ascii
@@ -0,0 +1,91 @@
+Btrfs:RAID 5 Rsync Freeze
+=========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+My server's _/home/_ directory is a btrfs RAID 5, spanning three drives (I did
+a blog post about it Btrfs:RAID_Setup[here]). Everything worked fine, until I
+used rsync to sync my files from my laptop to my server.  At that point, the
+sync would go well for a little while and then slow to a crawl. I couldn't
+cancel the sync with a ctrl+c. If I could get on my server over ssh, I'd find
+that one of my cpus was pegged at 100%.  Sometimes though it got so bogged down
+I couldn't even get to the server at all. If I were already on the server and I
+did a kill -9 on rsync, it'd go defunct.
+
+I checked my logs after trying to umount /home/ and found...
+
+----
+Nov 03 12:01:18 zion kernel: device label home devid 1 transid 1173 /dev/sdb
+Nov 03 12:01:19 zion kernel: btrfs: disk space caching is enabled
+Nov 03 12:11:53 zion kernel: INFO: task umount:1668 blocked for more than 120 seconds.
+Nov 03 12:11:53 zion kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+Nov 03 12:11:53 zion kernel: umount D ffff880037afbc60 0 1668 1653 0x00000000
+Nov 03 12:11:53 zion kernel: ffff880037afbbd0 0000000000000086 0000000000014500 ffff880037afbfd8
+Nov 03 12:11:53 zion kernel: ffff880037afbfd8 0000000000014500 ffff8800aa0caa30 0000000000000010
+Nov 03 12:11:53 zion kernel: 000000000d6fffff ffff880037afbb98 ffffffff8113a911 ffff8800afedb728
+Nov 03 12:11:53 zion kernel: Call Trace:
+Nov 03 12:11:53 zion kernel: [<ffffffff8113a911>] ?  free_pcppages_bulk+0x3b1/0x3f0
+Nov 03 12:11:53 zion kernel: [<ffffffff81132700>] ? filemap_fdatawait+0x30/0x30
+Nov 03 12:11:53 zion kernel: [<ffffffff814e1029>] schedule+0x29/0x70
+Nov 03 12:11:53 zion kernel: [<ffffffff814e12cf>] io_schedule+0x8f/0xe0
+Nov 03 12:11:53 zion kernel: [<ffffffff8113270e>] sleep_on_page+0xe/0x20
+Nov 03 12:11:53 zion kernel: [<ffffffff814ddb5b>] __wait_on_bit_lock+0x5b/0xc0
+Nov 03 12:11:53 zion kernel: [<ffffffff8113284a>] __lock_page+0x6a/0x70
+Nov 03 12:11:53 zion kernel: [<ffffffff81084800>] ?  wake_atomic_t_function+0x40/0x40
+Nov 03 12:11:53 zion kernel: [<ffffffff81141fa3>] truncate_inode_pages_range+0x613/0x660
+Nov 03 12:11:53 zion kernel: [<ffffffff81142005>] truncate_inode_pages+0x15/0x20
+Nov 03 12:11:53 zion kernel: [<ffffffffa07df172>] btrfs_evict_inode+0x42/0x380 [btrfs]
+Nov 03 12:11:53 zion kernel: [<ffffffff811b97b0>] evict+0xb0/0x1b0
+Nov 03 12:11:53 zion kernel: [<ffffffff811b98e9>] dispose_list+0x39/0x50
+Nov 03 12:11:53 zion kernel: [<ffffffff811ba56c>] evict_inodes+0x11c/0x130
+Nov 03 12:11:53 zion kernel: [<ffffffff811a1cc8>] generic_shutdown_super+0x48/0xe0
+Nov 03 12:11:53 zion kernel: [<ffffffff811a1f22>] kill_anon_super+0x12/0x20
+Nov 03 12:11:53 zion kernel: [<ffffffffa07a8ee6>] btrfs_kill_super+0x16/0x90 [btrfs]
+Nov 03 12:11:53 zion kernel: [<ffffffff811a22fd>] deactivate_locked_super+0x3d/0x60
+Nov 03 12:11:53 zion kernel: [<ffffffff811a28e6>] deactivate_super+0x46/0x60
+Nov 03 12:11:53 zion kernel: [<ffffffff811bdeaf>] mntput_no_expire+0xef/0x150
+Nov 03 12:11:53 zion kernel: [<ffffffff811bf0b1>] SyS_umount+0x91/0x3b0
+Nov 03 12:11:53 zion kernel: [<ffffffff814ea5dd>] system_call_fastpath+0x1a/0x1f
+----
+
+The only way to solve the problem was to perform a restart. After that, the
+problem would come back as soon as I started rsync again.
+
+
+[[the-solution]]
+== The Solution
+
+I hunted around for a while until I finally just searched for the name of the
+pegged process, **btrfs-endio-wri**, and cpu time. It turns out, the btrfs
+folks have https://btrfs.wiki.kernel.org/index.php/Gotchas[a page] detailing a
+list of current "gotchas" btrfs has. This issue was one of them. They describe
+it as <pre> Files with a lot of random writes can become heavily fragmented
+(10000+ extents) causing trashing on HDDs and excessive multi-second spikes of
+CPU load on systems with an SSD or large amount a RAM. ... Symptoms include
+btrfs-transacti and btrfs-endio-wri taking up a lot of CPU time (in spikes,
+possibly triggered by syncs). You can use filefrag to locate heavily fragmented
+files. </pre>
+
+One of the best parts of rsync is that is syncs deltas instead of resyncing the
+entire file. What does that result in? Lots of little random writes. Sounds
+like a match to me.
+
+**To fix this**, I defragged all of /home/ (with _compression=lzo_ of course :)
+), and remounted using the *autodefrag* option.
+
+Now I can run rsync with no problems.
+
+One last thing to note. Their gotchas page says that once they've worked out a
+few potential kinks with the autodefrag mount option, they'll make it the
+default, which should prevent this from being an issue in future versions.
+
+Category:Linux
+Category:Btrfs
+Category:Storage
+Category:RAID
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Building_an_Ejabberd_Server_with_MySql.ascii b/src/Building_an_Ejabberd_Server_with_MySql.ascii
new file mode 100644
index 0000000..dfea4d1
--- /dev/null
+++ b/src/Building_an_Ejabberd_Server_with_MySql.ascii
@@ -0,0 +1,135 @@
+Yesterday I was upgrading my
+http://www.igniterealtime.org/projects/openfire/[OpenFire] server and thought
+it might be fun to learn something new and switch to a different server
+software. After doing some research, I decided upon
+http://www.ejabberd.im/[ejabberd] since that one seems to be a popular solution
+(not to mention that specs of course).
+
+I keep my jabber data in a MySql database and I don't really want to migrate
+away from that. That being said, I had a really difficult time finding any
+complete documentation on how to configure an ejabberd server to work with a
+MySql database. Here's how I did it.
+
+Firstly, you of course need to grab said bin
+http://www.process-one.net/en/ejabberd/archive/[here]. Once you have extracted
+and installed, you'll need to edit your config file (conf/ejabberd.cfg). You'll
+see a section in the middle (or so) that
+looks like
+
+----
+%%%   ==============
+%%%   AUTHENTICATION
+
+
+%%
+%% auth_method: Method used to authenticate the users.
+%% The default method is the internal.
+%% If you want to use a different method,
+%% comment this line and enable the correct ones.
+%%
+{auth_method, internal}.
+
+
+%%
+%% Authentication using external script
+%% Make sure the script is executable by ejabberd.
+%%
+%%{auth_method, external}.
+%%{extauth_program, "/path/to/authentication/script"}.
+
+
+%%
+%% Authentication using ODBC
+%% Remember to setup a database in the next section.
+%%
+%%{auth_method, odbc}.
+----
+
+Comment out the internal auth method line
+
+----
+%%\{auth_method, internal}.
+----
+
+Now, skip down to the line and uncomment the odbc auth
+method.
+
+----
+{auth_method, odbc}.
+----
+
+Lastly in the config file, we need to configure our database connection
+string. Head on down to the following location, uncomment the first
+odbc_server line and fill in your database connection information.
+
+----
+%%
+%% MySQL server:
+%%
+{odbc_server, {mysql, "MySqlServer", "MySqlDatabase", "MySqlUsername", "MySqlPassword"}}.
+----
+
+It's at this point that you might be thinking to yourself, "...but I don't have
+a database or tables configured". This is the part where I initially got stuck.
+All of the documentation I found pointed towards a sql file that could be found
+in the source code. Other sources indicated that ejabberd needs to be compiled
+with mysql support for this all to work. Thankfully, this is not the case (as
+per my experience at least).  I can't say this about the deb or the rpm
+installs, but the gzipped binary at least has this.
+
+If you go into the install location and navigate on down to
+
+----
+<ejabberd-home>/lib/ejabberd-2.1.8/priv/odbc/mysql.sql
+----
+
+and run the mysql file in there on the database you have created, you will find
+yourself with a completely empty database structure (but a structure none the
+less).
+
+Finally, we have to go back and make a few more simple changes to our conf
+file. The config file references several modules that store their data to the
+internal database, unless otherwise specified. We are going to otherwise
+specify here.
+
+Crack open that config file again located at conf/ejabberd.cfg Navigate down to
+the section that looks like the following (I won't put the whole thing in here
+since it's a big section)
+
+----
+%%%   =======
+%%%   MODULES
+
+
+%%
+%% Modules enabled in all ejabberd virtual hosts.
+%%
+----
+
+Here you'll find a lot of lines starting with **mod_**. These are all the
+modules your ejabberd instance will load on startup. There are several in here
+that we need to add *_odbc* to the end of to make them talk to our MySql
+database instead of the internal database. Find the following listed modules
+and add _odbc to them (I've already done that in my list)
+
+----
+{mod_last_odbc,     []},
+{mod_offline_odbc,  []},
+{mod_privacy_odbc,  []},
+{mod_private_odbc,  []},
+{mod_pubsub_odbc,   [ % requires mod_caps ...
+{mod_roster_odbc,   []},
+{mod_vcard_odbc,    []},
+----
+
+And finally, we're done. On a side note, you might want to uncomment the module
+mod_65[] to enable file transfers. You never know when you'll need to
+http://xkcd.com/949/[transfer a big file].
+
+
+Category:MySQL
+Category:XMPP
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Compiling_MariaDB_:_cannot_find_ncurses:_File_format_not_recognized.ascii b/src/Compiling_MariaDB_:_cannot_find_ncurses:_File_format_not_recognized.ascii
new file mode 100644
index 0000000..a30a6b6
--- /dev/null
+++ b/src/Compiling_MariaDB_:_cannot_find_ncurses:_File_format_not_recognized.ascii
@@ -0,0 +1,38 @@
+Compiling MariaDB:cannot find ncurses: File format not recognized
+=================================================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+This week I have been trying to upgrade my MariaDB instance to latest and have
+been having some problems with getting it to compile right. My first issue was
+that it couldn't find the ncurses libraries, so I had to grab and compile the
+source for that (I'm trying to run everything in userspace). Once I did that, I
+specified the "--with-named-curses-libs=[DIR]" switch and began my
+re-configure. Once I did that, I received the following error:
+
+----
+/usr/bin/ld: cannot find /home/mariadb/ncurses/: File format not recognized
+collect2: ld returned 1 exit status
+make[2]: *** [mysql] Error 1
+make[2]: *** Waiting for unfinished jobs....
+make[2]: Leaving directory `/home/mariadb/mariadb-5.3.3-rc-src/client'
+make[1]: *** [all] Error 2
+make[1]: Leaving directory `/home/mariadb/mariadb-5.3.3-rc-src/client'
+make: *** [all-recursive] Error 1
+----
+
+I searched around for some time and could not find the answer until I happened
+upon something unrelated that pointed me towards the
+*--with-client-ldflags=-all-static* switch.  I threw that switch onto the end
+of my configure string and presto!
+
+
+
+Category:MariaDB
+Category:MySQL
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Compiling_nginx_for_Solaris_10_-_Configure:_test:_argument_expected.ascii b/src/Compiling_nginx_for_Solaris_10_-_Configure:_test:_argument_expected.ascii
new file mode 100644
index 0000000..f9176f1
--- /dev/null
+++ b/src/Compiling_nginx_for_Solaris_10_-_Configure:_test:_argument_expected.ascii
@@ -0,0 +1,54 @@
+Compiling Nginx on Solaris 10 - Configure:test:argument expected
+================================================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Yesterday I was working on compiling nginx on one of our solaris boxes at work
+(someone please tell me why companies still choose Solaris over the various
+other unix or linux distros out there) and I ran into a problem. When I ran
+configure with any options, I saw the following error:
+
+----
+. / Configure: test: argument expected
+----
+
+And if you try to run make or gmake after that you get this error
+
+----
+Make: Fatal error: Command failed for target `objs / src / core / nginx.o
+----
+
+That's no fun, huh? Well, I searched around for a while and found the solution
+http://forum.nginx.org/read.php?21,220311,220313[here], which happened to be in
+Russian (Dear
+http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fforum.nginx.org%2Fread.php%3F21%2C220311%2C220313[Google
+Translate]).
+
+Basically, the problem was that the version of sh that Solaris 10 defaults to
+is very old and not POSIX compliant (go figure). The solution is to change the
+configure script to use a different version of sh. At the top of your config
+file, change the following line from
+
+----
+#!/bin/sh
+----
+
+to
+
+----
+#!/usr/xpg4/bin/sh
+----
+
+Rerun your configure script with all of your switches and all should be well
+(yay!). Once you've done that, gmake/make should run without a hitch (at least
+not due to this problem we hope).
+
+
+Category:Solaris
+Category:Nginx
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Configuring_Status.Net_for_NGINX_in_a_Subdirectory.ascii b/src/Configuring_Status.Net_for_NGINX_in_a_Subdirectory.ascii
new file mode 100644
index 0000000..0a83bea
--- /dev/null
+++ b/src/Configuring_Status.Net_for_NGINX_in_a_Subdirectory.ascii
@@ -0,0 +1,63 @@
+Configuring Status.Net for NGINX in a Subdirectory
+==================================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+This morning I tried to get status.net to work from a subdirectory of my main
+site, a task which proved to be quite frustrating, especially for someone who's
+not too great at rewrite rules in apache, let alone NGINX.  Unfortunately,
+there is also not much documentation on this topic online since status.net does
+not officially support NGINX. That's okay though.  I don't know much about
+rewrites, since they use regex, it seems you should be able to make just about
+anything work (I could be wrong about that though).
+
+To get this to work, we first need a location directive for our main site. That
+would look something like
+
+----
+location / {
+        index index.php;
+        try_files   $uri $uri/ @rewriteSection;
+}
+location @rewriteSection {
+        rewrite (.*blah.*) index.php?q=$1;
+}
+----
+
+Now that we have that, we can go ahead and put our subdirectory directive in
+here. For the purposes of this demonstration, our status.net instance will be
+running in a directory called testsub.
+
+----
+location /testsub {
+        index index.php;
+        try_files   $uri $uri/ @testsub;
+}
+location @testsub {
+        ## FOR FANCY URLS FALSE
+        ## rewrite ^/testsub/index.php/(.*)$ /testsub/index.php?p=$1 last;
+        ## FOR FANCY URLS TRUE
+        rewrite ^/testsub/(.*)$ /testsub/index.php?p=$1 last;
+}
+----
+
+
+To make this work for your instance, all you should need to do is swap out the
+testsub directory references for the directory your status.net instance is
+running in and you should be set. Keep in mind though that by default,
+status.net has fancy URLs disabled. That means you'll have to use the first
+rewrite line. If fancy URLs are turned on, then you should use the second
+rewrite line. That should be it!
+
+Yay microblogging!
+
+
+Category:Nginx
+Category:Status.Net
+Category:Blogging
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Creating_Search_Engine_Optimized_Drupal_URLS.ascii b/src/Creating_Search_Engine_Optimized_Drupal_URLS.ascii
new file mode 100644
index 0000000..3282b7f
--- /dev/null
+++ b/src/Creating_Search_Engine_Optimized_Drupal_URLS.ascii
@@ -0,0 +1,55 @@
+Creating_Search_Engine_Optimized_Drupal_URLS
+============================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+A big piece to search engine optimization is how your URLs are structured. A
+ways back, I was talking to a buddy of mine who does SEO for a living and he
+suggested that I use WordPress' URL rewrites to make my URLs friendlier. I went
+ahead and set my blog up for a 'yyyy/mm/dd/title' format and it did wonders for
+my search rankings.  Recently however, I moved to Drupal which sadly does not
+automagically create the friendly aliases to your posts. There is good news
+though. In typical Drupal fashion, there's a module for that (kind of like
+"there's an app for that") and it is very customizable.
+
+To set yourself up with article urls (or blog urls) that autoalias with a
+format that you want, you need to grab two modules. First you need the
+*Pathauto* module, and that depends on the *Token* module. Before we continue,
+I'm writing this to fit a Drupal 7 scenario, so likely some of the stuff will
+be in a slightly different place if you're running 6 or 5.
+
+Now, once you have those enabled, head on over to the Configuration->URL
+aliases section of your Drupal site. Once there, select the pattern tab.
+
+Where we put our aliasing string here depends on whether your writing your
+content as a blog or an article content type.
+
+If you blog in article content types, put the following string in the
+*Pattern for All Article Paths* field:
+
+----
+[current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]/[node:title]
+----
+
+If you blog in blog format, put the following string in the *Pattern for all
+Blog entry paths* field:
+
+----
+[current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]/[node:title]
+----
+
+image:files/pathauto-alias-strings0.jpg[height=300]
+
+Keep in mind that I formatted those strings for blog entries. If you're doing
+basic pages or something like those, you likely won't want the format I used in
+this article. Just expand the *Replacement Patterns* section in your patterns
+tab to see what other options you have for formatting those URLs.
+
+
+Category:Drupal
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Dell_V305_Printer_on_Linux.ascii b/src/Dell_V305_Printer_on_Linux.ascii
new file mode 100644
index 0000000..16da7e8
--- /dev/null
+++ b/src/Dell_V305_Printer_on_Linux.ascii
@@ -0,0 +1,190 @@
+Dell V305 Printer on Linux
+==========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+ 
+I spent this week hanging out with my wife and grandparents-in-law and spent
+some of my time performing the obligatory family tech support (no complaining
+here, I love doing that most of the time). To sum up the beginning quickly
+because I really don't want to write the post in great detail, my grandfather's
+computer got temporarily hosed and the guy from Dell made it even worse (thanks
+Deepak). He actually wiped the computer after taking very minimal backups
+(thankfully just enough). Not only that, but the restore from the Dell image
+actually corrupted a bunch of the core system libraries making installing and
+updating Windows or Microsoft software impossible. After wasting an hour trying
+to fix this, I finally decided to reinstall a fresh copy of Windows. Then it
+hit me, my grandfather doesn't use his computer for much more than Word
+documents, PDFs, browsing the internet, and email - all things that Linux does
+very well. With that, I suggested to him that he try
+http://linuxmint.com/[Linux Mint] (my favorite ready-to-go Linux desktop
+distro). After he played around with the live version for a bit, he decided he
+really liked it (kudos to you Linux Mint guys) so I went ahead to install it.
+
+I got everything working easily but one thing... his printer.
+
+[[the-dell-v305-printer]]
+The Dell V305 Printer
+--------------------
+
+The Dell V305 is actually a Lexmark printer rebranded as a Dell.  Specifically,
+it is the Lexmark x4650. Thankfully, Lexmark makes
+http://support.lexmark.com/index?page=downloadFile&actp=CONTENT&productCode=LEXMARK_X4650&id=DR20523&segment=DOWNLOAD&userlocale=EN_US+&locale=en&oslocale=en_US[a
+linux driver] for this thing, but it is of course, very problematic.  When I
+first ran the .sh with an embedded binary, it ran fine until I got to the
+install where it gave me an ambiguous "failed to install".  When you click
+**OK**, it closes the window with the actually error text in it. While the
+"failed to install" dialog is up, you can't check the log because it won't let
+you select the background window. Also, the background window isn't resizable
+so you can't hope for a bigger window to compensate for no scrollback. Great
+design, huh?
+
+I did notice on the last three or so lines though that it was trying to remove
+a .deb file. With that, I set out to search for it.
+
+
+[[the-fun-begins]]
+The Fun Begins
+--------------
+
+If you run the
+'http://support.lexmark.com/index?page=downloadFile&actp=CONTENT&productCode=LEXMARK_X4650&id=DR20523&segment=DOWNLOAD&userlocale=EN_US+&locale=en&oslocale=en_US[lexmark-08z-series-driver-1.0-1.i386.deb.sh]'
+file with the _--keep_ switch, the script will not remove all files extracted
+to perform the install process. This will leave you with a nicely populated tmp
+folder.
+
+If you cd into the tmp directory, you will find a file called
+**installarchived_all**. This is actually an lzma archive file. What you want
+to do now is extract this file using the following command
+
+----
+tar -xvf ./installarchived_all --lzma
+----
+
+This will extract several files, one of which will be called
+__lexmark-08z-series-driver-1.0-1.i386.deb__. You might think that this is a
+time for rejoicing, but alas it is not. From this point we should be able to
+run _dpkg -i ./lexmark-08z-series-driver-1.0-1.i386.deb_ and it would work, but
+it won't. If you do that you will receive the following friendly error:
+
+----
+dpkg: error processing ./lexmark-08z-series-driver-1.0-1.i386.deb (--install):
+ parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package 'lexmark-08z-series-driver':
+ blank line in value of field 'Description'
+Errors were encountered while processing:
+ ./lexmark-08z-series-driver-1.0-1.i386.deb
+----
+
+What? The .deb file was constructed wrong? 'Tis a shame. Here's where it gets
+really fun. What we need to do now is extract the deb file, modify the contents
+of a single file, and repackage the whole thing back up.
+
+First, let's create a working directory, copy our deb file in there, extract
+it, and set up a deb package folder structure. Create our working directory and put the bad .deb file in there.
+
+----
+mkdir ./working
+cp ./lexmark-08z-series-driver-1.0-1.i386.deb ./working/
+cd working
+----
+
+Extract the .deb file and clean up a bit (don't forget the period at the
+end of the dpkg-deb line).
+
+----
+dpkg-deb -R lexmark-08z-series-driver-1.0-1.i386.deb .
+rm ./lexmark-08z-series-driver-1.0-1.i386.deb
+----
+
+
+[[fixing-the-problem]]
+Fixing the Problem
+------------------
+
+The problem as you like noticed earlier is because the .deb file has a file
+named _control_ that is improperly formatted. Specifically, control files
+cannot have blank lines in them. To have a "blank" line in a .deb control file,
+you must have a period instead. That said, here's how we fix the file.
+
+Open up the control file in the DEBIAN directory and put a ' .' (yes, with the
+space before it) like so
+
+----
+Description:
+ Lexmark 08z Series Drivers Package
+ .
+ This package contains the Lexmark 08z Series Drivers. This is
+ a copyrighted package, please refer to the copyright notice
+ for details about using this product.
+----
+
+Now that that's done, We just need to repackage the .deb file and install it.
+To do that, cd out to one directory above the lexmark-08z directory (the
+working directory) and run **dpkg -b lexmark-08z**. This will take a few
+seconds (it's 22 megs) but it should create a file called lexmark-08z.deb. Now
+install this using **dpkg -i**.
+
+----
+dpkg -b lexmark-08z dpkg -i ./lexmark-08z.deb
+----
+
+_I'm too lazy to write the rest out right now so here's the shorthand_
+
+Now you have to edit a ton of files in __/usr/local/lexmark/08zero/etc/__.
+
+Firstly, we need to edit 99-lexmark-08z.rules and take the following
+line on the top so it looks like so
+
+----
+ATTRS{idVendor}=="413c", ATTRS{idProduct}=="5305", MODE="666"
+
+ACTION!="add", GOTO="lexmark_custom_rules_end"
+ATTRS{idVendor}=="413c", ATTRS{idProduct}=="5305", MODE="666"
+ATTRS{idVendor}=="043d", ATTRS{idProduct}=="0142", MODE="666"
+ATTRS{idVendor}=="043d", ATTRS{idProduct}=="0150", MODE="666"
+ATTRS{idVendor}=="043d", ATTRS{idProduct}=="013f", MODE="666"
+ATTRS{idVendor}=="043d", ATTRS{idProduct}=="0151", MODE="666"
+ATTRS{idVendor}=="043d", ATTRS{idProduct}=="0116", MODE="666"
+LABEL="lexmark_custom_rules_end"
+
+----
+
+Now that we've updated the 99-lexmark-08z.rules file, we need to edit a load of
+the lxd*.conf files. I say we need to edit lots of them because I'm still not
+sure which one or combination of them actually did the trick. I can say though
+that just lxdm.conf wasn't enough.
+
+Now, edit the following files
+
+* lxdm.conf
+* lxdq.conf
+* lxdw.conf
+* lxdu.conf
+* lxdx.conf
+
+...and replace *all* instances of _0116_ with _5305_ and all instances of
+_043D_ with _413C_
+
+Once that is done, add your printer from the cups admin console
+(localhost:631). Once you get to the driver part, select Lexmark 3600-4600 and
+you should be set!
+
+**Whew**
+
+Finally, here are the resources I found to help me out with this
+solution.
+
+* http://ubuntuforums.org/showpost.php?p=7809488&postcount=1
+* http://ubuntuforums.org/archive/index.php/t-1243920.html
+* http://ubuntuforums.org/archive/index.php/t-1554718.html
+* http://ubuntuforums.org/showthread.php?t=1379902
+* http://ubuntuforums.org/showthread.php?t=1554718&page=1
+
+
+Category:Linux
+Category:Debian
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Drupal,_Mod_rewrite,_Subdirectories,_and_Nginx.ascii b/src/Drupal,_Mod_rewrite,_Subdirectories,_and_Nginx.ascii
new file mode 100644
index 0000000..ce8b379
--- /dev/null
+++ b/src/Drupal,_Mod_rewrite,_Subdirectories,_and_Nginx.ascii
@@ -0,0 +1,106 @@
+Drupla, Mod Rewrite, Subdirectories, and NGINX
+==============================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+A few days ago I started dabbling with nginx (many thanks for the
+http://arstechnica.com/business/news/2011/11/a-faster-web-server-ripping-out-apache-for-nginx.ars[article]
+from http://arstechnica.com/[arstechnica]) knowing I was getting myself into a
+world without htaccess files. They say that Nginx is easier to configure than
+Apache, but oh contraire! If you're doing a simple setup, yes, Nginx is much
+easier than Apache. If you're even doing a slightly more complicated virtual
+host setup, Nginx is definitely much easier.  However, if you do much with
+mod_rewrite in Apache, you'll likely find yourself confused a bit with all
+kinds of 404s on your subdirectories.  Believe it or not though, with Nginx it
+is actually easier to configure URI rewriting as well, provided you know what
+you're doing...which I do not.
+
+My current setup has Drupal at the root directory, and various other tidbits
+hosted in subdirectories. These aren't anything fancy like subdomains, just
+directories beneath /.
+
+Pretty much any CMS/blog these days uses the .htaccess file to perform URI
+rewrites for search engine friendly URIs, which causes some complications for
+Nginx since you have one config file to set up all of that for your entire
+domain, rather than a config file per directory (if you wish) defining rewrite
+rules for each one. To get my Drupal instance back up and running, I took the
+location directive from the http://drupal.org/node/110224[Drupal Support page]
+for this issue.  Specifically I used the following lines...
+
+----
+location / {
+   root   /path/to/drupal;
+   index  index.php index.html;
+   if (!-f $request_filename) {
+   rewrite  ^(.*)$  /index.php?q=$1  last;
+   break;
+
+   }
+   if (!-d $request_filename) {
+       rewrite  ^(.*)$  /index.php?q=$1  last;
+       break;
+   }
+}
+----
+
+The problem with using that configuration is that any time you try to hit a
+legitimate sub directory, you receive a 404. The reason for this is because the
+request_filename will end up going to
+<nowiki>http://yoursite.com/index.php?q=request_filename</nowiki>. An example
+of this would be... Say you go to your site at the following URI:
+<nowiki>http://blerdibler.com/chips</nowiki>. The previous configuration would
+send the request to <nowiki>http://blerdibler.com/index.php?q=chips</nowiki>,
+which of course doesn't exist, so we receive a 404. The fix for this is
+relatively simple, which is very unfortunate because I spent a long time
+finding this face-palmingly simple solution (mostly because once again, I do
+not know what I'm doing).
+
+The fix is to move the Drupal rewrite stuff to its own named location
+directive (I'll show what that looks like in a few), and reference that for the
+last case scenario. So, here's what my location directives look like that allow
+for me to hit up my sub directories as well as my rewritten Drupal pages.
+
+----
+location / {
+        index  index.html index.htm index.php;
+        try_files   $uri $uri/ @drupal;
+}
+location @drupal {
+        rewrite  ^(.*)$ /index.php?q=$1  last;
+        break;
+}
+----
+
+So what we're doing here is trying all requests at face value. This means that
+Nginx tries to load http://blerdibler.com/anchovies when
+http://blerdibler.com/anchovies (a file called anchovies, not the directory) is
+called.
+
+If it can't load that, it tries http://blerdibler.com/anchovies/ (the directory
+called anchovies...consequently it searches for index.html/htm/php).
+
+Finally, if neither of those work, it calls the location directive called
+drupal (@drupal) which sends the request to
+http://blerdibler.com/index.php?q=anchovies. If that doesn't work, you're hosed
+and hopefully you've got an attractive 404 page set up. Incidentally, this also
+works for all nested Drupal/Wordpress instances as well (say, a drupal instance
+located at http://blerdibler.com/drupal2.
+
+Hopefully that helped someone out because I can't write anymore on this topic
+as I am now out of coffee. Sorry. If however, you have questions/comments/etc.,
+please leave them in the comments section and I will go brew up another cup o'
+joe and help you out (if I can...yet again...I still don't know what I'm
+doing).
+
+Thanks for reading!
+
+
+Category:nginx
+Category:Apache
+Category:Drupal
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Exim_Spam_Filtering_with_Bogofilter.ascii b/src/Exim_Spam_Filtering_with_Bogofilter.ascii
new file mode 100644
index 0000000..cb9578b
--- /dev/null
+++ b/src/Exim_Spam_Filtering_with_Bogofilter.ascii
@@ -0,0 +1,289 @@
+Exim Spam Filtering with Bogofilter
+===================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+I have been operating a personal email server for the past 4-ish years with
+very little trouble. My server itself received a truck-load of spam email, but
+none of it was delivered because every email was addressed to an account that
+didn't exist on my server (love that check_local_user filter). I received maybe
+one spam email every 3 - 6 months until recently when my email address was
+leaked in the link:Aol_Email_Hacked[Aol email breach]. While I'm a bit upset at
+Aol for that, I guess it was bound to happen sooner or later to one of the
+email providers, so I guess I can't be too upset. In the end, it's been a good
+experience because it forced me to [finally] learn to set up a spam filter with
+Exim.
+
+I searched the internet for several days weighing the pros and cons of each
+available spam filter (spamassassin, razor, dspam, bogofilter) until finally
+settling on http://bogofilter.sourceforge.net/[Bogofilter] due to it's small
+size and that it's written in C (might as well have something that _can_ handle
+a lot of spam, even if it isn't).
+
+Once I settled, I ran into the problem that spam filtering isn't a very well
+documented thing. All of its parts are _fairly_ well documented, but no one
+place really seems to put it all together with a good explanation of how each
+part interracts. Hopefully I can do that for you here.
+
+[[assumptions]]
+== Assumptions
+
+. Each user's mail is stored in *maildir* format
+. Each user's mail is stored in the *~/Mail* directory
+. Spam will be stored in a directory called *spam*
+. Less sure emails will be delivered to a *unsure* directory
+
+
+[[bogofilter-configuration]]
+== Bogofilter Configuration
+
+First, we need to set up the actual mail analysis software, Bogofilter.  My
+bogofilter configuration is fairly simple. To keep things nicely relegated to
+one area of my server, I have my bogofilter logs and word databases stored in
+__/home/mail/bogofilter__.
+
+Regarding the configuration file (/etc/bogofilter/bogofilter.cf), I am using
+the following simple configuration.
+
+./etc/bogofilter/bogofilter.cf
+----
+bogofilter_dir = /home/mail/bogofilter/
+ham_cutoff  = 0.60
+spam_cutoff = 0.80
+----
+
+To give you an idea of what that does, emails with a "spamicity" rank of 60% or
+higher are listed as *Unsure* (remember, ham is good email) and thus will be
+sent to the unsure mail directory. Emails with a "spamicity" rank of 80% or
+higher will be sent to the *spam* directory (see #Assumptions section).
+
+[[exim-configuration]]
+== Exim Configuration
+
+[[routers]]
+=== Routers
+
+Routers in Exim do just what their name indicates: route email.
+Specifically, they route email to transports, but more on those in the
+link:#Transports[next section]. One thing to note on these before we get
+to the actual configuration part, routers in Exim are all executed, in
+sequence, until the email is either denied or delivered.
+
+Note: To give the reader a better idea of where the spam-related routers go, I
+      have included the router names for the defaults to provide context.
+      Spam-related routers are listed in bold.
+
+./etc/mail/exim.conf
+----
+begin routers
+...
+dnslookup:
+...
+#
+# BOGOFILTER router
+#
+# Routes all mail to spam@domain.tld to the bogo_spam_transport
+bogo_setspam_router:
+  driver = accept
+  condition = ${if eq {$local_part}{spam} {yes}{no}}
+  transport = bogo_spam_transport
+
+# Runs the received email through as a neutral status to be scanned.
+bogo_check_router:
+  no_verify
+  check_local_user
+  domains = +local_domains
+  condition = ${if !eq {$received_protocol}{bogodone} {1}{0}}
+  driver = accept
+  transport = bogo_check_transport
+
+...
+system_aliases:
+...
+user_forward:
+...
+
+# Delivers bogo spam mail to the spam directory
+localuser_bogo_spam:
+  driver = accept
+  check_local_user
+  condition = ${if match{$h_X-Bogosity:}{Spam.*}{1}}
+  transport = local_delivery_spam
+  cannot_route_message = Unknown user
+
+# Delivers bogo unsure mail to the unsure directory
+localuser_bogo_unsure:
+  driver = accept
+  check_local_user
+  condition = ${if match{$h_X-Bogosity:}{Unsure.*}{1}}
+  transport = local_delivery_unsure
+  cannot_route_message = Unknown user
+
+...
+localuser:
+...
+----
+
+What we just did here is create four new routers. Here's what each does.
+
+bogo_setspam_router:: Sends emails sent to "spam@domain.tld" to the
+bogo_setspam_transport.
+
+bogo_check_router:: Sends _all_ emails to the bogo_check_transport.
+
+localuser_bogo_spam:: Sends all email to the local_delivery_spam transport.
+
+localuser_bogo_unsure:: Sends all email to the local_delivery_unsure transport.
+
+Those explanations make routers seem like they don't do much at all, and
+without corresponding transports, that would be true. Routers only serve to
+route mail that matches certain criteron to the appropriate transports.
+
+
+[[transports]]
+=== Transports
+
+Transports in Exim perform actions (you might also call these __drivers__).
+They are not processed unless an email is sent to them by a router.
+Consequently, they can be placed anywhere aned in any order within the
+*transports* section of the Exim config file.
+
+./etc/mail/exim.conf
+----
+begin transports
+...
+# Bogofilter will add X-Bogosity header to all incoming mail. This can go
+# anywhere in the transport section, usually at the very end after
+# address_reply
+bogo_check_transport:
+  driver = pipe
+  command = /usr/bin/exim -oMr bogodone -bS
+  use_bsmtp = true
+  headers_add = X-Bogofilterd: true
+  transport_filter = /usr/bin/bogofilter -d /home/mail/bogofilter -l -p -e -u
+  return_fail_output = true
+  group = mail
+  user = exim
+  home_directory = "/home/mail/bogofilter"
+  current_directory = "/home/mail/bogofilter"
+  log_output = true
+  return_path_add = false
+
+# This adds updates the bogofilter database with this email explicitely set as
+# spam (intended for spam@domain.tld)
+bogo_setspam_transport:
+  driver = pipe
+  command = /usr/bin/bogofilter -d /home/mail/bogofilter -s -l
+  use_bsmtp = true
+  return_fail_output = true
+  group = mail
+  user = exim
+  home_directory = "/home/mail/bogofilter"
+  current_directory = "/home/mail/bogofilter"
+  log_output = true
+
+
+# Called when delivering mail to the spam directory
+local_delivery_spam:
+  driver = appendfile
+  directory = $home/Mail/.spam
+  maildir_format
+  maildir_use_size_file
+  delivery_date_add
+  envelope_to_add
+  return_path_add
+
+# Called when delivering mail to the unsure directory
+local_delivery_unsure:
+  driver = appendfile
+  directory = $home/Mail/.unsure
+  maildir_format
+  maildir_use_size_file
+  delivery_date_add
+  envelope_to_add
+  return_path_add
+----
+
+We just added four transports.
+
+bogo_check_transport:: Uses the _pipe_ driver. Essentially, this one is a
+  passthrough transport. It takes the email text and sends it through the
+  bogofilter binary with a neutral status. The bogofilter binary inserts a few
+  headers into the email as it processes, and then returns. The most important
+  of these headers for our purposes is the X-Bogosity header. This one will be
+  used later on for delivering mail to the correct directory.
+
+bogo_setspam_transport:: This transport also uses the _pipe_ driver. It is
+  called by the bogo_setspam_router, which only catches email sent to
+  "spam@domain.tld". The intent of this router is to mark all emails sent
+  through it explicitely as spam. This is so users can foward a spam email the
+  filters missed to "spam@domain.tld" and the filter will update itself to
+  assume the text in the received email is "spammy".
+
+local_delivery_spam:: This transport is a final delivery transport (the
+  appendfile driver). All email sent through this transport will be delivered
+  to the destination user's "spam" directory.
+
+local_delivery_unsure:: This transport is a final delivery transport (the
+  appendfile driver). All email sent through this transport will be delivered
+  to the destination user's "unsure" directory.
+
+
+[[a-few-examples]]
+== A Few Examples
+
+There are a few possible paths a given email could take through this system.
+
+
+[[a-spammy-email]]
+=== A Spammy Email
+
+If you get, for instance, an email that bogofilter would indicate is spam.
+Here's how its path would go using the previous configurations.
+
+. Exim receives the email. The bogo_setspam_router is skipped because the email
+  was sent to you, not spam@example.com
+
+. The next router in line, bogo_check_router, is used because it catches all
+  email. It routes the email through the bogo_check_transport transport.
+
+. The bogo_check_transport has been called and thus pipes the email through
+  the bogofilter binary
+
+. The bogofilter binary inserts the *X-Bogosity* header. In the case of this
+  email which is most likely spam, it will insert "X-Bogosity: Spam".
+
+. Exim continues through the routers since the email still has not been
+  delivered.
+
+. The next router in line is localuser_bogo_spam. It checks that the email
+  header "X-Bogosity" is equal to "Spam". In this case, the
+  bogo_check_transport inserted this header and value, and so this router sends
+  the email through the localuser_delivery_spam transport.
+
+. The localuser_delivery_spam transport (being called by the
+  localuser_bogo_spam), delivers the email to the user's spam directory.
+
+
+[[an-aspiring-spammy-emaill]]
+=== An Aspiring Spammy Emaill
+
+[[a-hammy-good-email]]
+=== A Hammy (Good) Email
+
+If anyone has questions about this post, please ask your question on the
+link:{{TALKPAGENAME}}[discussion page] and I'll try to get this updated with
+explanations. Setting up a mail server is hard enough for new folks, without
+adding the extra complication of spam filtering (I'm fairly new to this
+myself), so please ask any and all questions.
+
+
+
+Category:Mail
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Git:Care_Free_Committing.ascii b/src/Git:Care_Free_Committing.ascii
new file mode 100644
index 0000000..2e518c3
--- /dev/null
+++ b/src/Git:Care_Free_Committing.ascii
@@ -0,0 +1,97 @@
+Git:Care-free Committing
+========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+In the past, I have found myself a bit afraid to fully use git, because git
+history is something so painful to rewrite, especially when the repo is shared
+by other users. Besides, it just seems bad practice (and it is) to rewrite
+history.
+
+With true code, my concerns are a bit alleviated because most of the time you
+can test that locally. The situation I'm referring to is using git as a
+deployment mechanism for servers. Let me walk you through my old thought
+process.
+
+I want to try a new change for particular server type. I have two options. I
+can just log into the server and try out my change, hoping the one that I
+commit as a "copy-paste" later into the git repo works identically, or I can
+make the change inside the git repo, push it upstream, triggering the test
+deployment, which I can (and should) test with. However, what if the change
+doesn't work? I can fix it sure, but I'll muck up the history with unecessary
+"Broke it...fixed it" commits, and removing those will require rewriting
+history.
+
+
+== Branching
+
+Git is well known for its "cheap branching". Because it makes it so easy to
+rebase and merge onto any given branch.
+
+
+== Squashing Commits
+
+Firstly, find the first commit of your branch. We'll assume that this branch
+came off of master and that we are currently working inside this branch (if
+not, run +git checkout <branchname>+)
+
+----
+git log master..HEAD
+----
+
+That command will give you a list of all commits that have happened on your
+feature branch ahead of the master branch. Assuming someone hasn't rewritten
+history (which has happened to me before...ugh), you should be looking at only
+your branch's commits. Scroll to the bottom and copy the commit id for the very
+first commit in the series.  
+
+Now run...
+
+----
+git rebase -i <commit_id>^1
+----
+
+Don't forget the "carrot 1" (+^1+) at the end there, as it is very important.
+We just told git to rebase the commit series on top of the most recent commit
+from master (the "carrot 1" says "one commit before this commit", hence one
+commit before your work started since you selected your first branch commit),
+interractively. Iterractive mode gives us a chance to tell git how to handle
+each commit, be it picking, squashing, editing, rewording, etc.
+
+Running the interractive rebase should bring you into an editor with text that
+looks something like...
+
+----
+pick e57d408 Implemented new ifcfg profile functionality
+pick cd476e8 Fixed minor issue
+pick 96a112b Fixed another stupid issue
+pick 9741e2c Testing a small change
+pick ec32a51 Revert "Testing a small change"
+pick 5d61d26 Revert "Fixed another stupid issue"
+...
+----
+
+Here we can change what we want to do with each commit as the rebase proceeds.
+In this case, I want to reduce my commit set down to one commit, the most
+recent (note in your set, the most recent is on the bottom).
+
+----
+pick e57d408 Implemented new ifcfg profile functionality
+s cd476e8 Fixed minor issue
+s 96a112b Fixed another stupid issue
+s 9741e2c Testing a small change
+s ec32a51 Revert "Testing a small change"
+s 5d61d26 Revert "Fixed another stupid issue"
+...
+----
+
+It doesnt matter what the commit messages are at this point. When the time
+comes to merge the commits, you'll get a chance to rewrite the commit message. 
+
+Category:Git
+Category:Drafts
+
+// vim: set syntax=asciidoc:
diff --git a/src/Git_Basics.ascii b/src/Git_Basics.ascii
new file mode 100644
index 0000000..03af5d3
--- /dev/null
+++ b/src/Git_Basics.ascii
@@ -0,0 +1,220 @@
+Git Basics
+==========
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Git can be a very complicated thing. Someone once told me that we mere humans
+have a very difficult time with it at first. I myself have had a
+tremendous<nowiki>[ly difficult]</nowiki> time learning how to use Git (many
+thanks to http://marktraceur.info/[marktraceur] for all the help).  It is an
+incredibly robust and so a very complicated solution. What source code
+management system isn't though (especially one that is command line)? This
+document should serve as a very high level view of how to use Git. It will not
+cover advanced functionality such as
+http://git-scm.com/docs/git-cherry-pick[cherry-picking],
+http://git-scm.com/docs/git-merge[merging],
+http://git-scm.com/docs/git-rebase[rebasing], etc. If something is not
+documented here, please see the http://git-scm.com/docs[Git docs] or suggest it
+on the discussion page.
+
+[[working-with-branches]]
+Working with Branches
+---------------------
+
+Branches in Git look are like tree branches. The Git repository itself is the
+trunk and the branches are the various projects in the repository. Typically
+(hopefully) these projects are related to each other. In the case of a
+development project with a frequently changing database schema that you wanted
+to back up, the repository would have two branches: the files branch where the
+code files are stored, and the database branch where the database dumps are
+stored.
+
+[[viewing-branches]]
+Viewing Branches
+~~~~~~~~~~~~~~~~
+
+Viewing branches is simple. Type *git branch* and you should see output
+similar to the following:
+
+----
+$ git branch
+
+* database
+  master
+----
+
+To use a different branch, a the checkout command is required. In this case, we
+will switch from the _database_ branch to the _master_ branch.
+
+Note:Some decompression happens here so if the branch to be checked out is very
+     large, this will likely take a few seconds.
+
+----
+$ git checkout master
+
+Checking out files: 100% (6110/6110), done.
+Switched to branch 'master'
+----
+
+[[commits]]
+Commits
+-------
+
+Git does not have commitmentphobia. In fact, it loves commits as if it were its
+only purpose in life.
+
+In most if not all source code management software, a commit is essentially a
+set of changes to be merged into the master repository.
+
+To create a commit, there are several steps that need to take place.
+
+Firstly, the changed files to be pushed to the repository need to be added. For
+this, we use the _git add_ command.
+
+----
+$ git add ./ex1.blah
+$ git add ./example2.blah
+----
+
+One handy bit for this is the _-A_ switch. If used, git will recursively add
+all files in the specified directory that have been changed for the commit.
+This is very handy if many files were changed.
+
+----
+$ git add -A .
+----
+
+Once the changes files are set up for commit, we just need one more step. Run
+_git commit_ and you will be taken to a text editor (likely vi
+- specified in the repository configuration) to add comments on your commit so
+  you and other developers know what was changed in your commit in case
+something is broken or someone wants to revert.
+
+_This piece is key if you are using the git repository as a code repository
+rather than a versioning repository for backups. Please write in meaningful
+comments._
+
+There is actually one more piece to committing a change if you have a remote
+repository on another box or a different location on the local box. So other
+developers can pull the repository and get your changes, you need to _push_
+your changes to the remote repository. Please see the
+link:#Pushing_Changes_to_the_Remote_Repository[Pushing Changes to a Remote
+Repository] section for more information on this. To do this, we use the _git
+push_ command.
+
+
+[[logs]]
+Logs
+----
+
+All of this commit and commit log business is a bit worthless if we can't look
+at logs. To look at the logs we use the _git log_ command.  This will open up
+your system's pager (typically less is the one used) to view the logs for the
+current branch. If you wish to view the logs on a different branch, you can
+either check out that branch, or you can type __git log BranchName__.
+
+A handy option for the _git log_ command is the _--name-status_ switch.  If you
+use this switch, git will list all of the commit logs along with all of the
+files affected and what was done (modified, deleted, created, renamed) in each
+individual commit.
+
+
+[[remote-repositories]]
+Remote Repositories
+-------------------
+
+Git is a distributed code versioning system which means that every person that
+has pulled the repository has a complete copy of the original. This is really
+great for working remotely because you don't have to be online and able to talk
+to the remote repository to see change history.
+
+
+[[adding-a-remote-repository]]
+Adding a Remote Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Git needs several things to add a remote repository. Firstly, it needs a
+local alias for the remote repository. It also needs a username to log
+in to the repo with, as well as the ip address or hostname of the
+repository, and the path to the actual repo directory on the remote
+server. With that, to add a remote repository the command looks somewhat
+like this:
+
+----
+git remote add origin gitman@someserver.org:repos/CleverProjectName
+----
+
+Now, let's break down what that all means since it seems a tad complicated.
+
+[cols=",,,,,",options="header",]
+|===========================================================================
+|git remote |add |origin |gitman |@someserver.org | :repos/CleverProjectName
+|This is the command to work with remote servers in git.
+|Tells git we are adding a remote
+|The local alias for the remote. Origin is typically used here.
+|The username to log in to the remote server with.
+|This is the server where the repo is stored
+|This is the path to the actual repository directory. Since it does not start
+ with a / it starts in the home directory of gitman (~/).
+|=======================================================================
+
+[[fetching-a-remote-repository]]
+Fetching a Remote Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that we have a remote repository added to our local git repository, we
+simply need to fetch the repo. To do this we use the _git fetch_ command. Here
+is where that alias from the remote add command comes in handy.
+
+----
+git fetch origin
+----
+
+This command will fetch all branches of the origin repository.
+
+[[pushing-changes-to-the-remote-repository]]
+Pushing Changes to the Remote Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that we have a local copy of a repository to work on and have made some
+changes, some amount of code synchronization needs to take place with an origin
+repository so each of the developers can have the latest-and-greatest. With
+that, a commit only pushes code to your local copy of the repository. What
+needs to happen after a commit is to push the change to the origin repository
+so everyone else will also have access to your change set. To do this, we use
+the _git push_ command.
+
+There are two parameters for this though. The first is the local alias for the
+remote repository (typically referred to as origin since presumably the remote
+server is where your repository originated). The second parameter is the branch
+name. Since we often have more than one branch, this is a good piece to pay
+attention to so you don't submit a database dump file to the code branch.
+
+----
+git push origin master
+----
+
+
+[[dealing-with-size-issues]]
+Dealing with Size Issues
+------------------------
+
+Since git is a code versioning system that contains as many versions of a file
+as the number of commits, its size can grow out of hand rather quickly,
+especially when dealing with binaries. Luckily, there is a handy command for
+this very situation: **git gc**.
+
+This command compresses all of your repository branches in the context of each
+other. This can reduce the size of your local and/or remote repositories very
+effectively. I have a repository that should be several gigabytes with about 60
+commits per branch (it's a repo used for versioned backups), and _git gc_
+reduced it to about 370 megabytes.
+
+
+Category:Git
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:Formatting_a_Hard_Drive.ascii b/src/Linux:Formatting_a_Hard_Drive.ascii
new file mode 100644
index 0000000..51ef09b
--- /dev/null
+++ b/src/Linux:Formatting_a_Hard_Drive.ascii
@@ -0,0 +1,108 @@
+Linux:Formatting a Hard Drive
+=============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Good afternoon everyone or good evening/morning, depending on which time zone
+you're reading this from...
+
+*Ahem*
+
+Good afternoon from GMT -7 everyone (much better),
+
+If you've done anything with Linux-based servers you have most likely at one
+time or another had to format a hard drive, which unfortunately can be quite
+the feat in Linux if you're not too comfortable with the command line (which if
+you're a linux sys admin, you shouldn't be). In this post, I will be describing
+how to format an ENTIRE drive (doing a portion is a bit more complicated...post
+in the comments section if you want to see a post on how to do a partial
+format).
+
+[[finding-which-drive-to-format]]
+== Finding which drive to format
+
+To start off, we need to find the disk that needs to be formatted. Do this by
+typing
+
+----
+sudo fdisk -l
+----
+
+If the disk has not been formatted you should
+see
+
+----
+Disk /dev/ doesn't contain a valid partition table.
+----
+
+If the drive has already been formatted you need to either identify the drive
+by the amount of space (the blocks column...it's in kilobytes. For example:
+249023502 is roughly 250 gigabytes). Another method is to use
+
+----
+mount -l
+----
+
+The drive should show up as **/dev/ on /media/**.
+
+
+[[formatting-the-drive]]
+== Formatting the drive
+
+To start up the format process, let's type
+
+----
+fdisk /dev/sdc
+----
+
+(sdc is our example drive. The drive you want to format was found in the
+previous step).
+
+If your drive already has a partition table, you need to delete that. Do this
+by typing the letter *"d"* and pressing enter.
+
+If the drive is NOT formatted yet, all you need to do here is press the letter
+**"n"**.
+
+Fdisk will now prompt you to give it a start and end block for the partition
+(this is essentially how much of the drive to create the partition table for).
+If you want to format the entire drive, just hit enter twice to select the
+defaults (the first and the last blocks...the entire drive).
+
+Now that we've selected which parts of the drive to format, press *"w"* to
+write the changes to the disk (up to this point, no changes have been made so
+if you want to get out, now is the time).
+
+Now that we've formatted the drive and created the partition table, we can
+mount the drive. To mount the drive, there are two options.
+
+First, the drive can be removed and plugged back in. This will cause an
+auto-mount (if that's enabled on your machine). The other way is to use the
+mount command. To do this, we need a mount point. This can simply be a folder
+where your drive will show up (without getting too complicated). For this
+example, I'll put a folder at *.
+
+Now, earlier when we formatted the hard drive, we formatted the drive located
+at* (drive sdc partition 1). Now, with that out of the way, let's mount
+partition one.
+
+Type *
+
+What that does is mount partition one (/dev/sdc1) at *.
+
+Many people say practice makes perfect. With that, go practice formatting on
+all of your hard drives and usb sticks.   :)
+
+Once again...
+
+*Disclaimer: I am not responsible for any loss of data or damage to
+personal property due to attempting the contents of this article.*
+
+
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:Luks_Password_Changing.ascii b/src/Linux:Luks_Password_Changing.ascii
new file mode 100644
index 0000000..96e3790
--- /dev/null
+++ b/src/Linux:Luks_Password_Changing.ascii
@@ -0,0 +1,43 @@
+Linux:Luks Password Changing
+============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Given my most recent posts about Linux Linux:System_Encryption[system
+encryption] and Linux:dm-crypt_Encrypted_Home_Directories[encrypted home
+directories], I think this post is a good followup since account passwords
+should be changed routinely.
+
+I use http://code.google.com/p/cryptsetup/wiki/DMCrypt[dm-crypt] with a
+http://code.google.com/p/cryptsetup/[LUKS header] for my work computer's
+encryption. It uses my Active Directory password for the luks password.  While
+my Windows password is a very safe one, Windows NTLM
+https://securityledger.com/2012/12/new-25-gpu-monster-devours-passwords-in-seconds/[is
+not the most secure hashing algorithm] on the planet, but I digress.
+
+I just changed my password at work after 3 months of use, which means I've got
+to update my LUKS header with the new key and remove the old one (it still
+works fine, I just want one password for my logins). Yes, this is in the man
+page, but I thought I'd post this here for anyone too lazy (like myself) to
+hunt through the man page. It turns out there is a change key feature of
+cryptsetup.
+
+----
+luksChangeKey <device>
+----
+
+If you run that command, it will ask you for the old password. Type that in and
+if it matches, you will be prompted to enter the new password twice. Once
+that's done, there's no need to umount and remount. The next time the volume is
+remounted though, it will require the new password.
+
+
+Category:Linux
+Category:Security
+Category:Encryption
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:RAID_Setup.ascii b/src/Linux:RAID_Setup.ascii
new file mode 100644
index 0000000..e9455cc
--- /dev/null
+++ b/src/Linux:RAID_Setup.ascii
@@ -0,0 +1,253 @@
+After fighting with the problem detailed in my Btrfs:RAID_Setup[ last
+post] about this, I decided to go hunting for information about RAID 5
+implementation in btrfs. It turns out that it hasn't been completely
+implemented yet. Given the status verbage on their wiki page, I'm
+surprised it works at all. I suspect the wiki isn't entirely up to date
+though since it does seem to work to a certain extent. I still need to
+do more research to hunt this down though.
+
+You can find that wiki post
+https://btrfs.wiki.kernel.org/index.php/Project_ideas#Raid5.2F6[here].
+
+[[the-new-new-solution]]
+== The NEW New Solution
+
+Since RAID 5/6 is not yet completely implemented in Btrfs, I need to find
+another solution. Given that I still want redundancy, the only other obvious
+option I thought I had here was a
+http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1[RAID 1] configuration.
+However, as many Google searches do, searching for something leads to something
+else very interesting. In this case, my search for Linux RAID setups sent me
+over to the official kernel.org
+https://raid.wiki.kernel.org/index.php/Linux_Raid[RAID page], which details how
+to use http://en.wikipedia.org/wiki/Mdadm[mdadm]. This might be a better option
+for any RAID level, despite Btrfs support since it will detatch dependency on
+the filesystem for such support. Everyone loves a layer of abstraction.
+
+[[setup---raid-5]]
+=== Setup - RAID 5
+
+Let's get the RAID array set up.
+
+----
+mdadm -C /dev/md0 -l raid5 -n 3 /dev/sdb1 /dev/sdc1 /dev/sdd1
+# Or the long version so that makes a little more sense...
+mdadm --create /dev/md0 --level raid5 --raid-devices 3 /dev/sdb1 /dev/sdc1 /dev/sdd1
+----
+
+
+[[setup---raid-1]]
+=== Setup - RAID 1
+
+----
+mdadm -C /dev/md0 -l raid1 -n 3 /dev/sdb1 /dev/sdc1 /dev/sdd1
+# Or the long version so that makes a little more sense...
+mdadm --create /dev/md0 --level raid1 --raid-devices 3 /dev/sdb1 /dev/sdc1 /dev/sdd1
+----
+
+
+[[what-just-happened]]
+=== What Just Happened?
+
+[cols=",,,",options="header",]
+|=======================================================================
+|mdadm |-C,--create /dev/md0 |-l,--level raid5 |-n,--raid-devices 3 /dev/sdb1 /dev/sdc1 /dev/sdd1
+|
+|Create a virtual block device at /dev/md0
+|Set the raid level to RAID 5 for our new device
+|The number of RAID devices is 3 - /dev/sdb1, /dev/sdc1, and /dev/sdd1.
+|=======================================================================
+
+
+[[the-rest]]
+=== The Rest
+
+We did just create a RAID array and a virtual device to map to it, but that's
+all. We still need a filesystem. Given that this whole series of posts has been
+about using Btrfs, we'll create one of those. You can still use whatever
+filesystem you want though.
+
+----
+mkfs.btrfs /dev/md0
+mount /dev/md0 /mnt/home/
+----
+
+
+[[mounting-at-boot]]
+=== Mounting at Boot
+
+Mounting at boot with mdadm is a tad more complicated than mounting a typical
+block device. Since an array is just that, an array, it must be assembled on
+each boot. Thankfully, this isn't hard to do. Simply run the following command
+and it will be assembled automatically
+
+----
+mdadm -D --scan >> /etc/mdadm.conf
+----
+
+That will append your current mdadm setup to the mdadm config file in /etc/.
+Once that's done, you can just add /dev/md0 (or your selected md device) to
+/etc/fstab like you normally would.
+
+
+[[simple-benchmarks]]
+== Simple Benchmarks
+
+Here are some simple benchmarks on my RAID setup. For these I have three
+1TB Western Digital Green drives with 64MB cache each.
+
+
+[[single-drive-baseline]]
+=== Single Drive Baseline
+
+[[ext4]]
+==== Ext4
+
+1GB Block Size 1M (1000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test.img bs=1M count=1000
+1000+0 records in
+1000+0 records out
+1048576000 bytes (1.0 GB) copied, 4.26806 s, 246 MB/s
+----
+
+1GB Block Size 1K (1000000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test2.img bs=1K count=1000000
+1000000+0 records in
+1000000+0 records out
+1024000000 bytes (1.0 GB) copied, 6.93657 s, 148 MB/s
+----
+
+
+[[raid-5]]
+=== RAID 5
+
+[[btrfs]]
+==== Btrfs
+
+1GB Block Size 1M (1000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test.img bs=1M count=1000
+1000+0 records in
+1000+0 records out
+1048576000 bytes (1.0 GB) copied, 3.33709 s, 314 MB/s
+----
+
+
+1GB Block Size 1K (1000000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test2.img bs=1K count=1000000
+1000000+0 records in
+1000000+0 records out
+1024000000 bytes (1.0 GB) copied, 7.99295 s, 128 MB/s
+----
+
+[[ext4-1]]
+==== Ext4
+
+1GB Block Size 1M (1000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test.img bs=1M count=1000
+1000+0 records in
+1000+0 records out
+1048576000 bytes (1.0 GB) copied, 12.4808 s, 84.0 MB/s
+----
+
+1GB Block Size 1K (1000000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test2.img bs=1K count=1000000
+1000000+0 records in
+1000000+0 records out
+1024000000 bytes (1.0 GB) copied, 13.767 s, 74.4 MB/s
+----
+
+[[raid-1]]
+=== RAID 1
+
+[[btrfs-1]]
+==== Btrfs
+
+1GB Block Size 1M (1000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test.img bs=1M count=1000
+1000+0 records in
+1000+0 records out
+1048576000 bytes (1.0 GB) copied, 3.61043 s, 290 MB/s
+----
+
+1GB Block Size 1K (1000000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test2.img bs=1K count=1000000
+1000000+0 records in
+1000000+0 records out
+1024000000 bytes (1.0 GB) copied, 9.35171 s, 109 MB/s
+----
+
+
+[[ext4-2]]
+==== Ext4
+
+1GB Block Size 1M (1000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test.img bs=1M count=1000
+1000+0 records in
+1000+0 records out
+1048576000 bytes (1.0 GB) copied, 8.00056 s, 131 MB/s
+----
+
+1GB Block Size 1K (1000000 blocks)
+
+----
+[root@zion home]# dd if=/dev/zero of=./test2.img bs=1K count=1000000
+1000000+0 records in
+1000000+0 records out
+1024000000 bytes (1.0 GB) copied, 9.3704 s, 109 MB/s
+----
+
+
+Those aren't exactly dazzling write speeds, but they're also not too bad, given
+what's happening in the background and that I'm using three standard 7200 rpm
+desktop drives with 64MB of cache a piece. Later down the line I might test
+this with a RAID 0 to see what the max speed of these drives are (though it
+should predictably be three times the current speed).
+
+
+[[final-thoughts]]
+== Final Thoughts
+
+My favorite thing about this at this point is the layer of abstraction doing
+RAID through mdadm provides (we all know how much Linux folk love modularity).
+Using the RAID functionality in Btrfs means I am tied to using that filesystem.
+If I ever want to use anything else, I'm stuck unless what I want to move to
+has its own implementation of RAID.  However, using mdadm, I can use any
+filesystem I want, whether it supports RAID or not. Additionally, the setup
+wasn't too difficult either. Overall, I think (like anyone cares what I think
+though) that they've done a pretty great job with this.
+
+Many thanks to the folks who contributed to mdadm and the Linux kernel that
+runs it all (all 20,000-ish of you). I and many many other people really
+appreciate the great work you do.
+
+With that, I'm going to sign off and continue watching my cat play with/attack
+the little foil ball I just gave her.
+
+
+
+Category:Linux
+Category:Btrfs
+Category:Ext4
+Category:Storage
+Category:RAID
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:Secure_Authentication.ascii b/src/Linux:Secure_Authentication.ascii
new file mode 100644
index 0000000..9b21934
--- /dev/null
+++ b/src/Linux:Secure_Authentication.ascii
@@ -0,0 +1,264 @@
+Linux:Secure Authentication
+===========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+:github: https://github.com/nullspoon/
+
+
+== {doctitle}
+
+**Edit**: I wrote the script for automating this finally. It can be found on my
+link:{github}/keymanage[GitHub].
+
+In my experience, Linux authentication seems to be one of those problems with
+so many answers. It's hard to define even a range of methodologies that could
+be considered right, let alone narrowing it down to one or two. I've been
+dealing with this one at work quite a bit recently at work and would like to
+post here an idea I had. Just to be warned, this idea was not accepted for our
+solution, despite no one being able to give me more than one reason to not use
+it, which I will detail at the end of this post along with any other exploits I
+can imagine for this authentication methodology.
+
+[[in-a-perfect-world...]]
+== In a perfect world...
+
+In a perfect world, chroot environments would work securely and our app
+developers and third party vendors would write code on par with apache or
+openssh which could be started as root and spawn child processes in user space
+for security. All application files would fit nicely into the defined standards
+for Linux filesystem organization so we could package everything up nicely and
+deploy using repo servers. To top it all off, all applications would roll their
+own logs instead of filling up /var/log or somewhere on / since they rarely
+follow standards. However, this is rarely if ever the case (I've never seen it
+at least).
+
+What I've seen up to this point is third party applications that install
+themselves exclusively in /opt; applications that are hard coded to not start
+unless running as uid 0 (root); binary startup scripts that situate themselves
+in /etc/rc.d/init.d/ (wtf guys?), and just general stubborness as to where the
+program is located.
+
+[[securing-an-application-server]]
+== Securing an Application Server
+
+The first step I typically take to securing applications is to run them in user
+space as a service account with access only to its directory in the /apps mount
+point. I put that one to use on my own servers and it has served me very well.
+However, with this we have a few problems.
+
+[[accessing-service-accounts]]
+== Accessing Service Accounts
+
+While security does tend to introduce complications and interruptions into
+workflow, it shouldn't be catastrophic. If your security measures are so
+strict, your users can't do what they need to, you're doing it wrong. Simply
+running in userspace introduces several problems. A few for example...
+
+1. How do your users get to their service accounts in a secure way (no shared
+   passwords or keys)?
+
+2. How do your users transfer files to and from their servers since they can't
+   directly access the service accounts?
+
+3. How do you manage this web of shared account access without it consuming
+   much of your time?
+
+Specifically, a solution is needed for the users to access their service
+accounts in an accountable and auditable way without hindering their ability to
+do their jobs [too much].
+
+This has been a problem myself and some fellow engineers have struggled with
+for a while now. Here's a few common service account authentication mechanisms
+that I'm sure we've all seen that aren't necessarily the greatest.
+
+
+[[service-account-passwords]]
+=== Service Account Passwords
+
+1.  They need to be shared for multiple users to have access
+
+2.  They can be shared without the admins knowing (no accountability)
+
+3.  They have to be routinely changed which causes a huge headache for everyone
+    involved, os and app admins alike
+
+
+[[service-account-keys]]
+=== Service Account Keys
+
+1.  They need to be shared for multiple users to have access
+
+2.  They can be shared without the admins knowing (no accountability)
+
+3.  They have to be routinely changed which causes a slightly lesser headache
+    than passwords for everyone involved, os and app admins alike
+
+
+[[sudo]]
+=== Sudo
+
+Sudo provides a pretty clean solution to the problem. It allows you to
+limit who has access to the service account as well log who uses it and
+when. Just put your application admins into their own group and give
+that group explicit access to run ONE command...
+
+[[sudo-su---service_account]]
+==== sudo su - service_account
+
+This one is tremendously popular for very obvious reasons. However, despite
+using sudo, this one still has problems
+
+1. Your end users can't perform file transfers between their boxes since can't
+   directly access their service accounts without a key or password
+
+2. We still lack accountability. Once the user is in a sudo'd shell, their
+   commands are no longer logged.
+
+3. Managing this across an environment can be a very time consuming thing
+   unless you have a source on a server that you propogate out, but then you
+   have to deal with server compliance.
+
+Granted, there is a pretty obvious _Unixy_ solution to this, but it involves
+your users all being in the same group as your service account, mucking around
+with umasks that unset themselves on reboot unless explicitely set, and making
+sure your sticky bit sticks.
+
+There is another way though.
+
+[[my-poorly-formed-idea]]
+== My Poorly Formed Idea
+
+My idea uses a combination of the crontab, jump hosts, ssh keys, and segregated
+networks.
+
+Start with two (or more) segregated networks: one for administration, and
+several for operations. You will probably want three for operations:
+production, QA, and dev.
+
+From there, you put your servers in your operations networks and set up
+firewall or routing rules to only allow ssh (port 22 or whatever port you
+prefer) traffic between the administration network and the operations networks.
+Your operations networks should now only be accessible for users using the
+applications and admins coming in from the administration network using ssh.
+
+Next, build out a jump box on your administration network. One per application
+would be ideal for seperation of concerns, but one for all apps should work
+well also. For sake of simplicity, we'll assume a single jump host.
+
+Next, put all of your service accounts on that jump host with their own home
+directories in /apps. This assumes you have defined and reserved UIDs and GIDs
+for each of your service accounts so they can be on one system without
+conflicts. Provide sudo access to each user group to _sudo su -
+<service_account>_ into their respective service accounts on the jump host.
+
+At this point, the application admins/owners still don't have access to their
+service accounts on the operations servers. Here's where they get that access
+using rotating ssh keys. Write a script to generate ssh keys (I'll post the
+source for mine later), ssh out to a box using the key to be replaced, push the
+new key, and remove the old key and any others while using the new key. This
+allows you to schedule key changes automatically using cron. With that in
+place, just have the script swap out each service account's key every x minutes
+(15 or 30 is what I have in mind). Once you've got the key exchange working,
+modify the sshd_config files throughout your environment to disallow all user
+login over ssh with passwords, that way if your users do set a password to try
+to circumvent your security, it won't be accepted anyways. You can also just
+disable password changing.
+
+[[pros]]
+== Pros
+
+[[operations-networks-become-a-black-box]]
+=== Operations Networks Become a Black Box
+
+With this method, there is only one way in to every single operations
+box. That one way in is in a secured subnet, presumably accessible only
+through a vpn or when on site.
+
+[[file-transfers-are-seamless]]
+=== File Transfers are Seamless
+
+Users can use scp or sftp to transfer files seamlessly using the jump host as
+the medium. If the keys are always regenerated as id_rsa, or the ssh config
+file is set up for each account, key regeneration won't affect anyone because
+it takes milliseconds to overwrite the old key with the new one, so any new
+connections out will use the new key. End users shouldn't even see an effect.
+
+[[safety-despite-turnover]]
+=== Safety Despite Turnover
+
+If your company has any measure of turnover, you've undoubtedly gone through
+the password and key change process after an employee leaves the team. With
+this method, you're automatically changing the key every X minutes, so even if
+they do get the key, it'll only be valid for a very short while.
+
+[[lower-licensing-costs]]
+=== Lower Licensing Costs
+
+Many companies, through the use of additional software such as Open LDAP,
+Samba, or some other third party product, put their Linux/Unix servers on their
+Windows Domain. A perk of this is it provides access to Linux to your AD users
+without having to manage a few hundred or thousand passwd, group, and shadow
+files. The downside to this is that if a third party product is used, it costs
+a lot of money in licenses.  With the jump host rotating key model, you can put
+just the jump host(s) on the domain, and leave all operations servers off of
+the domain. It saves on licensing costs, maintainence time, and software
+installs. It also removes yet one more service running on your operations boxes
+which removes one more access point for exploitation. Additionally, the fewer
+pieces of software running on a server, the less chance an update will break
+the applications it's hosting.
+
+
+[[clean-home-directories]]
+=== Clean Home Directories
+
+Next up, clean home directories. If you have an entire team of developers
+and/or application admins logging into every operations system, /home is going
+to be very large on lots of systems, costing money for backups (if you back
+home directories up that is), wasting storage space (which is fairly cheap
+these days though), and adding spread to your users's files, making it
+cumbersome for everyone to manage, including non system admins. With the jump
+host rotating key method, all of your home directories are on one host, so file
+management for the support staff is much easier.
+
+
+[[cons]]
+== Cons
+
+
+[[single-point-of-failure]]
+=== Single Point of Failure
+
+This is the one objection I heard from people at work. This can be
+mitigated in at least two ways. One is by having one jump host per
+application. It still beats putting hundreds or thousands of systems in
+AD and all the management and licensing costs that goes with that.
+Another way to mitigate this is to have a seconday jump host and set up
+rsync to synchronize the primary jump host with the backup, using the
+backup as a hot standby.
+
+
+[[single-point-of-global-access]]
+=== Single Point of Global Access
+
+This is the one problem with this idea that I think is most relevant and
+potentially exploitable. However, if your administration boxes are on a network
+that is not reachable from anywhere but controlled locations, this shouldn't be
+too big of a deal. However, if a mistake is made in the networking security or
+routing and a malicious user gets to a jump host, they still have to get into
+the service accounts which are inaccessible except through sudo, which means
+the malicous user has to exploit an existing account. Without that account's
+password though, they can't sudo so they would only have access to that one
+user's files.  Even if they could sudo though, they will still only have access
+to the service accounts that user works with, so their impact would be minimal
+unless that user works on very high profile applications. To sum it up, there
+are three very solid security measures in place (network segretation, user
+accounts, limited sudo access requiring passwords) that the malicious user has
+to get through before having any really impacting access.
+
+
+Category:Linux
+Category:Security
+Category:Authentication
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:System_Encryption.ascii b/src/Linux:System_Encryption.ascii
new file mode 100644
index 0000000..e9ff71b
--- /dev/null
+++ b/src/Linux:System_Encryption.ascii
@@ -0,0 +1,155 @@
+Linux:System Encryption
+=======================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+As mentioned in a Linux:dm-crypt_Encrypted_Home_Directories[previous post], I
+use dm-crypt with a luks header and the pam-mount module to encrypt and mount
+the home directories on my laptop and server. While this works fantastically,
+it does have a potential fatal flaw, which is that my operating system is
+readily available to a would-be attacker.  For instance, if they were skilled
+enough (which I am not), they could modify the any number of applications on my
+system to, quitely dump or send my encryption key password the next time I
+mount my home directory, thus defeating my security. Further, my system is
+readily available for any linux user good with mounting and chroot knowledge
+(which is probably most of us), and thus one could do all kinds of mischief on
+the unencrypted system partition of my computer.
+
+I'm sure this is a bit tin-foil hatted of me. I have nothing to hide (though
+it's not about that, it's a matter of principle). Further, there is no one
+[_that I know of_] who would be *that* interested in me or my data. Despite,
+this is a very cool thing that I am doing purely because it can be done (in
+slang I believe the term is "the cool factor").
+
+[[a-preliminary-note]]
+== A Preliminary Note
+
+I would not recommend this be done for servers or multi-user laptops or
+desktops. This process requires that a password be typed or a key be available
+every time the system is booted, which requires physical presence to do so.
+Since most servers are administered and used remotely over a network, a reboot
+would me a service outtage until someone were able to open a local terminal to
+type the password (to say nothing about having to share the password with
+multiple people).
+
+[[overview]]
+== Overview
+
+Due to the scope of this post and that I don't want to focus on documenting
+some other tasks that are more generic and less related to the actual
+encryption of the system, I will not be covering how to back up your system or
+to partition your drive. However, please see the following two notes.
+
+During the installation process we will...
+
+. Set up encryption
+. Modify the grub defaults so it properly sets up the loop device on boot
+. Modify the Initramfs Configuration (this one is Arch Linux specific)
+
+[[setting-up-encryption]]
+Setting Up Encryption
+~~~~~~~~~~~~~~~~~~~~~
+
+We're going to assume here that the system partition will be installed
+on sda2. With that, let's "format" that with luks/dm-crypt.
+
+WARNING: Again, back up your data if you haven't already. This will irrevocably
+         destroy any data on the partition [unless you are good with data
+         recovery tools].
+
+----
+cryptsetup luksFormat /dev/sda2
+----
+
+And so our installation can continue, the loop device needs to be set up and a
+filesystem created
+
+----
+# Open the encrypted container to the system map device (though you can name it whatever you want)
+cryptsetup luksOpen /dev/sda2 system
+# ...Type the password
+# Create the filesystem here - I use btrfs
+mkfs.your_choice /dev/mapper/system
+# Mount the filesystem
+mount /dev/mapper/system /mnt/ # Or wherever your distro's installation mount point is
+----
+
+Now that this is done, it's time to re-install or copy from backups your system
+to the new encrypted container.
+
+[[modifying-the-grub-defaults]]
+Modifying the Grub Defaults
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that the system partition is setup up and our system re-installation is
+complete, it's time to configure Grub so it knows the system partition is
+encrypted. Without this step, you won't get past the initramfs since an
+encrypted system partition without a password is effectively useless. Here I
+will again assume your system partition is on /dev/sda2..
+
+Change...
+
+./etc/default/grub
+----
+...
+GRUB_CMDLINE_LINUX_DEFAULT="quiet"
+...
+----
+
+...to ...
+
+./etc/default/grub
+----
+...
+
+GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=/dev/sda2:system quiet"
+...
+----
+
+
+[[modifying-the-initramfs-configuration]]
+Modifying the Initramfs Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This part is oriented towards https://archlinux.org[Arch Linux].  Modifying the
+initramfs generation configuration is something that varies from distribution
+to distribution. I run Arch, so Arch it is!  (let me know though if you want to
+know how to do it on another distribution and I'll figure it out and update the
+post).
+
+This is actually very simple on Arch. Simply open _/etc/mkinitcpio.conf_
+and edit the *HOOKS* line. What matters here is that the *encrypt* hook
+occurs _before_ the *filesystems* hooks.
+
+./etc/mkinitcpio.conf
+----
+...
+HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck"
+...
+----
+
+Once you've done that, save and close the config file and run
+
+----
+mkinitcpio -p linux
+----
+
+You should be able to now reboot your system and it will prompt you for a
+password immediately after grub. If you were successful, you should be brought
+to a screen that looks something like...
+
+[role="terminal"]
+----
+A password is required to access the sda volume:
+
+Enter passphrase for /dev/sda2:_
+----
+
+
+Category:Encryption Category:Security
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:Vpnc_Restart_Script.ascii b/src/Linux:Vpnc_Restart_Script.ascii
new file mode 100644
index 0000000..d7f7d0a
--- /dev/null
+++ b/src/Linux:Vpnc_Restart_Script.ascii
@@ -0,0 +1,47 @@
+Linux: VPNC Restart Script
+==========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+The VPN at my company is very... spotty... at best. When working from home, it
+used to boot you about once every hour. For whatever reason though, it has
+recently started booting sessions every five minutes.  Now, the solution is of
+course to speak with our networking folks rather than to write a script to fix
+the issue on a client by client basis.  Unfortunately, due to the culture and
+various political situations, the networking folks will not fix this because
+they don't believe it's an issue. All opinionattion aside, this sounds like an
+opportunity for a nice shell script.
+
+To start things off, on my Linux box I use vpnc from the command line as I
+don't want to install network manager due to additional resource consumption
+(albeit a very small amount). That said, throw the following script in
++~/bin/vpnconnect+ and include +~/bin+ in your PATH variable (+export
+PATH=~/bin:$\{PATH}+).
+
+[[source]]
+== Source
+
+_Edit_: Found a pretty sizeable flaw in my script. Pulled the source until I
+can sort it out.
+
+
+[[order-of-operations]]
+== Order of Operations
+
+. Check if vpnc is already running
+  * Start if it is not running
+. Start an infinite loop
+  . Sleep 5 to keep from using too many resources
+  . Check cpu time on pid - if it is greater than 1 minute
+    * Kill pid and restart vpnc
+
+
+
+Category:Linux
+Category:Drafts
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux:dm-crypt_Encrypted_Home_Directories.ascii b/src/Linux:dm-crypt_Encrypted_Home_Directories.ascii
new file mode 100644
index 0000000..8ee0e94
--- /dev/null
+++ b/src/Linux:dm-crypt_Encrypted_Home_Directories.ascii
@@ -0,0 +1,213 @@
+Linux:dm=crypt Encrypted Home Directories
+=========================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+There are three primary methods for encrypting one's home directory seamlessly
+in Linux: http://en.wikipedia.org/wiki/Dm-crypt[dm-crypt],
+http://ecryptfs.org/[eCryptFS], and http://www.arg0.net/encfs[EncFS].  All
+differences aside, this post will cover dm-crypt (as indicated by the title of
+course). A few things to note before going forwards though.  First, this method
+is by no means the standard. I'm not even sure if there is a standard way to do
+this. This is just the way I've done it and it has worked out swimingly thus
+far on more than one computer.  Secondly, my method detailed here will use
+something called http://code.google.com/p/cryptsetup/[LUKS]. I highly recommend
+this, if not just for convenience. While it does have its pitfalls, they
+shouldn't be too bad if you keep a backup of your data. Really though, when
+encrypting, you should _always_ keep more than one copy of your data in case
+something goes awry.
+
+Before proceeding, here is a list of what this will give you once completed, so
+you can decide if this is what you want before reading this monolithic post .
+
+. Users will each have their own encrypted home directory.
+  * Each home directory will be unlocked using the user's own password.
+  * Users have complete storage anonimity. Even root can't tell how many
+    files they are storing, filenames, or even how much data they have unless
+    the user is logged in at the time of inspection.
+. User's home directories will be seamlessly decrypted and mounted at login.
+. Users will have their own virtual device, so they will have a storage
+  "quota". To expand it, the virtual device needs to be extended on its own
+  (some might consider this cumbersome).
+
+
+[[setup]]
+== Setup
+
+This should be relatively simple. Install a package likely called *cryptsetup*
+(most of the mainstream distros should have it). This is the utility we will be
+using to manage dm-crypt volumes. Note also that cryptsetup can be used for
+managing more than just dm-crypt and luks. It also works with Truecrypt (much
+to my excitement a few months ago when I needed to extract some data from a
+Truecrypt volume, but didn't want to install it becuase of all the suspicion
+surrounding it lately).
+
+[[modifying-pam]]
+=== Modifying PAM
+
+[[etcpam.dsystem-auth]]
+==== /etc/pam.d/system-auth
+
+This piece assumes your distribution puts this file here and that it is named
+this. Unfortuantely, I can't really write this part to be distribution-agnostic
+as most of them do this differently to an extent.  The contents of the file
+will likely look similar, despite its name. For anyone wondering though, this
+section is written from an Arch Linux instance.
+
+Open /etc/pam.d/system-auth in your favorite editor. Be sure to do this either
+with sudo or as root or you won't be able to save your changes.
+
+Here we need to put in calls to a module called pam_mount.so so it will be
+called at the right time to pass the user's password to the mount command,
+allowing for seamless encrypted home directory mounting. Pay attention to where
+the calls to pam_mount.so are. Order is very important in this file.
+
+NOTE: Many distributions use eCryptFS as their default encryption for home
+      directories. They do it this way as well, but using pam_ecryptfs.so
+      instead of pam_mount.so.
+
+./etc/pam.d/system-auth
+----
+#%PAM-1.0
+
+auth      required  pam_unix.so     try_first_pass nullok
+auth      optional  pam_mount.so
+auth      optional  pam_permit.so
+auth      required  pam_env.so
+
+account   required  pam_unix.so
+account   optional  pam_permit.so
+account   required  pam_time.so
+
+password  optional  pam_mount.so
+password  required  pam_unix.so     try_first_pass nullok sha512 shadow
+password  optional  pam_permit.so
+
+session   optional  pam_mount.so
+session   required  pam_limits.so
+session   required  pam_unix.so
+
+session   optional  pam_permit.so
+----
+
+
+[[etcsecuritypam_mount.conf.xml]]
+==== /etc/security/pam_mount.conf.xml
+
+This is the configuration file used by pam_mount when the user logs in.
+Depending on your distribution, it may or may not already be set up the way we
+need for this.
+
+Just before the +</pam_mount>+ at the end of the xml file, insert the following
+lines.
+
+./etc/security/pam_mount.conf.xml
+----
+...
+
+<volume fstype="crypt" path="/home/.%(USER)" mountpoint="/home/%(USER)" options="space_cache,autodefrag,compress=lzo" />
+<mkmountpoint enable="1" remove="true" />
+
+</pam_mount>
+----
+
+Before proceeding, there are a couple of assumptions that I need to mention
+about the way I do this here.
+
+. My home directories are all formatted with btrfs. If you're not using that,
+  then remove the *autodefrag,compress=lzo* piece in the options section.
+
+. The encrypted block device files are located at */home/.USERNAME* (note the
+  dot).
+
+
+[[creating-an-encrypted-home-per-user]]
+=== Creating an Encrypted Home Per User
+
+The creations of each user's home directory has a few fairly simple steps [if
+you've been using linux command line for a bit]. For the sake of more succinct
+directions, here we will assume a username of __kevin__.
+
+. Allocate user's encrypted home space (assuming 15 gigs)
+  * +dd if=/dev/zero of=/home/.kevin bs=1G count=15+
+  * This command writes 15 gigabytes of zeros to one file, /home/.kevin
+
+. Encrypt the user's home device
+  * +cryptsetup luksFormat /home/.kevin+
+  * This command will require the user to enter _their_ password when
+    prompted after running the command, as that will be what is passed to
+    the file container on login.
+
+. Open the user's new home device (you'll need the user to enter their password
+  again)
+  * +cryptsetup luksOpen /home/.kevin kevin+
+  * This will only be needed the first time around. Kevin can't use this
+    yet becasue it doesn't have a filesystem and it can't be mounted for the
+    same eason.
+
+. Format the opened dm-crypt device
+  * +mkfs.btrfs /dev/mapper/kevin+
+  * This is assuming you want to use btrfs. Otherwise you'd use mkfs.ext4
+    or some other filesystem of choice.
+
+. Cleanup
+  * +cryptsetup luksClose kevin+
+  * In this case, _kevin_ can be the alias given to the opened device on
+    luksOpen. You can also provide its path at /dev/mapper/kevin.
+
+
+[[how-it-works]]
+== How it Works
+
+When a user logs in, they type their username and password. Those are passed to
+pam, which verifies the user's identity using the _pam_unix.so_ module. If the
+credentials provided by the user are correct, the next step is to pass that
+username and password to the _pam_mount.so_ module. This module runs the
+commands dictated in the pam_mount.conf.xml. The commands pam mount runs (as
+per our earlier configuration) are effectively
+
+----
+cryptsetup luksOpen /home/.$\{username} _home__$\{username} mount /dev/mapper/_home__$\{username} /home/%\{username}
+----
+
+Those commands open the dot file (/home/.username) for the given user with the
+recently provided password. It then mounts that user's decrypted dot file at
+the user's home directory (/home/username).
+
+
+[[backups]]
+== Backups
+
+This kind of encryption makes backups a bit difficult to pull off as the
+administrator. Because you don't have each user's password, you can't back up
+their data. This leaves you with one option - back up the encrypted block
+devices themselves. Depending on how much space each user is given, this can
+take a long time (though rsync helps significantly with that) and a lot of
+space. This is the downside to
+https://wiki.archlinux.org/index.php/Encryption#Block_device_encryption[block
+device encryption].
+https://wiki.archlinux.org/index.php/Encryption#Stacked_filesystem_encryption[Stacked
+encryption] though, while rumored to be less secure for various reasons, allows
+administrators access to encrypted verions of each user's data.  With stacked
+encryption, each individual file's contents are encrypted, but the user's
+filenames, paths, and file sizes are still accessible to the administrator(s)
+(hence the rumored security flaw).
+
+As a user though (if you're using this on your laptop for instance), backups
+are simple because the data itself is available to you (you have the password
+after all). This however assumes you have user rights on a remote server to
+rsync your data to. Even if the remote server has the same dm-crypt setup,
+rsync still sends your credentials, so your data can go from an encrypted
+laptop/desktop to an encrypted server.
+
+
+
+Category:Storage
+Category:Security
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Linux_Storage_Devices,_Partitions,_and_Mount_Points_Explained.ascii b/src/Linux_Storage_Devices,_Partitions,_and_Mount_Points_Explained.ascii
new file mode 100644
index 0000000..58d6a70
--- /dev/null
+++ b/src/Linux_Storage_Devices,_Partitions,_and_Mount_Points_Explained.ascii
@@ -0,0 +1,131 @@
+Linux Storage Devices, Partitions, and Mount Points Explained
+=============================================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Earlier today I was talking with a guy in the Ubuntu IRC channel (shout out to
+codemagician!) who was asking how to format a USB stick via the command line.
+Through explaining how it worked, I realized that to someone who isn't already
+very familiar with Linux, the way Linux handles drives can be very confusing,
+especially since you can control almost every step of the mounting process,
+unlike with Windows, which is why Windows is so easy (albeit less functional
+however).
+
+What do you say I do a post on how Linux handles storage devices? Yes?  No?
+Great!
+
+[[the-quick-overview]]
+The Quick Overview
+------------------
+
+When you plug in a USB stick (for example) to your linux machine, it is
+assigned a device location (/dev/sd<something>). From there, that new device is
+assigned a mount point (assuming we are using Ubuntu here many Linux distros
+won't auto mount a storage device, even if it is internal). This mount point
+can be located anywhere, but typically is located in /media/. From the folder
+created in /media (or wherever the mountpoint is located), you can indirectly
+read and write data.
+
+[[the-dev-directory]]
+The /dev/ Directory
+-------------------
+
+The /dev/ directory is an interesting one to explain. I probably won't do it
+right, but I'll give it a shot either way. Dev is short for devices. If you
+run ls from within /dev/ you will likely see things like sda, sdb, hda, and
+more and more devices.
+
+What do these mean? Basically, each of the files listed in /dev/ is a direct
+pointer to either a physical or a virtual device. This part is actually super
+cool I think. Basically, when you transfer say, a picture, to your usb stick,
+the operating system literally writes the instructions for writing the file (in
+binary) to the device location/file (/dev/sdb for instance), which in turn
+writes it to the USB stick. You may say that's not that neat, but consider your
+audio device. When your music player (amarok, rhythmbox, etc) plays music, it
+literally streams the music file's uncompressed binary audio to the audio
+device file and that is in turn translated by the hardware driver and converted
+into speaker vibrations.
+
+You can actually try this by running a quickie command in the command line. The
+audio device is typically located at /dev/dsp. Pick a file on your hard drive
+that you want to "listen" to (it is likely going to sound like static), and run
+the following command. For this example, I'm going to use a jpeg image.
+
+----
+cat /home/username/Desktop/background.jpeg > /dev/dsp
+----
+
+What we just did there was to redirect the file contents of background.jpeg
+into the device pointed to by /dev/dsp. Mine sounds like static for some time
+(It's a really high resolution jpeg).
+
+If THAT isn't cool, I don't know what is.
+
+
+[[mount-points]]
+Mount Points
+------------
+
+Once your storage device is assigned a device location (IE: /dev/sdb), it then
+needs a mount point that interfaces with the device location. In a less
+complicated fashion, you need a folder that represents the drive.  For
+instance, say you plug in your usb stick named Maverick (that's one I formatted
+last night). Ubuntu creates a temporary folder located at /media/Maverick/.
+That became the mount point for my usb stick. All a mount point is, generally
+speaking (I'll get into the technicalities of it in the next paragraph), is
+simply a folder that points to a device location. Ubuntu, Mint, as well as
+Debian all default to creating folders in /media/.
+
+
+[[so-what-do-mount-points-and-device-locations-have-anything-to-do-with-each-other]]
+So what do mount points and device locations have anything to do with each other?
+---------------------------------------------------------------------------------
+
+Here's where it gets pretty technical (so much so that I don't fully know how
+this works). Succinctly, a mount point provides an interface that your
+operating system uses to convert data into binary for writing directly to the
+device location. That means that when you copy a picture file to your usb stick
+(IE: /media/Maverick), your operating system converts it to binary and streams
+said binary to the device location associated (IE: /dev/sdb1) with that mount
+point.
+
+[[why-sdabcdef...]]
+Why sda,b,c,d,e,f...?
+---------------------
+
+The sd part of that stands for storage drive. The a, b, c, etc. is simply an
+incrementing value assigned to your drive. If you plug in a usb drive, it will
+be assigned sdb. If you plug in a second, it will be assigned sdc. If you plug
+in a third, it will be assigned sdd, and so on.
+
+[[how-do-you-explain-the-number-at-the-end-of-my-device-locations-ie-devsdb1]]
+How do you explain the number at the end of my device locations (IE: /dev/sdb1)?
+--------------------------------------------------------------------------------
+
+That number represents the partition. For instance, your local hard drive is
+device sda (presumably it was the first drive to be plugged in since your
+computer is running off of it). Your hard drive has partitions (these are like
+virtual sections in your hard drive with them you can divide your hard drive
+into one or more pieces mine is divided into 8 actually). Typically usb sticks
+only have one partition.
+
+That's all for now. I think I covered just about everything. If i missed
+anything, please let me know in the comments section and I'll add it on as soon
+as I get the chance.
+
+Now if you will all excuse me, I was at work at 2:00 this morning and
+desperately need sleep. Don't break too many things on your computer by
+redirecting file output to random devices now. I'm watching you...really.
+http://xkcd.com/838/[So is Santa].
+
+:)
+
+
+
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Migrating_from_Drupal_7_to_Habari_.8.ascii b/src/Migrating_from_Drupal_7_to_Habari_.8.ascii
new file mode 100644
index 0000000..1d2e5cf
--- /dev/null
+++ b/src/Migrating_from_Drupal_7_to_Habari_.8.ascii
@@ -0,0 +1,91 @@
+Migrating from Drupal 7 to Habari .8
+====================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Lately I've been trying out the latest release of
+http://habariproject.org/[Habari] and I really like it. They have created a
+very simple, yet functional and very clean interface with which to blog (not to
+mention its code implements the newest of just about everthing). With that,
+bitnode used to be run on Drupal, so converting from elenty billion 'articles'
+(that's the technical number) to posts in Habari was not looking too easy.
+After some searching, I found that the best way to convert without having to
+write some sql statements would be to migrate from Drupal 7 to Drupal 6, then
+from Drupal 6 to Wordpress 2.3; then from Wordpress 2.3 to Habari .8.
+
+What?
+
+So it seemed that manually copying the data from column to column with sql
+statements would be my best route. After some time (and so so many browser
+tabs), I finally came up with some queries that would migrate you from Drupal 7
+to Habari .8. Please keep in mind that these will not migrate all of your data.
+These are only for migrating your posts and their related comments.
+
+Assumptions:
+
+* Habari instance table prefix is habari_
+* Drupal instance table prefix is drupal_
+* Our author user id is 2
+
+
+----
+- Move our posts over using the drupal ids so we can relate our comments later
+insert into `habari_posts` (id, title, slug, content, user_id, status, pubdate, updated) select nid,title,title,body_value, 2, status,  created, changed from drupal_node join drupal_field_data_body on drupal_node.nid=drupal_field_data_body.entity_id;
+----
+
+Here we are doing a simple insert into habari_posts from another table.
+However, due to Drupal's robust database structure (not sure if it's 3NF), we
+have to query another table for our remaining post data as the meta-data (post
+subject, various dates, status, etc) is stored in the drupal_node table and the
+actual post is stored in the drupal_field_data_body table.
+
+Once again, in this query I have statically defined user id 2. You will need to
+change this to your user's ID in Habari who you want to show up as posting
+everything. If you need to import multiple user's posts, you will need to query
+for the Drupal user IDs and change the Habari user IDs to match the posts
+(that's the easiest way).
+
+----
+- update our drupal published status to the habari version
+update habari_posts set status=2 where status=1;
+- update our drupal draft status to the habari version
+update habari_posts set status=1 where status=0;
+----
+
+Here we are just converting our post statuses from
+Drupal values to Habari values. In Habari, status 1 is published and
+status 0 is draft (as of 2011.12.30).
+
+----
+-Now we migrate our comments
+insert into habari_comments (post_id, name, email, url, ip, content, status, date) select nid, name, mail, homepage, hostname, comment_body_value, status, created from drupal_comment join drupal_field_data_comment_body on drupal_comment.cid=drupal_field_data_comment_body.entity_id;
+----
+
+Here we are grabbing the comments for each of the posts. Since we pulled in all
+the post IDs from the Drupal tables in our first query, we can do the same here
+and everything should line up perfectly. Once again, like with the posts,
+Drupal stores comment data in more than one table. In Drupal, the comment
+meta-data is stored in the drupal_comment table and the actual comment data is
+stored in the drupal_field_data_comment_body table.
+
+And that should be it. You've just migrated all of your post and comment data
+to Habari .8. If you have any images used in your posts, you will also need to
+copy Drupal's *sites/default/files/* directory to the root directory of your
+Habari instance.
+
+If anyone tries this out, please let me know how it worked for you. It worked
+fine for me (evidenced by the fact that bitnode is still viewable), but I'd
+like some input on how to better write these queries in case there are any
+additional fields I may have missed that people would be interested in. Thank's
+for reading!
+
+
+Category:Drupal
+Category:Habari
+Category:Blogging
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Mutt:Sorting_Mail_Like_a_Boss.ascii b/src/Mutt:Sorting_Mail_Like_a_Boss.ascii
new file mode 100644
index 0000000..ecf31f7
--- /dev/null
+++ b/src/Mutt:Sorting_Mail_Like_a_Boss.ascii
@@ -0,0 +1,61 @@
+Mutt:Sorting Mail Like a Boss
+=============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Mutt is a relatively difficult mail client to learn. However, as most if not
+all mutt users will tell you, once you've got the hang of it, no other mail
+client can come close to matching the efficiency and speed of command line mail
+(or any thing else in command line for the most part).  I recently started
+using mutt myself and just can't get over how efficient it is once you've got
+your configuration sorted out. Yesterday I easily cleaned out 800 emails in
+about five minutes using some very simple search terms (and no I didn't just
+delete randomly 800 emails).  Unlike the title of this post implies though, I
+am not amazing with mutt, but what I do know, however, can get me around very
+quickly.  Here's what I use nearly every day.
+
+
+[[tags]]
+=== Tags
+
+Mutt supports this neat thing called tagging. It's basically the command line
+equivelant of multiselect (ctrl+click or shift+click).
+
+**To tag a message**, move the cursor to it and hit the _t_ key.
+
+**To tag a group of emails based on a pattern**, for example "Change Requests",
+hit capital __T__. You will see at the bottom of your mutt window __Tag
+messages matching:__. Type your tag term, hit enter, and you should see several
+highlighted messages now.
+
+Finally, **to peform an action on all tagged messages**, preceed the command
+letter (s for save/move, d for delete, N for new, etc) with a semicolon ( ; ).
+For instance, do delete all tagged messages, type __;d__.
+
+
+[[limit-filter]]
+=== Limit (Filter)
+
+In mutt, you can do this really cool (though not novel in the slightest) thing
+wherein you filter the displayed messages by a regular expression.  You don't
+have to use a regular expression of course, but never the less it can be done.
+
+**To limit/filter the currently displayed emails**, head over to a directory
+you want to get a better filtered look at and press the _l_ key. You will see
+at the bottom of your mutt window ''Limit to messages matching: ''. Type
+whatever you want to limit to.
+
+Note here though that limit by default only searches mail meta data unless
+otherwise specified. This makes searches go much faster since most of the time
+you're just cleaning up your inbox by subject, receivers, and date. If you do
+want to search the body of your emails, preceed your search term with __~B__,
+and mutt will go the extra mile and search email bodies for you.
+
+
+Category:Linux
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/My_.bashrc.ascii b/src/My_.bashrc.ascii
new file mode 100644
index 0000000..938e44b
--- /dev/null
+++ b/src/My_.bashrc.ascii
@@ -0,0 +1,40 @@
+Not that any of you care that much, but I thought I might post my .bashrc file
+as it evolves in case anyone is looking for something I have in mine. I have
+made quite a few of them and ultimately end up cleaning them out entirely on
+occasion to start over so I can keep it clean with only the things I need.
+
+That said, here's what we've got so far. The initial contents at the top are
+from the Arch Linux skel file.
+
+I'll keep updating this as I make changes.
+
+----
+#
+# ~/.bashrc
+#
+ 
+# If not running interactively, don't do anything
+[[ $- != *i* ]] && return
+ 
+alias ls='ls --color=auto'
+PS1='[\u@\h \W]\$ '
+ 
+# My modifications
+export TERM=xterm-256color
+ 
+# This will spawn a new tmux instance as our "shell" if tmux isn't already
+# running
+if [[ -z $TMUX ]]; then
+        exec tmux
+else
+        echo
+fi
+----
+
+
+
+Category:SSH
+Category:Bash
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Running_Load_Tests_with_a_Remote_VSTS_Controller_and_Associated_Agents.ascii b/src/Running_Load_Tests_with_a_Remote_VSTS_Controller_and_Associated_Agents.ascii
new file mode 100644
index 0000000..b696e5b
--- /dev/null
+++ b/src/Running_Load_Tests_with_a_Remote_VSTS_Controller_and_Associated_Agents.ascii
@@ -0,0 +1,51 @@
+Running Load Tests with a Remote VSTS Controller and Associated Agent
+=====================================================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Running a multi-agent load test isn't too complicated, compliments of Visual
+Studio Team Suite. Assuming you have a controller/agent environment set up,
+running the actual test requires a bit of modification to the test project so
+the local test machine doesn't run the test itself; rather it runs them on a
+remote machine (the controller and its agents). To set this up...
+
+[[load-in-your-test-project]]
+Load in your test project
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+image:files/01_Open_Test.jpg[height=300]
+
+* At the top of the window, select *Test -> Edit Test Run Configurations ->
+  Local Test Run (localtestrun.testrunconfig)*
+  +
+  image:files/02_Edit_Test_Run_Configurations.jpg[height=250]
+
+* Select *Controller and Agent* at the top left. Select the '''Remote''' radio
+  button. Select the controller.
+  +
+  image:files/03_Select_Controller.jpg[height=350]
+
+* Click **Apply**. Once you have selected Apply, you will receive a prompt
+  saying
+  +
+  image:files/04_Answer_Prompt.jpg[height=140]
+
+* Click *Ok*
+
+* Click *Close*
+
+Once all of that is done, it's time to run your test. You'll notice that once
+your test has been run, at the bottom left side of the results you'll see a
+reference to the remote controller and that it controlled X many agents.
+
+Happy Testing!
+
+
+Category:Microsoft
+Category:Visual_Studio
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/SQL_2008_Reinstall_Errors.ascii b/src/SQL_2008_Reinstall_Errors.ascii
new file mode 100644
index 0000000..2cb6715
--- /dev/null
+++ b/src/SQL_2008_Reinstall_Errors.ascii
@@ -0,0 +1,91 @@
+SQL 2008 Reinstall Errors
+=========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Hello again all, Recently, after the server build was 'finished', I discovered
+that the SQL install was not configured to use the proper authentication method
+or service accounts (oops) and without mixed mode authentication enabled,
+windows authentication could not be used to log in to sql to fix these things.
+That being said, I had to uninstall SQL 2008 (standard edition) and do a
+reinstall to correct these issues. Time to grab some popcorn and a drink and
+sit back to watch that entertaining progress bar as it slowly creeps across the
+tiny 800x600 virtual console window.
+
+I configured the SQL install and ran into an ambiguous error (how typical).
+
+----
+This access control list is not in canonical form and therefore cannot be modified.
+----
+
+How quaint. Thankfully, after searching for a few minutes with our friend
+Google, I stumbled upon a Microsoft feedback article that seemed to contain my
+answer.
+
+Here's what needs to be done.
+
+Navigate in an explorer window to
+
+C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log
+
+The link at the end of this post to the Microsoft feedback article says that
+from there you open up the "**details.txt**" file. I found that that folder
+actually contained 11 folders (from the current install and the previous
+install) and a file called "summary.txt". I found the right "**details.txt**"
+file in the most recently created folder.
+
+Once you've located the right "details.txt" file, open it up in notepad (or
+your editor of choice) and scroll to the end of the file (it's pretty big so
+use the scroller bar). Near the end, you should see some text that looks
+similar to...
+
+----
+2009-05-30 18:02:40 Slp: Sco: Attempting to set directory full path
+2009-05-30 18:02:40 Slp: Sco: Attempting to normalize directory path C:Program FilesMicrosoft SQL Server100COM
+2009-05-30 18:02:40 Slp: Sco: Attempting to check if directory C:Program FilesMicrosoft SQL Server100COM exists
+2009-05-30 18:02:40 Slp: Sco: Attempting to set security descriptor for directory C:Program FilesMicrosoft SQL Server100COM, security descriptor D:(A;OICI;FRFX;;;S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582)
+2009-05-30 18:02:40 Slp: Sco: Attempting to check if directory C:Program FilesMicrosoft SQL Server100COM exists
+2009-05-30 18:02:40 Slp: Sco: Attempting to normalize security descriptor D:(A;OICI;FRFX;;;S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582)
+2009-05-30 18:02:40 Slp: Sco: Attempting to replace account with sid in security descriptor D:(A;OICI;FRFX;;;S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582)
+2009-05-30 18:02:40 Slp: ReplaceAccountWithSidInSddl -SDDL to be processed:  D:(A;OICI;FRFX;;;S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582)
+2009-05-30 18:02:40 Slp: ReplaceAccountWithSidInSddl -SDDL to be returned:  D:(A;OICI;FRFX;;;S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582)
+2009-05-30 18:02:40 Slp: Prompting user if they want to retry this action
+----
+
+The text you're looking for is the directory path listed after the text
+
+----
+Attempting to normalize directory path
+----
+
+Open up another explorer window and navigate to (not inside) the directory that
+is specified after the previous quote. Right click the directory (in this case,
+the directory is COM within the directory 100) and select "*" tab. Windows
+should give you an error that says something along the lines of the permissions
+being out of order and might not be effective (sorry...I forgot to copy that
+error).
+
+Click "*" window to close it out as well.
+
+Go back to your installer now and click "*" on the error window.
+
+I had to fix two directories. The guy in the Microsoft feedback article said he
+had to fix five directories. That being said, this may need to be done more
+than once.
+
+That about sums this up. The article I found that helped me get started fixing
+this can be found here:
+
+http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=355216
+
+Dirk
+
+
+Category:Microsoft
+Category:MsSQL
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/SQL_Server_2008_Memory_Management.ascii b/src/SQL_Server_2008_Memory_Management.ascii
new file mode 100644
index 0000000..4125534
--- /dev/null
+++ b/src/SQL_Server_2008_Memory_Management.ascii
@@ -0,0 +1,72 @@
+SQL Server 2008 Memory Management
+=================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Once again, hello all: Recently I had a problem with SQL server. I was sifting
+through the processes in Task Manager a few days ago ordered by memory
+consumption. At the top of the list for memory consumption was SQL Server
+(sqlserver.exe) weighing in at 200 megabytes of memory. I decided to look past
+that one since 200 megabytes isn't too unreasonable for SQL, especially when
+it's hosting the data for quite a few SharePoint web applications.
+
+Today, I checked again. After my server had been online for two and a half
+days, SQL server had grown to over 650 megabytes of memory (653,224 KB
+specifically). Seeing as how I have not made any changes to my local SharePoint
+environment in that time (I'm currently developing a non-SharePoint related
+project), I decided to look into putting a cap on the memory consumption of
+SQL. Originally I had 2 gigabytes of ram for my server. I added an extra
+gigabyte to that and SQL took up the additional space.
+
+As it turns out, one can put a maximun and a minimum limit on SQL.  Here's how.
+
+Open up SQL Server Management Studio 2008
+
+Type in the information to connect to the server that has SQL server running on
+it and click connect.
+
+Right click the server name
+
+image:files/MgmtStudio1.jpg[height=400]
+
+Click Properties
+
+Select Memory on the left side of the window that comes up
+
+image:files/MgmtStudio2.jpg[height=400]
+
+Under Server Memory Options, adjust the minimum and maxiumum memory settings to
+what you need.
+
+Click OK
+
+Right Click the server name again
+
+Select Stop from the menu
+
+Click necessary buttons to get through the prompts
+
+Right Click the server name yet again
+
+Select Start from the menu
+
+Click the necessary buttons to get through the prompts
+
+And that's it. Mine (as in the screenshots) has yet to go over 300 megabytes of
+memory consumption.
+
+Thanks for reading.
+
+
+Dirk
+
+
+
+Category:Microsoft
+Category:MsSQL
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Securing_a_Postfix_Smtp_Server.ascii b/src/Securing_a_Postfix_Smtp_Server.ascii
new file mode 100644
index 0000000..79f20f5
--- /dev/null
+++ b/src/Securing_a_Postfix_Smtp_Server.ascii
@@ -0,0 +1,226 @@
+Securing a Postfix Smtp Server
+==============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+I must start this post with the acknowledgement that I know only what I've
+experienced on this topic.
+
+I recently set up my own mail server for the fun of it. I figured it was
+something I'd never done, so why not, right?
+
+Well, one day later, spammers discovered my server and began using it to send
+out spam mail (curse you spammers!). I didn't notice this until I received a
+notification from my hosting provider that my network IO was over the threshold
+I had set. I promptly logged in, tailed the mail logs and discovered
+unbelievable amounts of mail being rejected by Google, Yahoo, Aol, and Hotmail.
+Why? Spam.
+
+With that, I spent the next day figuring out how to better secure my smtp
+server. I'd like to detail some of the exploits that the spammers used to get
+in to my server, how I failed in configuring my server properly, and how I
+fixed it.
+
+[[leaving-an-open-relay]]
+Leaving an Open Relay
+~~~~~~~~~~~~~~~~~~~~~
+
+An open relay is basically an smtp server that requires no authentication
+and/or allows connections from outside ip addresses, so anyone can send emails
+from anywhere to anywhere. The settings in question specific to this issue in
+my configuration were the following:
+
+----
+smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains
+...
+mynetworks = 0.0.0.0/0 127.0.0.0/8 [::fff:127.0.0.0]/104 [::1]/128
+----
+
+Basically that is an open relay.  Here's why.
+
+* Firstly, *smtpd_recipient_restrictions = permit_mynetworks* allows any
+  email to be sent without any restrictions as long as the email originated
+  from a box in the IP ranges specified in the mynetworks variable.
+
+* Secondly, *mynetworks = 0.0.0.0/0* allows emails to be sent through my
+  smtp server from any client within the ip range of 0.0.0.0-255.255.255.255.
+  This is bad because any computer can try to send emails through my smtp
+  server and succeed because of the permit_mynetworks restriction (or lack
+  therof).
+
+[[specifying-incorrect-configuration-parameters]]
+Specifying Incorrect Configuration Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+One of my first mistakes when configuring Postfix was misspelling some smtpd
+parameters using smtp_ instead of smtpd_ to prefix them. As it turns out, if
+you do this, Postfix ignores your attempted configuration without a peep. This
+one went on for a long time before I noticed that two of my smtpd_ fields were
+missing the 'd'. As soon as I put those in there, everything started working as
+it should, albeit still insecure, but at least it was following the
+specifications of my config file.
+
+
+[[not-specifying-a-correct-smtpd_sasl_path]]
+Not Specifying a Correct smtpd_sasl_path
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This one took me a while. The *smtpd_sasl_path* is a path to the socket file
+for your SASL server. In my case, this is Dovecot.
+
+As it turns out, Postfix defaults to running in chroot mode which makes its
+root directory /var/spool/postfix/. This was my first mistake. I was specifying
+
+----
+smtpd_sasl_path = /var/spool/postfix/private/auth-client
+----
+
+and it was not starting up because it couldn't find the socket file. This was
+because it was looking for the file at
+/var/spool/postfix/var/spool/postfix/private/auth-client a path which clearly
+does not exist. The solution to this is to simply specify a relative path.
+
+----
+smtpd_sasl_path = private/auth-client
+----
+
+I decided that I would get smart though and shave off some text from the field
+value by configuring Dovecot to place the socket file at
+/var/spool/postfix/auth-client rather than at
+/var/spool/postfix/private/auth-client (speaking in absolute terms despite
+running in chroot mode). This returned the following error
+
+----
+warning: when SASL type is "dovecot", SASL path "auth-client" should be a socket pathname
+----
+
+As it turns out, postfix won't operate with the SASL socket file path outside
+of the private directory. So with that, I placed my auth-client file back in
+the private directory and Postfix started up fine.
+
+
+[[not-specifying-the-allowed-senders-file]]
+Not Specifying the Allowed Senders File
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Even if you do have authentication required, you still need to specify which
+users can send email with what addresses. This was a bit of a surprise to me
+initially because I was under the impression that a password is associated with
+an email address, not an email address(s) associated with a username and
+password. To keep users from being able to send email as addresses that are not
+theirs (specifically randomly generated addresses in my case), you need to
+create a mapping file that maps usernames to the addresses they are authorized
+to send mail as. In my case, this is a one to one relationship (one address per
+username).  Before my example I'd like to note that the filename is not
+required to be the one I use (though my filename is the one used in the Postfix
+setup documentation).
+
+Okay. Let's create the map file. To do this, open up and edit
+/etc/postfix/controlled_envelope_senders (this file likely doesn't exist yet)
+
+----
+vim /etc/postfix/controlled_envelope_senders
+----
+
+Once you've got that open, you simply need to put the maps in there.
+
+----
+# envelope sender owners jcricket@example0.com jimminey
+----
+
+Now that we've done that, we need to turn it into a binary. Run the following
+command and it will generate a <filename>.db binary map file in the same
+directory as the original file.
+
+----
+postmap /etc/postfix/controlled_envelope_senders
+----
+
+Presto! Now the user jimminey can send email as jcricket@example0.com. However,
+so can everyone else...still.
+
+Now that we have our controlled envelope senders file, we need to reference it
+in our postfix main.cf and set postfix up to restrict access to the maps
+specified in that file. Crack er open in your favorite editor and put the
+following line in somewhere after *smtpd_sasl_auth_enable*
+
+----
+smtpd_sasl_auth_enable = yes
+...
+# This line specifies our map file for use by postfix
+# Note that this does NOT reference controlled_envelope_senders.db
+smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
+# This line sets postfix to reject anyone who authenticates but tries to send email as an address they aren't permitted to use
+smtpd_recipient_restrictions = reject_sender_login_mismatch, permit_sasl_authenticated, reject_unauth_destination
+----
+
+So what we've just done is tell Postfix where our map file is
+(smtpd_sender_login_maps). After that, we tell Postfix to reject any users that
+have been authenticated but are trying to send with an address they aren't
+authorized to send with in our map file (smtpd_recipient_restrictions). Please
+note that *reject_sender_login_mismatch* comes at the beginning of the
+smtpd_recipient_strictions field. This is key. It is so key in fact, that I
+missed it (I only miss the key stuff of course thanks Murphy).  This was the
+forth exploit attempt that got me.
+
+
+[[misordering-smtpd_recipient_restrictions]]
+Misordering smtpd_recipient_restrictions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This one is the final bit that let the spammers in (so far at least).
+
+The smtpd_recipient_restrictions are restrictions that you can place on
+the users and their emails based on various things. In my case, I had
+the following restrictions string
+
+----
+smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_sender_login_mismatch, reject_unauth_destination
+----
+
+Postfix applies these restrictions in the order in which they are specified. As
+they put it <blockquote>Restrictions are applied in the order as specified; the
+first restriction that matches wins.</blockquote> As soon as one restriction
+matches, then the ones that follow don't get applied.  This was very
+problematic because in my case permit_mynetworks is first.  So that I can log
+in from my cell phone which has an IP address that changes, I set
+
+----
+mynetworks = 0.0.0.0/0 127.0.0.0/8 [::fff:127.0.0.0]/104 [::1]/128
+----
+
+which allows any IP address to connect to my SMTP server. Since Postfix takes
+the first match and goes no further and any IP address is in 0.0.0.0/0, anyone
+can send mail through my SMTP server. This = bad.
+
+What you should do is start your restrictions with the the most strict
+restrictions followed by the less strict. In my case, that looks like
+
+----
+smtpd_recipient_restrictions = reject_sender_login_mismatch, permit_sasl_authenticated, reject_unauth_destination
+----
+
+In the event someone tries to send an email, first they must login. If they
+don't log in, they are rejected due to reject_sender_login_mismatch (we can't
+do a match if we don't have a sender username). Secondly, once logged in, the
+user must be authorized to use the address they are trying to send as as
+specified in the smtpd_sender_login_maps line.  Finally, once the user has been
+authenticated and they have permissions to use the address they are trying to
+send as, their email is not rejected. It follows that they are then filtered
+through permit_sasl_authenticated. This basically runs a check to see if they
+are authenticated (which we know they already are because of the previous
+filter) and since they are, they are permitted and Postfix stops looking for
+more matches because it's found one that permits the user to perform their
+requested action.
+
+As chef Elzar says, "Bam!"
+
+
+Category:Linux
+Category:Postfix
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Server_Administration:Firewalls.ascii b/src/Server_Administration:Firewalls.ascii
new file mode 100644
index 0000000..9c7450f
--- /dev/null
+++ b/src/Server_Administration:Firewalls.ascii
@@ -0,0 +1,41 @@
+Server Administration:Firewalls
+===============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Hello again all, The majority of the servers that I manage have to communicate
+with many other servers I manage for various reasons.  Inevitably, I have many
+firewall blocking issues. Despite my age, I still have trouble remembering all
+of those commonly used ports and what they are for. That being said, this post
+will list all of the Windows default firewall ports used for the various
+software sources. Yes these are all readily available at other sites. This is
+simply a central collection.
+
+I will update this post when I have more blocks come up.
+
+Post comments if you would like to have a particular port added to the list.
+
+[cols=",",width="50%"]
+|===================================================
+|FTP                                           |21
+|HTTP                                          |80
+|HTTPS                                         |443
+|POP3                                          |110
+|SMTP                                          |25
+|SQL Server Management Studio (remote connect) |1433
+|Terminal Services                             |3389
+|VMWare Server Administration                  |8222
+|VMWare Server Administration (Secure)         |8333
+|===================================================
+
+Let me know in the comments section if there are any ports you would like added
+to this list.
+
+
+Category:Networking
+
+
+// vim: set syntax=asciidoc:
diff --git a/src/Sidebar.ascii b/src/Sidebar.ascii
new file mode 100644
index 0000000..f05a6be
--- /dev/null
+++ b/src/Sidebar.ascii
@@ -0,0 +1,5 @@
+- Navigation
+  - link:index.html[Main]
+  - link:about.html[About]
+
+// vim: set syntax=asciidoc:
diff --git a/src/Team_Password_Management.ascii b/src/Team_Password_Management.ascii
new file mode 100644
index 0000000..b48fb36
--- /dev/null
+++ b/src/Team_Password_Management.ascii
@@ -0,0 +1,112 @@
+Team Password Management
+========================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+A while back I started looking for alternate means to manage my passwords,
+specifically because I started playing more with pgp encryption. I thought it'd
+be neat to be able to use pgp to encrypt a password database and/or use git to
+version the passwords. It turns out that someone had the idea before I did: the
+developers of password-store.
+
+Password-store, or pass, is a [very impressive] command line bash script that
+uses git to version passwords, and pgp keys to encrypt/decrypt each password.
+Specifically to this post though, it implements support for something that
+pgp/gpg supports: the --encrypt-to switch.
+
+
+== gpg --encrypt-to
+
+The --encrypt-to switch for the gpg command allows for encryption of the given
+stream to multiple recipients. For the purposes of password management, it
+allows for each user of the password database to add their pgp key to the
+_.gpg-id_ file. The effect is that each subsequent save of the given password
+re-encrypts it using every pgp key listed in the .gpg-id file.
+
+Effectively, each user of the password repo can have their own password (the
+password to their pgp privat key), whilst not knowing the passwords other
+members are using. This means that if for example, an employee leaves the
+company, the remaining repo members can just remove that person's key from the
+\.gpg-id file, and all further changes (regenerations) of the passwords will
+not be encrypted with the departed employee's key, thus revoking their access.
+
+
+== Setup
+
+Setup for this is fairly simple, if you're accustomed to using git and gpg/pgp.
+The commands for pass are very intuitive.
+
+To create a pass database (assuming you already have it installed), execute...
+
+----
+pass init user@gpg-id-to-be-used.com
+----
+
+To add other user's pgp keys, just add their ids to the .gpg-id file located at
+\~/.password-store/.gpg-id. Each password created after that will be encrypted
+to each user listed in that file.
+
+Note: Remember that each key that you're adding to the .gpg-id file must at
+      least have marginal trust in gpg.
+
+
+== Questions
+
+=== What about arbitrary users adding themselves to .gpg-id?
+
+The nice thing about gpg is that it will not allow usage of the --encrypt-to
+switch (amongst other switches) without a measure of trust given the key in
+question. This means that if any user does add their key to the .gpg-id file,
+every subsequent password change will yield an error, indicating that the
+password file cannot be encrypted to the given untrusted key.
+
+Another perk to pass is that it versions all changes to the password "database"
+in git, so the user who added their key to the .gpg-id file will have left a
+log entry (assuming they didn't rewrite history to conceal their subterfuge),
+and thus they can be dealt with appropriately.
+
+
+=== What if I want to run more than one database?
+
+Add the following to your .bashrc file.
+
+----
+#
+# Function to override calls to pass binary. Allows for multiple password-store
+# backends. Based on the first argument given to "pass", selects a different
+# password store backend.
+#
+# Example Usage:
+#   # Will edit default password-store foo
+#   pass edit foo
+#
+#   # Will edit alternate, team, password-store foo
+#   pass team edit foo
+#
+function pass {
+  alt='team'
+  if [[ ${1} == ${alt} ]]; then
+    export PASSWORD_STORE_DIR=~/.password-store.${alt}
+    # Shift off the first argument
+    shift
+  else
+    export PASSWORD_STORE_DIR=~/.password-store
+  fi
+
+  # Call the actual binary
+  /usr/bin/pass ${@}
+}
+----
+
+That will override calls to the pass binary (usually /usr/bin/pass),
+intercepting the first argument. If the first argument is team, it will look in
+\~/.password-store.team for passwords. If the first argument is not team, then
+it looks in the default location, ~/.password-store. 
+
+
+Category:Security
+Category:Encryption
+// vim: set syntax=asciidoc:
diff --git a/src/Updating_SSH_Keys_Across_an_Environment.ascii b/src/Updating_SSH_Keys_Across_an_Environment.ascii
new file mode 100644
index 0000000..becdea2
--- /dev/null
+++ b/src/Updating_SSH_Keys_Across_an_Environment.ascii
@@ -0,0 +1,347 @@
+Updating SSH Keys Across an Environment
+=======================================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+Most Linux environments with any number of servers uses keys to perform tasks
+from simple manual administration to gathering manifests, backing up config
+files across an environment, and really any kind of automation. Why? Because
+passwords are terrible things (how's that for indignant). Seriously though,
+despite the risks passwords present with minimum constraints not being
+appropriately set or enforced, at least passwords make authentication and
+semi-secure security accessible to people. Of course, keys are preferable, but
+not reachable for the general public. Enough about my philosophical ramblings
+about security though. I have several servers that I run (including this one)
+that all use keys almost exclusively for logins. Like passwords, keys should be
+cycled through frequently as well and if you have things set up right, that
+should be completely painless. Here's the script I wrote to bulk change
+passwords across my entire environment.
+
+----
+#!/usr/bin/env bash
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+# @author Nullspoon <nullspoon@iohq.net>
+#
+ 
+manifest=''
+key=''
+action=''
+id=''
+user=''
+ 
+#
+# Backups by a specific ssh key to <date_modified>.<key_name>
+#
+# @param ssh_base string Path to where the ssh keys and configs are stored
+# @param key string Name of the key to backup
+#
+# @return string The filename of the key backup
+#
+function backupKeys {
+  local ssh_base=$1
+  local key=$2
+  moved=0;
+  date=""
+  priv_ls=$(ls -l --time-style='+%Y%m%d%H%M%S' ${ssh_base}/${key})
+  date=$(echo "${priv_ls}" | tr -s ' ' | cut -d ' ' -f 6);
+  # Rename the old key
+  if [[ -e "${ssh_base}/${key}" ]]; then
+    mv ${ssh_base}/${key} ${ssh_base}/${date}.${key}
+    moved=1;
+  fi
+  # Rename the old public key
+  if [[ -e "${ssh_base}/${key}.pub" ]]; then
+    mv ${ssh_base}/${key}.pub ${ssh_base}/${date}.${key}.pub
+    moved=1;
+  fi
+  if [[ ${moved} == 0 ]]; then
+    echo ''
+  else
+    chmod 700 ${ssh_base}/*
+    echo "${ssh_base}/${date}.${key}"
+  fi
+}
+ 
+#
+# Pushes specific public key to remote user's authorized_keys
+#
+# @param user string User owning the authorized_keys file to be modified
+# @param server string Server the user's authorized_keys file is on
+# @param old_key string The key to use for authentication
+# @param new_key string The key, public or private, to be pushed
+#
+function pushKey {
+  local conn=$1
+  local old_key=$2
+  local new_key=$3
+  if [[ ${#new_key} -lt '4' ]]; then
+    echo "Key to be pushed is not a public key."
+    exit
+  fi
+
+  ispub=$(keyIsPublic ${new_key})
+  if [[ ${ispub} == 0 ]]; then
+    # Append .pub because a public key wasn't specified
+    new_key="${new_key}.pub"
+  fi
+
+  local cmd="if [[ ! -d ~/.ssh/ ]]; then mkdir ~/.ssh/; fi"
+  cmd="${cmd} && echo '$(cat ${new_key})' >> ~/.ssh/authorized_keys"
+
+  # Unset our identity file if it doesn't exist
+  local id_file="-i ${old_key}"
+  if [[ ${old_key} == '' ]]; then
+    id_file=''
+  fi
+  contents=$(cat ${new_key})
+  ssh -q ${id_file} ${conn} "${cmd}"
+}
+ 
+#
+# Removes the specified public key from a remote user's authorized_keys file
+#
+# @param user string User owning the authorized_keys file to be modified
+# @param server string Server the user's authorized_keys file is on
+# @param key string The key to use for authentication which is to be removed
+#
+function removeRemoteKey {
+  local conn=$1
+  local key=$2
+  pub_key=''
+  priv_key=''
+  ispub=$(keyIsPublic ${key})
+  if [[ ${ispub} == 0 ]]; then
+    priv_key="${key}"
+    pub_key="${key}.pub"
+  else
+    priv_key="${key:0:-4}"
+    pub_key="${key}"
+  fi
+  contents=$(cat "${pub_key}")
+  local cmd="if [[ ! -d ~/.ssh/ ]]; then mkdir ~/.ssh/; fi"
+  cmd="${cmd} && cat ~/.ssh/authorized_keys | grep -v '${contents}' "
+  cmd="${cmd} > ~/.ssh/auth_keys"
+  cmd="${cmd} && mv ~/.ssh/auth_keys ~/.ssh/authorized_keys"
+  ssh -q -i ${priv_key} ${conn} "${cmd}"
+}
+ 
+#
+# Determines if the specified key is public (or not which would be private).
+#
+# @param key string Path to the key to check
+#
+# @return int Whether or not the key is public
+#
+function keyIsPublic {
+  key=$1
+  if [[ ${#key} -lt '4' ]]; then
+    echo 0;
+  fi
+  # Check the extension
+  ext=${key:$((${#key}-4)):${#key}}
+  if [[ ${ext} == '.pub' ]]; then
+    echo 1;
+  fi
+  echo 0
+}
+ 
+#
+# Generates a new ssh key of the length 4096
+#
+# @param filepath string Path to where the new ssh key will be written
+# @param bits int Number of bits in the new key (eg: 2048, 4096, 8192, etc.)
+#
+function genKey {
+  local filepath=$1
+  local bits=$2
+  ssh-keygen -b ${bits} -f "${filepath}" -N ''
+}
+ 
+#
+# Prints the help text
+#
+function getHelp {
+  echo
+  echo -n "Manages ssh keys en masse. Designed to perform pushes, "
+  echo " removals, and creations of ssh keys on lists of servers."
+  echo
+  echo "Usage: keymanage.sh action --manifest systems.list"
+  echo -n "  -m, --manifest       Text file containing a list of systems, "
+  echo "delimited by new lines."
+  echo -n "  [-k, --key]          Path to a key to perform an action "
+  echo "(push or remove) with."
+  echo -n "  [-i, --id]           Key to use for automated logins. Not "
+  echo "used when performing an update."
+  echo -n "  [-u, --user]         Username on remote systems to work on "
+  echo "(defaults to root)."
+  echo
+}
+ 
+function parseArgs {
+  argv=(${@})
+  # Parse the arguments
+  for(( i=0; i<${#argv[*]}; i++ )); do
+    if [[ ${argv[$i]} == '-h' || ${argv[$i]} == '--help' ]]; then
+      getHelp
+      exit
+    elif [[ ${argv[$i]} == '-m' || ${argv[$i]} == '--manifest' ]]; then
+      manifest=${argv[$i+1]}
+      i=$(( ${i} + 1 ))
+    elif [[ ${argv[$i]} == '-k' || ${argv[$i]} == '--key' ]]; then
+      key=${argv[$i+1]}
+      i=$(( ${i} + 1 ))
+    elif [[ ${argv[$i]} == '-i' || ${argv[$i]} == '--id' ]]; then
+      id=${argv[$i+1]}
+      i=$(( ${i} + 1 ))
+    elif [[ ${argv[$i]} == '-u' || ${argv[$i]} == '--user' ]]; then
+      user=${argv[$i+1]}
+      i=$(( ${i} + 1 ))
+    else
+      action=${argv[$i]}
+    fi
+  done
+
+  # Enforce some business rules
+  echo
+  exit=0;
+  if [[ ${action} == '' ]]; then
+    echo "Please specify an action.";
+    echo "  Available actions: push, remove, update."
+    echo
+    exit=1;
+  fi
+  if [[ ${manifest} == '' ]]; then
+    echo "Please specify a manifest file."
+    echo "  Example: keymanage.sh action [-m|--manifest] ./systems.txt"
+    echo
+    exit=1;
+  fi
+  if [[ ${exit} == 1 ]]; then
+    exit
+  fi
+}
+ 
+#
+# Determines the path to the parent directory containing a file.
+#
+# @param filepath string Path to the file to get the parent directory for
+#
+# @return string Path to the file's parent directory
+#
+function getFilePath {
+  filepath=$1
+  filename=$(basename ${filepath})
+  echo ${filepath} | sed "s/\(.*\)${filename}/\1/"
+}
+ 
+#
+# Push main function. One param because the rest are global
+#
+function keyPush {
+  argv=( ${@} )
+  if [[ ${id} == '' ]]; then
+    echo "No identity file specified (-i). This will likely be painful."
+  fi
+  for (( i=0; i<${#argv[*]}; i++ )); do
+    dest=${argv[$i]}
+    if [[ ${id} == '' ]]; then
+      pushKey "${dest}" '' ${key}
+    else
+        pushKey "${dest}" ${id} ${key}
+    fi
+    echo "Key ${key} added for ${dest}."
+  done
+}
+ 
+#
+# Update main function. One param because the rest are global
+#
+function keyUpdate {
+  argv=( ${@} )
+  ssh_base=$(getFilePath ${key})
+  filename=$(basename ${key})
+  # Backup our old key
+  backup_key="$(backupKeys ${ssh_base} ${filename})"
+
+  # Let's get to work on that new key
+  genKey "${key}" 4096
+
+  for (( i=0; i<${#argv[*]}; i++ )); do
+    dest=${argv[$i]}
+    if [[ ${backup_key} == '' ]]; then
+      echo "No current key exists."
+      echo "Skipping backup and removal from remote."
+      # Push the new key
+      pushKey "${dest}" '' ${key}
+    else
+      # Push the new key
+      pushKey "${dest}" ${backup_key} ${key}
+      # Clean up the old key from our remote
+      removeRemoteKey "${dest}" "${backup_key}"
+    fi
+    echo "Key ${key} updated for ${dest}."
+  done
+}
+ 
+#
+# Remove main function. One param because the rest are global
+#
+function keyRemove {
+  argv=( ${@} )
+  for (( i=0; i<${#argv[*]}; i++ )); do
+    dest=${argv[$i]}
+    removeRemoteKey "${dest}" "${key}"
+    echo "Key ${key} removed from ${dest}."
+  done
+}
+ 
+#
+# The main function
+#
+function main {
+  # Parse our script args
+  # Believe me, this is a lot better than the alternatives
+  parseArgs ${@}
+
+  destinations=( $(cat ${manifest}) )
+  # Key required
+  if [[ ${key} == '' ]]; then
+    echo -n "Please specify a key (-k) to ${action}."
+    echo
+    exit
+  fi
+
+  # Let's start doing stuff
+  if [[ ${action} == 'push' ]]; then
+    keyPush ${destinations[*]}
+  elif [[ ${action} == 'update' ]]; then
+    keyUpdate ${destinations[*]}
+  elif [[ ${action} == 'remove' ]]; then
+    keyRemove ${destinations[*]}
+  fi
+}
+ 
+main ${@}
+----
+
+
+Category:Linux
+
+
+// vim: set syntax=asciidoc: