MagOS in industrial applications

When doing this work, the goal was to minimize the time it takes to service the network from a large number of Linux machines.

1. Basic description of the basic principles
1.1. Application of MagOS.
1.2. Technology.
1.3. Choosing a basic distribution.
2. Network structure.
2.1. Magos-server.
3. Configuring the bootloader.
3.1. Loader strings.
3.2. Options that were used.
3.3. Options that can be used.
3.4. Features network boot.
4. The procedure for initializing the system.
4.1. The default basecfg.ini configuration file structure.
4.2. The structure of the system directory.
4.3. Implementation.
5. MagOS server.
5.1. General information.
5.2. Network settings.
5.3. Configure services.
5.4. Program repository.
5.5. Additional server data
5.6. Monitoring
6. Custom modules.
6.1. General principles for creating custom modules.
6.2. How many modules do.
6.3. Modules for special purposes.
6.4. Limitations for modules.
6.5. Instructions for creating modules.
6.6. System update module.
6.7. Office software installation module.
6.8. Module with utilities and servers.
6.9. System settings module.
7. Scripts.
7.1. Additions to magos-patches.
7.2. OS installation script.
7.3. Inclusion scripts in AD.
7.4. System Management (/ root / bin).
7.5. Additional scripts that correct the operation of magos programs and the operating system.
8. Instructions for technicians.

Basic description of the basic principles

MagOS Application

MagOS is a specific build of a distribution, selected from an extensive list. Live distributions of Magea, Mandriva, Rosa, Ubuntu, Debian, Fedora, AltLinux, etc. can serve as the basis for building the assembly. The specific elements of MagOS are the modified kernel (to support AUFS), the initrd created in a special way (using UIRD) and an additional set of scripts designed to control MagOS.

MagOS allows you to create on the basis of Live assemblies of various distributions (assemblies designed to be downloaded from a CD, DVD disc) a complete operating system. The specifics of using MagOS provides a whole range of additional advantages of this approach:

Very simple system restore to its original state. It can be compared with the technology of working with equipment, when the introduction of a special command allows you to reset all settings made by the user and bring the system to its original state. Here, the same effect is achieved by the destruction of data in the sections in which user data is stored. Thus, this option to install the distribution becomes simply indispensable when used in the educational process. To the above, you need to add the ability to install the distribution kit on a flash drive, which allows a student or student to use it not only in the classroom, but also at home.

The second most important advantage of the distribution kit is the ability to pre-configure the system. It is achieved by including all the necessary configuration files with parameters in the immutable part of the distribution, the so-called modules. Using this technology, we minimize the number of administrator actions after installing the system on the user's computer. This opportunity can be used not only for the organization of computer classes, but also among industrial enterprises, minimizing the possible minimum labor costs for installing and configuring when working with a large number of users' computers.

The third advantage is the ease of installation and updating of such an assembly of the operating system, which boils down to partitioning the disk, creating file systems, copying a set of files to a computer, and installing the bootloader. In industrial applications, all of these operations can be performed automatically when you run the appropriate script. Updating the installed distribution also comes down to copying files, which can be done automatically, for example, when you turn off the computer.

Some of the advantages include the ability to network download the distribution, including from the Internet.

The unrealized capabilities of MagOS include the lack of the ability to store user data on a secure distributed file system. The implementation of such a distributed file system will allow for full reintegration of users.

Some introductory information about MagOS can be obtained from the article: MagOS Linux (September release) .

Technology

Modification of the Linux kernel included in MagOS is to include a patch with the AUFS file system. AUFS allows you to connect external file systems to the file system using the loopback interface, assembling the resulting file system like a layer cake. The intermediate layers of such a resulting file system are connected, most often, in the RO (read only) mode, and the uppermost layer, as a rule, is connected in the RW (read-write) mode and is projected onto a disk file system, which can be placed in RAM , on a physical disk, in a disk image, and saved during the shutdown operation in a special module that is connected using the SquashFS file system.

The SquashFS file system allows you to perform compression using the block algorithm, while retaining all the attributes of the file system. In MagOS, it is used to create loadable modules with layer images of the AUFS file system. The block compression algorithm allows not to unpack the entire module files if it is necessary to extract data from them.

In MagOS, the initrd disk image used to boot Linux on most distributions is used to organize the system. There are scripts that create a “layered” distribution file system, process configuration files, etc.

The data required to configure the system is transmitted through the kernel parameters of the operating system, which are written in the grub4dos / grub2 / syslinux bootloader, and using the special configuration file MagOS.ini. Where and what parameters are transmitted is described in the documentation. Parameters related to the general configuration of the operating system are transferred using kernel parameters. They are organized into the Unified Init Ram Disk (uird) parameter system.

Parameters are described on the project website: UIRD . Used Magos multi distribution .

In industrial applications, you cannot do without a server that contains the distribution kit and supports the HTTP (for remote download), TFTP (remote download via PXE), SSH (for file management) and RSYNC (for installing and updating the OS on users computers) protocols. The server can be implemented on any distribution, including MagOS. In my case, a virtual container based on the CentOS 6 distribution was used.

To control the system, the necessary options and scripts were added to MagOS to process them.

Choosing a base distribution

Choosing a distribution kit on the basis of which a network is built is always a complex and controversial task. Choosing a particular distribution you have to consider many factors, including many local problems. We had the following factors: very unproductive user computers, although they were recently acquired, they saved on computers, therefore, in a typical machine, where the user sits, only 2 Gigabytes of RAM and a dual-core Celeron with a not very high clock speed. Such a typical configuration of a user's computer imposes restrictions on the choice of a desktop manager; in particular, it is no longer possible to use KDE without losing the possibility of a comfortable user experience.

Secondly, this is a problem of low qualification of personnel, whose main function is, by no means, not working with a computer. It is necessary to remember the long-standing habit of one single operating system that people have had to work with for many years - Windows XP, which support has been discontinued, which is why the problem of replacing the OS in users' workplaces actually arises.

Exploring the possibilities of adapting the appearance of the desktop to the appearance of the good old XP, we decided to stop at Cinnamon. Despite the fact that the development has not yet been released, in the standard configuration this desktop works quite steadily and easily adapts to the XP appearance by installing the appropriate theme. An additional factor affecting the choice of OS was the “desire” of the state structures to see computers with a domestic operating system at workplaces. So the whole choice, in our case, came down to the choice between the Rosa OS and the Alt Linux OS.

Despite considerable experience with the Rosa OS, comparing AltLinux and Rosa distributions was not in Rosa's favor. First of all, due to the lack of Cinnamon as part of LiveDVD, and secondly due to a decrease in the quality of the distribution package recently.

Thus, AltLinux, one of the P7 starter kit assemblies containing the Cinnamon desktop, was chosen as the basis for creating the assembly . The positive side of this choice is the minimum composition of the set, which allows you to expand it at your discretion.

Network structure

Magos server

The enterprise network has a virtualization server on which Magos-server was deployed. The server performs several functions.

First, it serves as a remote download server. Remote boot is implemented using TFTP and allows you to boot MagOS in the same configuration that is used to work on workstations. Using this download, you can test the equipment, install the operating system on a workstation, and perform many other tasks. In addition, Clonezilla and Memtest images are downloaded using the remote download server.

Remote loading of a workstation running MagOS is done via HTTP, for which Lighttpd is installed on the server, whose DocumentRoot points to the MagOS repository.

Installing the distribution kit on a workstation and updating workstations is performed using the RSYNC protocol. Therefore, rsyncd is installed on the server.

Server management is carried out using the SSH protocol. Using the same protocol, changes to program modules prepared on a test computer are updated on the server.

This computer is equipped with 4Gb of memory, because there were problems with the creation of modules with less memory.

Network integration

Deployed AD based on Windows 2008 SP2 and all network computers are included in AD. No exception, and computers running Linux.

Bootloader setup

Loader strings

title AltLinux i586 cinamon save
#find --set-root --ignore-floppies --ignore-cd /MagOS/MagOS.sgn
kernel  /AltLinux/kernel/i586/vmlinuz uird.ro=*.xzm,*/live uird.from=/AltLinux/iso/altlinux-p7-cinnamon-latest-i586.iso;/AltLinux/modules/i586/ uird.load=* root=uird rw findswap vga=788 quiet plymouth.enable=0 uird.home=/dev/sda3/AltLinux-Data/homes/ uird.changes=/dev/sda3/AltLinux-Data/changes/ users
initrd /AltLinux/kernel/i586/uird.soft.cpio.xz /AltLinux/kernel/i586/uird.magos.cpio.xz

Options that were used

Due to the multiplicity of kernel parameters, the parameter prefix 'uird' (Unified Init Ram Disk) has been introduced to highlight MagOS parameters.

uird.ro=*.xzm,*/live 

uird.ro - MagOS parameter. Defines a filter for modules that are mounted in RO mode. As such, the actual MagOS modules and LiveDVD AltLinux itself are used.

uird.from=/AltLinux/iso/altlinux-p7-cinnamon-latest-i586.iso;/AltLinux/modules/i586/ 

uird.from - MagOS parameter. The list of sources on which the modules for the system lie. This is an indication of the path for loading the modules and the distribution itself.

uird.load=* 

uird.load - MagOS parameter. Filter for modules that need to be connected at the boot stage.

root=uird 

root - The kernel parameter. Specify the root file system.

rw

rw - enable read / write mode.

findswap

findswap - MagOS parameter. Causes the system to automatically enable Swap. If the Linux Swap partition is on the system, then it is connected. Otherwise, the Windows swap file is searched.

vga=788

vga - The kernel parameter. Enabling the graphics mode.

quiet

quiet - Kernel parameter, indicates the need to create a dmesg log.

plymouth.enable=0

plymouth.enable - The kernel parameter. Controls the graphical screen and log output while the operating system is loading.

uird.home=/dev/sda3/AltLinux-Data/homes/ 

uird.home - MagOS parameter. Specifies the source on which user home directories are stored. Due to an error in the existing version of MagOS, a full path is required, including a device.

uird.changes=/dev/sda3/AltLinux-Data/changes/ 

uird.changes - MagOS parameter. Specifies the source on which persistent changes to the root file system will be stored.

users

users - The kernel parameter.

Options that can be used

It is possible to use encryption for data stored on the hard drive. In this case, instead of saving data to partitions, you must use saving to disk images. The images should take the following form:

  *.RWM.ENC - RW слой криптованый
  *.ROM.ENC - RO слой криптованый

uird.copy2ram [+] = - filter for modules that are copied to RAM. It can be used to speed up work in the presence of a significant amount of RAM.
uird.copy2cache [+] = - filter for modules that are copied to the cache.
uird.cache [+] = - sources to which the modules should be synchronized.

It is possible to use the cache instead of synchronizing MagOS files with the server when you turn off the computer. The disadvantages of the method include the fact that the exchange with the server is performed using the HTTP protocol, which in itself significantly reduces performance. The second drawback is that it becomes difficult to separate update objects — the MagOS.ini file, the boot partition, and the OS partition itself. It should be noted that the layer-cache level and the corresponding uird.cache parameter used to synchronize remote repositories into local or private (INTRANET) repositories, as well as to update the system, must be set as follows:

uird.cache=/MagOS/cache;/MagOS-Data/cache;/MagOS-Data/netlive

Each source has its own directory.

uird.netfsopt [+] = - additional options for mounting network FS: sshfs, nfs, curlftpfs, cifs.

Using these file systems, you can later connect network file systems with user data sections.

uird.noload [+] = - filter for modules that must be skipped during loading.
You can selectively disable some modules for individual computers or networks.
uird.homes [+] = - sources on which user home directories are stored (AUFS are combined).

Essentially, here you enter the layer-homes user home directory level and the corresponding parameter: uird.homes:

uird.homes=/MagOS-Data/homes;/MagOS-Data/home.img;nfs://magos.sibsau.ru/homes/n/e/myuser

All user directories from various sources are cascaded through AUFS and mounted in / home. The first source is more priority, then, in the order of listing, priority is reduced. If the source is specified by the uird.home = parameter, then the source is mounted in / home. Thus, there is the possibility of multiple connection of the home folder with the imposition of different file systems. It can be used when network hosting user folders.

Types of sources:
/path/dir - a directory on any available medium;
/dev/[..]/path/dir- directory on the specified medium;
file-dvd.iso, file.img- disk image (ISO, image of a block device);
server/path…- source accessible via HTTP (using httpfs);
ssh://server/path/…- source available via SSH (used by sshfs);
server/path…- FTP accessible source (using curlftpfs);
nfs://server/path/…- source available via NFS;
cifs://server/path/…- source available via CIFS;
uird.machines=- the source where machine-dependent persistent changes are stored.

It is possible to use machine-dependent resources for changes, which is necessary to ensure reentrant users.

Network boot features

The following parameters are used for network boot:

kernel images/vmlinuz uird.ro=*.xzm,*/live uird.from=http://magos-server.mydomain.local/magos/AltLinux/iso/alt linux-p7-cinnamon-latest-i586.iso;http://magos-server.mydomain.local/magos/AltLinux/modules/i586/ uird.load=* root=uird rw findswap vga=788 quiet plymouth.enable=0 users

These are the same parameters, but pay attention to the uird.from parameter:

uird.from=http://magos-server.mydomain.local/magos/AltLinux/iso/altlinux-p7-cinnamon-latest-i586.iso;http://magos-server.mydomain.local/magos/AltLinux/modules/i586/

This is the full http url of the server from which the OS is loading. The base layer-base level and the corresponding uird.from parameter can be set in the following form:

uird.from=/MagOS;/MagOS-Data;MagOS.iso;http://magos.sibsau.ru/repository/netlive/2014.64/MagOS

System initialization order

• The configuration file is searched for by the path specified in the uird.basecfg parameter.
• Устанавливаются параметры из конфигурационного файла, которые еще не установлены в параметрах ядра.
• Происходит монтирование источников base-уровня в порядке, указанном в параметре uird.from.
• Происходит монтирование источников cache-уровня в порядке, указанном в параметре uird.cache.
• Происходит монтирование источников homes-уровня в порядке, указанном в параметре uird.homes.
• Происходит подключение в самый верхний уровень AUFS источника персистентных изменений, указанного в параметре uird.changes.
• Осуществляется синхронизация base-уровня в cache-уровень с учетом параметра uird.copy2cache, а также соответствия подуровней. Если подуровней cache-уровня меньше, чем base-уровня, то оставшиеся подуровни синхронизируются в RAM.

        ├── layer-base       ==>      ├── layer-cache
        │   ├── 0            -->      │   ├── 0
        │   ├── 1            -->      │   ├── 1
        │   ├── ...          -->      │   └── ...
        │   └── ...          -->      │   RAM

• Осуществляется синхронизация base,cache-уровней в RAM с учетом параметра uird.copy2ram.
• The modules are searched in RAM, cache-level, base-level and connected to the upper level of AUFS or copied to the root (taking into account the filters specified in the parameters uird.load, uird.noload, uird.ro, uird.rw, uird. cp).
• The cascading association of homes-level sources is carried out and their connection in / home /.
• Rc.preinit scripts are running.

Default basecfg.ini configuration file structure

uird.config=MagOS.ini
uird.ramsize=70%
uird.ro=*.xzm;*.rom;*.rom.enc;*.pfs;*.sfs
uird.rw=*.rwm;*.rwm.enc
uird.cp=*.xzm.cp,*/rootcopy
uird.load=/base/,/modules/,rootcopy
uird.noload=
uird.from=/MagOS;/MagOS-Data
uird.changes=/MagOS-Data/changes
uird.cache=/MagOS-Data/cache
uird.machines=/MagOS-Data/machines
uird.home=/MagOS-Data/homes

If uird.basecfg is not specified, then /uird_configs/basecfg.ini is used inside initrd.

System directory structure

 /memory/
  ├── bundles                   - точка монтирования модулей
  │   ├── 00-kernel.xzm
  │   ├── 01-firmware.xzm
  │   ├── 10-core.xzm
  │   ├── 80-eepm-1.5.2.xzm
  │   └── ...                   - и т.д.
  ├── changes                   - точка монтирования для хранения изменений 
  │   ├── etc
  │   ├── home
  │   ├── memory
  │   ├── run
  │   ├── var
  │   └── ...                   - и т.д.
  ├── data                      - точка монтирования источников
  │   ├── cache                     - кэш уровня
  │   ├── homes                     - homes уровня
  │   ├── machines                  - (зарезервировано)
  │   └── from                      - базового уровня
  ├── layer-base                - точка монтирования базового уровня
  │   ├── 0                         - ресурс первого источника
  │   ├── 1                         - ресурс второго источника (в порядке перечисления в uird.from=)
  │   └── ...                       - и т.д.
  ├── layer-cache               - точка монтирования кэш уровня
  │   ├── 0                         - ресурс первого источника
  │   ├── 1                         - ресурс второго источника (в порядке перечисления в uird.cache=)
  │   └── ...                       - и т.д.
  ├── layer-homes               - точка монтирования homes уровня
  │   ├── 0                         - ресурс первого источника
  │   ├── 1                         - ресурс второго источника (в порядке перечисления в uird.homes=)
  │   └── ...                       - и т.д.
  ├── cmdline                   - системный файл для хранения дополнительных параметров командной строки
  └── MagOS.ini.gz              - системный файл для хранения конфигурационного файла

Implementation

The implementation is based on a set of dracut initialization scripts (base, busybox modules) and uird scripts (livekitlib + uird-init):

• cmdline-hook: parse-root-uird.sh (checks the root = uird parameter);
• mount-hook: mount-uird.sh (executes the uird-init script);
• livekitlib - contains a library of functions of the initialization system;
• uird-init - sequentially executes a set of functions from livekitlib and performs cascading-block mounting of system modules into a single AUFS root in the directory specified in the dracut $ NEWROOT variable.

MagOS Server

General information

In our case, magos-server is deployed as an openvz container. Implementation is not critical.

• It serves as a remote download server. Remote boot is implemented using TFTP / PXE and allows you to boot MagOS in the same configuration that is used to work on workstations. Using this download, you can test the equipment, install the operating system on a workstation, and perform many other tasks.
• Remote loading of a workstation running MagOS is done via HTTP, for which Lighttpd is installed on the server, the documentroot of which points to the MagOS repository.
• Installing the distribution package on a workstation and updating workstations is performed using the rsync protocol. Therefore, rsyncd is installed on the server.
• Server management is performed via ssh protocol. Using the same protocol, changes to program modules prepared on a test computer are updated on the server.

Server implementation

Operating system Centos v6. The following resources are allocated for the virtual container: CPU - 2, RAM - 512Mb, swap - 1Gb, virtual disk size 40Gb.

Network settings

Service Setup

Lighthttpd

Tftpd

The repository consists of two parts: a worker, called magos, and a test, called testing. Work repository is designed to install and update user workstation software. Preliminary testing of the installed software is performed on the testing repository. The boot menu allows you to load the operating system both from the working repository and from the test one.

Rsync

sshd

Program repository

The program repository structure shows only the essential files and directories.

magos

├──AltLinux
│  ├──iso
│  │  └──altlinux-p7-cinnamon-latest-i586.iso
│  ├──kernel
│  │  └──i586
│  │     ├──uird.magos.cpio.xz
│  │     ├──uird.soft.cpio.xz
│  │     └──vmlinuz
│  └──modules
│     └──i586
│        ├──00-kernel.xzm
│        ├──01-firmware.xzm
│        ├──03-1-nvidia-current.xzm
│        ├──03-2-nvidia304.xzm
│        ├──03-9-fglrx.xzm
│        ├──80-eepm-1.5.2.xzm
│        ├──80-uird.soft.xzm
│        ├──90-magos-patches.xzm
│        ├──99-squashfs-tools.32.xzm
│        ├──99-u10-update.xzm
│        ├──99-u40-office4.xzm
│        ├──99-u50-utils.xzm
│        ├──99-u99-default.xzm
│        ├──MagOS.ini
│        └──update.txt
├──AltLinux-Data
│  ├──cache
│  ├──changes
│  ├──homes
│  ├──machines
│  ├──MagOS-Data.sgn
│  ├──modules
│  ├──optional
│  └──rootcopy
└──boot
   ├──grub4dos
   │  ├──install.lin
   │  ├──install.win
   │  └──local
   │     └──menu.lst
   ├──syslinux
   └──tools

testing

├──AltLinux
│  ├──iso
│  │  └──altlinux-p7-cinnamon-latest-i586.iso
│  ├──kernel
│  │  └──i586
│  │     ├──uird.magos.cpio.xz
│  │     ├──uird.soft.cpio.xz
│  │     └──vmlinuz
│  └──modules
│     └──i586
│        ├──00-kernel.xzm
│        ├──01-firmware.xzm
│        ├──03-1-nvidia-current.xzm
│        ├──03-2-nvidia304.xzm
│        ├──03-9-fglrx.xzm
│        ├──80-eepm-1.5.2.xzm
│        ├──80-uird.soft.xzm
│        ├──90-magos-patches.xzm
│        ├──99-squashfs-tools.32.xzm
│        ├──99-u10-update.xzm
│        ├──99-u40-office4.xzm
│        ├──99-u50-utils.xzm
│        ├──99-u99-default.xzm
│        ├──MagOS.ini
│        └──update.txt
├──AltLinux-Data
│  ├──cache
│  ├──changes
│  ├──homes
│  ├──machines
│  ├──MagOS-Data.sgn
│  ├──modules
│  ├──optional
│  └──rootcopy
├──boot
│  ├──grub4dos
│  │  ├──install.lin
│  │  ├──install.win
│  │  └──local
│  │     └──menu.lst
│  ├──syslinux
│  └──tools
└──update.tar.gz

Since recording to the repository is performed with system user rights, it is necessary to create groups responsible for the right to write to the corresponding repository:

# groupadd magos
# groupadd testing

Set permissions on all repository directories:

# cd /var/www
# find magos -type f -exec chmod 664 {} +
# find magos -type d -exec chmod 775 {} +
# find testing -type f -exec chmod 664 {} +
# find testing -type d -exec chmod 775 {} +

Set repository owner groups:

# chown -R :magos magos
# chown -R :testing testing

Set SGID to repository directories:

# chmod g+s magos
# chmod g+s testing

Additional server data

yum.repos.d
CentOS-Base.repo
CentOS-Debuginfo.repo
CentOS-fasttrack.repo
CentOS-Media.repo
CentOS-Vault.repo
epel.repo
epel-testing.repo
vz.repo

Control scripts

Scripts were created for current use and do not claim to be “box-like” in use, so please be careful when using them!

Monitoring

The update-txt.sh script, which runs on a daily schedule, writes the update.txt file containing the current date to the modules directory. After synchronizing data to a user computer, it makes it easy to check when the computer was last updated. This is a necessary moment for tracking computers that do not overload for a long time (the user does not turn off the computer).

Update

The scripts testig2magos_kern.sh, testig2magos_mod.sh and testig2magos_all.sh are designed to update the working repository from the testing repository and are executed only in manual mode.

testig2magos_kern.sh - updates only system modules and the kernel directory.
testig2magos_mod.sh - updates only user modules.
testig2magos_all.sh - Performs a full update including the kernel, iso and modules folders.

None of the scripts update the MagOS.ini file!

Changes to this file are made only manually.

Custom modules

General principles for creating custom modules

What you need to know

When creating modules in MagOS, you have to take into account one important feature associated with creating users and groups. When creating a module, the changed passwd, group, shadow, etc. files are saved in it. But, in order for the next module to be created to “see” them with the epm2xzm script, it is necessary that the module name matches the “NN-” template. If the names of the modules do not correspond to this template, then each subsequent module created, just like the first one, will be created on the basis of only basic MagOS modules. This will hit the authentication files most painfully: programs that create system users and are installed in different modules receive the same UID and GID, and passwd files created in different modules are overwritten by subsequent layers. As a result, the programs installed in the underlying modules are inoperative.

There are two ways to eliminate this problem: group the programs that create system accounts within one module or set the module names according to the above template.

The scripts creating the modules are written so that they use their own name as the module name. A script called 99-u30-example.sh will create a module called 99-u30-example.xzm.

How many modules do

The order of connecting the base modules does not matter, because they do not have any overlapping files and directories. But the order of connecting user modules does matter. If user modules contain corrections of base module files, and in the case of MagOS adaptation for AltLinux distribution, such a situation is observed, then they should be located in the upper layers of aufs and connected after system ones. Modules are connected to the system, sorted by name, so the name of the module is important. Since the name of the last system module starts with the characters “99-”, it is recommended to use the names of custom modules starting with the characters “99? -” so that when sorting the directory by name they appear after the system modules.

Special Purpose Modules

It is recommended to distinguish two modules with a special purpose: the module in which the current update of the operating system is located. It is recommended to be installed first, therefore its recommended name is “99-u10-update”. And a module containing adapted settings files for the operating system and its programs. It is recommended to install it last. When creating a module with settings, you need to observe several rules:

• You cannot install programs in this module.
• in this module there should be no files responsible for assigning rights (passwd, group, etc.)

Subject to these rules, the module may not be excluded from the system when reassembling the underlying modules, and system management scripts may be located in it.

Limitations for Modules

There are no restrictions on the number of modules (by default it can be up to 127), but it is advisable to observe some compromise on the division of programs into modules. Firstly, when reassembling the underlying module, we need to disconnect all modules that should be loaded later. And after rebuilding such a module, it is recommended to rebuild all subsequent modules, even if the programs in them have not been updated or changed. This is due to library dependencies. Thus, we must strive to ensure that the number of user modules is not large.

The second limitation, but on the other hand, is the resource requirements of the computer on which the modules are reassembled. During the installation of programs in the module, the file system, by default, is located in the RAM, so the number of installed programs is directly related to the size of the required RAM. So, to install Libreoffice, you need about 3 gigabytes of free RAM on your computer. In order to eliminate this restriction, it is necessary to specially prepare a directory for placing temporary files for creating modules.

Thus, the minimum number of modules that you have to work with can be 3, and the optimal number of 4 modules.

Instructions for creating modules

The module assembly procedure is as follows:

1. Download update tools /root/bin/loadupdate.sh.
2. Disable system update during OS reboot: set the variable AUTOUPDATE = No in the / etc / sysconfig / MagOS and /mnt/livemedia/MagOS.ini files.
3. Rename the updated module and all subsequent ones by adding the .bak extension (other extensions are not allowed).
4. Build the module. Upon request, save the module to the magos-server server.
5. Restart the computer in order for the changes to take effect correctly.
6. Repeat steps 3-5 for all subsequent modules.

The method of installing new programs

The methodology for searching, installing and configuring programs is as follows:

• Boot the computer in clean mode.
• Find the desired program and install it.
• Configure the program with the available configuration tools, including acc and the web interface. To achieve result.
• Если программа на не подошла, перегрузить компьютер и начать сначала.
• После получения результата сохранить измененные в процессе настройки конфигурационные файлы в отдельный каталог на жестком диске.
• Внести программу в список для установки в составе подходящего модуля.
• Создать модуль. Отредактировать скрипт создания модуля для получения нужных нам значений конфигурационных файлов. При необходимости повторять процесс многократно. Вместо редактирования скрипта создания модуля можно положить конфигурационные файлы и т.п. в каталог модуля установки значений по умолчанию. Все зависит от программы.
• Выполнить последовательную пересборку всех вышележащих модулей.

Модуль обновления системы

The module with operating system updates is the simplest. The number of updates depends on the time elapsed since the distribution release. If the number of updates becomes critical, then you should consider updating the iso distribution image. The update period is at the discretion of the system administrator, since updates are performed only in manual mode and require reassembly of all other modules.

Office software installation module

The module includes applications for the end user that do not require the creation of a service account. The list of applications is not very large, but due to the large number of dependent packages, this module is quite large.

Module with utilities and servers

This module contains all the utilities and servers that require the creation of a user service record and their dependent components. It is possible to transfer part of the following utilities to the office module, but despite the significant list of programs, the total number of installed programs and the resources consumed during installation do not exceed 3 Gigabytes.

In addition to actually installing the programs, some elements of the operating system and installed programs are configured directly in the installation script.

This approach allows you to react more correctly to updating versions of programs in which changes occur in the format of configuration files or if default settings appear / change in configuration files. For such cases, this mechanism is more preferable than putting the corrected finished configuration file in the module with the final settings. Then, when changing the configuration settings, there is a big risk that they cannot be detected at all during the creation or updating of modules.

A few words about the software suite used. Computer software does not contain any specific requirements and tasks. Enterprise systems moved to the intranet level of applications. Computers are thin clients and typewriters.


In our case, timezone is configured in this configuration file, since its values ​​differ from the default values ​​of the distribution kit, and the standard setting of the specified MagOS parameters does not work correctly in our case (cp / usr / share / zoneinfo / Asia / Krasnoyarsk $ NAME / etc / localtime).

Some strange error is being corrected in the settings of the AltLinux distribution, in which the names of the computers on the local network are not resolved if the domain name of the local network ends in local (cp /etc/nsswitch.conf $ NAME / etc / nsswitch.conf sed -is / ' ^ hosts: files mdns4_minimal \ [NOTFOUND = return \] * '/' hosts: files dns mdns4_minimal \ [NOTFOUND = return \] myhostname fallback '/ $ NAME / etc / nsswitch.conf).

The configuration file zabbix_agentd is configured, which allows real-time monitoring of the state of users' computers, which is important enough to reduce downtime.

The configuration file for fusioninventory-agent, a utility that works in conjunction with the GLPI technical support automation system and allows automatic inventory of equipment and software, is configured.

System settings module

The system settings module does not contain any installed programs and is just a packer for the module catalog, which is of main interest.


The etc / module directory contains the following directories and configuration files:


A line has been entered for allowing sudo operations to the administrator without a password (necessary for parallel operations using the ssh protocol).


Keyboard locale switch pre-configured:


Keyboard setup:



Added autoimports repository for installing fusioninventory-agent.



The keys of the italc program are installed.


Autologin mode is disabled and additional settings are made.




The network interface and firewall were pre-configured.




The skel directory contains files that perform pre-configuration of the environment and user programs.




The settings for the services that are launched by default or are absent in the distribution kit are completed.


Italc is used in a different configuration than the original. Since many parameters in the configuration files change, the configuration files were simply placed in the default module.

Scripts

When designing the system, special attention was paid to the automation of system administration, the purpose of which was to reduce labor costs for its subsequent maintenance. For this purpose, a set of additional scripts was created, which can be conditionally divided into two categories: scripts for automating maintenance and system administration and scripts for creating modules. The main part of the module maintenance scripts was described above, however, their library part, which will be considered here, remained “overboard” there.

Magos-patches add-ons

Since in industrial operation we have slightly different tasks and conditions for using MagOS, we need some means to automate the operation of the MagOS core itself. The scripts below should, in theory, be built into MagOS-patches, but now we will consider them separately.

Start scripts

The script /usr/lib/magos/rc.halt/05-update.sh is designed to automatically update the operating system when you turn off or restart the computer. Three parameters have been added to the MagOS.ini configuration file for the script to work:


Here: the AUTOUPDATE parameter indicates whether or not to update when the power is turned off. UPDATE - enumeration of directories for which updating is to be carried out.

SRCUPDATE - server address and repository from which the update is carried out. The address can be specified as an IP address, or as the name of a DNS server.
The same parameters are involved when installing the operating system on the user's computer.

Script source code:


Correction of the existing script /usr/lib/magos/rc.preinit.d/21-ntp that configures the NTP server has been performed. Apparently, this part is dependent on the AltLinux distribution, therefore, it can be fixed in the future.

OS installation script

Installing the OS using a special script allows you to achieve uniformity with all installations, eliminate the mistakes of technicians performing this work, and speed up this process many times.

The script /usr/share/magos/install/magosinstall.sh is specialized. Performs the creation and formatting of hard disk partitions. It copies the repository sections from the magos-server server to the local drives of the computer and installs the boot loader.


From the script text, you can see that 30 Gb is allocated to the main partition into which the OS is installed, 6 Gb to swap, and the rest is reserved for the data section, including Changes and Home. So far, no variables have been used that allow putting these parameters into the configuration file or, at least, to the beginning of the file.

The path to the script is not accidentally chosen difficult, this should prevent accidental launch of the program.

Inclusion scripts in AD

Turning on a computer in ADS is implemented differently in different operating systems. AltLinux, to complete this task, created their own program. However, its functionality is quite large and its own scripts were implemented to simplify this operation. There are two scripts, one connects in console mode, the second uses TCL and works in graphical mode. It is recommended to use console mode, although the graphic has also been tested.

After installing the operating system, the computer has hostname = MagOS. For mass installation of computers, this is critical, especially if the computer is included in AD. Therefore, scripts solve two problems at once: renaming the computer and including it in AD.

A short note: the computer name is not defined in the MagOS.ini file, but with these scripts it is entered directly into the / etc / sysconfig / magos file. All other MagOS scripts that run when the operating system starts use the computer name from the file / etc / sysconfig / magos.


It should be noted that the domain name and realm are specified directly in the script in the variables $ domain and $ realm. Perhaps this is not the right decision ...


Since there is an operation for entering a computer into a domain, there must be an operation for removing from a domain. But in the case of MagOS, this is not necessary, since for this it is enough to simply delete the corresponding files in Changes.

Fix AD issues

After connecting the computer to ADS, we found such a problem: after loading the computer, winbind takes a long time to fill the caches with information about AD, including lists of users and groups. At the same time, it may freeze and restart according to its internal schedule, but this can take a lot of time - up to half an hour. The problem may be related to the organization of the internal structure of AD, or it may be common to all implementations. It is only known that there are no problems in a sufficiently empty AD database. However, we had such a problem and to solve it, the following “crutch” was invented.

Empirically, it was revealed that restarting winbind after it detects an AD domain helps to solve the problem. Therefore, the program below runs as a service through systemd, monitors the detection of a winbind domain, then restarts winbind and terminates. The delay in compiling a list of users, in this case, is 1 to 2 minutes. If the user does not enter his name and password very quickly, then he practically does not notice the existence of this problem.

Another function is assigned to this script - updating the system files of AD users' home folders, since the scripts existing in magos-patches update the home folder of only one user specified in MagOS.ini - the system administrator, and updating virtual user folders is not provided at all. The script copies hidden system files and directories that are not in the home folders of domain users from the / etc / skel folder and assigns them the owner rights of the folder. Thus, to update the settings in the users home folders, you need to delete the corresponding files and reboot the service with the winbind-restart script. A necessary condition for the correct operation is the lack of user registration in the system at the specified time.

However, it should be noted that the script, as a service for updating the settings of computer users, needs to be improved.

System Management (/ root / bin)

These scripts are designed to control the MagOS system based on the AltLinux distribution for industrial applications.
If for some reason a forced OS update is required, then the following two scripts are used. The first one updates the operating system, the second update the configuration file MagOS.ini.

The script for forced updating of the operating system /root/bin/updatemagos.sh. After the operation is completed, an automatic overload of the operating system follows.



/root/bin/mnt.sh is a fairly simple auxiliary script for connecting a disk with user data and operating system save.


The loadupdate and saveupdate scripts are designed to load scripts for generating modules and module originals from the MagOS server onto the test machine and then upload them to the server after making any changes to them.

OS Maintenance Scripts

In the process of servicing the operating system, tasks arise of mass servicing computers, for example, executing commands on all computers at once. One of the options for solving this problem is parallel access to computers using the ssh protocol and running the corresponding command there. The hostalt-create.sh script is not universal; it is intended to compile a list of computers on which MagOS is installed based on the AltLinux assembly. To detect computers, they must have a name ending in "-a". The list of computers is kept, which allows it to be gradually expanded.

In general, this solution cannot be called full-fledged, because the operation is performed only for computers that are turned on. Secondly, the use of scripts requires setting up sudo with tasks without a password.

As the username used to access computers, an administrator account is used; in AltLinux assemblies, this is the alttlinux account.

Module Creation Management Scripts

Scripts for managing the creation of modules are designed to automate the creation of custom modules and their placement on the magos-server.
Scripts are a complex of programs containing a configuration file and libexec script libraries that automate the process and, in fact, the scripts themselves, which assemble the modules, clean the received modules from garbage, and tune the module programs.

Scripts and the configuration file are located in the root directory of the disk, but can be placed in any convenient place. A prerequisite is that the file system on which they are located must support the Unix ACL, that is, it must be Posix compatible.

Module assembly system configuration file /update/conf/devel.conf.

DISTTYPE="testing"
DISTNAME="AltLinux"
ARCH="i586"
UPDETESRV=yes
SERVER=192.168.0.3
USER=altlinux

Here:

DISTTYPE - points to the magos-server repository directory.
DISTNAME - The name of the distribution directory.
ARCH - System Architecture.
All three of the above parameters determine the path in which the folder with the modules should be located on the server and in the computer.
UPDETESRV - whether or not to automatically update the server repository. SERVER - the address or URL of the magos-server server.
USER is the name of the magos-server user who has write permissions to the repository. In this user's home folder, symlinks to the corresponding repository folders should be created.

Example script for creating a module:


A script called from the module creation script itself, which cleans up the garbage left after the module was built by the epm2xzm command.


The script disables the module with the settings and makes a backup copy of the old module.

The technology of module redundancy is as follows: we rename the modules that we are going to change by adding the .bak extension. In the following, we can run the module creation script several times, correcting the errors that have occurred. Each time, the previous version of the module will be renamed and will receive the extension .old. After completing the work, unnecessary copies will need to be deleted.


The script transfers the module to the modules directory and copies it to the network repository. Sets access rights and performs module reconnection.

Additional scripts that fix the operation of magos programs and the operating system

MagOS does not quite correctly implement the mechanism for connecting the / tmp and / var / tmp folders to the tmpfs file system. There is Unit systemd for connecting / tmp to the tmpfs file system, but it is not included. To enable it, a symbolic link was placed in the /etc/systemd/system/local-fs.target.wants directory:

tmp.mount -> /lib/systemd/system/tmp.mount
var-tmp.mount -> ../var-tmp.mount

Unit var-tmp.mount is simply not implemented. MagOS, when you turn on the VARTMPFS option, makes a symbolic link / var / tmp → / tmp. For the CUPS print server, this is not permissible, so the corresponding unit must be implemented independently.


Unit for connecting the / var / tmp directory to the tmpfs file system.

Instructions for technicians

Install Alt Linux in MagOS mode:

• Select bios to download from the network.
• Download AltLinux.
• Register as altlinux using the default password.
• If you need to save user data, then connect to the network and save the data to the network. All data on the hard drive will be destroyed!
• Open console
• Obtain administrator rights:

$ su -
Password:

When entering a password, characters are not displayed. This is normal. The default password for the mydomain network is used:

• Run the command:

# /usr/share/magos/install/magosinstall.sh

• To install the system, you will have to press the Enter key three times. It is possible to refuse the installation in the first stage by pressing ^ C.
• Reboot the computer. If overload does not occur, perform a hardware reset.
• Enter user environment as user altlinux.
• Open console
• Obtain administrator rights as described above.
• Enter the computer into the domain using the command:

# /usr/share/magos/ad_join/ad_join.pl -h  -u  -p 

Where:

hostname is the name of the computer. At the same time, the computer is renamed.
username - Domain name of the mydomain.local domain administrator.
password - The password for the domain administrator mydomain.local.

If the command is executed correctly, it will be written:

Joined 'Имя компьютера' to dns domain 'mydomain.local'

Other messages can be ignored.

• Check the connection of the computer to the domain:
  
  

  # wbinfo -u
  

  
  The system takes some time to cache network resources, so the first entry into the domain can be delayed by several minutes. It depends on network load.
  
  As a result of the command, a list of all domain users will be displayed.
• Reboot the computer.
• Register on a computer using a domain user account.
• Connect network resources, for this, open a file browser, open a network resource in it, for example, "new_drive" on the side tab. Enter user password.
  Select the "Remember forever" radio button. Otherwise, the user will have to enter a password after each new login to the computer.
• Recover user data on a computer.
• Disable network boot in the bios of the computer.

Removing desktop shortcuts

Right-click on the desired program. Send a shortcut to the desktop. If necessary, open the properties of the shortcut and enter the necessary parameters.

Authors: Goroshkin Anton Nikolaevich, Fiskov Mikhail Mikhailovich.