saltstack-formulas / zabbix-formula

http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
Other
50 stars 121 forks source link

[BUG] zabbix/4.4/ubuntu focal/main zabbix-agent includes zabbix-sender #139

Open OrangeDog opened 4 years ago

OrangeDog commented 4 years ago

On Ubuntu 20.04 this formula tries to install both zabbix-agent and zabbix-sender, which doesn't work with the 4.4 repo:

[ERROR] Command '['systemd-run', '--scope', 'apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'zabbix-sender']' failed with return code: 100 [ERROR] stdout: Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: zabbix-sender 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 104 kB of archives. After this operation, 396 kB of additional disk space will be used. Get:1 https://repo.zabbix.com/zabbix/4.4/ubuntu focal/main amd64 zabbix-sender amd64 1:4.4.8-1+focal [104 kB] Fetched 104 kB in 1s (98.3 kB/s) Selecting previously unselected package zabbix-sender. (Reading database ... 74574 files and directories currently installed.) Preparing to unpack .../zabbix-sender_1%3a4.4.8-1+focal_amd64.deb ... Unpacking zabbix-sender (1:4.4.8-1+focal) ... dpkg: error processing archive /var/cache/apt/archives/zabbix-sender_1%3a4.4.8-1+focal_amd64.deb (--unpack): trying to overwrite '/usr/bin/zabbix_sender', which is also in package zabbix-agent 1:4.0.17+dfsg-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/zabbix-sender_1%3a4.4.8-1+focal_amd64.deb

OrangeDog commented 4 years ago

Actually, it installed just fine with a manual apt install zabbix-agent zabbix-sender, so I have no idea what was going on.

myii commented 4 years ago

For reference from our conversation in Slack.


I was able to avoid zabbix-sender being installed using the following pillar:

zabbix:
  # Overrides map.jinja
  lookup:
    version_repo: '4.4'
    agent:
      pkgs:
        - zabbix-agent

Tested locally with Kitchen on default-ubuntu-1804-3000-2-py3.

hatifnatt commented 4 years ago

You already have zabbix-agent installed from Ubuntu repo - zabbix-agent 1:4.0.17+dfsg-1, this package include zabbix-sender utility. But in official Zabbix repo there is 2 separate packages - zabbix-agent and zabbix-sender.

Most obvious solution - install zabbix-agent from official repo then zabbix-sender should install without problems.

So this issue is not directly related with this formula, @OrangeDog would you mind close it?

OrangeDog commented 4 years ago

It's this formula that should be deciding what gets installed from where on each platform.

hatifnatt commented 4 years ago

I don't think that formula can cover all cases. There is no problems when formula is applied on clean system. You have system in unknown but definitely not clean state. I described cause of this issue above, how you suppose formula must behave in this situation? This formula and Salt too can't solve package manager conflicts.

hatifnatt commented 4 years ago

Probably I faced this issue too. Root of the issue - how apt select candidate for installation when specific version is provided.

Check policy first.

# apt-cache policy zabbix-agent
zabbix-agent:
  Installed: 1:5.0.1-1+buster
  Candidate: 1:5.0.1-1+buster
  Version table:
     1:5.0.1+dfsg-1~bpo10+1 100
        100 http://ftp.halifax.rwth-aachen.de/debian buster-backports/main amd64 Packages
 *** 1:5.0.1-1+buster 500
        500 https://repo.zabbix.com/zabbix/5.0/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
     1:4.0.4+dfsg-1 500
        500 http://ftp.halifax.rwth-aachen.de/debian buster/main amd64 Packages

Looks good, official repo have more priority. Lets try to actually install package.

# apt-get -s install zabbix-agent=1:5.0*
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1:5.0.1+dfsg-1~bpo10+1' (Debian Backports:buster-backports [amd64]) for 'zabbix-agent'
The following packages will be upgraded:
  zabbix-agent
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
Inst zabbix-agent [1:5.0.1-1+buster] (1:5.0.1+dfsg-1~bpo10+1 Debian Backports:buster-backports [amd64])
Conf zabbix-agent (1:5.0.1+dfsg-1~bpo10+1 Debian Backports:buster-backports [amd64])

it's easily can be noticed that apt tries to install package from backports though backports repo have a lover priority. And after package from backports (or from system repository as in OrangeDog case) will be installed, then installation of zabbix-sender will fail.

Only solution I can see in this situation - provide more specific version for apt. I.e. in my example problem can be solved by using 1:5.0*buster as version string

apt-get -s install zabbix-agent=1:5.0*buster
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1:5.0.1-1+buster' (zabbix:repo.zabbix.com [amd64]) for 'zabbix-agent'
The following NEW packages will be installed:
  zabbix-agent
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Inst zabbix-agent (1:5.0.1-1+buster zabbix:repo.zabbix.com [amd64])
Conf zabbix-agent (1:5.0.1-1+buster zabbix:repo.zabbix.com [amd64])

Something like 1:5.0.*{{ grains['oscodename'] }} can be used in pillars for Debian family, not sure about other distributives. Due fact that version string is completely under user control, from the formula side we can only update documentation and pillar.example and notice users about this behavior and possible consequences.

@OrangeDog does this looks similar to your situation?

It's this formula that should be deciding what gets installed from where on each platform.

It's impossible to pin specific repository for specific package in Debian family OS-es. It is possible to pin release but in Zabbix official repository generic main is used, therefor pining something like release a=main makes a very little sense.