Zimlet Lifecycle and the Zimlet Management Tool
|
You are looking at legacy Zimlet documentation. For Zimbra Modern UI Zimlet development go to: https://wiki.zimbra.com/wiki/DevelopersGuide#Zimlet_Development_Guide. |
Zimlet Lifecycle and the Zimlet Management Tool
This section describes the Zimlet lifecycle in conjunction with the Zimlet Management tool (zimlet) for managing this lifecycle.
zmzimletctl: [command] [ zimlet.zip | config.xml | zimlet ]
- deploy {zimlet.zip} - install, ldapDeploy, grant ACL
- on default COS, then enable zimlet
- undeploy {zimlet} - remove the zimlet entry from the system
- install {zimlet.zip} - installs the zimlet files on this host
- ldapDeploy {zimlet} - add the zimlet entry to the system
- enable {zimlet} - enables the zimlet
- disable {zimlet} - disables the zimlet
- acl {zimlet} {cos1} grant|deny [{cos2} grant|deny...] – change
- the ACL for the zimlet on a COS
- configure {zimlet} {config.xml} - installs the configuration
- listPriority - show the current Zimlet priorities (0 high, 9 low)
- setPriority {zimlet} {priority} - set Zimlet priority
Listing Zimlets
Lists all the Zimlets installed and deployed on the machine, in the LDAP, and enabled on COS.
zmzimletctl listZimlets
Output
Installed Zimlet files on this host:
- com_zimbra_phone
- com_zimbra_po
- com_zimbra_sforce
- com_zimbra_tracking
- com_zimbra_url
- com_zimbra_ymaps
Installed Zimlets in LDAP:
- com_zimbra_phone
- com_zimbra_po (disabled)
- com_zimbra_sforce
- com_zimbra_track
- com_zimbra_url
- com_zimbra_ymaps
Available Zimlets in COS:
- default:
- com_zimbra_po
- com_zimbra_sforce
- com_zimbra_tracking
- com_zimbra_url
- com_zimbra_ymaps
Deploying
This is when the Zimlet is first deployed to the ZCS system. Physically this means that a Zimlet may be deployment to a number of host machines running the ZCS. Deployment is the first step in the lifecycle process. The Zimlet may not be in a “runnable” state post deployment.
The command for deploying Zimlets is as follows:
zmzimletctl deploy <zimletname>.zip
where:
- <zimletname>.zip is the Zimlet bundle
Configuration
Zimlets may need additional site specific configuration before being ready to run. If such configuration is required, the template for it is provided in the config_template.xml file that is part of the Zimlet bundle. Zimlet configuration may include both global and per host properties. The Zimlet Management Tool provides the functionality for setting up Zimlet configuration.
The commands for configuring Zimlets are as follows:
zmzimletctl dumpConfigTemplate <zimletname>.zip
The above command will extract the config_template.xml configuration from the Zimlet bundle (if one exists). This file should then be edited for the specific site. For example given the following template:
<zimletConfig name=”com_acme_Maps” version=”1.0”>
<global>
<property name=”defaultToGoogle”></property>
</global>
<host name=””>
<property name=”googleapi”></property>
<property name=”geocodeuser”></property>
<property name=”geocodepass”></property>
</host>
</zimletConfig>
A site may create the folowing configuration file:
<zimletConfig name=”com_acme_Maps” version=”1.0”>
<global>
<property name=”defaultToGoogle”>true</property>
</global>
<host name=”mailserv1.acme.com”>
<property name=“googleapi”>uh8ieu54l5lv48h489uh</property>
<property name=“geocodeuser”>Zimbra</property>
<property name=“geocodepass”>674g7382a</property>
</host>
<host name=”mailserv2.acme.com”>
<property name=“googleapi”>uh7jsh8374uae9js76uh</property>
<property name=“geocodeuser”>Zimbra</property>
<property name=“geocodepass”>837hs7we8</property>
</host>
<host name=”mailserv3.acme.com”>
<property name=“googleapi”>uh8su8e9378sjdg739uh</property>
<property name=“geocodeuser”>Zimbra</property>
<property name=“geocodepass”>802shd837</property>
</host>
</zimletConfig>
Note that this file may be saved for later modification/distribution. The configuration for Zimlets is set via the following command
zimlet configure <configfile.xml>
where:
- configfile.xml is the modified template file
The above command will create the appropriate configuration for each host.
Access Control
By default, Zimlets are deployed such that no access is granted to any user to the Zimlet. Zimlet access control is specified on a Class of Service basis. Thus if a COS is granted access to a given Zimlet, then all members of that COS have access to that Zimlet. The following command permits specifying access control to a Zimlet:
zmzimletctl acl <zimletname> (<cosname> grant | deny])+
where:
- <cosname> is the COS to which access is to be granted or denied
- “grant” enables access to the Zimlet for the specified COS, and “deny” denies access
The command for listing Zimlet permission is as follows:
zimlet listacls <zimletname>
Priority
Zimlets have a priority. The lower the priority value, the higher priority the Zimlet is. Priority plays an important role for Zimlets that define content objects. Specifically, if there is conflict in the content objects specifications among two Zimlets, then the Zimlet with the higher priority will win. For example, consider a Zimlet that defines a content object representing a URL, and another Zimlet that defines a content object that represents a tracking number. Now assume that at runtime some content has embedded in it a URL that contains what coincidentally passes as a tracking number. If the priority of the Zimlet defining the URL is higher than the Zimlet defining the tracking number, then the “tracking number” that is embedded in the URL would never be highlighted (which may actually be desirable if it is a bogus number - and which emphasizes the point that it is preferable that content objects should be uniquely identifiable)
The following command permits specifying the priority of a Zimlet:
zmzimletctl priority <zimletname> <value>
Where
- <value> is the priority value with 0 being the highest priority.
If a Zimlet already exists with the specified priority, then the zimlet tool will inform the administrator and prompt him to confirm that he wants to set the priority of the Zimlet to the given value. If the administrator confirms this, then the Zimlet that previously held the requested priority will have its priority incremented (as will all Zimlets of lower priority). If the supplied value is more than one unit greater that the lowest priority Zimlet’s value (i.e. if assigning the priority will result in a “hole” in the priority list), then the next available priority will be assigned. If the priority value is omitted, then the next available lowest priority will be assigned to the Zimlet. By default, when a Zimlet is added to the system, it will assigned the next available lowest priority.
The command for listing Zimlet priorities is as follows:
zmzimletctl listpriority
Enabling
Once a Zimlet is configured, it must be enabled. Enabling a Zimlet makes it available to all users to whom access has been granted. The command for enabling a Zimlet is as follows:
zmzimletctl enable <zimletname>
Disabling
Disabling a Zimlet makes it unavailable to users. A Zimlet is usually disabled before updating and before undeploying.
zmzimletctl disable <zimletname>
Undeploying
At the end of its lifecycle (either because it is being retired or upgraded) a Zimlet is undeployed. The command for undeploying a Zimlet is as follows:
zmzimletctl undeploy <zimletname>
Where:
When a Zimlet is undeployed from all known hosts, all of its user property, configuration and access control information will be purged from the ZCS.
Getting Zimlet infomation
The command for getting zimlet information is as follows:
zmzimletctl info <zimletName>+ | all [-acl] [-status] [-vers] [-hosts] [-a]
Where:
- -acl will provide a list of all the COSs which have access to the Zimlet
- -status will indicated the enable/disable state of the Zimlet
- -vers will list the Zimlet’s version
- -hosts will list the hosts on which the zimlet is deployed
- -config will output the configuration information (global and per host)
- -a will output all of the above
