[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/en/ITIL/Support" by PetterReinholdtsen

Debian Wiki debian-www at lists.debian.org
Sun May 31 04:31:03 UTC 2015


Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianEdu/Documentation/en/ITIL/Support" page has been changed by PetterReinholdtsen:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Support?action=diff&rev1=22&rev2=23

  
  For most situations, scripting is an easy way to "build" and roll out programs and configurations. But there are situations where building disk images may be the solution, e.g. for installation on many laptops.
  
- As we see, handling the construction process is about facilitating deployment on many computers. In exceptional cases, this may involve building a tailor-made Debian package. But in most situations, everything is ready-packaged. Then you have to put in place a script which installs additional programs and certain settings. One can also create disk images if you have many similar machines, such as laptops for all students
+ As demonstrated, handling the build process is about facilitating deployment on many computers. In exceptional cases, this may involve building a tailor-made Debian package. But in most situations, everything is ready-packaged. Then you must write and deploy a script which installs additional programs and certain settings. One can also create disk images if you have many similar machines, such as laptops for all students.
  
  === Testing ===
  
@@ -405, +405 @@

  
  Testing generally takes place in three steps.
  
-  * First, do an installation of the changes on a test network. This is technical testing to check that everything hangs together in a system with few users. Take care to include all changes in configuration files.
+  * First, do an installation of the changes on a test network. This is technical testing to check that everything functions in a system without users. Take care to include all changes in the configuration files.
-  * When you are sure that everything works on the technical side, try installing the solution in one school. It is very important to agree about the testing with the school's ICT contact. Users must also be fully briefed on changes made for the sake of testing. Take care to preserve current adjustments in the set-up files, which may have been made in the course of normal maintenance.
+  * When you are sure that everything works on the technical side, try installing the solution in one school. It is very important to book the testing with the school's ICT contact. Users must also be fully briefed on changes made for the sake of testing. Take care to preserve current adjustments in the set-up files, which may have been made in the course of normal maintenance.
   * When you are sure everything works, you can roll out the solution to all schools. It is easiest to create a script that simplifies upgrading of software packages, services and configurations.
  
  === Fall-back solution ===
  
  Much can go wrong during a new installation or upgrade. Therefore, one must have ready a fall-back solution. This lets one quickly get back to the system as it was before the upgrade. In technical terms, this is called roll-back.
  
- When rolling back it is absolutely essential to have ready the previous version of the software archive and configuration files. This means that you can install for example Edu 1.0 in under an hour, and put in place the appropriate configuration files.
+ When rolling back it is absolutely essential to have the previous version of the software archive and configuration files ready. This means that you can install for example Edu 1.0 in under an hour, and put in place the appropriate configuration files.
  
- But roll-back takes time. Therefore, it may be prudent to have a server ready with the previous version of the software, the right configurations, and a recent copy of the users' home directories. This server can quickly replace any machines on which the upgrade does not go according to plan. Having server machines in reserve can ensure high availability even if something goes wrong.
+ But roll-back takes time. Therefore, it may be prudent to have a server ready with the previous version of the software, the right configurations, and a recent copy of the users' home directories. This server can quickly replace any machines on which the upgrade does not work according to plan. Having server machines in reserve can ensure high availability even if something goes wrong.
  
  === Advantages and possible problems ===
  
- The advantage of having records of the software in production can't be underestimated. Many rely on having the software on their respective CDs and DVDs. This is inefficient distribution. To save time and trouble all the software in Debian Edu is available online.
+ The advantage of having records of the software in production can't be underestimated. Many rely on having the software on their respective CDs and DVDs. This a inefficient method of distribution. To save time and trouble all the software in Debian Edu is available online.
  
- Your operating department can create a copy of the Debian Edu archive on a central server. From here, all the software can quickly and smoothly be installed on other machines. The advantage is that your ICT service has a constant overview of the versions of the software they have made available to schools. This also prevents the installation of software that has not been considered by the Change Management.
+ Your operations department can create a copy of the Debian Edu archive on a central server. From here, all the software can quickly and smoothly be installed on other machines. The advantage is that your ICT service has a constant overview of the versions of the software they have made available to schools. This also prevents the installation of software that has not been reviewed by the Change Management.
  
  There may be considerable problems if you do not maintain the software archive and configurations. It can also lead to mistakes with a configuration or software package. Then this gets rolled out to all machines. In addition, some schools may install insufficiently tested software or use beta releases in production. So one must have good processes and have someone to take responsibility for maintenance of the program archive and configurations.
  



More information about the debian-edu-commits mailing list