K
Kent Tenney
Howdy,
Any recommendations for automating
administrative tasks using Python?
Thanks,
Kent
Any recommendations for automating
administrative tasks using Python?
Thanks,
Kent
D
David M. Wilson
Kent said:
vim? *ducks*
David.
K
Kent Tenney
David said:
honk *geese*
P
Peter Hansen
Kent said:
Yes, do it! I strongly recommend Python for automating administrative tasks.
(You might improve the question with a little more context if you wish better
responses.)
-Peter
K
Kent Tenney
Peter said:
My interest in this stems from doing a bunch
of installations of a package which requires
editing quite a few files, tedious and error
prone.
I'd like the convenience of being able to define
the edits in a script.
I was trolling for a response like;
"I've been building this great package which
allows scripting common configuration tasks
in this really clever and simple way ..."
For some reason I got the idea cfengine required
Perl scripting. Upon researching it to improve
my question with a little more context
I find it's not Perl-centric, it's
very well documented and complete ...
Nevermind.
Thanks,
Kent
?
=?iso-8859-1?Q?Fran=E7ois?= Pinard
[Kent Tenney]
I did use `cfengine' for a good while, before I decided that Python
would serve me better for the same kind of tasks. It took me two or
three full time weeks for converting all of my `cfengine' setup to
Python, and in my case at least, this was a good move to do.
However, my setup was not written with publication in head, and I did
not retain from `cfengine' the things I did not use nor need. Moreover,
since I wrote it for me, I was not shy to push many of my own habits in
the code. What required the most attention, if I remember well, was
proper sorting and merging of all requested actions for efficiency, for
example, a single pass through the file system did it all. Another
point was proper logging of actions (for debugging or otherwise), with
due references to the controlling files: and this proved very useful.
It was easy to design all controlling files so they use Python syntax,
this gave me a tremendous power and flexibility for almost free.
Surprisingly, the result was not significantly slower than `cfengine'
in practice, teaching me that Python interpretation overhead merely
disappears in I/O bound contexts. The overall result was immensely more
readable than `cfengine' (I often had to dive in them to understand
behaviour or correct bugs), and consequently, more maintainable.
Over years, I got my configuration engine to take care of many things
that would likely escape `cfengine' capabilities, like firewall build-up
automatically derived from (Python) descriptions of the network topology
and distribution of services, easy fetching and deployment for various
external tools we depend upon, and other such things, so it does not
much look like `cfengine' anymore.
All in all, I found that Python is a marvellous framework for automatic
system-administrative tasks, and shaping this framework is not that
difficult, even if it requires some work. For me, it was much worth it.
In these years, I do not do much real system administration anymore.
But in the team I work in, the main system administrator, who saw my
framework, understood that it was not that difficult to do, and prefer
making his own (in Python, of course), at least as a way to make sure he
understands everything inside out. That's very OK!
I did use `cfengine' for a good while, before I decided that Python
would serve me better for the same kind of tasks. It took me two or
three full time weeks for converting all of my `cfengine' setup to
Python, and in my case at least, this was a good move to do.
However, my setup was not written with publication in head, and I did
not retain from `cfengine' the things I did not use nor need. Moreover,
since I wrote it for me, I was not shy to push many of my own habits in
the code. What required the most attention, if I remember well, was
proper sorting and merging of all requested actions for efficiency, for
example, a single pass through the file system did it all. Another
point was proper logging of actions (for debugging or otherwise), with
due references to the controlling files: and this proved very useful.
It was easy to design all controlling files so they use Python syntax,
this gave me a tremendous power and flexibility for almost free.
Surprisingly, the result was not significantly slower than `cfengine'
in practice, teaching me that Python interpretation overhead merely
disappears in I/O bound contexts. The overall result was immensely more
readable than `cfengine' (I often had to dive in them to understand
behaviour or correct bugs), and consequently, more maintainable.
Over years, I got my configuration engine to take care of many things
that would likely escape `cfengine' capabilities, like firewall build-up
automatically derived from (Python) descriptions of the network topology
and distribution of services, easy fetching and deployment for various
external tools we depend upon, and other such things, so it does not
much look like `cfengine' anymore.
All in all, I found that Python is a marvellous framework for automatic
system-administrative tasks, and shaping this framework is not that
difficult, even if it requires some work. For me, it was much worth it.
In these years, I do not do much real system administration anymore.
But in the team I work in, the main system administrator, who saw my
framework, understood that it was not that difficult to do, and prefer
making his own (in Python, of course), at least as a way to make sure he
understands everything inside out. That's very OK!