database inconsistencies should be much more rare with 2.0 - it introduced foreign keys and other checks. some are still possible, though (like application-item linkage in nested configuration etc)

Maybe the referenced script might be a reference for checks.

I fully agree, preventing problems is better than discovering problems

DB : Oracle
OS: Linux 6.9
Zabbix Version : 2.0.17 (JDA supports only this version )

Unfortunately we do not provide Zabbix with Oracle support packages currently. You need compile it yourself.

Hi Alexey,

I saw the in zabbix forma . it supports One of: IBM DB2, MySQL, Oracle, PostgreSQL, SQLit. But I don't find installation step for oracle. If you any referral doc, Can you please share to me.

Please use this one: https://www.zabbix.com/documentation/3.4/manual/installation/install

Better create function between($a,$b) to avoid write multiple expressions for each trigger.

install orabbix3.0.1 on solaris 10 failed

Note that Orabbix is a 3rd party product. I suggest to take a look at the Zabbix forum. There you'll find some threads dealing with Orabbix.

thanks.
can u enjoy the best practice to monitor oracle database on solaris?

I suggest to get in touch with the Zabbix community or to request consultancy by Zabbix LLC.

PostgreSQL

I would like to know the opinion of the developers on this issue

can this patch be applied on 2.0.2?
we still see deadlocks on items table.

6295:20130221:234529.230 [Z3005] query failed: [1213] Deadlock found when trying to get lock; try restarting transaction [update i
tems set name='Fax failed train for "4"',key_='rcProviderFaxFailedTrain["4"]',type=4,value_type=3,data_type=0,delay=120,delay_flex='
',history=30,trends=180,trapper_hosts='',units='',multiplier=0,delta=0,formula='1',logtimefmt='',valuemapid=null,params='',ipmi_sens
or='',snmp_community='public',snmp_oid='SNMPv2-SMI::enterprises.31232.1001.30.1.7.1.52',port='1161',snmpv3_securityname='',snmpv3_se
curitylevel=0,snmpv3_authpassphrase='',snmpv3_privpassphrase='',authtype=0,username='',password='',publickey='',privatekey='',descri
ption='',interfaceid=100100000034552,flags=4 where itemid=100100000596516;

ZBXNEXT-822 ZBXNEXT-1689 asks about something related.

I think you mean ZBXNEXT-1689

zalex_ua ohh, indeed, it was a typo . thanks, fixed !

i believe ZBXNEXT-1689 should solve this - can we close this issue ?
dotneft I think we have to wait when ZBXNEXT-1689 will be implemented and if it'll help we'll be able to close the issue.

Attached file ZbxNext3779.diff adds optional HTTP proxy support to local builds.
In order to do local builds behind a HTTP proxy, it just needs to properly set the shell variables http_proxy and https_proxy in advance of running docker-compose. The latter will be also used to tunnel Subversion connections.

Some explanations...

Consideration of http_proxy, resp. https_proxy environment variables:

--- a/docker-compose_v2_alpine_pgsql_local.yaml
+++ b/docker-compose_v2_alpine_pgsql_local.yaml
@@ -1,7 +1,11 @@
 version: '2'
 services:
  zabbix-server:
-  build: ./server-pgsql/alpine
+  build:
+   context: ./server-pgsql/alpine
+   args:
+    - http_proxy=${http_proxy}
+    - https_proxy=${https_proxy}
   image: zabbix-server-pgsql:alpine-local
   ports:
    - "10051:10051"
--- a/server-pgsql/alpine/Dockerfile
+++ b/server-pgsql/alpine/Dockerfile
@@ -5,6 +5,8 @@ ARG APK_FLAGS_COMMON="-q"
 ARG APK_FLAGS_PERSISTANT="${APK_FLAGS_COMMON} --clean-protected --no-cache"
 ARG APK_FLAGS_DEV="${APK_FLAGS_COMMON} --no-cache"
 ARG DB_TYPE=postgresql
+ARG http_proxy
+ARG https_proxy
 ENV TERM=xterm
 ENV MIBDIRS=/usr/share/snmp/mibs:/var/lib/zabbix/mibs MIBS=+ALL

Tunneling of the Subversion protocol via Netcat through a HTTP proxy:

@@ -41,6 +43,7 @@ RUN addgroup zabbix && \
             libldap \
             libcurl \
             openipmi-libs \
+            netcat-openbsd \
             libssh2 && \
     rm -rf /var/cache/apk/*

@@ -49,7 +52,19 @@ ARG ZBX_VERSION=${MAJOR_VERSION}.4
 ARG ZBX_SOURCES=svn://svn.zabbix.com/tags/${ZBX_VERSION}/
 ENV ZBX_VERSION=${ZBX_VERSION} ZBX_SOURCES=${ZBX_SOURCES} DB_TYPE=${DB_TYPE}

-RUN apk add ${APK_FLAGS_DEV} --virtual build-dependencies \
+RUN [ $https_proxy ] && { \
+      PXY_HOST=$( echo $https_proxy | sed -rn 's%^([^:]+://)?([^/:]+)(:[0-9]+)?.*%\2%p' ) ; \
+      PXY_PORT=$( echo $https_proxy | sed -rn 's%^([^:]+://)?([^/:]+)(:([0-9]+))?.*%\4%p' ) ; \
+      SVN_PROXY=${PXY_HOST}:${PXY_PORT:-3128} ; \
+      SVN_HOST=$( echo $ZBX_SOURCES | sed -rn 's%^([^:]+://)?([^/:]+)(:[0-9]+)?.*%\2%p' ) ; \
+      SVN_PORT=$( echo $ZBX_SOURCES | sed -rn 's%^([^:]+://)?([^/:]+)(:[0-9]+)?.*%\3%p' ) ; \
+      SVN_PORT=${SVN_PORT:-3690} ; \
+      ZBX_SOURCES=$( echo $ZBX_SOURCES | sed -rn 's%^([^:]+://)?([^/:]+)(:[0-9]+)?(.*)%\1127.0.0.1\4%p' ) ; \
+      SVN_PIPE=$( mktemp -ut svn-proxy.XXXXXXXXXX ) ; \
+      mkfifo $SVN_PIPE ; \
+      nc -klw3 3690 < $SVN_PIPE | nc -X connect -x "$SVN_PROXY" "$SVN_HOST" "$SVN_PORT" > $SVN_PIPE & \
+    } ; \
+    apk add ${APK_FLAGS_DEV} --virtual build-dependencies \
             alpine-sdk \
             coreutils \
             automake \
@@ -100,7 +115,8 @@ RUN apk add ${APK_FLAGS_DEV} --virtual build-dependencies \
     rm -rf /tmp/zabbix-${ZBX_VERSION}/ && \
     apk del ${APK_FLAGS_COMMON} --purge \
             build-dependencies && \
-    rm -rf /var/cache/apk/*
+    rm -rf /var/cache/apk/* && \
+    [ -e $SVN_PIPE ] && rm -f $SVN_PIPE

 EXPOSE 10051/TCP 162/UDP

For the record, the installation of netcat-openbsd is only required for Alpine based images.

Is this just a case of changing the schema file supplied so the type is varchar (255)?

Can we identify the area / impact of the change in question ?
It looks very quick fix on the face of it.

I attempted to change the DB schema, along with the schema file.
I was able to create a trigger prototype with max 255 characters.
But unfortunately, the change in graph prototype was not reflected when we push the values.
It looks like some more validation is also done at the backend c-libraries, created at the time of compilation.

Frankly, I'd say, that it should be 512 char. Just to be safe. ISP/DC level switchport descriptions are impacted by it.

I think it's because of this https://support.zabbix.com/browse/ZBX-5687 issue that is closed and won't be fixed?

It would be good to go ahead and create the graph and truncate the name at 128 characters, then instead of showing in the info column in the discovery rule that a graph was not created because of the length, that it was created but the name truncated. That way you at least get the graph without having to go create it manually with a shorter name.

Changing the column length doesn't do anything, it's coded somewhere to check the length and reject it over 128 characters.

We're in the process of implementing Zabbix across our network. Currently we have 1000+ devices in Zabbix with 8000+ more planned, and we're running into this specific issue. Going through thousands of devices and renaming interfaces to fit within the 128 character limit is a hard stop for us for two reasons:

1. It would negatively impact several departments who use these interface names to identify circuits

2. It would be a massive undertaking to log into all of these devices and rename interfaces, which defeats the purpose of LLD.

Manually identifying missing graphs and creating them by hand is equally problematic. Ideally these graphs could be added with a truncated name, as suggested by sbindley. We will have to consider alternative solutions without it.

Having looked at the source briefly it appears this is limited by GRAPH_NAME_LEN within include/db.h as well as the name column width in the database table definition. For now I'm going to do some experimentation and see what kind of issues we run into with increasing these values, but an official solution would be perferred.

> GRAPH_NAME_LEN within include/db.h as well as the name column width in the database table definition
No, you find only half part of iceberg. You must also hack 128 byte limit in src/libs/zbxdbhigh/dbschema.c and include/schema.inc.php - enjoy real-time validation!

> official solution would be perferred.
Four years official solution is "not a problem for us" (C)

Thanks. I had found include/schema.inc.php already but not the other one. I decided instead that it might be easier to come at the problem before it gets there. It's an ugly hack, but I'm working on having it truncate the initial snmp query response for ifAlias before it gets passed in. That way it avoids the character limit issue.

@Billy, I'm interested in your stop-gap solution of truncating the ifalias.  Were you able to get that working, and can you provide patch files?

@Josh, yes and no. Yes I was able to get it working and it has been doing well ever since, but no I don't recall exactly what it was I had done to resolve this particular error. I've made a bunch of other changes and added new views and API extensions since then to better suit our needs, so it's a bit hard to tell what is original and what isn't at this point. I'll do some poking around in it and see if anything refreshes my memory.

Looks like what I ended up doing was in /src/libs/zbxdbhigh/host.c and /src/libs/zbxdbhigh/lld_graph.c I checked the length of the graph name and truncated it if necessary right before the insert and update queries are generated. Someone else could very likely do a better job of it than I have, and it should be using the value from dbschema.c instead of a hard-coded length. I simply cut off the end and added a '...' to indicate that it was truncated. Obviously use this info at your own risk.

/src/libs/zbxdbhigh/host.c:

                if (strlen(name_esc) > 127) {
                        char *nCpy = malloc(sizeof(char) * 124);
                        strncpy(nCpy, name_esc, 124);
                        strcat(nCpy, "...");
                        strcpy(name_esc, nCpy);
                }
                zbx_snprintf_alloc(&sql, &sql_alloc, &sql_offset,
                                "insert into graphs"
                                " (graphid,name,width,height,yaxismin,yaxismax,templateid,"
                                "show_work_period,show_triggers,graphtype,show_legend,"
                                "show_3d,percent_left,percent_right,ymin_type,ymax_type,"

                if (strlen(name_esc) > 127) {
                        char *nCpy = malloc(sizeof(char) * 124);
                        strncpy(nCpy, name_esc, 124);
                        strcat(nCpy, "...");
                        strcpy(name_esc, nCpy);
                }

                zbx_snprintf_alloc(&sql, &sql_alloc, &sql_offset,
                                "update graphs"
                                " set name='%s',"
                                        "width=%d,"
                                        "height=%d,"
                                        "yaxismin=" ZBX_FS_DBL ","

/src/libs/zbxdbhigh/lld_graph.c:

                        zbx_strcpy_alloc(&sql, &sql_alloc, &sql_offset, "update graphs set ");
                        if (0 != (graph->flags & ZBX_FLAG_LLD_GRAPH_UPDATE_NAME))
                        {
                                name_esc = DBdyn_escape_string(graph->name);

                                if (strlen(name_esc) > 127) {
                                        char *nCpy = malloc(sizeof(char) * 124);
                                        strncpy(nCpy, name_esc, 124);
                                        strcat(nCpy, "...");
                                        strcpy(name_esc, nCpy);
                                }

                                zbx_snprintf_alloc(&sql, &sql_alloc, &sql_offset, "name='%s'", name_esc);
                                zbx_free(name_esc);
                                d = ",";
                        }
 

description for :

• global regexps ZBXNEXT-597
• graphs ZBXNEXT-716
• host groups ZBXNEXT-2408
• maintenance subperiods ZBXNEXT-2770
• users ZBXNEXT-2825

This is definitely a nice quick easy addition!

It looks trivial to add a description field, with minimal impact on database and other features.

In large installations, it's necessary to document the purpose of each usergroup and some users: why was it created for? permissions? alerting? dashboards? api access?.

Zabbix configuration should allow for some kind of auto-documenting, it'd make the life of Zabbix administrators easier.

if not a description field, then a tags field. this would allow to add tags for short description, expiration dates, a temp flag, etc.

umm i search something and i think in script uninstall of debian we must parse the db type as "psql" but i dont know where exactly..

IBM DB2

ZBX-8328 is related, but asks for proper UTF-8 character support in varchar(N).

Solaris 10

palivoda, any idea if we will provide pre-compiled agents for Solaris?

https://www.zabbix.com/download_agents

Was also asked in ZBXNEXT-4632.

Hi,

Since I can only find it at repo: https://repo.zabbix.com/zabbix/3.0/rhel/7/SRPMS/  as a rpm.

Any way I can find an official link to the source code of this?

svn://svn.zabbix.com

Can you please tell us in which Zabbix release will this change be available?

From the Fedora docs:

The use of RPM’s facility for generating relocatable packages is strongly discouraged. It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review.

Thus I'm not sure we should do it.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_relocatable_packages

The real reason for this is that some users only grant permission of a single directory to zabbix. They prefer all content from zabbix are placed at the same place, not spreading out  as the default configuration. They will use the rpm installation instead of yum.

So it would be appreciated to keep the option, though may not be used commonly.  

Implemented in development branch feature/ZBXNEXT-8925-6.5

Implemented in 7.0.0beta1 (master) f881b5aae8e

Documentation updated (7.0):

• Introduction > What's new in Zabbix 7.0.0
• Installation >
  • Requirements
  • Installation from packages > SUSE Linux Enterprise Server
  • Web interface installation (screenshot and table)
  • Upgrade procedure (table)
  • Upgrade procedure > Upgrade from sources
  • Known issues (section related to PHP 7.3 removed)
  • Upgrade notes for 7.0.0 > Breaking changes

RHEL7, Oracle 19.3

For versions older that Oracle Database 12c Release 2 (12.2) we could reduce field length to 2000.

Two issues linked as duplicates as a proof.

Why this is happening with users.

A lot of PHP-based "frontends" suppose only one action performed manually by a user - DB creation and granting all required permission to the created DB.

Then on first attempt to open the frontend its php scripts create DB's tables and fill some data (if required).

This is not the case regarding to zabbix frontend, so we could be more friendly to such user mistakes and provide more precise errors during PHP frontend setup.

Yes, we have required steps to install zabbix described in documentation, but time to time we see that users do not read documentation

ZBX-6376 is very related (they should be fixed together)

Interesting note for 2.2.0 release:

If we have created database but schema is not filled then the "setup.php" on the 3rd step returns message:

The frontend does not match Zabbix database.

If we point config file "zabbix.conf.php" to that empty database and open "setup.php" then frontend returns message:

Configuration file error: The frontend does not match Zabbix database.

And finally index.php returns:

Database error: The frontend does not match Zabbix database.

Such cases could be more user friendly.
Otherwise we will have cases like this (in Russian) - https://www.zabbix.com/forum/showthread.php?t=43123

It would be nice to check and automatically populate it if DB has no schema at all.

Additional question: is it possible to compile zabbix agent for Open Indiana?

Zabbix agent can be compiled under Open Indiana without any problems (you need just install gcc compiler).

SunOS openindiana 5.11 oi_151a2 i86pc i386 i86pc Solaris

1. zabbix_agentd -V
   Zabbix Agent (daemon) v1.8.10 (revision 24303) (28 December 2011)
   Compilation time: Feb 26 2012 00:44:57

1. zabbix_agentd -p
   agent.ping [u|1]
   agent.version [s|1.8.10]
   system.localtime [u|1330210124]
   system.run[echo test] [m|ZBX_NOTSUPPORTED]
   web.page.get[localhost,,80] [t|EOF]
   web.page.perf[localhost,,80] [d|0.000000]
   web.page.regexp[localhost,,80,OK] [s|EOF]
   vfs.file.exists[/etc/passwd] [u|1]
   vfs.file.time[/etc/passwd,modify] [u|1330192152]
   vfs.file.size[/etc/passwd] [u|1044]
   vfs.file.regexp[/etc/passwd,root] [s|root:x:0:0:Super-User:/root:/usr/bin/bash]
   vfs.file.regmatch[/etc/passwd,root] [u|1]
   vfs.file.cksum[/etc/passwd] [u|2234160828]
   vfs.file.md5sum[/etc/passwd] [s|db821a53f6c8e9a7f760320766fdff41]
   net.tcp.dns[,zabbix.com] [u|1]
   net.tcp.dns.query[,zabbix.com] [t|zabbix.com SOA ns1.nameresolve.com hostmaster.zabbix.com 2012022512 16384 2048 1048576 2560]
   net.tcp.port[,80] [u|0]
   system.hostname[] [t|openindiana]
   system.uname [t|SunOS openindiana 5.11 oi_151a2 i86pc i386 i86pc Solaris]
   system.users.num [u|2]
   log[logfile] [m|Accessible only as active check!]
   logrt[logfile] [m|Accessible only as active check!]
   eventlog[system] [m|Accessible only as active check!]
   kernel.maxproc [u|9706]
   vfs.fs.size[/,free] [u|10697522688]
   vfs.fs.inode[/,free] [u|20893599]
   vfs.dev.read[sd0,bytes] [u|4860797565]
   vfs.dev.write[sd0,bytes] [u|506519552]
   net.tcp.listen[80] [u|0]
   net.if.in[hme0,bytes] [m|ZBX_NOTSUPPORTED]
   net.if.out[hme0,bytes] [m|ZBX_NOTSUPPORTED]
   net.if.total[hme0,bytes] [m|ZBX_NOTSUPPORTED]
   net.if.collisions[hme0] [m|ZBX_NOTSUPPORTED]
   vm.memory.size[free] [u|36921344]
   proc.num[inetd,,] [u|1]
   proc.mem[inetd,,] [u|4710400]
   system.cpu.switches [u|1164792]
   system.cpu.intr [u|471357]
   system.cpu.util[all,idle] [m|Collector is not started!]
   system.cpu.load[all,avg1] [d|0.144531]
   system.cpu.num[online] [u|1]
   system.swap.size[all,free] [u|1047973888]
   system.swap.in[all] [u|0]
   system.swap.out[all,count] [u|0]
   system.uptime [u|1622]
   system.boottime [u|1330208503]
   net.tcp.service[ssh,127.0.0.1,22] [u|1]
   net.tcp.service.perf[ssh,127.0.0.1,22] [d|0.100118]

Binaries and packages for Solaris 11 should be compatible with Open Indiana.
Source: http://wiki.openindiana.org/oi/Frequently+Asked+Questions#FrequentlyAskedQuestions-IsOpenIndianaa“fork”%3F

I've checked and I confirm that zabbix_agentd binary for Solaris 11 is working on Open Indiana.

Please compile binaries for zabbix agent/zabbix server for version 3.4.11 / 4.0 for Solaris 11 SPARC and x86 

However, zabbix server isn't as important as the agent

Please could we have a agent for Solaris 11 with Open SSL encryption on the download page for server version 4 LTS

Thanks guys 

Linux zabbix 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
MonetDB Database Server v1.6 - Toolkit v1.0 (Apr2012-44068741341a)

operating system Debian

another problem its that script do not stop the sever/proxy process if only remove the package.. so then database removal could not performed.. that its in line 14 of postrm of script

postrm scritp removes config files before ucf purge the configuration file if "purge" are th case of deinstallation of package

Linux

Check this script, this can be a start for implementing the one-line installer for zabbix. At least it works for us quite well.

https://github.com/xenserver/devops/blob/master/prepare.sh

kodai, do we want to look into something like this ?

I think it quite nice feature, but I'm not sure what tool is the best. We need to think all platform (not only Linux, but also Windows, Solaris, HP-UX, AIX, etc.),

Also, it's necessary to consider updating agents as well.

I've created in ZBX-11767 patch for this with improved dummy module tree am/ac/lt support with example covering whole live cycle of module code from creating dist tar ball to make almost instant create rpm package with module.
This patch adds installing header files and adds pkgconfig support.

This is a serious issue for Module developers. I've spent hours tracing an issue for my community of users. The issue was caused because the headers in the Zabbix sources were being used by my modules and being mutated by the configure scripts in Zabbix build process.

See:https://github.com/cavaliercoder/libzbxpgsql/issues/68

Windows

Debian 11

PS: A non-modular approach could be to add a file /etc/php/7.4/fpm/pool.d/zabbix.conf:

php_value[max_execution_time] = 300
php_value[memory_limit] = 4096M
php_value[post_max_size] = 256M
php_value[upload_max_filesize] = 4M
php_value[max_input_time] = 300
php_value[date.timezone] = "CET"

and to restart the php7.4-fpm service.

Docker Compose

and consider to add an alpha/beta tag

We are using chromedp package which has an ExecPath(..) function but we must ensure all chromedp versions that we officially support have that.

Current compose files are good example. At the same time, the real life examples are missing (ZBXNEXT-4984).

could you please clarify, is this about always compiling in ipv6 support - thus not by default, not making it configurable anymore ?

richlv Maybe the description is a bit misleading indeed . What i meant was that we always compile with ipv6 support, thus removing the need of configuring it. The only weird bit will be to check what can be involved on the agent side (that still support really old operating systems, in particular windows 2000).
(BTW, there should be some investigation about the supported platforms)

what about compiling on older aix/solaris systems ? would ipv6-enabled server/proxy work perfectly there ?
it is probably also worth keeping in mind a few edge cases where people have wanted to compile zabbix without ipv6 support, such a change would break zabbix for them.

Jep, also true. Definitely should be investigated properly if we decide to see if it's worthwhile.

It seems the auto-registration metadata value have the same limitation of 255 chars

I moved this request into ZBXNEXT project because it's a database limitation and we can only fix it in a major release.

with postgresql, this results in errors :

ERROR:  value too long for type character varying(255)
STATEMENT:  update dservices set status=0,lastup=1488280308,lastdown=0,value='...long_value...' where dserviceid=1234

should this be moved back to ZBX ?

Dear richlv, I will not ask you to reveal the "long value", but please give us some information about it:

1. number of characters;
2. number of bytes;
3. number of LF and CR characters;
4. presence of non-ASCII characters and original encoding.

Also please provide some general information:

1. version of Zabbix being used;
2. Zabbix database character set.

taking one case as an example - others differ somewhat in size, but not much.

1. 546 characters
2. 546 bytes
3. 7 LFs
4. no non-ascii chars; value obtained by agent from a script, agent locale - en_US.UTF-8

1. this specific case on 2.4.6
2. utf8

Hmm, this piece of 2.4 code is suspicious:

		/* only UTF-8 characters should reduce a variable max_src_len */
		if (0x80 != (0xc0 & *s) && 0 == --max_src_len)
			break;

But I don't think that the issue affects latest supported versions.

A link where we can find some simple init script, thanks to dotneft.
http://www.packetwatch.net/documents/guides/2010111001.php

How about our own: https://www.zabbix.com/wiki/howto/install/solaris/opensolaris
and https://www.zabbix.com/forum/archive/index.php/t-252.html

Thanks for these links.
Should maybe consider including these with the source code?

As this classified as a feature request, we are not sure when devs will take it in work
Community feedback which init script is better would be appreciated.

Starting from Solaris 10 there is used SMF for service management. initd is still supported, but will be replaced.

• In Solaris 11 create SMF manifest:

  svcbundle -o zabbix-agentd.xml -s service-name=application/zabbix-agentd -s model=daemon -s start-method="/usr/local/sbin/zabbix_agentd" 

• Import manifest:

  svccfg import misc/solaris/11/zabbix-agentd.xml

• Usage: svcadm enable/disable/restart zabbix-agentd

*For Solaris 10 there need create manifest manually.

I have created a SysV init script that works in Linux/AIX/Solaris for both agent and server. Please check https://support.zabbix.com/browse/ZBXNEXT-2229

Not providing a zabbix-agent.xml for the poor guys bound to SunOS 5.10 is mean. See attachment. Use at your own risk. Hope this helps.

Debian Wheezy, PostgreSQL 9.1

MySQL

could you please clarify what this is about ?
which action-related field is limiting you ?

This is an error I get when creating an action with 15 conditions (through the API, but this also happens when adding the action through the frontend)

The entered formula is "A and B and C and (D or E or F or G or H or I or J or K or L or M or N or O)" where everything between () are hosts.

Value "'

Unknown macro: {200200000000080}

and

Unknown macro: {200200000000081}

and

Unknown macro: {200200000000082}

and (

Unknown macro: {200200000000083}

or

Unknown macro: {200200000000084}

or

Unknown macro: {200200000000085}

or

Unknown macro: {200200000000086}

or

Unknown macro: {200200000000087}

or

Unknown macro: {200200000000088}

or

Unknown macro: {200200000000089}

or

Unknown macro: {200200000000090}

or

Unknown macro: {200200000000091}

or

Unknown macro: {200200000000092}

or

Unknown macro: {200200000000093}

or

Unknown macro: {200200000000094}

)'" is too long for field "formula" - 316 characters. Allowed length is 255 characters.

So this is what is stored in the table after the formula got expanded.

Note that we usually use hostgroups to select the hosts in actions, but we want to allow our end-users to select the hosts (and later also hostgroups) to subscribe to, so that's where I ran into this limit.

We mitigated this issue a bit by rewriting the IDs so that they are much shorter which gives more room for conditions. Still it would be nice if the maximum number of conditions could be expanded.

Same problem here with PostgresSQL.

Value "({149} or {150} or {151} or {153} or {154} or {185} or {383} or {384} or {385} or {386} or {387} or {388} or {389} or {390} or {391} or {392} or {393} or {394} or {152} or {428} or {429} or {430} or {431} or {432} or {433} or {434} or {435} or {436} or {437} or {438} or {439} or {440} or {441} or {442}) and {395} and {396} and {397}" is too long for field "formula" - 335 characters. Allowed length is 255 characters. 

I've had to split a large subnet in multiple small one to speed up discovery. Now I have a lot of discovery check to match from but I can't add them all.

I've updated the field lengh in include/schema.inc.php and ran "alter table actions alter column formula type character varying(512);" on the DB to workaround the problem. Until the next update I guess.

currently that's by design, as one could have proxy with same name
it does make some things harder, so probably we should do this at some point.

(1) what to do if user has proxy with same name as a host or template ?

i do not understand the (1)

hum, i name host/proxy this way:
host | name | status
-------------------------------------------------------------------------------------------------------------
zabbix-proxy-mlb-prod.sup.internal.domain. | zabbix-proxy-mlb-prod.sup | 0
zabbix-proxy-mlb-dev..sup.internal.domain | zabbix-proxy-mlb-dev.sup | 0
zabbix-proxy-par3-prod.sup | | 5
zabbix-proxy-mlb-prod.sup | | 5

I understand, we could do:
zabbix-proxy-mlb-prod.sup.internal.domain | zabbix-proxy-mlb-prod.sup | 0
zabbix-proxy-mlb-prod.sup.internal.domain | | 5

Perhaps, we could have a special table "proxy" to reference hosts which are proxies
proxy_id, host_id

Yes, I believe we should move proxies to a different table.

...but probably not in 2.2, removing "fix version"

The Zurich Versicherungen had the same problem and also changed their Logo some days ago.

Before any official solutions are in place, you may take advantage of the re-branding functionality in order to replace the "Z" logo with something else.

Is there a way to change favicon by re-branding functionality?
BRAND_LOGO did not change it.

I do not think favicon can be changed easily, only by a custom patch.

@pavel you might wish to take a look at the module https://github.com/BGmot/zabbix-module-peace.

Thank you!
On my system (zabbix 5.0.21) it failed to activate with following error:

AH01071: Got error 'PHP message: PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in /usr/share/zabbix/app/controllers/CControllerModuleUpdate.php on line 69'

but it seems unrelated to the module.

After I fix this favicon changed when I enable the module but restore to its original form on shift-reload the page. If I go to modules and enable it again it changes again, until shift-reload.

I tested with 5.0.22 (re-tested just now, and with latest 6.0 and 6.2) and works as expected. What method of installation did you use 1.a or 1.b? Can you compare what you have in Module.php with what I have in the repo?

Ouch.... Chrome and Safari do not change favicon -( Mozilla does. I was testing with Mozilla, sorry. Testing from MacOS, I am travelling and don't have anything else at the moment.

I know how to fix Chrome. Let's proceed with the discussion on GitHub to avoid spamming here.

The problem is not just the letter Z but also the colors white and red which are part of the symbol for Russian fascism (as promoted by A. Dugin in his manifesto)

After 6 months of Russian aggression with Z as its universal symbol, it seems to me that there should be an official solution. At least a temporary one.

BGmot your turn. =D We need a plugin to change red to yellow and white to blue. 

Не солидно, Саша, говна набрасывать. Не нужно - проходи мимо. Уверен Zabbix сам разберётся, что ему делать (или не делать).

Не, мне нормально, на самом деле, хотя я и согласен, что над больными грешно смеяться. Но ничего не могу с собой поделать.

Nou! Ik als Nederlander vind het maar een triest onderwerp. Het is een fucking Z als de eerste letter van het product, en voorderest niets.

Stelletje kleuters, zeikend over een Z en niet in het engels communiceren.... jammer.

brian.baekel I'm sorry, you are totally right, we should't use the fucking agressor's language. I apologize to all of you, it's really shame on me.

Linux

Patch corrected to not use in autoreconf parameters -f switch because it will overwrite COPYING file.

If this option would be used it will change zabbix license from GPL v2 to v3

Debian Wheezy, gcc 8.2

Do you think it's OK to specify it during ./configure:

./configure RANLIB=gcc-ranlib --enable-server [...]

?

Yes, it's OK and should be considered as expected behaviour. There is no way for libtool to automatically determine which version of ranlib you are considering to use.

As I understood the patch would be:

Index: configure.ac
===================================================================
--- configure.ac (revision 86007)
+++ configure.ac (working copy)
@@ -39,6 +39,7 @@

 AC_PROG_CC([cc c99 gcc clang])
 AM_PROG_CC_C_O
+AM_PROG_LIBTOOL

 dnl *****************************************************************
 dnl * *
@@ -1643,9 +1644,6 @@

 AC_SUBST(ICONV_CFLAGS)

-RANLIB="ranlib"
-AC_SUBST(RANLIB)
-
 SERVER_CONFIG_FILE="${sysconfdir}/zabbix_server.conf"
 PROXY_CONFIG_FILE="${sysconfdir}/zabbix_proxy.conf"
 AGENT_CONFIG_FILE="${sysconfdir}/zabbix_agentd.conf"

Useful links:

https://mail.gnome.org/archives/commits-list/2017-February/msg03967.html
https://stackoverflow.com/questions/40374061/autoconf-recipe-to-use-gcc-ar-and-gcc-ranlib
https://bugzilla.redhat.com/show_bug.cgi?id=1467409

There is no need for libtool macro AM_PROG_LIBTOOL. Just delete RANLIB="ranlib" and keep AC_SUBST(RANLIB).
ranlib is called explicitly not by libtool.

All. I'm using a Debian-based Zabbix server but there is nothing system-specific in this particular regexp.

Debian/Ubuntu. May work for CentOS too.

+1 for this. I opened https://support.zabbix.com/browse/ZBXNEXT-3050 a few months back. I'm happy to sponsor a mirror. Offering rsync would allow everybody to also create their own private mirror.

1.) Disk space requirement

wget ‐‐execute robots=off ‐‐recursive \
  ‐‐no-parent ‐‐continue ‐‐no-clobber \
  -l 100 --reject-regex "=" http://repo.zabbix.com

=> 9.2GB (html files included) ~= 10GB

BTW: 10GB of AWS S3 standard storage (99.99% availability, 99.999999999% durability) = $0.3/month
Only traffic is a question.

Well, 10-20 GB of space and 10-30 Mbps of traffic I can donate as a person, not as company (on kimsufi, but this is enough).

I believe we can have better availability if we make this the same way as httpredir.debian.org is made: round robin DNS and a swarm of backends.

Another advantage: if company uses Zabbix repo a lot, making public mirror and using redirector makes perfect sense - their machines should be pointed to their repo. If it is running, but when it isn't, packages still will be retrived from another repo.

Another advantage: better geographical coverage.

I know, we can make private mirrors, move to servers with better availability etc. but if we are changing things, why not make it really good? Especially that not available repository is PITA when things are automated.

Attached ArchLinux systemd files for agent and server (both files 2013 Nov 13). Please include them upstream! We need them for packaging (https://aur.archlinux.org/packages/?O=0&K=zabbix)

zabbix-agent.service has errors and Jonas' file basically matches what Fedora now ships with. That said, it would be good to finally standardize the name of the service: zabbix-agent or zabbix-agentd? Debian, Ubuntu and Fedora/EPEL use -agent; Suse, Arch and Gentoo use -agentd.

Jonas' server file is too specific tough, in that it requests mysqld.service. In Fedora/EPEL we are using the Alternatives system to switch between different backend implementation unit files. That basically means, the unit file appears to always have a generic name, but acutually points to a specific implementation.

I'm not sure about the relevance of "-R config_cache_reload". I was under the impression that would happen anyway on start. It might be useful as a setting for "ExecReload" though.

i would prefer 'agentd' over 'agent' to avoid increased confusion regarding agent/agentd (which is already large enough).

as for config cache reload, i can't think of a reason to do that after startup - was it an attempt to work around some problem ?

Adjusted the zabbix_agentd config for Debian Jessie

cat /etc/systemd/system/zabbix-agent.service
[Unit]
Description=Zabbix Agent
After=syslog.target network.target

[Service]
Type=forking
ExecStart=/usr/sbin/zabbix_agentd
PIDFile=/run/zabbix/zabbix_agentd.pid
Restart=always

[Install]
WantedBy=multi-user.target
----
cat /etc/tmpfiles.d/zabbix-agent.conf
d /var/run/zabbix 0755 zabbix zabbix

This is a bad .service file.

I know - but compared to other .service files on Debian (check dnsmasq.service...) it is a beauty

I welcome your suggestions for improvement!

That's the secret how to feel good: you just need to compare your work to something that is worse. Yay. I have to try it some day.

Why zabbix-agent service does not enable by default in deb packages? Is it a RedHat style in Debian like distrs? =)

I think that dh_systemd_enable should be added for not broke old behavior.

Hi,

possible to get any progress here? I'm maintaining a puppet module to configure zabbix, we had:

PrivateTmp=yes
ProtectSystem=full
ProtectHome=yes

in the service file for the agent. Possible to get this upstream?

zabbix-server.service does not consider the possibility of postgres as database backend. In such case, the After directive should be

After=syslog.target network.target postgresql.service

This affects also 3.0.6 installed today (Ubuntu Xenial, Zabbix repo).

// Edit: OK, so no. The whole problem is that the systemd unit is not enabled by default

systemctl enable zabbix-server

fixed the problem.

We still have init.d scripts, but no unit files. Which is strange if we are talking about systemd based operating systems (e.g. RHEL 7).
It would be awesome to have unit files in the sources.

Some things mentioned here are also listed in ZBX-15602

I think we should just disable the "dist" target in created tar.gz .

operatin system: debian

kodai, can you please take a look, is this something to fix ?
thanks.

yes, the solution its easy.. just in debian/rules around line 274 the sed command also must sustitute the user to DBC_USER as does with server cases...