• The sysadmws-utils-v1 package has appeared in our repository. The name has been lengthened to distinguish it from existing sysadmws-utils packages. This will allow the system to install both versions of the package at the same time. Versions of the new package are numbered 1.x.
• sysadmws-utils-v1 is built from the master branch, sysadmws-utils is built from the v0 branch. The old utilities (v0) are separated into a separate branch in order to be able to update them until we switch to v1 everywhere.
• CI has been added to the sysadmws-utils project on our gitlab for both branches. Accordingly, the code must be pushed to both Github and Gitlab. Perhaps a Github hook handler will be added to automatically sync repositories.
• CI has fully automated the build of the deb, tgz, apt repository for both branches. After pushing to the Gitlab repository and successfully passing the pipeline, you can do apt update && apt install sysadmws-utils|sysadmws-utils-v1.
• The package version is no longer incremented for each sneeze. Curl pulls the current version of the package available through the repository, the new package is built with version +1. If the pipeline fails (the repository sync is the last step), for example, the counter will not increase with each attempt.
• rsnapshot_backup modified to read JSON config like:

 

[
{
    "connect": "srv1.example.com",
    "path": "/var/backups/srv1.example.com",
    "source": "UBUNTU",
    "type": "RSYNC_SSH"
  },
  {
    "connect": "srv1.example.com",
    "path": "/var/backups/srv1.example.com",
    "source": "ALL",
    "type": "POSTGRESQL"
   }
]

• The retain fields in JSON are separated, so now it is possible to assign more than 9 copies to a backup type (previously only 1 bit was given for each type).
• A prototype JSON config generation code for rsnapshot_backup has been written.It hasn’t yet been merged into the formula. Description of backups is now done in pillars. The description of the checks will be part of the description of the checks and, accordingly, the backup_check package will be merged into rsnapshot_backup in order to match the entities in the salt.
• The backup config prototype in the pillar turned out to be much more compact and flexible than the flat config + checks in grains. Example:

rsnapshot_backup:
  sources:
    srv1.example.com:
      - type: RSYNC_SSH
        data:
          - UBUNTU
          - /srv
          - /var/cache/salt
        checks:
          - type: .backup_check
        backups:
          - host: srv1.example.com
            path: /var/backups/srv1.example.com
          - host: backup1.example.com
            path: /var/backups/client/srv1.example.com

• The config allows you to describe backups and checks for several hosts at once. The pillar must be bound to each host listed in the backups: section in order for the server to find itself in the description.
• As a theoretical option in this format, it is possible to describe in general all the backups of the client or even the entire park in one pillar, which is attached to each host.