maintenance:releases:7.0.3_20171214
LDAP: couldn't connect to LDAP server
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
maintenance:releases:7.0.3_20171214 [2019/07/16 13:33] – ↷ Links adapted because of a move operation jbosch | maintenance:releases:7.0.3_20171214 [2019/12/23 16:13] (current) – ↷ Links adapted because of a move operation yspeerte | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
+ | ===== NetYCE 7.0.3 Build_20171214 ===== | ||
+ | ===== Release notes ===== | ||
+ | Date: 2017-12-14 | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Enhancement ==== | ||
+ | </ | ||
+ | |||
+ | === Management-ethernet port-class === | ||
+ | <WRAP indent> | ||
+ | A new port-class ' | ||
+ | dedicated Gigabit-ethernet interfaces that some vendors integrated on the main board | ||
+ | to support out-of-band management over Ethernet. | ||
+ | |||
+ | The class was added in generic format although the actual models were added only for | ||
+ | the HP-C7 and Huawei vendor-types at this stage. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Active Directory === | ||
+ | <WRAP indent> | ||
+ | NetYCE can connect with Active Directory over LDAP for authentication purposes. The user-group | ||
+ | can be retrieved using a basic attribute-based LDAP schemas. | ||
+ | |||
+ | This functionality has been extended to support more complex schemas where user objects | ||
+ | contain ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | === LDAP user attributes === | ||
+ | <WRAP indent> | ||
+ | For users logging in using LDAP authentication User records are created. These records | ||
+ | can now be enriched with information from the LDAP user. Five NetYCE User attributes can | ||
+ | be mapped to LDAP account attributes using the NetYCE Ldap setup records defined | ||
+ | in the ' | ||
+ | These new user attributes belong to the ' | ||
+ | are optional. The following attribute names can now be added: | ||
+ | * ' | ||
+ | * ' | ||
+ | * ' | ||
+ | * ' | ||
+ | * ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | === NCCM archives === | ||
+ | <WRAP indent> | ||
+ | The NetYCE database NCCM was split from the YCE database in version 7.0.1. The NCCM archiving | ||
+ | tool allowed the manual creation of an NCCM archive set, but was not created daily. | ||
+ | |||
+ | Automatic daily archives of both YCE and NCCM are now standard and takes place at 23:00 or | ||
+ | 23:20 (primary or secondary server) by default. | ||
+ | |||
+ | The maximum number of archives for each type are now also controlled using Tweaks in the Lookup | ||
+ | form. The ' | ||
+ | that are maintained. Likewise the ' | ||
+ | Both use defaults of ' | ||
+ | |||
+ | All archives of each type count against these values, regardless if they were created manually, | ||
+ | uploaded, or created automatically. The only archives NOT counted (and therefore not deleted) are | ||
+ | uploaded archives where the filename was modified. | ||
+ | |||
+ | The deletion of excess archives takes place after each archive creation, regardless of type. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Service-types ' | ||
+ | <WRAP indent> | ||
+ | Service-types support for locating a service has been extended to locate the service | ||
+ | in a client-alias or a service-alias. The match criteria for the service include | ||
+ | Service-type, | ||
+ | |||
+ | With the addition of these six new syntaxes, there are now 19 different options to locate | ||
+ | a service. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Templates for vendor-type ' | ||
+ | <WRAP indent> | ||
+ | Port-templates and Sub-templates can be defined for a specific vendor-type, | ||
+ | for //all// vendors using the vendor ' | ||
+ | template for a device, the template matching the devices vendor-type will have | ||
+ | precedence over the ' | ||
+ | Bit it also allows to use default templates that can be overruled when a vendor-specific | ||
+ | version is created. | ||
+ | |||
+ | The ' | ||
+ | purposes the 'View config' | ||
+ | In this case the precedence order becomes: | ||
+ | 1) vendor-planned 2) ' | ||
+ | |||
+ | The ' | ||
+ | for configuration generation until now. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Custom subnets using Service-types === | ||
+ | <WRAP indent> | ||
+ | When adding new CUSTOM subnets to a service using a service-type, | ||
+ | the Net_name provided. The Net_addess, Net_size and Net_mask needed all be specified using | ||
+ | additional service-type commands, one for each attribute. | ||
+ | |||
+ | A simplification has been provided where the Net_address can include the Net_prefix using the | ||
+ | notation "< | ||
+ | |||
+ | If the service-type is intended to be used over the API, this same format can be used by | ||
+ | the Add-Subnet-Custom command by using a custom variable. If you add the ' | ||
+ | in the API call using the < | ||
+ | attributes derived from this value. In addition, the Add-Subnet-Custom also supports the API | ||
+ | ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Synchronization repair === | ||
+ | <WRAP indent> | ||
+ | When using redundant NetYCE databases in a master-master configuration, | ||
+ | are kept in synchronization using a sophisticated replication mechanism. This mechanism | ||
+ | involves temporary replication log files and a pointer administration on each server. | ||
+ | |||
+ | This mechanism can fail in two distinct cases. The first is where the servers' | ||
+ | system runs out of space to host the growing replication logs. The second is where one of | ||
+ | the database table files gets corrupted. Observed cases of table corruption always involved | ||
+ | heavy usage where a great number of records were added and removed. The corruption is then | ||
+ | created during a daily cleanup where the table fragmentation causes the datafile to be | ||
+ | rebuilt. During this process, any filesystem issue will cause a corrupt file. Usually buy | ||
+ | repeating the process the corruption is auto-repaired - if disk space suffices. This leads | ||
+ | to the conclusion that insufficient free space can cause severe database problems. | ||
+ | |||
+ | Once these problems manifest - database synchronization failure - two options are available. | ||
+ | For situations where one server can be identified as having a healthy and complete ' | ||
+ | the standard synchronization procedure using the double archive can be used. | ||
+ | |||
+ | The other situation where the databases really need to be repaired and records must be merged, | ||
+ | only a manual recovery procedure is available. This procedure is to be executed by a NetYCE | ||
+ | application manager. NetYCE incorporated a database recovery tool for this purpose some time ago | ||
+ | (ck_dbsync.pl), | ||
+ | in an extensive and flexible procedure. The procedure can be found on the NetYCE Wiki: | ||
+ | [[guides: | ||
+ | |||
+ | A more general description of the database replication is given in: | ||
+ | [[guides: | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Browser cache === | ||
+ | <WRAP indent> | ||
+ | With the release of YCE 6.3 we adopted the ' | ||
+ | of the various browsers. This is a method where the webserver and the browser use an application | ||
+ | specific configuration file on what files and under what circumstances the webserver and the browser | ||
+ | may cache files. At the time, the ' | ||
+ | |||
+ | Unfortunately, | ||
+ | the ' | ||
+ | update of NetYCE, many users were forced to manually clear their browsers cache. An option that was | ||
+ | also increasingly hard to locate. | ||
+ | |||
+ | To alleviate this problem we decided to continue the appcache support, but revert back to the old-and-trusted | ||
+ | method of including versioning information in the URL's requiring it. This method provides the developers | ||
+ | a means to specify which files must be replaced in the browser cache on a version or patch update. | ||
+ | It is a crude but effective solution to an issue that often caused irritation by the users. | ||
+ | |||
+ | We added into this method an additional mechanism that forces a cache refresh for users that were | ||
+ | actively using the system during the NetYCE software update. From the moment a new version | ||
+ | installation is completed, the very next action the user completes will result in a page reload | ||
+ | (and partial cache refresh). All the user will notice is that he is ' | ||
+ | the main Build form. | ||
+ | |||
+ | For users that have bookmarked the old NetYCE login page, a popup is displayed to inform the user | ||
+ | that he will be redirected to the new login page and his bookmark needs updating. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === GUI support for tweak ' | ||
+ | <WRAP indent> | ||
+ | The recently added tweak ' | ||
+ | has now been extended to include the NetYCE GUI. With the tweak enabled for the Client-type at | ||
+ | hand, multiple topology links per port can now be created. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Node_type substitutions === | ||
+ | <WRAP indent> | ||
+ | When defining a Node_Type, a number of records require entries that will be assigned to any | ||
+ | new node using that node-type. These values can be literal text or the output of a function. | ||
+ | |||
+ | To simplify and expand the flexibility of these value assignments, | ||
+ | related to the new node can now directly be used in the value using the same notation as the | ||
+ | variables in the templates. The variables in pointy brackets ('< | ||
+ | values available at that point in the node definition. | ||
+ | |||
+ | Where previously about 10 variables could be used in this fashion from within functions, now | ||
+ | all Client, Site, Region, Service and Domain variables including any custom attributes can | ||
+ | be used directly. Previously the' function' | ||
+ | variables, now the string can be typed as a ' | ||
+ | The existing Node_types will function as usual. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Service-type: | ||
+ | <WRAP indent> | ||
+ | To deal with designs that stipulate that individual addresses from a subnet range need to be | ||
+ | assigned from last through first rather than first through last, the service-type | ||
+ | ' | ||
+ | ' | ||
+ | |||
+ | Likewise the service-type ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | === API authentication === | ||
+ | <WRAP indent> | ||
+ | The NetYCE API authenticates each request using a username and password. That password may be provided | ||
+ | in three formats: in cleartext, in MD5 hash and in encrypted format. The detection of the format | ||
+ | is automatic. | ||
+ | |||
+ | When LDAP or AD is used for user authentication the user password was validated once against the LDAP | ||
+ | server and then thrown away. This setup posed a challenge when using the API as there was no means | ||
+ | to authenticate the user at that stage. | ||
+ | |||
+ | To resolve this issue, the LDAP password design is modified in such a way that the LDAP passwords | ||
+ | are maintained in the NetYCE user administration along with the local passwords. This enables | ||
+ | the API to validate the request authentication locally (not checking with LDAP for every request). | ||
+ | |||
+ | There are two consequences of this arrangement. First is that when authenticating against LDAP, the | ||
+ | user's local (and API) password will be updated to the password used by LDAP. User accounts that are | ||
+ | setup to be ' | ||
+ | their LDAP account too. Secondly, LDAP users must have logged in at least once to the NetYCE | ||
+ | front-end using their (new) LDAP password before submitting API requests. The LDAP password gets | ||
+ | only included in the administration using the front-end login procedure. | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Change ==== | ||
+ | </ | ||
+ | |||
+ | === Database Synchronization === | ||
+ | <WRAP indent> | ||
+ | For NetYCE database servers using the master/ | ||
+ | in the master-slave setup has been incorporated that is more reliable. Instead of | ||
+ | filtering updates at the master to be sent to the slave, now the master sends all | ||
+ | actions and the slave determines which tables to replicate. | ||
+ | |||
+ | This replication change MUST be executed with minimal delay between both NetYCE | ||
+ | database servers to permit the synchronization to continue. | ||
+ | |||
+ | This change will also include replication updates to its (new) NCCM database and | ||
+ | the (future) CMDB database. Any existing NCCM database must be restored at both | ||
+ | servers to start synchronization. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Domain password lengths === | ||
+ | <WRAP indent> | ||
+ | Passwords maintained in the Domain table are by default encrypted. This encryption requires | ||
+ | more storage space than unencrypted entries. The Domain table used column widths of 100 | ||
+ | characters to allow for these longer values. | ||
+ | |||
+ | However, when storing password values in a format that is not clear-text but uses device-specific | ||
+ | encoding or encryption, the required storage space of the database-encrypted string exceeds | ||
+ | in some cases these 100 characters. | ||
+ | |||
+ | For this reason, the storage space for passwords in the domain table has been extended | ||
+ | to 200 characters. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Maximum Password length === | ||
+ | <WRAP indent> | ||
+ | The maximum user-password length has been increased from 20 to 50. This is to facilitate | ||
+ | users wishing to use password phrases. Longer passwords will be ignored at login time. | ||
+ | |||
+ | These 50 characters is the absolute maximum allowed by the system, the administrator | ||
+ | can reduce the maximum length by updating the Lookup entry for ' | ||
+ | class. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Scenario Db_update command === | ||
+ | <WRAP indent> | ||
+ | The scenarios have a command available to change a value in the database, Db_update. This | ||
+ | command was redefined for version 7 so that it could change multiple variables in the same | ||
+ | database table. The original could set only one variable. | ||
+ | |||
+ | To support multiple variables the Db_update command options were changed where the '-f " | ||
+ | and '-v " | ||
+ | This change required existing scenarios te be modified which was not obvious to many users. | ||
+ | |||
+ | A modification to the Db_update command has been made by which the new ' | ||
+ | original ' | ||
+ | |||
+ | One point of attention remains for existing scenario users: Option attribute values need | ||
+ | to be enclosed in quotes when spaces are included. They are essential in much more formal | ||
+ | scenario parsing of version 7 needs it.needs it. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Custom Data Grid === | ||
+ | <WRAP indent> | ||
+ | The custom data grids now are twice as big, and the last entry is now fully visible. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Subnet assignment to Ports === | ||
+ | <WRAP indent> | ||
+ | When assigning subnets to interfaces using the front-end GUI or the service-types, | ||
+ | subnet' | ||
+ | to the interface. This selection depends on the subnet' | ||
+ | this interface may have. | ||
+ | |||
+ | Over time, various subnet-names have been hardcoded to be used for point-to-point or loopback | ||
+ | usage in the front-end but not for service-types. The resulting mappings gave inconsistent | ||
+ | results. | ||
+ | |||
+ | To rectify we changed the behaviour to that the assignment soley uses the subnet-plan details | ||
+ | and the topology. The subnet-plan has individual settings for ip-address calculation in three modes: | ||
+ | ' | ||
+ | Based on the presence of these settings in the subnet-plan the correct ip reference is now | ||
+ | determined for both front-end and back-end usage. | ||
+ | |||
+ | An accompanying NetYCE patch (17120601) will completely recreate the subnet-to-port | ||
+ | mapping in the database to make it consistent. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === System page === | ||
+ | <WRAP indent> | ||
+ | The 'Admin - System' | ||
+ | permissions. However, the 'Admin - System - Edit configs' | ||
+ | that are of interest to ' | ||
+ | |||
+ | To make this tool accessible, the ' | ||
+ | ' | ||
+ | to make changes. | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | \\ | ||
+ | <WRAP widths 60% box safety> | ||
+ | ==== Fix ==== | ||
+ | </ | ||
+ | |||
+ | === Infoblox export === | ||
+ | <WRAP indent> | ||
+ | The Infoblox exporter failed intermittently to export dns records for a set of specific dns zones. | ||
+ | The problem was introduced when the ' | ||
+ | Dns-views residing under each Network-view are then reported zone-by-zone. | ||
+ | |||
+ | As it turned out, the zones from one Dns-view had a ' | ||
+ | the ' | ||
+ | results of the forwarding zone would result in an empty dataset for the zone. | ||
+ | |||
+ | By skipping the ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Installation package === | ||
+ | <WRAP indent> | ||
+ | A recent enhancement was aimed at relauncing the various NetYCE daemons at the completion | ||
+ | of the update process, but before executing the update patches. | ||
+ | This ' | ||
+ | updating the system. | ||
+ | |||
+ | As a result, the update progess indicator (issuing a growing list of ' | ||
+ | returing the update log to the user. In the background the update process still completed the | ||
+ | operation, including the update patches. | ||
+ | |||
+ | The relaunching of the various daemons now skip the API causing the update to complete the | ||
+ | process properly. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Archive timeout === | ||
+ | <WRAP indent> | ||
+ | When executing database archives or restores of very large databases the users Browser would | ||
+ | timeout while waiting for the process to finish. When this happened the archive or restore | ||
+ | procedure would be aborted, usually leaving the database stopped or patches partially applied. | ||
+ | |||
+ | Now the user is informed every five seconds how much time has passed waiting for the current | ||
+ | operational step. This is both informative for the user, but it also keeps the Browser from | ||
+ | timing out and thus ensuring the operation will be completed. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === API Add-Supernet-Ip_plan === | ||
+ | <WRAP indent> | ||
+ | When adding a supernet to a client using a service-type (Add-Suppernet-Ip_plan), | ||
+ | action was aborted with "ERROR Failed ADD - SUPERNET - IP_PLAN: IP-plan ' | ||
+ | found for client_type ' | ||
+ | |||
+ | The problem was an error while resolving the available ip-plans for the client-type where | ||
+ | the client type was left blank. This was resolved by correctly referencing the client-type. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === OSS Integration parsing error === | ||
+ | <WRAP indent> | ||
+ | Using an array of datasets with various network-footprints, | ||
+ | produced unexpected results. The problem was caused by referencing the various network-footprints in | ||
+ | random order. Each dataset is processed in sequence, each time loading the appropriate configuration | ||
+ | file for the footprint. | ||
+ | |||
+ | However, when the same footprint was again referenced for another dataset, the system would | ||
+ | ignore the config-file load, assuming it was already loaded. The result was that the dataset | ||
+ | would be processed and validated using the last original configuration file. In a random | ||
+ | ordered dataset that would lead to erroneous results. | ||
+ | |||
+ | The issue was resolved by maintaining all configuration file loads internally, thus eliminating | ||
+ | the dependency on the repeat usage of the same configuration file (and associated procedures). | ||
+ | |||
+ | </ | ||
+ | |||
+ | === IP Plan Create === | ||
+ | <WRAP indent> | ||
+ | Fixed a bug where you could not create an ip plan after deleting it. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Subnet VRF === | ||
+ | <WRAP indent> | ||
+ | You can now set IP Subnet VRFs to empty again. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Node deletion leftovers === | ||
+ | <WRAP indent> | ||
+ | When deleting a node, either manually or using a service_type, | ||
+ | not removed causing (harmless) clutter in the Ip_map table. This has now been fixed. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Non-existing Port subnet assignment === | ||
+ | <WRAP indent> | ||
+ | The topology form of any node would display at least one, incomplete, entry in the | ||
+ | port subnet list grid. Regardless if any subnet was assigned to the selected port, | ||
+ | one entry would always be listed. It proved that this phantom entry was due to an | ||
+ | imprecise sql query that feeds this grid. This has now been optimised. | ||
+ | |||
+ | If incomplete entries are now listed in the grid, these actually represent incomplete | ||
+ | subnet references. By selecting the checkbox " | ||
+ | filtered out as well. | ||
+ | </ | ||
+ | |||
+ | === Custom Data === | ||
+ | <WRAP indent> | ||
+ | Custom Data views now all have pagination. You can search and your search will be on the entire dataset. Sorting only works on the current page. | ||
+ | All IPv6 fields are hidden now, since viewing and editing them falls beyond the scope of what Custom Data was meant to be. | ||
+ | </ | ||
+ | |||
+ | === Node bootimage reset === | ||
+ | <WRAP indent> | ||
+ | Resetting the boot loader in the node edit form also updates its value in its form. | ||
+ | </ | ||
+ | |||
+ | === Node Redundant === | ||
+ | <WRAP indent> | ||
+ | The node edit form now correctly displays if a node is redundant. | ||
+ | </ | ||
+ | |||
+ | === Menu buttons === | ||
+ | <WRAP indent> | ||
+ | Some menu items only were selectable if you clicked on their text, rather than their menu item. They now respond to the whole menu button. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Subnet Topology not set === | ||
+ | <WRAP indent> | ||
+ | When assigning a subnet to an interface using the front-end, the topology position of that | ||
+ | interface in the subnet would be set to ' | ||
+ | This behaviour is corrected. Previous incorrect assignments are corrected using a patch. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Switchport config wrong node === | ||
+ | <WRAP indent> | ||
+ | The issue where the switchportdetails form showed the different node when you open the form through the services window is now fixed. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Node redundant fixed === | ||
+ | <WRAP indent> | ||
+ | The issue where the Redundant option for a node got saved as NULL has been fixed. Also includes a patch that changes all NULL-entries in the database back to 0. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Node Class Notes === | ||
+ | <WRAP indent> | ||
+ | Fixed the issue where you get prompted repeatedly when switching editing node classes without saving. | ||
+ | </ | ||
+ | |||
+ | === IPv4 Subnet Forms === | ||
+ | <WRAP indent> | ||
+ | Fixed an issue where vlan templates were missing when creating IPv4 subnets, and the correct values not updating. | ||
+ | </ | ||
+ | |||
+ | === Custom attributes group sorting === | ||
+ | <WRAP indent> | ||
+ | Fixed a bug where the grouping sort suggestions for the custom attributes form displayed the wrong possible values. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Changing Job statuses === | ||
+ | <WRAP indent> | ||
+ | With the introduction of version 7.0.2 a periodic check was introduced to detect | ||
+ | Jobs that were reported ' | ||
+ | crashes. These job states would then be modified to ' | ||
+ | |||
+ | However, the implementation examined the ' | ||
+ | compared the existance of the job only to the local server. As a consequence, | ||
+ | server would conclude the job failed while it was still running on another server. | ||
+ | The user would then observe that the running job would change into an aborted one which | ||
+ | could then change into a successful state when it finished. | ||
+ | |||
+ | The job status monitoring is now confined to local jobs only. | ||
+ | </ | ||
+ | |||
+ | === Service type records === | ||
+ | <WRAP indent> | ||
+ | Creating a new service type record now immediately jumps to that record automatically, | ||
+ | </ | ||
+ | |||
+ | === Confirm window enter === | ||
+ | <WRAP indent> | ||
+ | A confirm window (the windows with a simple message, ok- and cancel-buttons) can now always be closed with enter. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Job log details === | ||
+ | <WRAP indent> | ||
+ | Job details of a remote server whould not be shown. The result window of a job on a different | ||
+ | than the local server would open, but no data was retrieved. This was corrected. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Vrf_id ' | ||
+ | <WRAP indent> | ||
+ | The Vrf_id column was defined in the various tables using different default values. | ||
+ | The Ip_subnet tables allowed Null entries were others use empty string ('' | ||
+ | and denied Nulls. | ||
+ | |||
+ | Since this was introduced in NetYCE version 7.0.0, it caused existing relationships to | ||
+ | fail their criteria. Now all Vrf_id references use the empty string as default and deny | ||
+ | Nulls. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Template variable typo's === | ||
+ | <WRAP indent> | ||
+ | When a variable used in templates and command jobs is not properly enclosed in | ||
+ | angled brackets ('<' | ||
+ | and the command-job evaluate tool would not detect it and show nothing or just | ||
+ | the name as plain-text. | ||
+ | |||
+ | The generated configuration will contain the literal string (the caret and variable name) | ||
+ | as is intended. To detect and highlight these (probably) unintentional typo' | ||
+ | above tools will now always display the variable name and show the unmatched caret in red. | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Cisco-IOS ' | ||
+ | <WRAP indent> | ||
+ | The Cisco-IOS error message concering ' | ||
+ | string is now added to the Cisco-IOS error message list. | ||
+ | |||
+ | </ | ||
+ | |||
maintenance/releases/7.0.3_20171214.txt · Last modified: 2019/12/23 16:13 by yspeerte