September 23, 2014

PuppetConf 2014

Posted in Uncategorized at 6:15 pm by questy

Glad to be at PuppetConf with #ShadowSoft exploring all the latest and greatest in PuppetLabs.


March 16, 2010

Steady Progress

Posted in Family, General, God, Life, Me tagged , , , at 7:47 am by questy

I’ve been making steady progress on my theological degree of late.  I even finished a couple certificates along the way.  I’ve completed “Biblical Theology” and “Kingdom Theology” courses of work, and only have one more class to complete for the “Practical Theology” portion.  I will be continuing my bachelor’s work for the next year or so, and should be done with it by next summer.

Donna continues to waver back and forth.  Honestly, I’m not sure what to make of it.  One night she’s bad enough that they call me up to the nursing home to comfort her, and she is so inconsolable and complaining of pain that I have her sent to the hospital for observation.  I come to visit the next night, and it seems not only is there nothing wrong, she’s communicating with me at a higher level than I’ve seen in awhile.  We had a wonderful conversation and time together before she had to go eat.

Still reconsidering my workplace.  Various issues I really can’t get into here at the moment, just suffice it to say that it is definitely a drain on my joy.  I may need to consider a few things (ugh! again) here soon.

December 29, 2009

My Review of Roku HD Player

Posted in General at 4:15 pm by questy

Originally submitted at Roku

The best-selling HD Player (as known as Netflix Player by Roku) plays High Definition video and connects to surround sound audio.

Roku Outstanding, Content Scarce

By cvquesty from Atlanta, GA on 12/29/2009


4out of 5

Pros: High quality picture, Reliability, Great value, Easy to use, Easy to set up

Cons: Want more video choices

Best Uses: Primary TV

Describe Yourself: Movie buff, Netflix fan, Technophile, Early adopter, Power User

We are on the verge of eliminating Cable TV, thanks to Roku. The only problem left is the dearth of programming choices. There are MANY more online video and audio networks out there all primed and ready to be carried by the likes of a Roku. Give me more programming, and I’ll go with you all the way.

I *might* even pay a monthly subscription if you can get Hulu or Boxee or some other content market deal.


LDAP Administration III – 'Odds 'n Ends'

Posted in Linux, Systems Administration, UNIX tagged , , at 11:17 am by questy

By now you should have a functional LDAP server, a properly configured client, and the ability to authenticate against your server.  However, the last couple “cogs in the wheel” are left to manage.

Generally speaking, when you add a user in UNIX-land, part of the process of the adduser command also sets their shell, creates a home directory for them and so forth.  As you may notice, there is no particular method to make this happen in Linux-LDAP.  You just have a store and a tool to manage the store.

Have no fear, it’s PAM to the rescue.

As we said in our first installment, the following packages are all that is necessary to have the basic plumbing of LDAP to work:


While that is true, there are a couple more packages that put the finishing touches on this to make it sing.  Those are:


NSS is a glibc mechanism or interface allowing access to the common UNIX databases such as the password or hosts database.  It is most commonly used to provide an interface to both local /etc/passd and /etc/shadow files and usually for the purposes of interfacing with LDAP or NIS.

NSS_LDAP is a set of C library extensions which allows X.500 and LDAP directory servers to be used as a primary source of name service information such as users, hosts, groups, and other such data historically managed via local flat files or a NIS infrastructure.

NSCD is a name services caching daemon that provides a cache for the most common name requests.  While useful in speeding up response to queries, nscd has it’s own set of problems.  I’ll cover only some of it’s usefulness, and you should circumspectly determine whether you will need caching at all based on your organization’s size and the size of your serving infrastructure.

Home Directories

First and foremost, to make the login process as pleasurable/smooth an experience as possible, there are some things that we generally do in standard administration practices that ease the user’s experience.  Namely, we setup a standard set of configuration and environment files to provide a consistent user experience of the shell.  These are usually their home directory files such as:


Usually these are handled in the usual way via the useradd command, which also copies one of everything from the /etc/skel directory to your user’s home.

As you can see, simply adding a user to the LDAP store would not give occasion for this to happen.  PAM to the rescue!  PAM contains a module that is their “mkhomedir” module.  Depending on your architecture, this lives in the /lib or the /lib64 directories under “security”:


What these modules do when properly invoked is on the first connection of a user that is validated as a proper user/password combination via LDAP, PAM sees that they have no home directory, and creates the home directory for them just as if you, the administrator had created it with the adduser script.

This, by far, is one of the handiest modules provided by PAM.

Turning on the PAM

To turn on the mkhomedir facility for your servers and clients, simply do the following:

In /etc/pam.d there are a number of configuration files for handling login defs for varying circumstances.  What we are interested in is system-auth.  System-auth is also sourced by the sshd option, so this will work for both console logins and ssh/remote logins.

The last stanza of the system-auth configuration file is the “session” section.  On the second-to-last line between the pam_unix and pam_ldap designations, add the following:

session     required

This is a keyword set that tells Linux to load up and perform the functions offered by the pam_mkhomedir module.  Now, whenever you connect to a system configured in this way, it will automatically create the user’s skel information and change ownerships to the proper settings so the user can login.


You may note that I also referred to using group-based security.  In LDAP/PAM-land, this is just as simple as the above PAM setup.  Look into the individual system’s /etc/security directory for a file called access.conf.  This file allows you to grant/deny access to individual users, groups, and also where they can connect to this machine from.  The syntax is clearly explained in the file itself, but here’s an example.

Let’s say I only want root, wheel, and the admins group to be able to access a certain system.  let’s say they can access this system from anywhere.  Now let’s say I also want the backup group to access the same system, but only from one host.  The setup is quite simple.  First, let’s allow complete access to the people we wish to be able to connect from everywhere.  At the end of the /etc/security/access.conf file, add the following line:

+: root wheel admins : ALL

This tells the system to add access for root, wheel, and admins from ALL hosts.  Now, let’s put in those backup admins, but only allow them to connect from the host we want them to come from:

+: backup :

This means the backup group can access this host, but only from the host  There are many other methods of allowing and denying access in this file.  The documentation is contained within the file, so feel free to look through it for more information.

The MOST important line is the last line, however.  After you’ve setup all the people you WANT to access the system, that does no good if all access is still left on for everyone, everywhere.  The final line in the file should be to deny all access to anyone else not specified above, and would look like this:

– : ALL : ALL

Simply stated, this removes (or subtracts) all access for ALL other users from ALL other hosts.  This line is evaluated last after the preceding lines are, and will take the preceding lines into account when setting up it’s rules in memory.

At the very worst, if you mis-order the lines here, you may not be able to login to the system and will need to boot to single-user mode and then use the article here on this site entitled “A Neat Trick” to make /etc read/write so you can change the configuration and then reboot back into your system’s default runlevel, but if you’re careful, this will be quite easy to configure and manage.

Closing Thoughts

I’m sure there’s a few things I left out, and I will be revising this series at some point in time to allow for any omissions I’ve made.  I will also be adding in feature suggestions and will be following this up with a sudo article so you can overlay the “on-box” security set you’d like to see happen in your environment *after* your LDAP infrastructure is in place.

Feel free to drop me a note if you see anything amiss, and I’ll be sure to correct it and give you props.

December 28, 2009

Medical Nonsense…

Posted in General tagged , at 11:26 pm by questy

Got into a bit of a snit with someone today over some singer guy who offed himself after getting paralyzed while drinking and driving at 18 years old.  He made it to his 40’s, all the while dwelling on his dark mood in the lyrics of his songs.

Despair finally had it’s way, as he also needed some kidney work done and didn’t see the whole thing through.

I guess I’m still a little raw about just about anything medical…  I let him have it right off the bat… (not unfairly, mind you) but I really need to temper that whole thing back if I’m going to move on at all…

LDAP Administration – Part II

Posted in Geekstuff, Linux, Systems Administration, Tech, UNIX tagged , , , at 11:53 am by questy

Ok, so in our previous installment, we got LDAP all configured up from the client perspective.  I’ll cover some other client-based niceties such as extra PAM modules and security in our third installment.  For now, back to the show!

The Server

The lightweight Directory Access Protocol (LDAP) gives us tons of things to use to help make the system login/logout process easy to manage and maintain.  The LDAP server runs over the Berkeley Database (BDB) as a data backend, and has a long history as a protocol/standard.

As we said last time, the server configuration consists of the contents of the /etc/openldap directory with the primary file of interest being the /etc/openldap/slapd.conf file.  The secondary file of interest will be the /etc/ldap.conf file, another server configuration file.


First, we will cover the ldap daemon (slapd) configuration file, /etc/openldap/slapd.conf.  This file is responsible for specifying information regarding what schemas to use, loggin parametwes, database specifications and locations, security, replication, and security grants.

Let’s start with a very simple slapd.conf file:

# OpenLDAP Server Configuration

# Primary Server Schemas
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/redhat/autofs.schema

# Logging

loglevel 0
pidfile      /var/run/openldap/
argsfile    /var/run/openldap/slapd.args

# bdb database definitions
database             bdb
suffix                   “dc=bob,dc=com”
rootdn                 “cn=admin,dc=bob,dc=com”
rootpw                secret
schemacheck    off

# location of the data files
directory              /var/lib/ldap

# Indexes to help speed up queries
index objectClass,uid,uidNumber,gidNumber,memberUid     eq
index cn,mail,surname,givenname                                                eq,subinitial

# Grant users rights to change their own password
access to attrs=userPassword
by self write
by anonymous auth
by dn.base=”cn=admin,dc=bob,dc=com” write
by * noneaccess to *
by self write
by dn.base=”cn=admin,dc=bob,dc=com” write
by * read

This is a very basic slapd.conf file without TLS security information, without replication information, and without any frills at all.  Recall that our primary goal here is to get a basic LDAP server running and working without any frills.  We want the ting to work, and then we’ll add features and security as time goes on.


The /etc/ldap.conf file bills itself as the “configuration file for the LDAP nameservice switch library and the LDAP PAM module”.  While we just configured the operation of the server, we must now put the “glue” in place so that PAM knows how to ask questions of the LDAP system to know if a user is allowed to login or not.  Again, a very simple /etc/ldap.conf file:

# ldap.conf — simple configuration

# Distinguished name of the search base
base dc=bob,dc=com

# The distinguished name to bind to the server with
binddn cn=admin,dc=bob,dc=com

# Password to bind to the directory with
bindpw secretpassword

# Search TimeLimit
timelimit 120

# bind/connection timelimit
bind_timelimit 120

# idle timelimit
idle_timelimit 3600

# PAM password format
pam_password md5

# Assume no supplemental groups for these named users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman

# Main LDAP configuration piece
uri ldap://
ssl no
tls_cacertdir /etc/openldap/cacerts

A couple of notes here.  First, the nss_initgroups_ignoreusers portion can most likely be left out.  This is an artifact (as far as I am aware) of being on a RedHat system as several of these users are defaults on RedHat.  Next:  The timelimits are just sane numbers, nothing special.  Should there be any need for tweaking this, it will be in your own experience across your own environment.

Much like the earlier client configuration file, this serves somewhat the same purpose, but for the PAM system as a client rather than a system itself as a client.

Crank it Up!

At this point, you should be able to start up your server to begin configuring it for use.  In RedHat-land, as many of you already know, this is typically a two-part process.  First, you set the service to start at boot and then you start it up.  First, run the command to set the runlevels in which you want ldap to start:

chkconfig –level 2345 ldap on

And then use the RedHat tools to start the service up:

/sbin/service ldap start

At this point, you should have a fully functional LDAP server running with no particular schema or setup, ready to take data (in our case, POSIX compliant login information) and serve it out to your infrastructure.

Populating the Database

With the RedHat packages come a myriad of important tools you need to help migrate your current authentication information into the LDAP store.  The location of these helpful perl scripts is: /usr/share/openldap/migration.  Before you use these tools, make sure you edit the file in this location to match your environment like so:

$DEFAULT_BASE = “dc=bob,dc=com”

This file is sourced by all the migration scripts resident in this directory, and will automagically insert these values where necessary.

Next, let’s do a trial-run of converting our passwd file in “LDAP-ese”.  Since you’ve already edited the, you can directly migrate your /etc/passwd and /etc/group files like so:

From the /usr/share/openldap/migration directory:

./ /etc/passwd ./passwd.ldif

Similarly, convert your groups file as well:

./ /etc/group ./group.ldif

What these commands will do is convert your standard /etc/passwd and /etc/group file to ldif-formatted files for import into your LDAP store.  Let’s look at a record for an example:

dn: uid=bin,ou=People,dc=best,dc=turner,dc=com
uid: bin
cn: bin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}*
shadowLastChange: 14251
shadowMax: 99999
shadowWarning: 7
loginShell: /sbin/nologin
uidNumber: 1
gidNumber: 1
homeDirectory: /bin
gecos: bin

dn: uid=bin,ou=People,dc=best,dc=turner,dc=comuid: bincn: binobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountuserPassword: {crypt}*shadowLastChange: 14251shadowMax: 99999shadowWarning: 7loginShell: /sbin/nologinuidNumber: 1gidNumber: 1homeDirectory: /bingecos: bin

The LDIF format has a number of self-explanatory fields that you can see correlate to your /etc/passwd file.  There are other fields here that LDAP needs, but are beyond our concern at this point.  We’ll come back to these later.

I picked a system-default user just to illustrate the format of the ldif.  This user generally has no password, and thus you cannot login using his credentials.  In the userPassword line above, for a regular login user, you would normally see {crypt} followed by a rather large SHA encrypted string representing the user’s hash.

This brings about the question of how you wish to manage your users.  Generally speaking, I allow the local /etc/passwd file manage root and all system-default users (bin, spool, lp, etc.) and all users I add post-installation get placed into LDAP.  In that way, I manage the user centrally from the outset.  I’ll be covering how I limit what users are allowed to access what systems in a later article.

Importing the LDIF

Once you have your LDIF, you have some decisions/edits to make.  look through your dumped ldif file.  Remove each stanza relating to the users you do not wish to manage via LDAP.  The resulting LDIF file will be the one we import.  Generally speaking, in a RedHat system I delete everything before UID 500 (which is usually me) and import everything else.

Once your LDIF file is how you want it to look, it’s time to import.  Import it using the following command, modifying the search base and admin user to suit your configuration:

ldapadd -W -x -D “cn=admin,dc=bob,dc=com” -W -f passwd.lif

When you run this command, the LDAP server will churn for a moment (depending on how large your passwd file is) and then will return a clean shell with no errors.

Time to “Get your GUI On”

At this point, I usually point people toward the excellent Apache Directory Studio available at the Apache Directory Project.  This is a gui directory administration tool that can browse and edit your entire store.  The Apache Foundation describes it like so:

Apache Directory Studio is a complete directory tooling platform intended to be used with any LDAP server however it is particularly designed for use with the ApacheDS. It is an Eclipse RCP application, composed of several Eclipse (OSGi) plugins, that can be easily upgraded with additional ones. These plugins can even run within Eclipse itself.

Apache Directory Studio is available for Windows, Linux, and Mac OSX and is a freely-available Apache 2.0 licensed product.

Once you download and configure the Apache Directory Studio, you should be able to view, browse, edit, and manage all aspects of your LDAP store.

Next time, we will tie PAM into LDAP, work with security and group-based access as well as cover a few “odds & ends” to help you use your LDAP store in a variety of different ways.

December 26, 2009

More Ouch…

Posted in Family, Life, Me tagged , , at 11:56 am by questy

Well, made it through Christmas with only a little pain.  It’s my first Christmas without the wife at home in 20 years.

I went to see her in the Nursing Home a couple times this week, and even read her some of her Christmas cards that were sent by all sorts of people in the community.  She started falling asleep on me 🙂 so I had the nurse put her to bed and went ahead and left.

I took the boys to a movie, probably more to get out of the house on Christmas than to see a movie.  I just didn’t want to stay here without the wife around.

Folks… It’s been a rough couple weeks.

On the bright side, I found out this week that both her Medicaid and her SSI have come through, and her hospital bills are all going to be paid by those sources now.  It’s time for me to do a “life qualifying event” with our medical insurance and drop her since all her medical needs will be handled by the government now.

Keep her in your prayers.  Her body is declining rather quickly.  I don’t see another year in her, but she sure has surprised me before.

Merry Christmas everyone.  Happy New Year.

December 22, 2009


Posted in Family, General, Life, Me at 11:33 pm by questy

I didn’t expect to really be crazy to do the nursing home thing tonight after that crazy emotional roller-coaster last night, but GOSH was it a hard trip.

I got there to find Donna just crying and crying in the hall and not able to stop.  I asked about meds levels and I asked about the day and nothing seemed to be out of the ordinary.

I rolled her away from the hubub and just held her and told her how much I loved her over and over.  It took about an hour, but she finally calmed down and we had the first really wonderful conversation we’ve had since she’s been there.

God, I miss my princess.  Can you see your way clear to send her back to me?

LDAP Administration – Part I

Posted in Linux, Systems Administration, Tech, UNIX tagged , , , at 4:59 pm by questy

One of the things I’ve worked on over the last year is setting up a centralized LDAP server for authentication in a UNIX environment.  My clients range from early RedHat to our current distro of RH5.2 or CentOS5.2.

A huge issue I’ve run across while doing this work is that I had to piecemeal the information together from all over the Internet because the grand majority of what I could find out there was either for Windows clients or non-POSIX login authorization.

I plan to tell this story mostly in the context of a RedHat-ish rpm-based distro, and the setup of both the server and a Linux client to tell both sides of the story.  I will use my own terminology to begin, making it very simple to explain precisely the setup we’re looking for without getting into a lot of LDAP-ese.  As we go through the setup, I will slowly start to relate my description back to LDAP-ese so you can, once your setup is working, go back to the documentation and determine “just what happened here”

At the end of the story, I’m going to have a LOT of keywords so Google gets a good sampling of this to help someone who may be like I was, looking for a very specific UNIX auth implementation.


One of the big things I needed first was to have the server packages installed.  When I did the original installation, I went a little overboard and downloaded and installed everything from the patch level I used, but the essentials are:


After getting these installed (via either yum or rpm -i…whichever is your preference) then you should have a subset of important files and tools lying about around your system.  These will be (in no particular order):


The /etc/openldap directory houses all the files pertaining to your server piece.  From your certs to the appropriate schemas to an example DB_CONFIG for the LDAP backend (Berkeley DB…more about these later…)  The primary file of interest in /etc/openldap will be slapd.conf.  In /etc/ldap.conf, you have the server configuration file.

In my setup, the purposes and configuration of these particular files seemed to be the biggest hinderance to getting everything running as I would expect.  At one moment, there was a config element in /etc/ldap.conf and in another there was one in /etc/openldap/slapd.conf.  It appears there has been some overlap from version to version, and even now you have to take all files together, viewing it all as a single configuration.  That’s where we will start.


I’d say that my first confusing issue was that this file serves different functions depending on whether you are looking at a server or a client.  For the client, it is a simple, short file specifying the server and the ldap URI to use for searches.  In the server context, it is for the LDAP nameservice switch configuration and the LDAP module for PAM.


Let’s start with the client config.  I know this is putting the cart before the horse, but it is the simplest part of this procedure.  If we configure it now and utilize it in it’s easiest configuration, we know that once resolution and searches are functioning, the server is setup correctly.

First, let’s talk about your organization a bit before launching into this configuration.  Recall that our entire purpose at this point is POSIX-compliant user/pass functionality and everything that implies.  I’m not looking for a phonebook (what seems to be a large portion of the tutorials out there on the ‘net and in the O’Reilly LDAP book) and I’m not looking to find where employee X sits.  I want user/pass/GECOS, etc. of a POSIX-compliant login.

Most organizations are on the Internet these days.  Let’s take my mythical company “”.  Bob’s company, has a website and all the standard DNS resolution and email and the like for is already working perfectly.  It already has a nifty website driving tons of customers to Bob’s company.  As for the infrastructure of UNIX logins and passwords, the ONLY THING that and LDAP have in common is that their bits and bytes are traveling over the same wires as’s Internet traffic.  That’s where the connection ends.  When we start talking about the naming in the LDAP space, even though is valid in the Internet as well as the LDAP world, they have absolutely nothing to do with one another from a technical perspective.

In LDAP-land, is the name of the company we will be serving.  So, think of this as the top of your tree from which all the other branches will grow. is your organization.  It is also the top of your tree.  This is a conceptual designation.

We will be installing the LDAP server on a piece of server hardware hanging in a rack.  This server will have a DNS hostname, and will be called  This has absolutely nothing to do with LDAP-land.  This is simply the every day server naming and numbering like you would do for a new name/app/web server and the like.

The top of our conceptual tree in our organization is the base name.  In LDAP-land, we refer to this as your “search base“.  This is the name root from which all things flow.  Like an OU in active directory or a root filesystem in UNIX, everything happens under this.  So, for our LDAP-land based conceptual idea of our organization, we will have a base distinguished name of  In LDAP-ese, we refer to a base by it’s separate parts.  In the case of the base name (for our purposes) these separate parts are known as “domain components”.  This, should you choose an LDAP name space to match your Internet name space, is the sole point where these two worlds converge. is an Internet domain name while the LDAP-ese separations of the search base are called “domain components”.

Let’s see what this looks like:

Internet domain name:         
hostname of the server:         
LDAP Search base:                          dc=bob,dc=com

If you remember some of your DNS-fu, you’ll recall that the host/domain portions of the Internet name have significance in IP-Address land, but that is outside the scope of our little discussion here.  The important thing for you to know is that is an Internet-based domain name that can be resolved in your browser of choice to a location on the Internet for your viewing pleasure.  The LDAP name space of dc=bob,dc=com is an LDAP-formatted representation of the search base of your organization conceptually referred to as

I know that was painful, but the distinction is paramount to proper understanding of this process, how it is named, and how it is used.

So, let’s take our client configuration and give it a whirl…

Configuring a Client

Simply stated, the client only needs to know three things.  First, it needs to know our base conceptual name (or search base), an Internet-formatted URI to know how to get to the host that has this storehouse of information, and the OS itself needs to know to look at LDAP for this information rather than local files.  Let’s look at a client machine’s local file:

File:  /etc/openldap/ldap.conf

# LDAP Defaults

BASE dc=bob,dc=com
URI ldap://
TLS_CACERTDIR /etc/openldap/cacerts

That’s really all there is.  The search base and the URI to find the server.  You already know about the file that tells UNIX where to look for information.  It is the file /etc/nsswitch.conf

This file contains mappings regarding what the system should look at for which services.  The file is in the format:

service:     location1 location2 location3…

You can have as many locations as you need for UNIX to search, but we’re only going to worry about two.  local files and the LDAP store.  In the /etc/nsswitch.conf file, you will have three lines for authentication we are concerned with.  They will look like so:

passwd:     files
shadow:    files
group:        files

This essentially tells the system  that for passwords, password hashes, and groups that you should look at the local files.  Pretty straightforward.  However, to point us at the LDAP server for this information, you need only change this file in the following way:

passwd:     files ldap
shadow:    files ldap
group:        files ldap

What this will do is check the local files for a user and then the LDAP store for that user.  If they do not exist locally, they will resolve from LDAP.  The caveat here is that the user you’re trying to login with for testing LDAP should not already exist on the client system.  If it already does, you have a possible issue in that things will work, and you’ll never know if you’re resolving from local files or LDAP.  I’ll show you how to handle this later.

That’s it for the client.  Now we have a client configured to shout at using the search base of dc=bob,dc=com looking for password, shadow, and group information for POSIX compliant logins on your client host.

Next time, we’ll start setting up the server.


Posted in Family, God, Me tagged at 2:06 am by questy

Tonight I was feeling the tug of my first Christmas without my darling wife at home.

In cleaning out the basement of old stuff to donate to Goodwill and such, I found a shoebox… A wonderful treasure-trove of love.

My darling sweetheart in all the years of our marriage; the ups, downs, and all the in-betweens kept every card and letter we ever sent to each other, dating them and treasuring them. I choose to believe so I would find them tonight.

I read each letter, each word of a lovers’ exchange; a back-and-forth of promises and sentiments meant to last an eternity. Declarations of undying love and God’s providence of each one for the other, a unique gift of love from Heaven and it’s master.

Plans were made. Doubts were discussed. Edification and healing love like a balm flowed freely between the lovers across miles of separation early in their engagement. A temporary divide of summer between semesters, designed by God to forge the strongest of bonds that would last for eternity, endure forever.

After this journey through hills of unabashed devotion, love, and rapturous embrace, I am left yet again with the question that rings louder than the loudest bell in the highest tower…


I cannot begin to fathom the purposes of God, or the direction He wishes. I only know that I am His and this sojourn is not over; the final chapter is not yet written.

It is a difficult thing to live in hope for miraculous restoration while living life as though it will never come… But, I live in a similar conundrum coined by the modern day psalmist Richard Mullins:

Live like you’ll die tomorrow. Die knowing you’ll live forever.

If faith is indeed the subtance of things you hope for, and the evidence of things you have yet to see, then the events of this evening have truly filled my heart with faith and hope. Our lives were intertwined by our divine Father, forging in a crucible of love the strongest of bonds to weather the harshest of storms. Those storms began blowing for us shortly after we wed, and escalated to hurricane strength.

God, show me your purpose that I might fully enjoy faith again. The faith of my youth, he faith of my love.

Bring that precious flower of my heart back to full bloom that you might be glorified in our union.

Next page