Discussion: "The Server IS the Documentation" (OR Standard Process [Obnosis] verses Useless Arrogance [Experience/Training])

[Nathan England]

I agree documenting deviations can be nice, but are those deviations moving outside 
of the standard configuration locations?

Maybe I should not have said "/etc" but instead said "standard configuration locations" 
meaning the standard places where the configuration files should be. Though I will 
content that in most cases, that means /etc.



I deal with Oracle databases and application servers a lot and while the asterisk based 
systems I create and support have most of their configuration in /etc other things are 
stored as data in the MySQL database and other places.  With Oracle eBusiness Suite 
applications none of it is in /etc and /var except for startup scripts.  



Yes I'll admit you can get away with doing what you're saying a lot especially on simple 
servers.. *until you can't.*  Sometimes there is no reliable working version of the 
server to go to.. because the 'working version' was on a hacked server and then 
sometimes even your backups have the problem.  Usually the stuff in /etc is pretty 
safe because it isn't executable but wrong settings there can open a lot of 
vulnerabilities; having what you deviated from the default install documented helps a 
lot.



I think the horse is dead here :)  If you're ok trusting that what you have in /etc and 
/var is sufficient good luck to you.  




On Thu, May 16, 2013 at 11:53 PM, Nathan England <nathan at nmecs.com[1]> wrote:




 
Are you serious? Do people actually configure linux servers with configuration files 
outside of /etc ? Beyond LDAP and MySQL what else keeps the configuration outside 
of /etc ? 
 
I'm not talking about replacing all the data from a web server or loading the data into 
an LDAP or MySQL server. I'm talking reconfiguration. 
 
As far as "recreating problems from the original server" did you not read what I wrote? 
I said ...
 
[QUOTE]
A complete backup of /etc and /var from a machine that was running as intended 2 
hours before the SHTF.
[/QUOTE]
 
Notice the *as intended*. If the machine was not running properly to begin with, that 
would have to dealt with before the machine goes down. If your misconfigured 
machine fails before you get it configured correctly, you have bigger problems my 
friend! 


What kind of servers do you manage where knowing what is in /etc and /var is 
sufficient?


Ho
w
are you sure you aren't recreating problems from the original server on the new one?




On Thu, May 16, 2013 at 11:36 PM, Nathan England <_nathan at nmecs.com_> wrote:




>From my experiences with server rebuilds after catastrophic failures, I absolutely have 
to agree. The server *is* the documentation. I have rebuilt servers using extensive 
documentation about how it was setup, with scripts and plans included in the 
documentation and why it was set up the way it was set up. I have also rebuild servers 
after massive failures using only data backups. 
 
If I had to rebuild a server today, in a time crunch, and I had the choice of complete 
documentation of how and why vs a copy of the /etc folder.... I'd go /etc in a heart 
beat. I wouldn't even flinch. 
 
Who is to say I am going to understand someone else's logic when reading their 
documentation. Who's to say the system wasn't built by a genius and then 
documented by a teenage kid still wet behind the ears having only built his first 'puter 
a week ago. 
 
vs
 
A complete backup of /etc and /var from a machine that was running as intended 2 
hours before the SHTF.
 
I agree completely that this kind of attitude comes across as arrogance. But is it really 
arrogance if I really am just better than you? (lol - ducks) 
 
When you build a machine for a client it is highly recommended that you well 
document the system. But at the end of the day, if the admin who must fix what is 
broken can't figure it out from looking at the code or reading the configuration files 
what makes you think endless reems of documentation is going to help? 
 
I know a few guys who could figure it out, but where some of us could rebuild the 
machine in a couple of hours given that /etc backup, the other guy might take days... 
 
The server *is* the documentation.
 
Good post Lisa! 
 
Nathan


Across the board, the number 1 worst attribute that I see working with the PLUG, 
technology teams, and mentoring (at or around year 3 in academics, and year 3 - 10 in 
IT/linux professionalism) = arrogance. 


What exactly is arrogance anyway.  Where is this found?  Why? 


It's the place in the discussion where one person dominates assuming that their 
position or knowledge is greater (without investigation).  This is also referred to as 
"OneUpManShip". 
It's the place in the presentation where students and PLUG peers write off the person 
who has taken on the role to "present on the subject" based on their ability to verbally 
spiel acronyms.  This is referred to "Minimizing". 
It's the place in the team dissemination of project roles and tasks where a member's 
enthusiasm is downplayed based on experience.  This is referred to "Dues Hierarchy".  
This is the place in the interview where the employer fails to realize all they need to do 
is very the work history, since everything for a Linux professional is motivated by and 
driven from an ethical systems administrator viewpoint (not any communications with 
or responsibilities disseminated from the employer); just as we are woken from sleep 
to work on or check systems; and jazzed beyond belief by a well engineered hardware 
server like IBM Blade (can you say Fiber channel switched backplane?)... 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130517/db5490ab/attachment.html>