Updating System Tables to Describe Your Application

Two system tables describe your application:

Edit the your-package-name.xml file in sandbox/src/lib/ddl/feature to update the tables. The following is a sample description for the <daemon-table> and <require-table> tags:

<sdk-bundle>
  <daemon-table>
    <default-package>sync-monitube-mgmt</default-package>

    <daemon-entry>
      <name>monitube-mgmt</name>
      <ui-name>sync-monitube-mgmt-service</ui-name>
      <binary>INSTALLDIR/sbin/monitube-mgmt</binary>
      <description>SDK Your Net Corp. Monitube Example IPTV Monitoring management process</description>
      <system-process-failover acceptable="exclude"/>
      <optional/>
      <checkconf/>
      <mode-protocol-master/>
      <run-if-configured/>
      <noversion/>
    </daemon-entry>

  </daemon-table>

  <require-table>

    <require-entry>
      <name>sync-monitube</name>
      <help>SDK Your Net Co. Sample for Monitube configuration</help>
      <configure/>
      <view/>
    </require-entry>
    
  </require-table>

</sdk-bundle>

Daemon Table XML Tags

The XML tags you use to describe your application are as follows.

<daemon-table/>
Root tag enclosing all daemon entries for a package.

<default-package/>
The package to use if a daemon-entry does not supply one. This is useful for reducing the number of entries in a daemon.xml file. Each daemon-entry can still supply a package name using package.

<default-binary-path/>
Path prefix for any daemon-entry that does not supply a binary tag. This tag is not used for RE SDK processes; instead, these processes use the binary tag.

Note:
You must append a slash (/) at the end of the path.
For example:

   <daemon-table>
      <default-binary-path>/usr/sbin/</default-binary-path>
      
      <daemon-entry>
        <name>myapp</name>
      </daemon-entry>
    </daemon-table>

The system generates a dc_binary value using default-binary-path and the name. The entry for dc_binary in the example just given thus becomes /usr/sbin/myapp.

<daemon-entry/>
Tag to begin a daemon entry.

 <init-args/>

Specifies that command-line arguments will be provided. For example:

<init-args>-U -M -p 10 -i 10</init-args>. 

<name/>
Name of the daemon; this should be the binary name without the path. For example:

 <name>myapp</name>

<description/>
Description of the daemon, for the help string.

Note:
In the Requirements table, this function is provided by the help tag.
<ui-name/>
User-viewable name for display in the UI. For example: <ui-name>custom-routing-process</ui-name>.

<package/>
Package to which this daemon belongs.

<pid-name/>
Name used to generated the process ID filename. Normally, this can be left out because the system uses the value of the name tag to generate the pid filename. This tag is used for those daemons that have pid names different from the binary name; for example, syslogd has a pid filename of /var/run/syslog.pid (note the missing d)

<binary/>
The path to the daemon binary, starting from INSTALLDIR. For example: INSTALLDIR/sbin/monitube-mgmt.

<optional/>
The daemon is optional. The system generates no error if the daemon is not found.

<checkconf/>
The daemon should be executed to check the configuration during commit; that is, it performs a commit check.

<noversion/>
The daemon should not be queried for version information. It does not handle the -v, -vv, or -X flags.

<noxml/>
The daemon cannot handle the -X flag.

<nohup/>
The system should not send a SIGHUP to the daemon on a commit full. Daemons use SIGHUP as a signal to reread configuration files or to reinitialize. In JUNOS, a commit full operation causes the system to reread the entire configuration file, as opposed to a regular commit operation, which causes the system to read only the changed part of the configuration.

<run-if-configured/>
The daemon will run only if configured.

<mode-protocol-master/>
The daemon runs on the protocol master Routing Engine of a dual Routing Engine system.

<mode-protocol-backup/>
The daemon runs on the protocol backup Routing Engine of a dual Routing Engine system.

<mode-all-master/>
The daemon runs on all master Routing Engines of a multiple Routing Engine system.

<mode-all-backup/>
The daemon runs on all backup Routing Engines of a multiple Routing Engine system.

Requirements Table XML Tags

The following XML tags create a new permission bit called ifinfo that allows users to view and change the configuration:

<require-entry>
      <name>ifinfo</name>
      <help>Interface info configuration</help>
      <configure/>
      <view/>
    </require-entry>

The view tag provides read permission for a configuration class; the configure tag provides write permission.

The ifinfo permission appears in the user interface as a possible value for the permissions parameter. For example, a user could enter:

#set class class-name permissions ifinfo

XML Tags for Display

Some tags to control display of daemon names in the UI are:

<restart acceptable="{exclude|hidden}"/>
By default, the daemons in the daemon table are visible in the restart daemon command. To hide the command, add <restart acceptable="hidden"/> to the daemon entry. To exclude the daemon from the restart command, enter restart acceptable="exclude"/>.

<system-process acceptable="{exclude|hidden}"/>
By default, the daemons in the daemon table are visible in the system processes ui-name tag value hierarchy. To hide this configuration, add system-process acceptable="hidden"/> to the daemon entry. To exclude it, use <system-process acceptable="exclude"/>

<system-process-failover acceptable="{exclude|hidden}"/>
By default, the daemons in the daemon table are visible in the system processes ui-name tag value failover hierarchy. To hide this configuration, add <system-process-failover acceptable="hidden"/> to the daemon entry. To exclude it, use <system-process-failover acceptable="exclude"/>.

<product>daemon-product</product>
Use this tag to limit the display of your daemon to a product or collection of products.

Product strings can be collected in a #define for reuse in the XML file. For example:

#define J_SERIES_EXCLUDE j2300 j4300 j6300 j4350 j6350

<product>J_SERIES_EXCLUDE</product>

Return to Build and Packaging Procedure


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5