Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
OrangeDog opened this issue May 8, 2020 · 6 comments
Open
Labels

Comments

@OrangeDog
Copy link

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 OrangeDog added the bug label May 8, 2020
@OrangeDog
Copy link
Author

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

@myii
Copy link
Member

myii commented May 8, 2020

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
Copy link
Collaborator

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
Copy link
Author

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

@hatifnatt
Copy link
Collaborator

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants