I’ve been asked by the Digg auto-submission system to paste an invisible key into my page so Digg can curate my posts.
Into my next story on my site. Of course, if ANYthing on here catches on, my server is toast, but let’s see what happens, shall we? :)
Somewhere in the back recesses of my mind, I was brewing a post about permissioning and the relationship between DEV and Sysadmin teams and when and how elevated access should be granted.
Well, Kyle over at serverfault.com has approached this topic in a post entitled “Should Developers Have Access to Production?”. I highly recommend this read, as it covers many of the topics I wished to cover. I do have some additional commentary, but I’ll circle back around to that and share my thoughts at a later time.
Oftentimes I peruse various support forums and IRC channels. Not for support, and not always to help out, but to just observe the community in action.
I have occasion to see the best of what Linux is all about (as it pertains to community), people literally all over the world at all levels of development asking for and giving help on a wide array of issues with their systems from very basic unix navigation and installation issues to extremely complicated configuration issues that require no less than code modification and custom compilation of new device drivers.
In and among this crucible of collaboration I find an almost pernicious insinuation to the conversation. Whether it be because of youth, undeveloped social skills, or some other societal construct, you begin to find those who are there for the sole purpose of detracting from the conversation. Taking pot-shots and newcomers, ridiculing marginally experienced recent-converts and even getting into heavy argumentation regarding matters of practice in administration and or management of Linux systems.
For whatever reason, these find it a jolly good time to detract from the conversation; to make themselves present for little more than obstruction. This can (and does) have a chilling effect on the community.
First, the open nature of the community is compromised. Newcomers experience a chilling effect in not wishing to ask questions and interact for fear of being ridiculed and condescended toward. Next, it generates a conversation away from these support channels about the character of those in the community, that they are elitist and snobbish in their assistance, and they wish not to help, but to lord over you their level of attainment. Many times these conversations end with the phrase “I’ll just stick with Windows, I guess.”
Too bad for the community.
Widespread adoption of our beloved OS will not see any significant amount of growth until we move beyond this practice. In light of this situation, I have some suggestions for community participants to both help them obtain the sense of community they wish and still allowing the newcomer to have a good experience, thus enjoying Linux early on, and then in turn propagating our community to his circle of friends.
First, if you must hang around Linux support forums, be prepared to answer any and all questions no matter how dumb you personally believe them to be. Remember that we all started at ground zero at some point in our lives. We had those who helped us, and we had to pore through tons of documentation to get up to speed. Show some understanding and compassion for the newcomer, and help them as much as you can. If you do this regularly, before you know it, those “newbs” are now helping others only slightly newer than themselves with the very issues they themselves have just dealt with.
This does two things. First, it brings them much higher in the food chain, making them closer to your level and much easier to relate to. Next, it places yet another level of support for newcomers where you used to help out. This is an optimal situation. It broadens the community, “pays it forward” through newcomers to even newer adherents, and then builds up the ecosystem.
Next, if you don’t have anything to offer, say, or help with, it is perfectly ok to shut up. If you see a question that you really feel is stupid and you are running over the litany of wonderfully snarky things you can say, maybe it is just best that you not say anything at all. I firmly believe this benefits everyone. If you must type something, private message an online friend instead so you can have a private laugh together.
Finally, when you do have things to offer, remember that as users we have preconceived notions about what everyone “should just know”. The fact of the matter is that everyone does’t “just know” those things, and will never learn them if they’re the butt of finely crafted barbs heading their way. Be prepared to remediate in a very friendly, non-condescending way and be prepared to even go as far as “Ok, a shell interprets the commands you type on the screen.” Or even (God forbid) “your keyboard and/or mouse is sometimes referred to as input whereas your screen, network card, or modem is considered output.”
Painful, I know, but the more friendly, welcoming, and helpful you are, you play a part in helping to build up the community in a way that is self-perpetuating. Help out. Be friendly. Be patient. With a little help and a little patience, you build a group of community members that one day will be doing the very same thing for another generation of users.
Once you’ve got your handy LDAP server authenticating users for login throughout your environment, inevitably you find yourself getting around to the question of authentication for all your backend tools/services machines. Can you authenticate from Apache to that same auth store to reduce administration burden across the environment?
Yes you can.
Recall from part I of this series that we have a server that is serving auth for our mythical “Bob.com” environment. Recall also the important info regarding this environment:
Internet domain name: bob.com
hostname of the server: ldap.bob.com
LDAP Search base: dc=bob,dc=com
File: /etc/openldap/ldap.conf
#
# LDAP Defaults
#
BASE dc=bob,dc=com
URI ldap://ldap.bob.com
TLS_CACERTDIR /etc/openldap/cacerts
Now, we add to the mix an Apache web server that has an area it wants to secure. Instead of using the old htpasswd method to create a disk-file containing usernames and password hashes, it would make much more sense to simply point Apache’s authentication system at our shiny new LDAP server so we eliminate yet another user/pass system we have to administer.
Apache
As many of you are already aware, Apache offers simple authentication to allow/disallow access to specific shared directories over the web. The Apache Project has detailed documentation to help you get started here. I’ll cover the basics here.
Traditionally, in Apache’s config file(s) you specify a directory you wish to have secured via the “Directory” directive like so:
<Directory “/super/secret/directory”>AllowOverride NoneOptions ExecCGI IncludesOrder allow,denyAllow from allAuthUserFile /secure/passwd/file/locationAuthType BasicAuthName “Cool Security Name”Require valid-user</Directory>
If the Kingdom of God has come, how is it that the words and workso Christ are not being seen in widespread fashion?
Wow, Squeeze for Mac ($9.95) “fell off” the @MacHeist truck… get it at a 5-finger discount! http://MacHeist.com
So, I just tied my Twitter to Buzz…. Let’s see what happens.
I’ve been waiting all 42 years of my life to see this. Founded the year I was born, going to the bowl. #saints
BAH! Late start. Work, home to get the guitar and then back up to kinship at 7.
Win a new Canon 5DMKII or $2700 of photo printing/product from @WHCCPro & Scott Bourne. Pls RT. Info: http://bit.ly/6Mtx9I
