How the File Upload Servlet and Attachment Upload Servlet be de-activated in web.xml

The functionality for File Upload Servlet, as well as Attachment and Image Upload servlet does not match the table extensionstate, and it requires maintaining this list in addition to maintaining the extensionstate table.

The idea with the allowed extension is to provide additional protection using a so-called “white list”. From the web client, you can submit only attachments whose file types are in this whitelist.

The extensionstate on the other hand, is meant to manage the restrictions, so the “black list”. So actually the File, Image and Attachment Upload Servlet Parameters complement the protection of the table. At startup, the web tier and the Windows client retrieve the forbidden list, which is stored in the extensionstate table in the database; if no list is available, the clients use a default list of forbidden file types stored on the client side. With the new feature you can limit what can be submitted from web client, while you might allow other file types added from Windows client or web services, if they are not restricted in the extensionstate table.

The functionality cannot be disabled directly as there is no switch parameter provided. The fast way is to remove the whole xml label including “allowed” as follows
<init-param>
<param-name>allowed</param-name>
<param-value>bmp,jpg,jpeg,png,gif</param-value>
</init-param>

If this is done, the files with any file types not restricted in the extensionstate table will be allowed to upload, so disabling this functionality you take the risk.

Service Manager Web Tier: How to determine if the JAVA certificate is expired

How to check the JAVA certificate validation period for the Web Tier. A message about “Java Application Blocked” may appear on screen if the certificates are expired. The message may say “Application Blocked by Java Security”.

java

The certificate validation period can be checked using the following steps:

  1. Locate the SMWorkflow.jar file. For example, navigate to the <webtier webapps folder>\ext

cd <webtier webapps folder>\ext

  1. In a DOS command prompt, run command:

jarsigner -certs -verbose -verify SMWorkflow.jar > SMWorkflow.jar.certs.txt

“jarsigner” can be found in $JAVA_HOME\bin directory. the call could also look like:

“C:\Program Files\Java\jdk1.7.0_40\bin\jarsigner” -certs -verbose -verify SMWorkflow.jar > SMWorkflow.jar.certs.txt

NOTE: If the JRE is installed instead of the JDK, the “jarsigner” utility will likely not be available.

3.Open SMWorkflow.jar.certs.txt, check if there is [certificate is valid from xxx to xxx] or [certificate expired on 11/16/14 7:59 AM]

If the output indicates that the certificate is expired, it is necessary to locate and deploy a version of the Web Tier with a valid certificate to avoid the expired java certificate errors. If a version of the Web Tier with a valid certificate can’t be located on the HPE Software Support Site, please contact customer support for further assistance.

Only the first certificate duration is the one that is important to consider.

For example, it may look like this:

>>>>>> SMWorkflow.jar.certs.txt

s      16470 Tue Jun 28 18:04:10 CST 2016 META-INF/MANIFEST.MF

[entry was signed on 6/28/16 6:04 PM]

X.509, CN=Hewlett Packard Enterprise Company, OU=HP Cyber Security, O=Hewlett Packard Enterprise Company, STREET=3000 Hanover Street, L=Palo Alto, ST=CA, OID.2.5.4.17=94304, C=US      [certificate is valid from 1/14/16 8:00 AM to 1/14/18 7:59 AM]

X.509, CN=COMODO RSA Code Signing CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB      [certificate is valid from 5/9/13 8:00 AM to 5/9/28 7:59 AM]

X.509, CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB      [certificate is valid from 5/30/00 6:48 PM to 5/30/20 6:48 PM]

X.509, CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE      [certificate is valid from 5/30/00 6:48 PM to 5/30/20 6:48 PM]

Error: Caught XML API exception scxmlapi(23) – XML DOM exception caught – code 5 msg invalid or illegal XML character

User receives an error when trying to login:

Caught XML API exception scxmlapi(23) – XML DOM exception caught – code 5 msg invalid or illegal XML character

The logs may appear similar to the following:

RTE W Exception occurred for method execute and XML request <?xml version=”1.0″ encoding=”utf-8″?><SOAP-ENV:Envelope

2324( 7880) 06/23/2016 13:26:11 RTE W CTopaz::process(): Caught DOMException code:5 msg:invalid or illegal XML character

2324( 7880) 06/23/2016 13:26:11 RTE E Caught XML API exception scxmlapi(23) – XML DOM exception caught – code 5 msg invalid or illegal XML character

2324( 5908) 06/23/2016 13:26:11 JRTE W Send error response: A CXmlApiException was raised in native code : error 23 : scxmlapi(23) – XML DOM exception caught – code 5 msg invalid or illegal XML character

xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”><SOAP-ENV:Header/><SOAP-ENV:Body><execute><thread>0</thread><type>detail</type><event>0</event><authModel><var><user.id>RDE</user.id><old.password Password=”1″>756A5325B9829848</old.password><L.language>en</L.language></var></authModel></execute></SOAP-ENV:Body></SOAP-ENV:Envelope>

Upgrading the RTE to a more current version should resolve this issue.

Unable to login to Service Manager

Based on the following message that was seen on the log file capture in the session:

“JRTE E groupbindaddress 172.22.27.202 is not a valid local address.
JRTE E List of valid local ipaddresses are [192.168.0.22, 172.22.27.225, 172.22.27.219, 172.22.27.224] JRTE E Provide a valid local ipaddress to use in groupbindaddress parameter.”

Change the ip on this parameter for one of the valid ones, in the sm.ini file of the server that is erroing out:

Change this one: ” groupbindaddress:172.22.27.202″ to ” groupbindaddress:172.22.27.219″
Restart the SM service and login with the same ip.

Connect IT service is not getting up in Service Manager

Issue related to the SM side, the scenario was not working due to the SM side was erroing out, the customer was unable to login. Based on the following message that was seen on the SM log file captured in a session:

“JRTE E groupbindaddress 172.22.27.202 is not a valid local address.
JRTE E List of valid local ipaddresses are [192.168.0.22, 172.22.27.225, 172.22.27.219, 172.22.27.224] JRTE E Provide a valid local ipaddress to use in groupbindaddress parameter.”

Change the ip on this parameter for one of the valid ones, in the sm.ini file of the server that is erroing out:

Change this one: ” groupbindaddress:172.22.27.202″ to ” groupbindaddress:172.22.27.219″
Restart the SM service and login with the same ip. The scenario does not error out anymore.

Hover functionality not working correctly on Web client in Service Manager

On Web client, if one field has multiple related link lines defined for it, Hover functionality will fail if query of the first link line return no record. But on windows client, Hover functionality will go through all the related link lines until get record returned or reach the last link line. This is what is also expected on Web client. And Hover functionality works like that on Web client before.

Hover pop-up code has been refactored in SM9.41 Web Client to only return a value if the link query also returns a value. Customer has been advised to change their code to handle this situation.

Changes to devtype records with application patch 9.41.0020 in Service Manager

There are 4 devtype records identified as “Renamed” during the application of the OOB patch 9.41.0020. Obviously those records were modified or they wouldn’t have been “renamed”, but only changed the Sub Types and not the other elements and these are the things that have been change with the patch. For example, the Attr File, Join Def, and Bulk Update Format Name changed for the Computer devtype. The Attr File has changed from computer to node and the Join Def changed from joincomputer to joinnode. The same change was made for the Mainframe, Network Components, and Storage devtypes. All now have an Attr File of node but the node file does not contain all the combined records of the previous 4 Attr Files

The reason why the new devtype record exist it’s because in the newer versions of Ucmdb all server, computer, mainframe and other similar devices are consider nodes, and because of that these new devtype records were modified to match the new sending methodology by Ucmdb.

Still it’s possible to use any of them either the existent ones prior upgrade or the new ones. The main different will be the attribute table node as you have seen its meant to store attributes for all those types of CIs together.

If you are integrated with Ucmdb and Ucmdb is using the old devtype can keep doing that, there is no impact other than the fact the data will get stored across the different attribute tables if the devtype existent uses different tables.

Accept OOB changes when possible, so if it will not affect but why for example the computer attr file contains X records but the number of records in the node file does not change after the patch is applied. Shouldn’t the node file now have the original value (before patch) and the additional x records now added? Right now the data will remain in the current tables because unless a different version of Ucmdb that will use ucmdbNode web service node tables will not handle any data. Once that change is done then the data should sync to the correct table and on.