09.1 (Conspect) Package Maintaining (finish) & System hardware setup

Package maintenance: what maintainer will do after package is built (additional information from the previous lecture)

Last time we created an RPM package based on some author code from Oxford University - shpigot.

However, when it came to checking the syntax suitable for placement in the repository, we stuck to a strange error: an unknown unprintable character in the description of the package (our description was taken from the site and there met quotes "" from unicode-encoding). The fact that the description of your package if it does not have an encoding - it is a description in ASCII encoding, then the description in ASCII encoding should not include any characters except for ASCII characters, respectively. And since it's not unicode - there was an error.

We have so-called branches or platforms. The platform is a frozen realise - a branch of the main update repository where updates are done only for 3 reasons:

1. Security updates - if there are any security claims, of course, we need to update. And forever it is an update, it is just fix the old version.
2. Updating key components, which do NOT update the users.
3. The reason why the platform is called so. If it is necessary to provide some consumer properties of the product that we make on the basis of this large repository, they must of course be contributed.

There are two concepts of the distribution:

1. The concept of a community distribution that is completely repository oriented - that is, repository = distribution (example, debian);
2. In our case this is not the case, the distribution is images.

If we go to some resource https://www.altlinux.org/Главная_страница. There are resources for bug tracking. If we find some bug, we can explain the problem there and what to do with it. And so, we can solve the problem openly.

The maintainer does not stop working when it sends a packet after testing to the server. Firstly, software products have the property to be updated + free software products will be tested by others and then there will be no errors. Free software is implemented approximately every 1-3 months - this is normal. That is, maintainer builds the package, set up, delete bugs, put in sisyphus and then send a report from users -> bugs rule and upload. And then it's all over again, because while you were fixing bugs from user reviews a new version came out and it's not clear whether there will be bugs to take into account or we have to do everything again.

Bottom line: the maintainer accompanies each package through its entire existence!

System hardware setup

Run the SimpleLinux virtual machine. Systemd - which kind of does everything, but in fact almost nothing. It's a meta-a tool for starting and controlling. The task is to determine the hardware content of our operating system - that which lies in

•    1 ls /sys/devices/
     2 
  

It is not enough just to find that new hardware has appeared in the OS while working. Generally speaking, when new hardware hangs up, something has to be done.

Let's go to the super user:

•    1 su -
     2 password
     3 
  

There is also a directory in which these devices are started. This is a special virtual file system, which is designed to start everything as soon as something appears in it:

•    1 ls /dev 
     2 
  

It's all being watched by udev:

•    1 ps gaxw | grep udev
     2 
  

It is part of systemd, but a separate thing that can work without systemd, track these new devices and do something with them.

It's an experiment

•    1 cat /etc/udev/rules.d/70-persistent-net.rules
     2 
  

This is a file that says that this thing is machine generated during installation, which sees that we have new devices when it is added - it is important that it has a macadress. And if a network device with this macadress is added, it will be called 'eth0'. Let's try this rule and remove the package and see what happens:

•    1 rpm -qf /lib/udev/write_net_rules
     2 apt-get remove dev-rule-generator-net
     3 
  

We remove the rule:

•    1 mv /etc/udev/rules.d/70-persistent-net.rules
     2 
  

It must happen: this device must be called as it was called at the start level. Now you can restart udev or reboot. It all happened! Our interface is now called what it's called. It's called by the name of the bus it's on. Obviously, if the network settings were nailed directly to the name eth0, those settings would fall off. In fact, this is the result of the renaming.

An example from real life of another function in udev

You can remove the alt key to make screenshots. Note : From inside the virtual machine, you can enter the machine on which we are working.

•    1 ls /etc/udev/hwdb.d 
     2 
  

A system that is a database of all operators. It contains the identifiers of our various devices, from which udev determines the same device.

•    1 -n
     2 
  

You'll need to change the configuration, then go through this database, restart the udev rule, and then see. And we find out that now the test is 0. It all worked out.

These rules are actually pretty big. The pain of it is a lot. If we have a new device, which is from the sound subsystem, if there's a file, it launches nrestore, if there is not launches - restore.

== Summary: == Udev, when some new devices appear on the system, including when they appear at startup, performs additional actions, which sometimes we see the desktop, so that the results of these actions may appear on desktop.