[ZBXNEXT-6368] Move SSH/Telnet/IPMI/Script operations to Global Scripts Created: 2020 Nov 26  Updated: 2024 Apr 10  Resolved: 2021 May 31

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: API (A), Frontend (F)
Affects Version/s: None
Fix Version/s: 5.4.0beta2, 5.4 (plan)

Type: Change Request Priority: Trivial
Reporter: Rostislav Palivoda Assignee: Ivo Kurzemnieks
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File image-2021-02-25-18-46-29-419.png     PNG File image-2021-03-08-11-34-21-312.png     PNG File image-2021-03-08-11-36-37-044.png     PNG File screenshot-1.png     PNG File screenshot-2.png     PNG File screenshot-3.png     PNG File screenshot-4.png     GIF File script_long_name.gif     GIF File script_page_long_name.gif     GIF File script_sorting.gif    
Issue Links:
Causes
Sub-task
depends on ZBXNEXT-6360 Support of JavaScript for global scripts Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
ZBXNEXT-6369 Server side changes to move SSH/Telne... Specification change (Sub-task) Closed Andris Mednis  
Team: Team B
Sprint: Sprint 70 (Nov 2020), Sprint 71 (Dec 2020), Sprint 72 (Jan 2021), Sprint 73 (Feb 2021), Sprint 74 (Mar 2021), Sprint 75 (Apr 2021), Sprint 76 (May 2021)
Story Points: 10

 Description   

Summary

Currently configuration of action operations is very confusing especially for execution of global scripts or scripts using SSH/Telnet connections: too many clicks, confusing naming. 

It can be made more secure and simplified very much by moving SSH/Telnet/IPMI/Script functionality entirely to global scripts.

Acceptance

  1. Global scripts must support execution of shell scripts using SSH/Telnet connectivity
    1. Two additional types will be supported: SSH and Telnet
  2. It must be possible to define where global script is available using new configuration options
    1. Scope: Action operation, Manual host action or Manual event action (one of must be selected)
      1. Action operations: script can be used for action operations
        1. Only scripts of this type are allowed to be used in action operations
        2. Examples of scripts using problem context: Clean /tmp filesystem
      2. Manual host action: menu entry will be visible in context host menu 
        1. Monitoring→Hosts: menu on host name
        2. Monitoring→Overview: menu on host name
        3. Monitoring→Latest data: menu on host name
        4. Monitoring→Maps: menu on host icon
        5. There could be other elements as well
        6. Examples of scripts using host context: Ping, Traceroute, Reboot
      3. Manual event action: menu entry will be visible in context event menu 
        1. Monitoring→Problems: menu on event name
        2. Problem widget in the Dashboard: menu on event name (same as in Monitoring->Problems)
          1. Existing mouse-over popup must be moved from event name to event duration
        3. There could be other elements as well
        4. Examples of scripts using problem context: Open new ticket
    2. Menu entry: menu entry (mandatory if Host menu or Event menu is selected), if specified then global script will be visible in context host or event menu
      1. Name of the global script will not be used for host menu anymore
  3. Script configuration form must be redesigned to make absolutely clear what fields are used for different selection of "Scope" field
    1. Fields used only for manual actions: Menu entry, User group, Required host permissions, Enable confirmation, Confirmation text
      1. Note that "Host group" is used for action operations as well
  4. The following macros must be supported for global scripts (including confirmation text)
    1. User macros
    2. {EVENT.ACK.STATUS}
    3. {EVENT.AGE}
    4. {EVENT.DATE}
    5. {EVENT.DURATION}
    6. {EVENT.ID}
    7. {EVENT.NAME}
    8. {EVENT.NSEVERITY}
    9. {EVENT.OBJECT}
    10. {EVENT.OPDATA}
    11. {EVENT.SEVERITY}
    12. {EVENT.SOURCE}
    13. {EVENT.STATUS}
    14. {EVENT.TAGS}
    15. {EVENT.TAGSJSON}
    16. {EVENT.TAGS.<tag name>}
    17. {EVENT.TIME}
    18. {EVENT.VALUE}
  5. Context menus
    1. Event context menu must contain section "SCRIPTS"
    2. No section must be displayed if it contains no entries
  6. Action operations must not support execution of IPMI, Custom scripts, SSH and Telnet commands anymore
    1. Configuration form of action operations will be simplified
      1. No Type, Commands, etc will be supported anymore
      2. Existing "Operation type" will be renamed to "Operation" and it will contain selection of "Send message" (first entry) and then sorted list of available global scripts
    2. Configuration of global scripts must be extended to contain SSH and Telnet related fields having same behaviour as currently supported for operations
  7. A database patch must be created
    1. Populate "Menu entry" by copying Name
    2. Move operations of type "Remote command" to global scripts
      1. New scripts with unique names will be created automatically

Use cases

  1. I want more secure action operations
  2. I want more straightforward configuration of action operations

Decisions made

  1. No support of test functionlity
    1. It will be implemented in the future as part of merging media types and scripts
  2. No ability to configure shell-scripts, IPMI commands, etc for action operations. Can be done for global script only.


 Comments   
Comment by Andris Mednis [ 2020 Dec 02 ]

Part of script migration from action operations to global scripts is generating unique names for migrated scripts.
Generated names will be shown to user in Zabbix frontend - they should be user friendly.

Here is a proposed algorithm for script name generation.
The generated names will be composed of up to 5 parts, separated by ' ' (space):

  • Part 1. Up to 4 words from script's commands 1st non-empty line, from 'opcommand' table 'command' column, but no more than 40 UTF-8 characters. The last character cannot be ';' (semicolon), ':' (colon), or opening braces '(', ' {' or '[' to avoid confusing opening/closing structure.
  • Part 2. Type of script: CUSTOM, IPMI, SSH or TELNET.
  • Part 3. (only for SSH scripts). Authentification type: PASSWORD or PUBLICKEY.
  • Part 4. (only for CUSTOM scripts). Execute on: AGENT, PROXY or SERVER.
  • Part 5. (only if needed) Suffix to achieve uniqueness. If the script name, composed of the parts 1 - 4 is not unique, then append suffix 2, 3, .. .

Most likely, all these generated names will have to be edited by user to reflect their true purpose. Capital letters in names, like CUSTOM, SSH, PUBLICKEY, will turn attention to them as artificially generated and invite renaming.

Examples of generated names:

   ping -c 3 {HOST.CONN} CUSTOM SERVER
   /usr/bin/traceroute {HOST.CONN} CUSTOM AGENT
   sudo /usr/bin/nmap -O {HOST.CONN} SSH PASSWORD

Comments are welcome. Can you propose a better generation of names? Or improve the proposed one?

andris : It was decided to use a simpler naming.

Comment by Ivo Kurzemnieks [ 2021 Feb 11 ]

Implemented in development branch feature/ZBXNEXT-6368-5.3-2

Comment by Andris Mednis [ 2021 Mar 19 ]

Available in versions:

Comment by Brian van Baekel [ 2021 Apr 03 ]

Hi!

I am a bit confused. I thought 5.4 was working towards a Zabbix that is ready for 'true multi tenancy' and 'all global things' will break that philosophy, thus therefor are bad.

Now, stuff is moved into the 'global' part of configuration. Is there a bigger picture / decisions somewhere that I am unaware of, or is this a strange move?

I LOVE the webhook part!

Comment by Alexei Vladishev [ 2021 Apr 06 ]

brian.baekel, it is also about security. Currently every admin is able to create an action that may execute any command on any host regardless of user permissions. Starting from Zabbix 5.4 we will manage all scripts in one place. Also note that the same script can be reused for automatic actions and manual operations from host- or problem context menus.

 

I think that now scripts are much easier to configure and use and also they may contain complex logic thanks to support of JavaScript. Instead of creating fake users for integration with Jira (for example) we can just create a script called "Open Jira ticket". Nice!

Comment by Ivo Kurzemnieks [ 2021 May 27 ]

Updated user documentation:

Updated API documentation:

Generated at Sun Mar 30 11:01:30 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.