This post is more than 5 years old
3 Posts
0
1668
December 27th, 2010 14:00
Purpose of IP/smarts/local/conf/discovery/ip-tag-settings.conf
Does anyone know what is the purpose of IP/smarts/local/conf/discovery/ip-tag-settings.conf. I think its related to tagging but its not explained in any manuals. The entries in the file relates to what I see under "System IP Tag Groups" in Smarts console "Tagging" tab.
I tried commenting the whole file and restarted the AM, to see what changes I see in the console - nothing changed. Is there anyway to see the changes in this file(ip-tag-settings.conf).
I'm trying to setup IP-Tagging without using the smarts console.
Thanks
No Events found!
bkuhhirte
52 Posts
0
January 31st, 2011 12:00
There appears to be some general confusion around the use of the various *settings.conf files, when they are loaded, what they do, etc. so let me attempt to clarify.
In normal operations, when a domain is loaded for the first time, we load the configuration files from their sections of the directory tree when the domain is started with no RPS file or with an RPS file but with --norestore. Typically, we find that most users make changes to the various setting parameters and groups via the UI. As a result, the settings in the files and the ones in the server have become divergent. Loading them from the file could potentially overwrite good entries already stored in the server. After the domain has been started for the first time, we do not re-read from the various *setting.conf files.
That said, if you want to maintain via a file rather than through the UI, it can be done.
There is an operation which can be called through dmctl (or an equivalent one using sm_tpmgr) that will load the contents of a particular file:
dmctl> invoke ICF_PolicyManager::ICF-PolicyManager loadSettings full_path_to_file_name
The path may include $SM_SITEMOD or other known environmental variables, but the system expects a fully qualified name as the argument.
NOTE: This operation is intended to be additive - it will not remove stale entries that exist in the server and no longer exist in the file. The UI can clean those up (or even a smarter loader), but at the moment you just need to be careful.
Regards,
Bill
AdaDie
54 Posts
1
December 27th, 2010 23:00
Hi,
I made a short test and the config file is loaded if you start APM with a clean repository (no *.rps file). Guess thee is a command to load a changed configuration. As soon as I have any news I'll let you know.
Regards,
Ada
sudoer1
3 Posts
0
January 31st, 2011 12:00
Thanks for all the replies. Here is some more info that is not documented. The example only describes "match" and "setting". If you want to add more tag setting criteria like you do in GUI, use "param". For Ex:
param IPTag
param MgmtIPAddrOrRange x.x.x.x
param OverlappingIPAddrOrRange y.y.y.y
bkuhhirte
52 Posts
0
February 2nd, 2011 09:00
I realized after my post that the documentation on the syntax of the various *settings.conf files is a litte vague. Please don't treat this (yet) as a formal document, but I wanted to put together something quick that covered the basic syntax and order of entries. Hopefully, this will be generally helpful outside the context of this specific issue. I will post the full document somewhere in this forum when I finish it.
General notes:
The settings must be applied in a particular order to be successful, but can be applied across multiple files. A typical order would be:
Category
Config
Match (repeated)
Setting (repeated)
Param (optional)
Specific definitions for the groups as below.
Category:
::= category
::= polling
| threshold
| security
| tagging
| certification
defines the class name in the ICIM heirarchy that the setting in question should be applied to.
is a unique top-level grouping name for all of the various configuration groups and their matching criterias to be applied. It allows settings to be applied across the topology per top-level group as a bulk operation.
Config:
The "config" declaration block describes a unique name applied to a subgroup within the overall category and has direct relationships to the set of matching criteria to differentiate it from sibling config entries, an implied order of precedence, one or more settings that should be applied to the matching objects.
NOTE: This implied order of precedence is described in the order in which they are placed in the file (first in is the highest priority match). However, subsequent loads of the same file will append new entries to the end of the sequence. Changing the priority of the matching is *very* difficult to do via the files.
::= config
Setting:
The setting declaration block identifies the particular setting class that should be applied to the config group.
::= setting
Where describes the class of the setting to be applied.
Match:
The match block describes matching criteria for a given config block. The purpose is to differentiate sibling config blocks so different settings may be applied to different matching groups.
NOTE: The match lines for a given config are combined together into an implicit "and" logic.
::= match
The match_attribute must be an attribute defined in the of the category block. In many versions, the may not be an empty string. Implicit data type conversion will be done to convert from a string-esque representation of the value into the real data types (e.g. enum values, Booleans).
NOTE: The match logic uses a glob pattern match (not regular expressions), so please check the validity before using it.
Param:
This block describes the actual values to be applied to a particular setting declaration within the context of a specific config. The values represent any deviation from the default values of the setting itself.
::= param
The but be an writeable attribute of . The has the same data type conversion methods as and should be matched to the type of .