Changes

== Dextrose Server ==

== Dextrose Server ==

(The following pages describe the dextrose server infrastructure. We currently have 2 parts to the server, the Server Builder (Mothership Dextrose) and the build itself (School Server) This is of course a very simplistic view, and over the last weeks, things have begun to clarify themselves somewhat so that A real revision to this section makes sense and will also be readable to the typical layperson:)

Before diving straight into what the Dextrose server is, should and will be, I'd like to talk a little about policy, and the way its used in both small, medium and defenitely large companies. This policy document, is usually written with 2 essential ideas in mind, and passed around the company or often even expected to be known instinctively by all company employees of all categories (we'll mention just the relevant parties here):

Before diving straight into what the Dextrose server is, should and will be, I'd like to talk a little about policy, and the way its used in both small, medium and defenitely large companies. This policy, is usually a document that has been written up with 2 essential ideas in mind, and passed around the company or often even expected to be know by employees of all categories.:

1. Techies tend to have the mindset that, whatever it takes, however long it takes, and however many other systems are affected is not something they ought to be aware of nor is it really their problem. Adhering to a strict policy stops this kind of thinking from happening. Techies are unfortuantely almost all culpable in some way or another of this condition [me included], which is why they/we are usually very good at finding a solution for almost anything, but also very good at bringing a system down in order to resolve it.

1. Techies tend to have the mindset that, whatever it takes, however long it takes, and however many other systems are affected is not something they ought to be aware of nor is it really their problem. Adhering to a strict policy stops this kind of thinking from happening. Techies are unfortuantely almost all culpble in some way or another of this condition, which is why the are usually very good at finding a solution for almost anything.

2. On the other hand a more admin-like policy perspèctive, is that what a techie does comes second to having a fully functional system that does not crash, change too often, or make dramatic changes to the policy document in place. In other words, if its not broken they shouldn't fix it. The problem here lies in the fact that most admins/managers don't realise that not being continously aware of the system, understanding how it works, when updates are required and such, are just as important as keeping the system running. Policy, therefore, for them strictly outlines that updates, especially security related ones must be perfomed on a reguar cycle, power systems must be checked, internet connectivity, etc, etc. For them it is a kind of checklist that needs to be performed every so often.

2. On the other hand a more admin-like policy perspèctive, is that what a techie does comes second to having a fully functional system that does not crash, change too often, or have dramatic changes to the policy in place. In other words, if its not broken they shouldn't fix it. The problem here lies in the fact that most admins/managers don't realise that not being continously aware of the system, understanding how it works, when updates are requires and such, are just as important as keeping the system running. Policy, therefore, for them strictly outlines that updates, especially security related one must be perfomed on a reguar cycle, power systems must be checked, internet connectivity, etc, etc.

Normally, small companies notice the terrible state of affairs that occurs when either one or more commonly both of these groups of people ignore policy altogether, resulting in the numerous non-functional servers in the field. And if the techies and managers/admins/deployers are not taking much notice of policy, you can imagine how much attention a teacher or headmaser gives it. Ususally this third group of people are very briefly made aware of a certain set of steps they should adhere to, when problems occur. It is usually not well explained, possibly only in one language, and thought of as a weird document that some guy wrote way up the food chain, that has never been in the field, and couldn't possibly have written anything that might help the particular problem they are experiencing.  

Normally, small companies notice the terrible state of affairs that occurs when either or more commonly both of these groups of people ignore policy altogether, resulting in the numerous non-functional servers in the field. And if the techies and managers/admins/deployers are not taking much notice of policy, you can imagine how much attention a teacher or headmaser gives it.

The end result of this is usually many many broken systems all because a proper structure was either not created in the first place (most commonly) or it being ignored due to too much growth, too much turn around, or not enough people to enforce and more commonly believe in the policy document.

The end result of this is usually many many broken systems all because a proper structure was either not created in the first place (most commonly) or it being ignored due to too much growth, too much turn around, or not enough people to enforce the policy.

This is one of the main reasons, automation was integrated into larger companies that want to do a number of differing jobs, but that all revolve around strictly following a policy (who can do what, when, how it should be done, what every member is responsible for, etc) Unfortuantely, companies rarely comply fully with policy, but by automating the processes for building the servers we want to create, it almost creates the policy for us. Of course this involves documentation!

This is one of the main reasons, automation was integrated into larger companies that want to do a number of differing jobs, but that all revolve around strictly following a policy (who can do what, when, how it should be done, what every member is responsible for, etc) Unfortuantely, companies rarely comply fully with policy, but by automating the processes for building the servers we want to create, it almost creates the policy for us. Of course this involves documentation!

Techies are terrble at this, but this is an attempt at trying to get that right. We want to spend quite some time on the various aspects of the policy document so that it can help every member involved in the deployment scenario. The whole aim of this is to make things run more smoothly, faster, more efficiently, and hopeully even with a little more excitment involved. Yes... this document needs to be created... so lets do our best to join forces with all the different brain types (Jungian Archetypes) and create a kick ass policy document that can make it easy for us to know where we all fit in this large wheel of ongoing change.

Right we are in the process of defining/documentin/testing 2 automated installation processes, one based for RHEL 6 (CentOS 6) and the other Debian 6. We don't need to go into the best parts of one system (sysadmins ususally say debian 6 is much easier to control for centralised networking services like DNS, NTP, CFengine or Puppet, Nagios, etc), whereas RHEL 6, which is the system we have chosen to support solely at this time, on the other hand is based on the direct support we can get from the company itself, who, I am sure, as soon as they see our automated builder, would be very interested in giving us access to their RHN Satellite (If not, we just wait for CentOS rpms) for educational purposes.

Right now we are in the process of defining/documentin/testing 2 automated installation processes, one based for RHEL 6 (CentOS 6) and the other Debian 6. We don't need to go into the best parts of one system (sysadmins ususally say debian 6 is much easier to control for centralised networking services like DNS, NTP, CFengine or Puppet, Nagios, etc), whereas RHEL 6, which is the system we have chosen to support solely at this time, on the other hand is based on the direct support we can get from the company itself, who, I am sure, as soon as they see our automated builder, would be very interested in giving us access to their RHN Satellite (If not, we just wait for CentOS rpms) for educational purposes.

Right now, We have various pieces that have been created to help both simplify and modularise the existing XS system. Clearly, .au has done a wonderful job with taking out components which just weren't necessary. Granted, it is always much easier to add on new items, than to start reverse engineering and extracting elemens that we might find are essential further down the line. Having buld both the FAI (Fully automated Installer) for debian, and the kickstart based automatic installer for RHEL 6, these are the current bases we will want to be working on.

Right now, We have various pieces that have been created to help both simplify and modularise the existing XS system. Clearly, .au has done a wonderful job with taking out components which just weren't necessary. Granted, it is always much easier to add on new items, than to start reverse engineering and extracting elemens that we might find are essential further down the line. Having buld both the FAI (Fully automated Installer) for debian, and the kickstart based automatic installer for RHEL 6, these are the current bases we will want to be working on.

If new SAs at the site read some internal documentation about installing and configuring system software, they dont have any assurance that following the documentation will achieve the desired effects they are looking for. The SA is much better off using a script that has been used all the previous times the software needed to be installed (hence the reasonf for documenting steps in the wiki,and pushing code to an SVN/Git/BZR)

If new SAs at the site read some internal documentation about installing and configuring system software, they dont have any assurance that following the documentation will achieve the desired effects they are looking for. The SA is much better off using a script that has been used all the previous times the software needed to be installed (hence the reasonf for documenting steps in the wiki,and pushing code to an SVN/Git/BZR)

In this way either the script will work as advertised, or it will show breakage somewhere. Using automation, where all systems that install use the same sequence of events as laid out in a careful y laid out policy will help insulate the SA against breakage scenarios.

In this way either the script will work as advertised, or it will show breakage somewhere. Using automation, where all systems that install use the same sequence of events as laid out in a carefully laid out policy will help insulate the SA against breakage scenarios.

The other advantage, though a rather morbid one is, should someone with the majority of this knowledge be hit by a car/truck/boat, the whole project won't come to a standstill.

The other advantage, though a rather morbid one is, should someone with the majority of this knowledge be hit by a car/truck/boat, the whole project won't come to a standstill.

[http://watson-wilson.ca/blog/ent-sysadmin.html] ← very nice visual outline for how things change from doing things the old fashioned one computer at  type way to many systems automation via policies.

[http://watson-wilson.ca/blog/ent-sysadmin.html] ← very nice visual outline for how things change from doing things the old fashioned one computer at  type way to many systems automation via policies.

== Applying Practical Automation ==

== Applying Practical Automation ==