Are there any nice tools to document the configuration of a server?
I want to write down every operations I do, with comments and most
important configuration files.

Any useful program?
Maybe just latex?

Svn would be really nice (for commenting and see diffs) but I can't
use it for system files...

andrea wrote:

I tend to use vim (or vi if vim is unavailable) to document any changes
I make to a system's configuration. It works beautifully, I have the
fallback to vi when vim is unavailable, and the resulting files are small
and readable on any new system. I also can easily duplicate actions on
different systems by simple means of copying and pasting between xterms
when necessary.

I hope that helps ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On 16 Ott, 18:33, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
Yes vim it's fine, I use it for system files, but how do you organize
the informations?
Something like that?
-- 12 OCtober --
- change 1
- change 2

I think with latex I could get a much better result, and I don't need
to write stuff directly on that machine.
My question is how to organize informations...

andrea <kerny404@gmail.com> writes:

I am currently thinking about using NOWEB for this purpose. Noweb
is a literate programming tool. As literate programming is not a very
common topic, I will give you a taste of it (just in case) before
discussing how it could be used for your problem.

In case you are not familiar with this kind of tools, literate
programming tools are designed to produce both a program and its
documentation from a common source file. Note that the point of view
is rather different from the one used in tools like DOXYGEN where
documentation lives as a parasite in program comments.

The most famous literate programming tool is certainly the pair
CWEAVE, CTANGLE, from a common source CTANGLE will produce a C program
and CTANGLE a TeX file documenting the program. Unlike CWEAVE/CTANGLE,
the NOWEB program do not insist producing C programs and TeX-able
documentation. It is therefore less specialized but more easy to use
and more adaptable to different tasks.

To give a concrete example of the (hypothetical) usefulness of NOWEB
is managing administrative files, let's discuss an (hypothetical)
example. Let's say you have two groups of users, backupteam and
wwwteam, with two different missions. These missions require special
amenagements in various configuration files:

/etc/rc.conf because some services are to be enables
/etc/login.conf because some system-wide limitations are
unsuitable for these missions
/etc/devfs.conf because backupteam should access backup devices
/usr/local/etc/sudoers because some privileges have to be delegated
to users

... and some other random configuration files

You will write two files backupteam.nw and wwwteam.nw where you put
doumentation along with the pieces of /etc/rc.conf you are working on.
You will also nead a system.nw that describes parts of the
configuration unrelated to backupteam nor wwwteam.

After this tou will run noweave on *.nw to produce all configuration
files and notangle on *.nw to produce all documentation files. With
noweb you can pickup almost any documentation format you want, but
plain text is really fine for all the reasons Sylvain Robitaille
mentionned earlier. If you want to give a coool aspect to your plain
text files, I recommand you to try the `fixed' font from Xorg in your
X terminal and in your editor. The fixed font displays cleanly and
it's ``future seen from the 70's'' design is very hype and is in touch
with the contemporary revival of 70's aesthetics.

If you are interested by this way to tackle your configuration files
problem, recall that I do not actually walk this way (for now, this is
just a bluesky idea) and point your favourite web browser to

WWW: http://www.eecs.harvard.edu/~nr/noweb/

You will find gentle tutorials and examples of use.


Being an amateur BSD user, and by no mean a professionnal sysadmin, I
am curious to get the opinion, about this chatting, of experienced
sysadmins that were patient enough to read this very long article.
--
Best wishes,
Michaël

On 16 Ott, 20:54, michaelgrunew...@yahoo.fr (Michaël Grünewald) wrote:
Well this project looks really nice, that's what I was looking for,
I'll give it a try.
I know literate programming in haskell, that's very different but the
concept is the same.

andrea <kerny404@gmail.com> writes:


My pleasure
--
Cheers,
Michaël

michaelgrunewald@yahoo.fr (Michaël Grünewald) writes:

I have looked into literate programming a long time ago and it is a
fascinating subject but I have since ended up with the opinion that
literate programs are for those implementations that are so complex
that it is impossible to understand without a thorough high level
description - perhaps even with graphs.

When I was a sysadmin I ended up with having a set of predefined
commands to bring the virgin computer correctly on the network and
download an architechture specific tarball of extra scripts which
unpacked in /etc and patched a few existing scripts.

This worked well for us. The differences was clearly documented
(either the result of the bootstrap commands or a file from the
tarball), and comments in the individual files explained why.

These days I write Java - here the refactoring tools are invaluable in
making the code self-explanatory with long descriptive names.

Literate programming is an enlightening exercise which everybody
should try, but I would suggest you try with another project first
--
Thorbjørn Ravn Andersen

On 17 Ott, 04:34, Thorbjoern Ravn Andersen <nospam0...@gmail.com>
wrote:
Yes maybe you're right, comments normally are more than enough.
Anyway I think I may do a simple text file, but the most important
thing is to structure it well, so I can extrapolate data from it.

I also decided to use sshfs, vim it's fine but textmate is much
better

andrea wrote:

Yes, something like that. I use conventions to quickly identify files
that need to be preserved over OS upgrades (for example), or for new
"sections"

A quick example might look something like this:

# ----------------------------------------------------------------------
# 2007/10/17 Sylvain Robitaille (identify who made the change because I
# work on systems with multiple sysadmins; include a brief
# description of the purpose for the change, such as:
# add new DNS resolver)
#
# Note the next line, which identifies a file that should be preserved
# over an OS upgrade:
### /etc/resolv.conf
# --- /etc/old/resolv.conf.20071017 ...
# +++ /etc/resolv.conf
#
# Next lines are a unified context diff of the file that was changed,
# making it easy for a colleague to duplicate the same change on another
# system (for example).
# ----------------------------------------------------------------------
#
# 2007/10/17 Sylvain Robitaille (New section delimitted by the above
# line; if there are commands to issue following the
# modification of a file, for example to restart a process or
# cause it to reload its configuration file, such lines are
# documented as well, without the leading '#' to make it very
# simple for the to be copied and pasted between xterms)
### /etc/syslogd.conf
# --- /etc/old/syslogd.conf.20071017 ...
# +++ /etc/syslogd.conf
#
# (unified context diff of syslogd.conf changes)
kill -HUP `cat /var/run/syslogd.pid`
# ----------------------------------------------------------------------
#
# ...

Keep it simple to work with, or else you risk not using it as regularly
as you're intending to. You can't get much simpler than a plain-text
file on the system itself.

Also, it makes sense to keep every system's documentation on the systems
themselves (with a sufficient backup strategy, of course), in the same
place on all systems, so you always know where to look to find what's
been changed on any system.

The real answer is "whatever works for you." I hope the above inspires
you to develop a way to organize the information that you find works
even better.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

andrea <kerny404@gmail.com> writes:

If you need to keep data from several machines, then you might as well
start with a spreadsheet - you will end there anyway.

Then save as a CSV and all your scripts parse data from that single
file. This is almost guaranteed to end up saving you time in the long run.

In the bad old days you ONLY had vi available when you needed to do
emergency rescue, so it was necessary to practice. If you plan on
eventually living from this I'd recommend using the native editor on a
daily basis.

--
Thorbjørn Ravn Andersen

On 18 Ott, 09:24, Thorbjoern Ravn Andersen <nospam0...@gmail.com>
wrote:
The cvs idea is not bad at all, is there a very light cvs editor for
macosx?
(I don't want to use excel or anything like that of course)

Thorbjoern Ravn Andersen <nospam0...@gmail.com> wrote:
I've been in situations where I only had "ed" and occasionally when
all I had was a running "sh" so I was stuck with built-in "echo" and
IO redirection. It is necessary to learn an assortment of basic tools
to fluency, whether practice is needed after that depends on how
good your retention is.

SAs need to know vi or vim extremely well. I have forward preferred
various versions of emacs but I actually use vi or vim. It isn't a
matter
or personal preferences. In this sense it is all about practice - As
an
SA I need to be able to edit text files quickly and easily on hosts I
have never logged into before and that likely only have the basics.

One dull day if ever some lost imp scratched :

That's clear but you won't have LaTeX useable on every server you'll have
to admin.

If you don't have the doc local to the machine it's related to
you'll bite your fingers to the bone next time you'll be of
duty on distant access to this poor good old dying server :-)

As to organize the info that's beyond the scope od a tool choice,
I guess it is deeply related to your own conditions of work and
your own abilities to synthesize info.
Buildind a doc nest for you and three machines is not on the same
level of anguish and fear than having clear and neat doc for several
rotating teams and hundreds or thousands starving servers in the
world.

Maybe the same question asked on a documentalists newsgroup will
give you the perfect blade but really, as a SA I never believed
there was a magic word that'd fit everyone :-)

I usually recommend to use vi (or 'cat > docfile...^D in case of emerg.)
but you may extend this with frontends and backends like 'asciidoc'
(or similar) wich would empower you of different presentation
abilities like HTML,Xhtml,docbook,pdf,LaTeX exports.
These kind of tools include the "collation of heteregenous docs",
you may export one doc to different export formats one per chapter
or export different docs towards one united doc.
The effort on semantics and rewriting is close to null, basically
you write an ascii text with vi and a few "reflexes" like ``quoting'' words
to quote and *bolding* words to be bold ;-)

andrea <kerny404@gmail.com> writes:

You could just use tab-separated lines in any editor.
--
Thorbjørn Ravn Andersen

On Thu, 18 Oct 2007 09:04:05 -0700, Doug Freyburger <dfreybur@yahoo.com> wrote:
Yup. Back in the dark ages, I once rebuilt the hosts file on our NIS
master with:
cat > /etc/hosts
....and a bit of luck remembering enough IPs to let the box know who it
was and who it could get the real hosts file from.

Fun interview question: you have physical access to the box but its
network is gone, and you have no root shell. How do you get it back
online?

Dave Hinz <DaveHinz@gmail.com> writes:

Insufficient data.

Unplug and replug the network cable?

--
Thorbjørn Ravn Andersen

Dave Hinz <DaveH...@gmail.com> wrote:
BTDTgtTS. I've also done the same with /etc/passwd to a 1-liner
and later gone back to recover it from backup tape.

Huh. You've managed to overhear one of my interviews a few
years ago? Scenario questions are the most rewarding to both
ask and answer.

On 19 Oct 2007 06:25:44 +0200, Thorbjoern Ravn Andersen <nospam0000@gmail.com> wrote:
Best kind of interview question. Can't just hand 'em the answer, I want
to see how they think.

Didn't work.

On Fri, 19 Oct 2007 06:55:11 -0700, Doug Freyburger <dfreybur@yahoo.com> wrote:
I like scenerios that I've lived through, or are mostly what I've lived
through with a bit of artistic license thrown in to make it a better
story or riddle. How about this one:

On your first day as sysadmin for a small department, you are told that
the previous admin quit so abruptly that he left no root password or
support documentation, left his sweater hanging in the computer room and
(...you find later, the hard way) that he left his lunch in the desk
drawer. It's been weeks and now things are starting to break. The
group of users are scientists, not IT folks, so their understanding is
limited to "the box doesn't go bing anymore when I push the button".

Upon entering the computer room, you see perhaps a dozen racks, systems
open and running on benches, under tables, and on a cluttered desk (see
previous re: lunch in drawer). The desk has the nicest monitor in the
room and a jumble of reference books, tapes, and general unixish
clutter.

Where do you start? How do you figure out what is important and what
isn't, how do you get into the domain without a password, and what do
you do first?

(I use this scenerio or a variation of same at nearly every interview,
once the "can the person do the work" has been established and we've
moved on to the "What is their thought process and judgement, and would
I want to spend most of my waking hours with them" phase of the conversation.)

Dave

Dave Hinz wrote:

Any log messages on the console to give the interviewee a hint at the
problem?

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------