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

im running ubuntu 16
Doing a salt '*' state.apply
Function: pkg.installed

Fails with: E: Unable to locate package zabbix-sender

Having an initial look at what would be required to get semantic-release running for this formula. The whole package involves introducing multiple linters to check the code during the Travis run. The current codebase (at 96b653d) has a large number of salt-lint violations:

• https://travis-ci.org/myii/zabbix-formula/jobs/596261955#L258-L488

Even if semantic-release takes a while to be introduced to this formula, these violations really need to be resolved.

It's not documented, but from the code it looked like this would work in pillar.

zabbix:
  version_repo: 4.0

However it still configures the 2.1 repo, which doesn't even exist for Ubuntu 16.04+

Err:7 http://repo.zabbix.com/zabbix/2.2/ubuntu bionic Release
404 Not Found [IP: 162.243.159.138 80]

Hi

The merge function in map.jinja doesn't seem to work in my Ubuntu installation.
}, merge=salt['pillar.get']('zabbix:lookup')) %}

My minion sees the following but it still attemts to install version 2.2. I have done a pull. Any ideas?

local:
    ----------
    agent:
        ----------
        version:
            3.4
        version_repo:
            3.4

[ERROR ] Data passed to highstate outputter is not a valid highstate return: {'': ["Rendering SLS 'base:zabbix.agent' failed: Jinja variable 'dict object' has no attribute 'pkgs'"]}
testvm:
- Rendering SLS 'base:zabbix.agent' failed: Jinja variable 'dict object' has no attribute 'pkgs'
ERROR: Minions returned with non-zero exit code

when applying the states zabbix.agent.repo everything seems to set up properly and work fine, except the fact that I then have to go and manually edit the configuration file.

If I then apply zabbix.agent.conf something in this script seems to break the service and either the pid file doesn't seem to get red by systemd or the service won't start altogether.

this is my pillar file

zabbix-agent:
server:
- XXX
listenip: 0.0.0.0
listenport: 10050
logfile: /var/log/zabbix/zabbix_agentd.log
logfilesize: 0
pidfile: /var/run/zabbix_agentd.pid

yes an actual server is in the server line.

The configuration file seems to get written properly but I can't figure out the differences between the two.

I'm now investigating the pgsql schema import and i don;t understand this line in
zabbix/pgsql/schema.sls:
- name: zcat {{ sql_file }} | psql | head -5

it sounds to me like someone was just testing it with the -5 and didn't finish at all. or am i missing something deeper?

also the zcat may not be installed by default, so it should be installed first if wants to be used.
if you're wanting to reuse existing (remote) DB (don't have the permission to create one), postgresql client will be missing too, as it's installed by conf.

i'll test it now more, because i'm not sure it would work with remote DB (it has the variables there, but the errors i was getting looked like they didn't use)

Problem:

I had a simple config running on a FreeBSD server:

zabbix-agent:
  server:
    - <serveraddr>
  serveractive:
    - <serveraddr>
  listenip: 0.0.0.0
  listenport: 10050
  logfile: /var/log/zabbix/zabbix_agentd.log
  userparameters:
    - net.ping[*],/usr/bin/fping -q -c3 $1 2>&1 | sed 's,.*/\([0-9.]*\)/.*,\1,'
  hostname: {{ grains['fqdn'] }}

But recently I am getting the following error whenever I run salt:

    Data failed to compile:
----------
    Rendering SLS 'base:zabbix.users' failed: Jinja variable 'dict object' has no attribute 'shell'
ERROR: Minions returned with non-zero exit code

Looking at the default map.jina it looks as though someone did not update the FreeBSD section with a default shell.

Running this formula on a clean Ubuntu 18.04 results in an error:

local:
    Data failed to compile:
----------
    Rendering SLS 'base:zabbix.mysql.schema' failed: Jinja variable 'salt.utils.templates.AliasedLoader object' has no attribute 'mysql'

This appears to be due to this check.

Why not unify repos? Currently (for some strange reason) zabbix.agent and zabbix.server are not setting the repo, although zabbix.frontend is!
Tried to follow your link to an issue but it 404'd on me

I tried to run zabbix.agent.repo after chainging version 2.2 to 3.2 in map.jinja and in the pillar file.

It fails giving the following errors:

ID: zabbix-agent
Function: pkg.installed
Result: False
Comment: Error occurred installing package(s). Additional info follows:

          errors:
              - Running scope as unit run-13477.scope.
                Loaded plugins: fastestmirror
                Loading mirror speeds from cached hostfile
                 * base: mirrors.xmission.com
                 * epel: mirrors.xmission.com
                 * extras: repos.forethought.net
                 * updates: denver.gaminghost.co
                Resolving Dependencies
                --> Running transaction check
                ---> Package zabbix-agent.x86_64 0:3.2.2-1.el7 will be installed
                --> Finished Dependency Resolution
                
                Dependencies Resolved
                
                ================================================================================
                 Package              Arch           Version               Repository      Size
                ================================================================================
                Installing:
                 zabbix-agent         x86_64         3.2.2-1.el7           zabbix         337 k
                
                Transaction Summary
                ================================================================================
                Install  1 Package
                
                Total size: 337 k
                Installed size: 1.1 M
                Downloading packages:
                warning: /var/cache/yum/x86_64/7/zabbix/packages/zabbix-agent-3.2.2-1.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID a14fe591: NOKEY
                Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX
                Importing GPG key 0xA14FE591:
                 Userid     : "Zabbix LLC <[email protected]>"
                 Fingerprint: a184 8f53 52d0 22b9 471d 83d0 082a b56b a14f e591
                 Package    : zabbix-release-3.2-1.el7.noarch (installed)
                 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX
                
                
                Public key for zabbix-agent-3.2.2-1.el7.x86_64.rpm is not installed
                
                
                 Failing package is: zabbix-agent-3.2.2-1.el7.x86_64
                 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX
 Started: 20:14:07.951274
Duration: 1125.148 ms
 Changes:   

      ID: zabbix-agent
Function: service.running
  Result: False
 Comment: One or more requisite failed: zabbix.agent.zabbix-agent
 Started: 
Duration: 
 Changes:   

When setting pillar data to a particular version it fails:
zabbix:
lookup:
agent:
version: 3.0.18

I had to change the version by specifying the package as shown below

zabbix:
lookup:
agent:
pkgs:
- 'zabbix-agent: 3.0.*'
version_repo: 3.0

Also, a pkg.installed.refresh=true should be used that way when an update takes place and a different version_repo is needed, it will update the rpms in the repo.

Made some attempts to get the CentOS testing working again but ran into a number of hurdles.

centos-6

This was actually working as-is a few months back for version: '4.4:

• https://travis-ci.com/github/saltstack-formulas/zabbix-formula/jobs/250901749
  • This is the last run that worked on centos-6.

The zabbix-server-mysql package is no longer available in the repo:

• https://repo.zabbix.com/zabbix/4.4/rhel/6/x86_64/

The highest version that still has it available is 2.4 (this isn't really useful, though):

• https://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/

centos-7 & centos-8

Essentially, these are failing due to issues between docker and systemd. The main error that reoccurs:

New main PID does not belong to service, and PID file is not owned by root. Refusing.

Research:

• docker/for-linux#835 (comment)
  • Suggestion here is to bypass the service and just run the binary directly when in a container.
• voxpupuli/puppet-zabbix#645
• moby/moby#38749
• systemd/systemd#11752 (comment)
  • Get the same duplication as well for systemd.

Potential solutions

1. Check if we're in a container and then run the service manually instead, using a check similar to:
   1. saltstack-formulas/ntp-formula#45
2. Use Vagrant boxes instead:
   1. Biggest issue here is that this will only be local testing, which is always difficult to work with.

Zabbix agent pillar data structure doesn't support pillar merging for things like Server, ServerActive or UserParameter. See saltstack/salt#28394.

For example, looking an excertp of pillar.example:

zabbix-agent:
  server:
    - localhost
  serveractive:
    - localhost
  userparameters:
    - net.ping[*],/usr/bin/fping -q -c3 $1 2>&1 | sed 's,.*/\([0-9.]*\)/.*,\1,'
    - custom.vfs.dev.discovery,/usr/local/bin/dev-discovery.sh

Anywhere you use - to build a set, Saltstack won't perform pillar merge.

If you structure the data like this:

zabbix-agent:
  server:
    localhost:
  serveractive:
    localhost:
  userparameters:
    'net.ping[*]': /usr/bin/fping -q -c3 $1 2>&1 | sed 's,.*/\([0-9.]*\)/.*,\1,'
    custom.vfs.dev.discovery: /usr/local/bin/dev-discovery.sh

then pillar data merges can happen, allowing Zabbix agent configuration to be composed more easily.

On this line

So i have the following error when running the formula :

zabbix.test.local:
    Data failed to compile:
----------
    Rendering SLS 'base:zabbix.agent.repo' failed: Jinja variable int object has no element 0
/var/cache/salt/minion/files/base/zabbix/repo.sls(47):
---
[...]
    - name: /var/tmp/zabbix-official-repo.gpg
    - source: {{ files_switch('zabbix',
                              ['/tmp/zabbix-official-repo.gpg']) }}


{%- elif salt['grains.get']('os_family') == 'RedHat' and    <======================
         salt['grains.get']('osmajorrelease')[0] >= '6' %}
{{ id_prefix }}_repo:
  pkgrepo.managed:
    - name: zabbix
    - humanname: Zabbix Official Repository - $basearch
[...]
---

You are unable to import schema because the requisite pkg "mysql-client" doesn't exist in RHEL 7/Centos 7.

{% for file in [
  '/usr/share/zabbix-server-mysql/salt-provided-schema.sql',
  '/usr/share/zabbix-server-mysql/salt-provided-images.sql',
  '/usr/share/zabbix-server-mysql/salt-provided-data.sql'
] -%}
{{ file }}:
  file.managed:
    - makedirs: True
    - source: {{ files_switch('zabbix', [ file ]) }}
  cmd.run:
    - name: /usr/bin/mysql -h {{ dbhost }} -u {{ dbuser }} --password={{ dbpass }} {{ dbname }} < {{ file }} && touch {{ file }}.applied
    - unless: test -f {{ file }}.applied
    - require:
      - file: {{ file }}
      - pkg: mysql-client
{% endfor -%}

The mysql client binary is provided by the mariadb package in rhel7/centos 7.

yum whatprovides $(which mysql)
Loaded plugins: product-id, search-disabled-repos, subscription-manager, versionlock
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
1:mariadb-5.5.47-1.el7_2.x86_64 : A community developed branch of MySQL
Repo        : @rhel-x86_64-server-7
Matched from:
Filename    : /bin/mysql

Is it possible to extend zabbix-agent conf to have multple includes via pillar

pillar example:

include:
  - /etc/zabbix/zabbix_agentd.userparams.conf
  - /etc/zabbix/zabbix_agentd.d/
  - /etc/zabbix/zabbix-agent-extensions.d/

It would be quite handy for zabbix: zabbix-agent: hostmetadata to support composability.

For example:

zabbix:
  zabbix-agent:
    hostmetadata:
      bind-monitor:
      squid-proxy:
      mx-in:
      {{ grains['osfinger'] }}:

(I'm using dicts to support pillar merging; lists can't be merged)

This might result in a configuration line of HostMetadata=bind-monitor squid-proxy mx-in CentOS Linux 7, as an example, and would permit easier configuration of Zabbix monitoring of autodiscovered hosts.

Hi

I'm getting the following error. Any idea what's going on ?

[CRITICAL] Rendering SLS 'base:zabbix.agent' failed: found unexpected ':'

Here is my pillar. It looks ok to me.

zabbix:
  lookup:
    version_repo: '4.0'
    agent:
      version: '4.0'

zabbix-agent:
  server: '10.3.0.214'
  serveractive: '10.3.0.214'
{% if grains['virtual'] == 'LXC' or grains['virtual'] == 'lxc' %}
  hostmetadata: lxc
{% endif %}
  pidfile: /var/run/zabbix/zabbix_agentd.pid
  logfile: /var/log/zabbix/zabbix_agentd.log
  logfilesize: 0

For example, startagents: 0 will not work, because the template will omit the section because it's falsy.

Your setup

Formula commit hash / release tag

0.21.3

Versions reports (master & minion)

Salt Version:
           Salt: 2019.2.3

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: 0.26.0
        libnacl: Not Installed
       M2Crypto: 0.32.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.26.2
         Python: 3.6.9 (default, Nov  7 2019, 10:44:02)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: ISO-8859-1
        machine: x86_64
        release: 4.15.0-91-generic
         system: Linux
        version: Ubuntu 18.04 bionic

Pillar / config used

zabbix:
  lookup:
    version_repo: '4.2'

Bug details

Describe the bug

Upgrading from 0.21.2 to 0.21.3 changed how the repo is configured.
It's now trying to use the default, which does not exist

The repository 'https://repo.zabbix.com/zabbix/2.2/ubuntu bionic Release' does not have a Release file.

Steps to reproduce the bug

See above.

Expected behaviour

No changes to existing behaviour on minor/patch releases.

Attempts to fix the bug

Had a look at the code and tried this pillar instead, but it had no effect.

zabbix:
  version_repo: '4.2'

Formula default version is 2.2 which is currently under Limited Support since August, 2017 till August, 2019.
It's time to change default version to 3.0.
Info about dates from Zabbix Life Cycle & Release Policy.

Merging #27 broke debconf configuration in two places:

• zabbix.server.conf https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/server/conf.sls#L28
• zabbix.frontend.conf https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/frontend/conf.sls#L33

More info in discussion: 19ed541#commitcomment-18739220

Founded by @aboe76

https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/map.jinja

In 3.0 and upwards, the default fping location is /usr/sbin/fping
In the map.jinja it's /usr/bin/fping

In checked the default conf files for 3.0, 4.0, 4,2 and the values FpingLocation and Fping6Location are not defined at all. We have now two choices:
Correct the value to the default or stick to the Zabbix defaults and do not define the value at all.

My suggestion would be, to just cut the example values from map.jinja and stick close to the Zabbix defaults, like we did in other issues and PRs.

UPDATE:
I did some further tests and it seems like I made a hasty conclusion. I switched my pillar to:

  fpinglocation: /usr/sbin/fping
  fping6location: /usr/sbin/fping6

And my Test Zabbix Proxy stopped working, as Debian 9 obiously has it's fping binaries in /usr/bin so I guess, despite the defaults in the example zabbix_proxy.conf we should stick with /usr/bin/fping

I understand why it was added, but i'm sure it's a bad thing to enable it unconditionally for whole system

Also it's possible now to use "--without-recommends" flag just for a package
According to docs https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html

Whether to install the packages marked as recommended. Default is True. Currently only works with APT-based systems.
New in version 2015.5.0.
httpd:
pkg.installed:
- install_recommends: False

When applying zabbix.agent on redhat, the minion creates a directory /etc/zabbix/zabbix-agend.d/*.conf.

This comes from https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/map.jinja#L77
Removing this line solves the problem.

Hi

I'm trying to set the version of Zabbix-agent to 3.2. I've set the pillar data as follows and it is still installing the 2.2 version. Please help, what am I missing?

zabbix:
lookup:
agent:
version: 3.2
version_repo: 3.2

Zabbix has finally released packages for Ubuntu Xenial (16.04). However, it appears they are not using the signing key listed in the repo but key 082AB56BA14FE591 instead which is available on the (ubuntu) keyserver.

If this key is missing, the Zabbix packages cannot be installed.

The zabbix.mysql.conf part (included in zabbix.mysql.schema) is trying to connect to a database running at localhost even though zabbix-mysql:dbhost is set to something else. Interestingly enough, the SQL files are imported with the right details.

Right now host is being used. According to the documentation there are several connection_* arguments that can be provided. We probably should add an option to provide the host the DB/user etc have to be created on. This must be a user with permissions, which likely differs from the dbuser/dbpass values.

When running this state on 2015.5 I receive the following:

    Warnings: '__prerequired__' is an invalid keyword argument for
              'debconf.set'. If you were trying to pass additional data to be
              used in a template context, please populate 'context' with 'key:
              value' pairs. Your approach will work until Salt Carbon is out.
              Please update your state files.

Did this ever work? https://github.com/saltstack-formulas/zabbix-formula/blob/34c5e990efefadd9a4b5f2c1fb9bf46d5875320d/zabbix/files/default/etc/zabbix/zabbix_server.conf.jinja

I am trying to figure out where you are getting the value dbsocket, if it's not in the pillars, where is it getting that value?

@michaelforge

While zabbix servers and proxies are only available from packages on linux machines. The agent is compiled for all kinds of OS's. Since windows is usually a large component in organizations, I think it would be nice to have an official state for installing and configuring a windows zabbix agent. The agent would have to be downloaded from zabbix website, or alternatively an installer in winrepo/-ng for zabbix agent (which also does not exist). The configuration is the same, however would need to have a file path default changed for windows.

1. Why Debian repository key stored locally in formula repository? While RedHat keys fetched directly via http.
2. What need in multiple repo states why it can't be single state? And all other tricks like including state file as Jinja template and then using extend to declare requisites.
3. Why result of applying repo state is actually installed packages? I think it must only configure repository and it's all. Installation must be preformed in conf state, or may be even better in separate install state.

My thoughts on this:

• Repository state can be simplified, local file with gpg-key can be removed, if you can fetch packages from official repository, you also can fetch gpg-key from it. If you are using your own or 3-rd party repository, you don't need this key at all.
• Multiple zabbix.*.repo states can be simplified to single zabbix.repo old ones can be saved for compatibility. Extend can be done in installation state.
• I think there is need to be single repo state, if you wan't use official repo - include it in top file, or run via state.sls. Another approach also can be used control usage of official repo via pillar, like in php-formula may be it's even better to control everything via pillar.
• repo must not install anything except repository itself, package installation must be moved in conf or even better in separate install state.

[WARNING ] The function "module.run" is using its deprecated version and will expire in version "Sodium".

While testing my proposed changes for #125 in possibly encountered a critical bug.

Steps to reproduce
Create a pillar for Zabbx Proxy /srv/pillar/zabbix/proxy.sls and write a value for pidfile, logfile, or dbname:

zabbix-proxy:
  pidfile: /tmp/zabbix_proxy.pid

Watch the resultant Pillar values on the minion salt 'zabprox.*' pillar.items they change accordingly:

    zabbix-proxy:
        ----------
        pidfile:
            /tmp/zabbix_proxy.pid

Make a state apply test salt 'zabprox.*' state.apply test=true and watch that the states do not change at all!

  Name: /var/lib/zabbix - Function: file.directory - Result: Clean Started: - 07:28:57.013935 Duration: 0.541 ms

Expected behavior
/srv/formulas/zabbix-formula/zabbix/proxy/init.sls has to read in the pillar not only from /srv/formulas/zabbix-formula/zabbix/map.jinja but also from /srv/pillar/zabbix/proxy.sls and change the file.directory states accordingly.

Partly resoltution
I believe this bug was introduced by @hatifnatt in commit 2907cda and @aboe76 in commit cdf5b80 for example.

I build an example solution that works very well for me and solves also #125 but I don't believe it's the right solution as it seems much too complicated:
/srv/formulas/zabbix-formula/zabbix/proxy/init.sls

{% set logfile = salt['pillar.get']('zabbix-proxy:logfile', zabbix.proxy.logfile) %}
{% set pidfile = salt['pillar.get']('zabbix-proxy:pidfile', zabbix.proxy.pidfile) %}
{% set sqlitedir = salt['pillar.get']('zabbix-proxy:dbname', zabbix.proxy.dname) %}

https://gist.github.com/xenadmin/2c951695d215ab9e59f31184642f6c6c/revisions#diff-39859e34161f0cb6f5f50974282a2593

It can't be the solution, to have a line in the header for each and every folder I have to read in from the pillar, including a fallback to the map.jinja, can it?

I would like to ask for your help so we can solve this together!

PR #114 and #120 introduced a problem, which I should have tested better, I'm sorry.
It seems like the comments in repo.sls already mention it, but the link is dead. Haven't seen this. I will create a PR to fix it in #120 .

    Data failed to compile:
----------
    Detected conflicting IDs, SLS IDs need to be globally unique.
    The conflicting ID is 'apt-transport-https' and is found in SLS 'base:zabbix.proxy.repo' and SLS 'base:zabbix.agent.repo'
ERROR: Minions returned with non-zero exit code

As many people use SQLite for Zabbix proxy, I think it's obvious that the definition of a SQLite in the pillar database has to create the directory. I handled that in a separate state until now, but I find it odd that the official formula has to fail inevitable, because the Zabbix proxy daemon will never launch, because the directory is missing.
But this pull request has a big drawback I think. I someone would like to use a real MySQL or MariaDB, this shouldn't be executed.
I need some kind of IF statement, that will check if dbname contains a word or a path. I wasn't able to fix that yet. If we solve that, this will be a very helpful addition, as the formula will fail otherwise for all SQLite users.
I provided a half-ready Pull request #115

Currently I'm working on new template for zabbix-server and I noticed there is a lot of changes between version 2.2 and 3.0+ of zabbix-server config, many parameters became supported or became deprecated. This can be managed with a lot of if blocks in template or with single if in state file and two template files.
It's not DRY, but I think it will be way much easier to understand and maintain code with 2 separate templates than with single template bloated with lots of if - else. For example if support for 2.2 will be dropped it will enough to change few strings in state and delete template file for 2.2. With single template it will require more work to review and clean unnecessary if - else blocks.

Do you have any thoughts against splitting single template in two separate ones?

Your setup

Formula commit hash / release tag

497406a

Versions reports (master & minion)

Master:

Salt Version:
           Salt: 3001

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
         Jinja2: 2.10
        libgit2: 0.27.7
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: Not Installed
   pycryptodome: 3.6.1
         pygit2: 0.27.4
         Python: 3.7.3 (default, Dec 20 2019, 18:57:59)
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
          smmap: 2.0.5
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist: debian 10 buster
         locale: UTF-8
        machine: x86_64
        release: 4.19.0-8-amd64
         system: Linux
        version: Debian GNU/Linux 10 buster

Minion:

Salt Version:
           Salt: 3001
 
Dependency Versions:
           cffi: 1.12.2
       cherrypy: 17.4.1
       dateutil: 2.8.0
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: Not Installed
         Jinja2: 2.10.1
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: Not Installed
   pycryptodome: 3.9.7
         pygit2: Not Installed
         Python: 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]
   python-gnupg: 0.4.4
         PyYAML: 5.1.2
          PyZMQ: 18.0.1
          smmap: 2.0.5
        timelib: 0.2.4
        Tornado: 4.5.3
            ZMQ: 4.3.1
 
System Versions:
           dist:   
         locale: cp1252
        machine: AMD64
        release: 2019Server
         system: Windows
        version: 2019Server 10.0.17763 SP0 

Pillar / config used

salt minion pillar.item zabbix zabbix-agent

minion:
    ----------
    zabbix:
        ----------
        lookup:
            ----------
            agent:
                ----------
                version:
                    5.0.2.2400
        psk:
            ----------
            identity:
                psk001
            value:
                0xdeadbeef
        version_repo:
            5.0
    zabbix-agent:
        ----------
        server:
            - zabbix.server
        tlsaccept:
            psk
        tlsconnect:
            psk
        tlspskfile:
            C:\\Program Files\\Zabbix Agent\\zabbix_agentd.psk
        tlspskidentity:
            psk001

Bug details

Describe the bug

https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/files/default/etc/zabbix/zabbix_agentd.conf.jinja#L19 checks for zabbix.version_repo. salt minion config.get zabbix:version_repo returns 5.0. Despite that, putting # TEST zabbix.version_repo {{ zabbix.version_repo }} above that line returns # TEST zabbix.version_repo 2.2 and the if (and all like it) evaluate to False

Steps to reproduce the bug

Try to enable TLS config on a Windows minion.

Expected behaviour

New zabbix agent version installed and recognized, with proper configuration options enabled.

Attempts to fix the bug

So far I "cheated", and placed a modified version of https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/defaults.yaml with version_repo set to 5.0

Additional context

Incorrect dictionary key access is causing a rendering issue for zabbix/agent/init.sls and zabbix/proxy/init.sls:

2019-03-05 09:59:45,059 [salt.state :3462][CRITICAL][52888] Rendering SLS 'base:zabbix.proxy' failed: Jinja variable 'dict object' has no attribute 'includes'
2019-03-05 10:04:09,998 [salt.utils.templates:181 ][ERROR ][54057] Rendering exception occurred
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/salt/utils/templates.py", line 170, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python2.7/site-packages/salt/utils/templates.py", line 403, in render_jinja_tmpl
buf=tmplstr)
SaltRenderError: Jinja variable 'dict object' has no attribute 'includes'

The code:
{% for include in settings.get('includes', defaults.includes) %}
Should be changed to:
{% for include in settings.get('includes', defaults['includes']) %}

Note that with SQLite database on proxies, history data from proxies before the upgrade will be lost, because SQLite database upgrade is not supported and the SQLite database file has to be manually removed. When proxy is started for the first time and the SQLite database file is missing, proxy creates it automatically.

Source: https://www.zabbix.com/documentation/4.2/manual/installation/upgrade/packages/debian_ubuntu

All the effort I've done for this formula in the last months, was for one large project: I would like to use Saltstack. to help me lift my 30+ Zabbix Proxies from 4.0 to 4.2 and later on to 4.4.

One point I've missed during my planing, was that I have to drop/delete the Zabbix Proxy SQLite database file. I'm not fit enough with Saltstack yet, and would like to ask for help. Right now, I have no idea where to start.
I would guess I have to add some lines in "https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/proxy/init.sls" after line 57.

Maybe something like:
"onchanges_in pillar.version.repo execute sls.zabbix_proxy_del_sqlite -> cmd.run rm pillar.dbname + watch_in service: zabbix-proxy"

The process would have to be like this:

1. The value of the pillar version_repo changes (onchanges?)
2. Zabbix Proxy has to be stopped (watch?)
3. SQLite has to be dropped (cmd.run?)
4. New Zabbix repo has to be installed (that's already the case I guess)
5. New Zabbix Proxy daemon has to be installed (that's already the case I guess)
6. Zabbix Proxy daemon gets started (that's already the case I guess)
   1. New Zabbix Proxy SQLite database gets created by the daemon

May I ask for your help @hatifnatt and @aboe76 ?

When running zabbix.pgsql.conf.sls on ubuntu 18.04 I get this error.

ID: pgsql_packages
    Function: pkg.installed
      Result: True
     Comment: All specified packages are already installed
     Started: 18:08:42.393597
    Duration: 746.815 ms
     Changes:   
    Warnings: The following package(s) are "virtual package" names: postgresql-
              client. These will no longer be supported as of the Fluorine
              release. Please update your SLS file(s) to use the actual package
              name.

These packages should be placed into the map.jinja file so that we can install the correct package for the environment.

it looks like the correct client for Ubuntu depends on the version of Ubuntu, so this may be hard to maintain, but currently 16.04 uses postgresql-client-9.5, 18.04 and 18.10 use postgresql-client-10, and 19.04 uses postgresql-client-11

I can see how this could be a constant and daunting task as each release of different OSes could have a different client, however if this is not going to be supported moving forward it needs to be fixed.

Hi, having a bit of an issue here.

Apparently in mysql/conf.sls there is this: {% set settings = salt['pillar.get']('zabbix-mysql', {}) -%}
Where dbhost etc is being configured.

I do have the pillar for zabbix.sls:

zabbix-mysql:
dbhost: 192.168.1.99
dbname: zabbix
dbuser: zabbix
dbpass: sum_pass

Then the state file:

linux1:
- mysql.client
- zabbix.agent.repo
- zabbix.agent.conf
- zabbix.mysql.conf
- zabbix.mysql.schema
- zabbix.server.repo
- zabbix.server.conf

However for some reasons this gets ignored, and fails with this:

      ID: zabbix_db
Function: mysql_database.present
    Name: zabbix
  Result: False
 Comment: MySQL Error 2003: Can't connect to MySQL server on 'localhost' ([Errno 111] Connection refused)
 Started: 11:31:10.170065
Duration: 7.631 ms
 Changes:

      ID: zabbix_db
Function: mysql_user.present
    Name: zabbix
  Result: False
 Comment: MySQL Error 2003: Can't connect to MySQL server on 'localhost' ([Errno 111] Connection refused)
 Started: 11:31:10.180416
Duration: 1.189 ms
 Changes:

      ID: zabbix_db
Function: mysql_grants.present
  Result: False
 Comment: One or more requisite failed: zabbix.mysql.conf.zabbix_db
 Changes:

I can load most the the sls and conf files, although I still see the following. Are you able to point me in the right direction as the latest formulas appear to be broken with zabbix top.sls example for non zabbix related sls and conf

error - https://pastebin.com/b8nYN9bT

top.sls - https://pastebin.com/n274eJzw

formulas - https://pastebin.com/anY8aZ6F

Hi all,

I'd like to add support for the Zabbix 4.0.x versions as this is the new LTS release.
However, I don't know the procedure that was used to generate the mysql create files that are shipped in this formula (Zabbix sources contain 3 separate files).

Does anyone have a step-by-step handy?

Hello!

Just wondering if this formula is planned to be updated to deploy the newer 3.x version. 3.2 is out and stable. Sorry if I could already set this. I'm new to Salt!

It looks like the formula requires a definition for zabbix-agent:pidfile. Otherwise, the generated zabbix conf file will point to 'false' and be invalid. This is fine expect that rhel7 uses /run, while rhel 6 uses /var/run. What is the recommended method of handling this split? Couldn't these defaults be included in the existing map files, rather than forcing OS policy into pillars?

When i run this state on my minions i get that the following in the log:

zabbix_agentd [5254]: Is this process already running? Could not lock PID file [/tmp/zabbix_agentd.pid]: [11] Resource temporarily unavailable

Does anyone know why the PID is being put in /tmp? Even if I specify where it goes in the pillar it still gets started in /tmp. not sure why. Can anyone help?

Is this formula still being maintained? There are many issues and pull requests that have been outstanding for months.