Debian 5.0.3

Confirmed on Zabbix 1.8.1

Remote command does not work threw proxy Proxy. I have nothing in proxy logs nor agent logs.

I have registered command like:

{HOSTPROXY}:{HOSTNAME}:{COMMAND}

It was the only way that web interface allowed me to register Remote Command Action.

Hi Krzysztof, can you tell me how did you do that? (I mean registering the command). Did it work? I want to do so too.

Thanks.

Hi. Does it mean that this is going to be resolved/implemented?
I'm not able to find/see DEV-378. Is it right?
Thanks.

Mail from Krzysztof Kardas:

Well I have registered command like this:
proxyname:servername:command

The other way does not work - like
servername:command

Zabbix frontend says that there is no such server.

I have tried it on 1.8.1 but not on 1.8.3.
Maybe something has been fixed ?

I think the simple way to repair it is to change the proxy delimiter from : to something else like maybe "|" or whatever sign. Then Zabbix server will have the ability to recognize that host is behind proxy and send the proper configuration to it. Or simple check if the host is behind proxy. I have not analysed the code for this bug.

Greetings
Krzysztof Kardas

To Jordi Clariana:

You were writing: "I'm not able to find/see DEV-378. Is it right?"
-->Yes, it is OK that you are not able to open DEV-378 issue, it is an internal issue for development.

Thanks for the answer. Does it mean that this issue is going to be resolved for the next release?

Jordi.

as far as i know, there's no specific plan regarding remote command support for proxies currently

The command provided by Krzysztof Kardas – {HOSTPROXY}:{HOSTNAME}:{COMMAND} – doesn't seem to work, atleast in v1.8.4 (that's the version I am using). Apparently, it's not accepting the "{HOSTPROXY}" directive and throwing an "incorrect command" error.
Did it work for anyone else? Jordi Clariana?

Please let me know if there's any workaround for this. Thanks!

Hi Shanu.

This command will not work because it need to be "registered" as Krzysztof said, in the zabbix source code (if I'm not mistaken). But, I don't know how to do this, that's because I asked later how to do so, without any response.
Besides, it seems that this functionality is lack of interest (not to me), as richlv said in the message before yours.

Regards,

Jordi.

Currently proxies do not support remote commands. There is a ZBXNEXT issue registered about it. I am closing it, not a bug.

couldn't find an existing zbxnext -> reopening

I can confirm that proxy's still don't execute remote commands as of 1.8.8. Below is the trigger I'm using

{HOSTNAME}:sudo /sbin/service puppet start 1>/dev/null 2>&1

This trigger works just fine on agents that are Server -> Agent. However it never gets executed when the agent goes through a proxy , Server -> Proxy -> Agent. The action is logged correctly in the Audit logs,(attached screenshot), but never actually gets executed. There is no error in either the Proxy or Server logs.

So I ran into this issue today, and was able to get a remote command to work on a host managed by a proxy.

The problem is, the main zabbix server is actually sending the call to execute the command on the host, not the proxy.
Here is the debug level 4 error in zabbix_agent.log
6737:20120301:100626.412 Listener error: Connection from [<main Zabbix Server IP>] rejected. Allowed server is [<Proxy Server IP>]

So I had to add the main zabbix server's IP to the list of Servers in the zabbix_agentd.conf

Server=<proxy ip>,<main zabbix ip>

Now I was able to run the remote command.

The problem now is that I have to open firewall holes to each host in another Datacenter so the main zabbix server can talk to them, which was most of the reason why we were using Proxies in the first place.

Hi,

I'm using Zabbix server 1.8.10, proxies are in same version and agent are in version from 1.8.5 to 1.8.10. I still cannot run remote command on host behind proxies even using solution provided by Krzysztof Kardas :
{HOSTPROXY}:{HOSTNAME}:{COMMAND}

For now, I have two solutions but not easy to maintain :

• using a script on server that does ssh tunneling through proxy to run command on the host
• running remote command,on proxy using the agent, to run script that does ssh to run commands on the hosts

One or other solution are dirty and not scalable. Any chance to run remote command on host through proxies ?

Hi,

we have the same situation: all of our infrastructure a located beyond proxies.
Right now we implementing scalable failover technics, and remote command execution is the global part of this.

Can we donate some amount of € for resolving this issue?

—
Best regards,
Eugene Istomin
[email protected]

Hi,

After migration of our zabbix server to a new server and transform the old server into a proxy, we have fall into this non existant feature. I won't have thought it wasn't already an existant feature.

Can you please create this ?

Thank you.
JC

Running into the same issue with 1.8.12, considering this as a major issue since our FW setup has to be changed for this, making the network ninja's very unhappy.

This is definitely causing me a few issues, should we expect a fix soon or is it quite a difficult one to progress?

there are currently no short term plans for this feature

This silenly-missing feature tricks one into building infrastructure and methods around the use of Proxy for remote-site monitoring. This should not be a separate "feature" that needs to be paid for and added, it's implicit. Please fix. If a cup needs to be passed around to sponsor it, please be up front about it and specify how much this will cost so it can be done.

Maybe via ZBXNEXT Sponsor Application Form
Just seen that it's planned for next major release
Actually it's just tagged for NMR. Meanwhile I know the tags better

In a related issue, I needed to run a command on the proxy of the host triggering so I modified the source code and added the new option of "Run in proxy" , here is the patch http://www.spotflux.com/blog/automated-high-availability-zabbix/ and it is in production since 7 months ago and even reused it for the different versions. You should place this file in debian/patches/ before creating the .deb.
I hope it helps someone else.

The only condition is that the proxy is running zabbix-agent with remote commands enabled and connecting to the zabbix server directly.

Saludos!

It would be nice to implement such feature: Remote commands through proxy.

As this topic is commented for a long time here and on other zabbix forums, I would like to add my 5 cents. Here is my proposed workaround:
I scripted a zabbix_get.py script, which is a "proxy aware zabbix_get". We are using it in "zabbix scripts" and it could be used to start a remote command by zabbix key 'system.run["command -to -run","wait"]'. Here is the detailed info:

# ABOUT
# The script is a 'zabbix_get' command, which is proxy aware.
# "Proxy Aware" means you can start zabbix_get.py on the zabbix server and take output of an agent key
# on a zabbix host, which is behind a proxy.
# Tested on Zabbix 2.0
#
# USAGE
# ./zabbix_get.py <zabbix_host_name> <zabbix_agent_key>
# <zabbix_host_name> is the host name configured in the zabbix web interface
# Note: This is the {HOST.HOST1} zabbix macro.
# <zabbix_agent_key> is the agent key, as used in -k option of the original zabbix_get
# Note: The agent key should be properly quoted as used in the -k option of zabbix_get, e.g:
#       'system.run["echo \"###\"","wait"] is working normally on zabbix_get and zabbix_get.py
#
# OPERATION
# The script first connects to the zabbix server API and takes the proxy configuration for the given host.
# If host is not behind a proxy, the script invokes the original zabbix_get directly from the zabbix server.
# If host is behind a proxy, the script invokes the original zabbix_get on the proxy.
# 
# CONFIGURATION
#   * You need to configure the zabbix API user and password below
#   * In the zabbix proxy configuration file 'zabbix_agentd.conf' enable remote commands "EnableRemoteCommands=1" 
#   * In the zabbix proxy configuration file 'zabbix_agentd.conf' set timeout to maximum "Timeout=30"

Cheers,
Todor

Hi Todor, how does the server connect with the proxy if the proxy is in active mode (not reacheable by the server)?

based on the zabbix_get.py, it doesn't deal with active proxies, if the script can't find any interface for a proxy (like in the case of active proxies), it exits with exit code "1".

It's also impossible to run a remote command on an "active only" agent behind proxy, but this is still not possible even for hosts not behind a zabbix proxy.

Also, I'm not sure, do your passive proxies allow to run "system.run" commands on them? Mine doesn't (2.2.1), it just replies with an empty string, did you modify the proxy somehow?

@Cristian Mammoli
@Gabriele Armao

Yes, the script does not deal with "active only" agent for hosts behind a proxy and for hosts not behind the proxy. So it can be used only with passive mode agents.
We do not use active checks and this is the reason I am not much knowlegeable about them. If someone can help me out how to deal with active agent checks, I may change the script. Here the first important question is - is it possible to run the original 'zabbix_get' on an "active only" agent?

@Gabriele Armao
Yes, in the zabbix_agentd.conf on the passive proxy I allow system.run by "EnableRemoteCommands=1" + I expand the timeout to maximum "Timeout=30". My proxies are secured at maximum possible - they communicate with the server via VPN and they allow only the server IP to place zabbix agent requests, so I consider system.run to be safe.

Thank you, guys, for the comments and if you help me with more suggestions, I could change the script further.

Cheers,
Todor

my +1 vote, would be great to have this sorted..

@ Zabbix-Team: Is there any scheduled date to have this feature available in Zabbix?

it is not on the current roadmap : https://www.zabbix.org/wiki/Docs/roadmap

I truly cannot understand why this is not considered a bug. Remote commands and process are core functionality and they should work together. It doesn't even feel like this should be all that hard to fix. This is the first item in Zabbix that I have run into that really disappoints me. Monitoring anything of size is going to require a distributed system. That system needs to be consistent across the environment.

^ totally agree with Michael Spurlock. This should be a bug and put on the roadmap. Especially since zabbix moved away from node based architecture to proxy based architecture. If they're pushing the use of proxies, but the proxies cannot process remote commands, that to me seems like an oversight and a bug that should be fixed immediately.

After having briefly investigated an implementation by myself some time ago, I can say that this needs significant development effort.
I share the opinion that using a Zabbix proxy must not break functionality.
Anyhow, due to the complexity to implement this in a reasonable way, I understand that this needs proper financial backing.

this feature has been voted on by the zabbix conference 2015 participants to be developed. development will likely start after the release of 3.0

can we please set the "fix version" to 3.2 to indicate the voting results ?

Yes, It's would be great !

One specific use case not mentioned here explicitly is ability to execute remote command "by proxy" itself, like remote command executed "by server".
Use case - monitoring vmware/snmp/etc services and need to restart something by a script executed on the proxy, because only proxy can connect to the services.

Workarounds with using locally running agent on the proxy - would be not very convenient.

totally need to run command on the proxy

Our infrastructures are distributed in several DCs, each with a Zabbix proxy as entry point (because of FW/NAT), and unfortunately we can't automate actions on agents, it's a real problem.
It's a mandatory feature for a real use of proxies... today they are pretty useless.
I really hope the next 3.2 alpha will provide the feature, as it seems to be still on roadmap

Proxies are far from useless and I appreciate the work going into granting the abilities for remote commands, but i still get great use out of my proxies as it stands currently.

You'r right, i was a bit hard =) I just want this feature so much

the current place I work for also is needing this feature. We're rolling out 3.2 as we speak.

Any news or target dates/versions?

(1) [F] Changed translation strings:

Strings added:

• Zabbix server (proxy)
• Server (proxy)
• Run custom commands on %1$s

Strings deleted:

• Run custom commands on Zabbix agent
• Run custom commands on Zabbix server
• Run custom commands on Zabbix server (proxy)

sasha Updated translation strings.

s.paskevics CLOSED.

Frontend side ready to testing. r64563

(2) [A] Tasks created by API (close problem) must have correct status, clock fields:

• status - 1 (ZBX_TM_STATUS_NEW)
• clock - task creation time

oleg.egorov RESOLVED in 65907

sasha CLOSED

(3) [F] 'Zabbix server (proxy)' must be added as third 'Execute on' target for global scripts.

oleg.egorov RESOLVED in 65906

sasha CLOSED

Server side ready for testing in in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-936-2

The meaning of execute on Zabbix server (proxy) is to execute script on proxy (if host is monitored by proxy) or on server. Better naming ideas are welcome.

proxy-sqlite complains about query:

[Z3005] query failed: [0] ambiguous column name: taskid [select t.taskid,t.type,t.clock,t.ttl,r.status,r.parent_taskid,r.info from task t,task_remote_command_result r where t.taskid=r.taskid and t.status=1 and t.type=3 order by taskid]

housekeeper part is missing?

(4) [S] Invalid SQL queries generated when selecting tasks to be sent to server/proxy (reported by lynxchaus)

RESOLVED in r65362

s.paskevics CLOSED.

What about global scripts? Actions - it's good, but some time need run traceroute/ping (for example) in network behind proxy.

Global scripts are supported in actions. Manual execution will be supported later (technically it won't be too complicated).

Geat idea by Andrey Melnikov about global scripts!
He is talking about a web-GUI scripts (tools) that run on the Zabbix GUI Server, even if the host is monitored by Zabbix Proxy.

(5) [S] Check port processing with IPMI commands after ZBXNEXT-3386 is merged.

wiper CLOSED

After patching, datasender process ignore DataSenderFrequency config knob and proxy connect to server every seconds (ZBX_TASK_UPDATE_FREQUENCY).

Yes, proxy has to poll server for new tasks. Active proxies uses empty 'proxy data' request when polling server for task data outside DataSenderFrequency intervals.

(6) [IT] Add task manager monitoring items to proxy template after template changes from ZBXNEXT-3386 are merged.

wiper RESOLVED in r65918

s.paskevics CLOSED.

Server & frontend ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-936-2

(8) [F] Improved translation strings in r66148.

s.paskevics CLOSED.

PHP side successfully tested. oleg.egorov, please close (1), (8) and (10) before a merge.

(9) [I] data.tmpl must be updated to change execute_on to ZBX_SCRIPT_EXECUTE_ON_PROXY for default global scripts

wiper CLOSED

(10) [A] Open question:

What should be set for execute_on field for IPMI, SSH and Telnet commands?

wiper I'd vote for either agent or proxy. It shouldn't be server, as we are not executing it on server. Currently it seems to be agent (might be just the default database value).

sasha API sets execute_on to 0, ZBX_SCRIPT_EXECUTE_ON_AGENT for these types of commands

CLOSED

(11) [S] Custom script is executed on a proxy, but it was created for the server.
These is need to add additional check -

ZBX_SCRIPT_EXECUTE_ON_SERVER == script.execute_on

in execute_commands:

if (0 == host.proxy_hostid)
  rc = zbx_script_execute(&script, &host, NULL, error, sizeof(error));
else
  rc = zbx_script_create_task(&script, &host, alertid, time(NULL));

wiper RESOLVED in r66440

s.paskevics CLOSED.

(12) [S] Typo in table name tasks, correct table name is task and udpate -> update
in taskmanager.c:

DBexecute("udpate tasks set status=%d where taskid=" ZBX_FS_UI64, ZBX_TM_STATUS_DONE, taskid);

wiper RESOLVED in r66442.

s.paskevics CLOSED.

(13) [S] There is a function zbx_tm_update_task_status to update the status of tasks, but sometimes we try to update directly via SQL query.

wiper zbx_tm_update_task_status function works with task batches, while direct sql updates are used when single task status is updated. I'd leave it as it is.

s.paskevics WON'T FIX.

(14) [S] Proxy can crash in tm_execute_remote_command function if it try to execute expired command or command with unknown hostid. It is necessary to exclude the situation when it is possible to commit without begin statement.

wiper RESOLVED in r66444

s.paskevics CLOSED.

(15) [S] I don't see the point of requesting a new task.id from different places, let it doing one place in zbx_tm_save_task function. I mean about DBget_maxid("task") function call.

wiper In zbx_script_create_task() the taskid is requested before calling zbx_tm_save_task to set corret parent_taskid.

s.paskevics WON'T FIX.

(16) [S] Many switch statements don't have a default cases.
For example:

		switch (task->type)
		{
			case ZBX_TM_TASK_REMOTE_COMMAND:
				task->data = tm_json_deserialize_remote_command(&jp_task);
				break;
			case ZBX_TM_TASK_REMOTE_COMMAND_RESULT:
				task->data = tm_json_deserialize_remote_command_result(&jp_task);
				break;
		}

I propose to add following default cases:

		default:
			THIS_SHOULD_NEVER_HAPPEN;
                        ret = FAIL;

wiper RESOLVED in r66446

s.paskevics CLOSED.

(17) [S] Incorrect using of the parent_taskid variable in tm_execute_remote_command function. First you need to get the ID from the database and after calling the zbx_tm_remote_command_result_create function.

wiper RESOLVED in r66447

s.paskevics CLOSED.

(18) [S] Unused macros:

#define ZBX_PROTO_VALUE_TASK_DATA		"task data"

wiper RESOLVED in r66448

s.paskevics CLOSED.

(19) [S] Why the task_remote_command_result.info column is empty if the remote command is executed successfully? Column name is info, but not a error.

wiper Currently only error message is returned. In future, when global script execution on proxies will be supported by frontend, the info field will contain the script execution output and it will be displayed in frontend.

s.paskevics WON'T FIX.

(20) [S] The server/proxy doesn't delete/update the record from task table after the proxy/agent successfully executed the script and returned the response. This record remains in ZBX_TM_STATUS_INPROGRESS status and it will be deleted only by ttl. I think this is incorrect.

s.paskevics I could not repeat this case. WON'T FIX.

(21) [I] The upgrade procedure doesn't update the old tasks and in the new version it will be with ZBX_TM_TASK_UNDEFINED type.

wiper RESOLVED in r66456

s.paskevics CLOSED.

(22) Support for remote command execution on proxies was added to frontend global script execution.

RESOLVED in r66464

s.paskevics CLOSED.

(23) [S] Function tm_process_tasks (server side) always returns 0.
This:

return 0;

replace with:

return processed_num;

RESOLVED in r66542.

sasha double initialization of tasks_num

1. src/zabbix_server/taskmanager/taskmanager.c:334

   int             tasks_num = 0, ...

2. src/zabbix_server/taskmanager/taskmanager.c:363

   tasks_num = tm_process_tasks((int)sec1);

REOPENED

s.paskevics RESOLVED in r66585.

sasha CLOSED

(24) [S] It would be nice if the process_tasks_contents function could return an error for process_proxy_data.

RESOLVED in r66545.

sasha please remove all these changes and make zbx_tm_save_tasks function with void result

REOPENED

s.paskevics RESOLVED in r66586.

sasha CLOSED with minor fix in r66593

(25) [I] Provide the correct default value for field scripts.execute_on, it should be 2 (ZBX_SCRIPT_EXECUTE_ON_PROXY)

RESOLVED in r66551, r66557.

sasha Have a look at my changes in r66570 and r66576. Still RESOLVED.

s.paskevics CLOSED.

(26) [S] Compilation warnings:

datasender.c: In function ‘proxy_data_sender’:
datasender.c:189:9: warning: ‘areg_records’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return history_records + discovery_records + areg_records;
         ^
datasender.c:189:25: warning: ‘discovery_records’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return history_records + discovery_records + areg_records;
                         ^
datasender.c:189:25: warning: ‘history_records’ may be used uninitialized in this function [-Wmaybe-uninitialized]

escalator.c: In function ‘execute_commands’:
escalator.c:773:22: warning: ‘status’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   zbx_alert_status_t status;
                      ^

../../../include/log.h:58:38: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 # define zabbix_log(level, fmt, ...) __zbx_zabbix_log(level, ZBX_CONST_STRING(fmt), ##__VA_ARGS__)
                                      ^
task.c:416:7: note: ‘ret’ was declared here
  int  ret;
       ^

task.c: In function ‘zbx_tm_save_tasks’:
task.c:385:25: warning: ‘taskid’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    task->taskid = taskid++;

RESOLVED in r66548.

sasha CLOSED with minor fix in r66583

Please review my minor changes r66527.

sasha Thanks! CLOSED

(27) [S] Server crash:

 11722:20170320:142239.409 12: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](print_fatal_info+0xbd) [0x47e60d]
 11722:20170320:142239.409 11: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations]() [0x47e8ce]
 11722:20170320:142239.409 10: /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f9233dcd4b0]
 11722:20170320:142239.409 9: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](zbx_strlcpy+0xd) [0x48ffcd]
 11722:20170320:142239.409 8: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations]() [0x43d682]
 11722:20170320:142239.409 7: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations]() [0x43ed04]
 11722:20170320:142239.409 6: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](escalator_thread+0x190) [0x43f260]
 11722:20170320:142239.409 5: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](zbx_thread_start+0x45) [0x4873f5]
 11722:20170320:142239.409 4: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](MAIN_ZABBIX_ENTRY+0x5fa) [0x41d36a]
 11722:20170320:142239.409 3: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](daemon_start+0x1c3) [0x47de93]
 11722:20170320:142239.409 2: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](main+0x3b4) [0x415a54]
 11722:20170320:142239.409 1: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f9233db8830]
 11722:20170320:142239.409 0: /zabbix/sbin/zabbix_server: escalator #1 [processed 0 escalations in 0.000000 sec, processing escalations](_start+0x29) [0x415d29]
 11722:20170320:142239.409 === Memory map: ===
 11722:20170320:142239.409 00400000-00591000 r-xp 00000000 08:01 13238319                           /zabbix/sbin/zabbix_server
 11722:20170320:142239.409 00790000-00791000 r--p 00190000 08:01 13238319                           /zabbix/sbin/zabbix_server
 11722:20170320:142239.409 00791000-00798000 rw-p 00191000 08:01 13238319                           /zabbix/sbin/zabbix_server

RESOLVED in r66540.

sasha CLOSED

Implemented in 3.4.0alpha1 (trunk) r66618.

(29) [D] martins-v please proceed with documentation.

martins-v Updated documentation:

• What's new
• Action operations (changed description of 'Execute on')
• Global scripts (changed screenshot and description of 'Execute on')
• Remote commands (the note about remote commands not supported through proxy removed)

Please review. RESOLVED

s.paskevics Looks good. CLOSED.

(30) [D] Documented in:

Template changes - https://www.zabbix.com/documentation/3.4/manual/installation/template_changes#template_changes_in_340
Zabbix Templates/Official Templates - http://zabbix.org/wiki/Zabbix_Templates/Official_Templates
API - https://www.zabbix.com/documentation/3.4/manual/api/reference/script/object

palivoda Continues in ZBX-12018. CLOSED

(31) [T] Add new templates to http://zabbix.org/wiki/Zabbix_Templates/Official_Templates

s.paskevics RESOLVED.

wiper We shouldn't publish template changes for unreleased versions.

wiper CLOSED

wiper Still it might be good to post the changed templates or at least placeholders - to not forget it later. In that case proxy template also must be added.
REOPENED

s.paskevics moved to ZBX-12018. CLOSED

(32) [S] task_remote_command_result.status field must not store negative values. REOPENED

RESOLVED in r66758.

wiper There is no need for database patch to change the remote command result status.
REOPENED

s.paskevics RESOLVED in r66873.

wiper CLOSED

(33) [D] Server-Proxy protocol changes must be documented in https://www.zabbix.com/documentation/3.4/manual/appendix/protocols/server_proxy

s.paskevics Documented in:
https://www.zabbix.com/documentation/3.4/manual/appendix/protocols/server_proxy
https://www.zabbix.org/wiki/Docs/protocols
RESOLVED

wiper The correct tag for task data is 'tasks'. The decribed tasks content is remote command data, which is sent from server to proxy in the response to 'proxy data' request. The tasks content sent from proxy to server is remote command result.
REOPENED

s.paskevics RESOLVED.

wiper The protocol description looks good, I updated the protocol 'changelog' at https://www.zabbix.org/wiki/Docs/protocols, please review.

s.paskevics Looks good. CLOSED

regarding (29), i'd suggest to put all the changed templates up now - that way, when 3.4 release is close, there is no need to remember which templates updated, how exactly, then scramble to document/upload them. similar how db patches and documentation are written alongside the development