Who keeps a change log?
We have a log to note down major changes against helpdesk tickets (which obviously go into more detail)
And System scripts are annotated at the top for chages.
Rob
Printable View
Who keeps a change log?
We have a log to note down major changes against helpdesk tickets (which obviously go into more detail)
And System scripts are annotated at the top for chages.
Rob
Me. I document everything that happens to every machine we have. I always have and anybody who doesn't is a fool (IMO). One of the really great things about working on unix boxes, is that all system changes are logged automatically, and in a useful format. If only M$ and Linux boxes did this. I use a wiki and if any of my staff make changes to a machine and fail to document, the punishment is worse than death.
We do, although on a "clustered" approach.
Any change to the system is communicated between all 3 of us via email and documentation updated in bulk.
This has lapsed somewhat with the complete migration of one setup to another but just in the works of re-setting this all up.
My aim is to have this linked with asset management within the next year.
Ours is all done Via the helpdesk, a search on the computer name will display all tickets that have been associated with it.
We also have a wiki for site, infrastructure and server changes as well as common issues and disaster recovery plans(printed too!).
As everything is text files, you can maintain Linux configuration via normal source code tools such as RCS/CVS or Git. The simplest to get along with is probably RCS.Quote:
Originally Posted by unixman_again
Sys Admin File Revision Control with RCS
There are however bespoke solutions, for example etckeeper.
Keep Configs Under Control With Etckeeper -- ServerWatch
Not only will these allow you to keep a changelog, but also allow you to rollback/forwards through configuration revisions and therefore back out of changes that broke stuff.
Finally, if like me, you have a lot of Linux machines you should be using Puppet or Chef which gets you this stuff for free along the way.
http://www.opscode.com/chef/
http://puppetlabs.com/
To be fair you really have to document everything with Linux, you can use a wider brush with windows as its just add interface here with this ip instead of recompile this for this MTU and specific custom firmware revision of the network card.Quote:
Originally Posted by unixman_again
I do agree that documentation is really important but a lot can also be done with saved configs and robust systems along with an overview. Stuff like puppet which can do all the mental config again for you are also helpful if you have a box of infinite settings to deal with.
Not a proper one at the moment. But then there are a number of other things I'm still trying to get right in terms of documentation.
We use Spiceworks for a basic help desk. I'd like to get it's inventory tided up and get the techs to associate jobs with the inventory but that is a way off.
I created a custom web based database called "Cluster Logs" for techs to log all work they do at any school we support in one central location. It's a bit loser than a full on change log but serves a similar purpose. I'm concentrating on this being used fully when they visit feeder schools but the goal is all completed jobs, both internal and external, are. We can quickly search by school, job type, hardware type, computer model, technician, etc so I should be come a good tool for cross referencing recurring or similar problems.
Then we have a Wiki site. This is our main area of systems documentation, period! This is also my number 1 focus with the technicians, until we have this working 100% I'm not going to battle with the rest.
I do have a full disaster recovery plan recorded in the Wiki and printed off in the fire safe, so there's that at least :D
We have a help centre but unfortunately because people still walk in that door and ring up every 5 minutes - like this morning technician turns up late (as usual) and while he walks in the door I have already dealt with a few people and still had 2 people in the office - while more walk in the door.
I simply can not write down everything that I have done when I am doing my best to support people.
We do copy/put jobs in to the help centre though for staff who couldnt be bothered :)
Still waiting for a decent wiki system that we can use here on Frog to record everything - did have one once but that server died..
Have a database though that records a lot of data.
Same here. Sometimes it gets behind, then one or other of us spends an hour or so updating the asset records.Quote:
Originally Posted by LiamH
I'm the only person here (I kid you not, honestly) who has ever worked with any form of change-control. I've been trying to introduce it ever since I've been here, but for some reason, the idea of planning a change, formulating backout procedures, testing and then implementing those changes seems to be completely incompatible with IT in this particular bit of the education sector.
My first experience of it here (I'd been in post for eight weeks maybe, five of which were the summer holidays):
Head of ICT (my LM at the time):<Service Provider> has given us two of the servers so we can rebuild the domain from scratch. So, off you go, carry on with that.
Me: Ok, cool. Don't you think we should sit down and talk about it for a while? Plan it a bit?
HoICT: Why? What's there to plan?
Me: Well, what do you want to call this domain, for a start?
HoICT: Oh.....I hadn't thought of that.
:doh:
She was a classic. I could tell you stories about her, make your teeth fall out.