Dextrose/Server - Revision history

Davelab6 at 04:39, 17 May 2016

2016-05-17T04:39:55Z

← Older revision		Revision as of 00:39, 17 May 2016
Line 1:		Line 1:
			{{Obsolete \| Moved and died at https://sugardextrose.org/ }}

	== Dextrose Server ==		== Dextrose Server ==

Nubae: /* Dextrose Server */

2011-03-07T21:01:24Z

Dextrose Server

← Older revision		Revision as of 17:01, 7 March 2011
Line 1:		Line 1:
	== Dextrose Server ==		== Dextrose Server ==

	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.:		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):

	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.		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.

	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.		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.

	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.		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.

	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.		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.

	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.		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.		== System builders ==

			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.
Line 24:		Line 26:

	The emphasis should of course be to make sure it is supported on one OS, but we shouldn't make it harder than it has to be for others to use the system on another OS. This strategy was quite successful with projects like LTSP, which used to be K12LTSP and only worked on Redhat. This caused many developers to shy away from working with it, until it was modularised, and supported seperately for other operating systems. I'm not saying the dextrose server should be supported for every operating system from onset, or that we should even build for every contingency, but we should keep in mind that this is an open source project, and as such should attract as many developers and users as possible. To that end, it seems the .AU OLPC developers have done a lot of cleaning up and modularising of the current XS code. That's great, and we will probably take that code as opposed to the current XS as our base. What I mean is we should take their components and include them into our mass builders, before we start taking appart the larger and more complicated original OLPC XS server.		The emphasis should of course be to make sure it is supported on one OS, but we shouldn't make it harder than it has to be for others to use the system on another OS. This strategy was quite successful with projects like LTSP, which used to be K12LTSP and only worked on Redhat. This caused many developers to shy away from working with it, until it was modularised, and supported seperately for other operating systems. I'm not saying the dextrose server should be supported for every operating system from onset, or that we should even build for every contingency, but we should keep in mind that this is an open source project, and as such should attract as many developers and users as possible. To that end, it seems the .AU OLPC developers have done a lot of cleaning up and modularising of the current XS code. That's great, and we will probably take that code as opposed to the current XS as our base. What I mean is we should take their components and include them into our mass builders, before we start taking appart the larger and more complicated original OLPC XS server.

	~~The idea of working inaisw Virutal MAchin~~


	~~eees às opoded~~

	== Defining Policy ==		== Defining Policy ==

Nubae: /* Defining Policy */

2011-03-05T14:49:26Z

Defining Policy

← Older revision		Revision as of 10:49, 5 March 2011
Line 45:		Line 45:
	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.
Line 58:		Line 58:

	[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 ==

Nubae: /* Dextrose Server */

2011-03-05T14:46:14Z

Dextrose Server

← Older revision		Revision as of 10:46, 5 March 2011
Line 1:		Line 1:
	== 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, 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.:		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.:
Line 26:		Line 24:

	The emphasis should of course be to make sure it is supported on one OS, but we shouldn't make it harder than it has to be for others to use the system on another OS. This strategy was quite successful with projects like LTSP, which used to be K12LTSP and only worked on Redhat. This caused many developers to shy away from working with it, until it was modularised, and supported seperately for other operating systems. I'm not saying the dextrose server should be supported for every operating system from onset, or that we should even build for every contingency, but we should keep in mind that this is an open source project, and as such should attract as many developers and users as possible. To that end, it seems the .AU OLPC developers have done a lot of cleaning up and modularising of the current XS code. That's great, and we will probably take that code as opposed to the current XS as our base. What I mean is we should take their components and include them into our mass builders, before we start taking appart the larger and more complicated original OLPC XS server.		The emphasis should of course be to make sure it is supported on one OS, but we shouldn't make it harder than it has to be for others to use the system on another OS. This strategy was quite successful with projects like LTSP, which used to be K12LTSP and only worked on Redhat. This caused many developers to shy away from working with it, until it was modularised, and supported seperately for other operating systems. I'm not saying the dextrose server should be supported for every operating system from onset, or that we should even build for every contingency, but we should keep in mind that this is an open source project, and as such should attract as many developers and users as possible. To that end, it seems the .AU OLPC developers have done a lot of cleaning up and modularising of the current XS code. That's great, and we will probably take that code as opposed to the current XS as our base. What I mean is we should take their components and include them into our mass builders, before we start taking appart the larger and more complicated original OLPC XS server.

			The idea of working inaisw Virutal MAchin


			eees às opoded

	== Defining Policy ==		== Defining Policy ==

Nubae: /* Dextrose Server */

2011-03-05T09:39:16Z

Dextrose Server

Show changes

Nubae: /* Dextrose Server */

2011-02-22T21:43:01Z

Dextrose Server

← Older revision		Revision as of 17:43, 22 February 2011
Line 9:		Line 9:
	''' Mothership - Debian ''' [[Dextrose/Server/DebianBuilding]]		''' Mothership - Debian ''' [[Dextrose/Server/DebianBuilding]]

	''' Extras to XS 0.6 ''' [[[Dextrose/Server/Addons]]]		''' Extras to XS 0.6 ''' [[Dextrose/Server/Addons]]

Nubae: /* Dextrose Server */

2011-02-22T21:41:59Z

Dextrose Server

← Older revision		Revision as of 17:41, 22 February 2011
Line 8:		Line 8:

	''' Mothership - Debian ''' [[Dextrose/Server/DebianBuilding]]		''' Mothership - Debian ''' [[Dextrose/Server/DebianBuilding]]

			''' Extras to XS 0.6 ''' [[[Dextrose/Server/Addons]]]

Nubae: /* Dextrose Server */

2011-02-17T20:08:46Z

Dextrose Server

← Older revision		Revision as of 16:08, 17 February 2011
Line 6:		Line 6:

	'''Mothership''' [[Dextrose/Server/Building]]		'''Mothership''' [[Dextrose/Server/Building]]

			''' Mothership - Debian ''' [[Dextrose/Server/DebianBuilding]]

Nubae: /* Dextrose Server */

2011-02-10T19:02:31Z

Dextrose Server

← Older revision		Revision as of 15:02, 10 February 2011
Line 5:		Line 5:
	The infrastructure is based on Redhat Enterprise Linux 6. We may move to/work with Centos 6 when it is released. Right now we only support 32 bit i386, though we might support x64 in the future.		The infrastructure is based on Redhat Enterprise Linux 6. We may move to/work with Centos 6 when it is released. Right now we only support 32 bit i386, though we might support x64 in the future.

	'''Mothership''' [[Building]]		'''Mothership''' [[Dextrose/Server/Building]]

Nubae: /* Dextrose Server */

2011-02-10T18:22:44Z

Dextrose Server

← Older revision		Revision as of 14:22, 10 February 2011
Line 5:		Line 5:
	The infrastructure is based on Redhat Enterprise Linux 6. We may move to/work with Centos 6 when it is released. Right now we only support 32 bit i386, though we might support x64 in the future.		The infrastructure is based on Redhat Enterprise Linux 6. We may move to/work with Centos 6 when it is released. Right now we only support 32 bit i386, though we might support x64 in the future.

	[[~~Server (mothership) Build~~]]		'''Mothership''' [[Building]]