When trying to import a transport request via transaction stms into a SAP R/3 system there is an error message (german)
Die installierte Komponenten-version stimmt nicht überein.
After logging out and logging in again with EN as language the english message is:
Does not match component version.
How can I proceed?
You can bypass/ignore the error for a single import by ticking the checkbox "Ignore Invalid Component Version" in the transport request options.
Some official SAP notes (like 1671989) recommend to ignore the warning as described above, others (like 1688610) describe steps to prevent it from occuring in the first place. The latter note also describes a way to disable the warning entirely: In transaction stms chose "Systems Overview" → ID of your system → "Transport Tool" → "Change Mode" and set the parameter SP_TRANS_SYNC to OFF
A detailed explanation of what this error message is trying to tell you can be found in SAP note 1742547.
Related
I'm working in a company network and was trying to import a "Spring Getting Started Content" (File -> New -> Spring Getting Started Content). The wizard open, but in both categories (Getting Started Guide, Reference App) is the error "SunCertPathBuilderException: unable to find valid certification path to requested target" shown.
I already included our company certificate and the spring.io - certificate to my cacerts of my used jre. Additional i set the proxy settings for our company proxy server (Window -> Preferences -> Network -> Manual).
If I try to add a Cloud Foundry Target, I also need to authentificate. The same error occours. But here I have the option to "Skip SSL Validation" and then it works.
I expect it to work after I included the spring.io certificate, but maybe the download request ist against something else?
I also added a github cert.
I am trying to connect to Hive2 using RJDBC but it failing with "GSS initiate failed". However same things working fine using beeline client. Any idea what may have caused different behavior when running both on same node with same credentials?
drv <- RJDBC::JDBC("org.apache.hive.jdbc.HiveDriver", cp, "`")
following is just for illustrative purpose as I wanted to show what all parameter I am using as JDBC url.
conn <- RJDBC::dbConnect(drv, "jdbc:hive2://node1:10000/default;principal=hive/hive_node#REALM;ssl=true;sslTrustStore=store_path;trustStorePassword=store_password", "user", "password")
log4j:WARN No appenders could be found for logger (org.apache.hive.jdbc.Utils).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Error in .jcall(drv#jdrv, "Ljava/sql/Connection;", "connect", as.character(url)[1], :
java.sql.SQLException: Could not open client transport with JDBC Uri: jdbc:hive2://:10000/default;principal=hive/hive_node#REALM;ssl=true;sslTrustStore=store_path;trustStorePassword=store_password: GSS initiate failed
A bit late for you, but... look at that post about the details of configuring Kerberos authentication for Hive/Impala JDBC (note also that "user" and "password" connection args are ignored by Kerberos auth)
The post assumes that you have the password stored in a "keytab" file, and use it to create a private Kerberos ticket. If you want to use the default, public ticket instead, then change the JAAS conf accordingly (i.e. useTicketCache=true useKeyTab=false and no keyTab entry)
And to pass the configuration to Java from your R code, the easiest way is to set the JAVA_TOOL_OPTIONS env variable before anything else bootstraps the RJava initialization
Sys.setenv("JAVA_TOOL_OPTIONS"="-Djava.security.auth.login.config=/Path/To/jaas.conf -Djavax.security.auth.useSubjectCredsOnly=false")
PS: on Windows the path would look like C:/Path/To/jaas.conf (Java converts slashes to backslashes automatically; that's easier that escaping each and every backslash because of the way R Strings interpret \)
Final note: if any jerk tags this with "answers should not rely on links", since the aforementioned link points to another post of mine in S.O., then he/she is really a jerk, and I will gladly tell him/her to his/her face, loudly and with exotic words.
Some of our users are encountering the following error page during the sequence of redirects after authenticating at their IdP.
"Unexpected exception occurred in Response Handling: null"
Partner: ...
Target: ...
This is what I believe is the corresponding info from the the server log.
2015-07-16 07:48:53,458 DEBUG [com.pingidentity.jgroups.MuxInvocationHandler] invocation of saveState on InterReqStateMgmtMapImpl state map size:215 attributes map size4 w/args: [ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB, State(1437050933419){
inMsgCtx=null
outMsgCtx=OutMessageContext
XML: <samlp:AuthnRequest Version="2.0" ID="E6_0yldGrt0iqNKfUpArog6DG8G" IssueInstant="2015-07-16T12:48:53.419Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">#issuer%</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/>
</samlp:AuthnRequest>
entityId: <Id> (IDP)
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
relayState: ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB
Endpoint: <endpoint>
SignaturePolicy: DO_NOT_SIGN
parameters=null}] returned null
Is there an obvious place to look for more details? This happens for around 10% of our users and seems to follow them from device to device.
I figured out what the issue was. We are using account linking using the SAML Subject from the IdP. It turned out that a number of accounts at the IdP didn't have the LDAP attribute mapped to the NameID populated. So we were receiving SAML assertions without any data in the Subject.
Understanding where to look is the key. The audit.log file shows a general "failure". Then you look up corresponding activity details in the server.log file. Then you examine the corresponding SAML assertion in the log to determine what the problem was. The difficult part is noticing omissions in the data. That's harder for the eye/brain to catch imho.
It would be useful if we had an option for directing users to a custom page rather than a Ping-specific error page when this occurs.
I have installed the API Mgr 1.7.0 in Win 7 64. I have been through the Quick Start guide and all appeared to work as described. However, when I get to the point of trying the subscribed-to cdyne api, the 'moving dots' graphic stays there forever. I can't find a way to stop it, other than a browser refresh. I can't see an entry in the API Mgr system logs.
I have removed the parameters and the auth info, which is supposed to return a 401, but it doesn't and the moving dots continue. I'm using Firefox 31, with AdBlock+ and Noscript. There are no blocked scripts as far as I can see.
[edit 1] I get the same problem with the first sample (YouTube). I wonder if the problem is caused by port values? As I have the ESB installed, I increased all the ports for API Mgr by 1. Maybe I missed one, or there is one that hasn't been documented.[/edit 1]
[edit 2] I have reinstalled the API Mgr. I stopped the ESB and left the APIM ports as default. I have recreated the Phone Verify service and I still have same problem with 'Try it now'. I set the global log level to DEBUG, but there is too much detail to be of use. I don't know what package names to set for this problem.
There was an entry in the Application Logs as follows, which might be relevant. The first few lines are shown:
System Error Occurred
Exception occurred while trying to invoke service method getApplicationNames
The following error details are available. Please refer logs for more details.
org.apache.axis2.AxisFault: Exception occurred while trying to invoke service method getApplicationNames
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:531)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:370)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:445)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:225)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at org.wso2.carbon.logging.view.stub.LogViewerStub.getApplicationNames(LogViewerStub.java:3700)
at org.wso2.carbon.logging.view.ui.LogViewerClient.getApplicationNames(LogViewerClient.java:165)
[/edit 2]
Regards, John
You may not have configured CORS. CORS is cross-origin resource sharing [1] and it is used by the try-it feature in the store.
The CORS configuration is stored in [API Manager Home]/reposotiry/conf/api-manager.xml . The header must include the Host name used by the CORS request. The host name being used by the try-it service is shown in gray at the bottom-left hand corner of the API-Console / try-it screen. It should show up as 'base url'. For example: [ base url: http://10.212.0.846.:8281 , api version: 1.0 ]
You may also be having trouble with the default APIs - please make sure that the APIs in [API Manager Home]/repository/deployment/server/synapse-configs/default/api/ are updated with your port offset. This may be preventing basic authentication. It is documented here [2]
Hope that helps.
-Colin
[1] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[2] https://docs.wso2.com/display/AM170/Changing+the+Default+Ports+with+Offset
I just want to have email notification when an error is declared in plone 4.
Any ideas of product or any "how-to" ?
Thanks
You can easily configure the built-in email notification for Zope, but we found that adding the mailinglogger package makes the emails a lot more managable.
The package adds:
customisable and dynamic subject lines for emails sent
emails sent with configurable headers for easy filtering
flood protection to ensure the number of emails sent is not excessive
support for SMTP servers that require authentication
configurable log entry filtering
The plone.recipe.zope2instance buildout recipe supports mailinglogger out of the box; simply define a mailinglogger variable in your [instance] part and include the mailinglogger egg:
[instance]
recipe = plone.recipe.zope2instance
eggs +=
mailinglogger
# Other options go here
mailinglogger =
<mailing-logger>
level warning
flood-level 100000
smtp-server localhost
from logger#example.com
to error-receiver#example.com
subject [ServerName Error] [%(hostname)s] %(levelname)s - %(line)s
</mailing-logger>
The package has been invaluable for us on larger clusters, where we configure additional variables per instance to be included in the subject; we can see what instance the problem occurred on directly in the subject.
Configuring mailing-logger is documented at http://pypi.python.org/pypi/plone.recipe.zope2instance but I think that email log notification is built into recent Zope2 releases, so you should now add the following to you [instance] section:
event-log-custom =
<email-notifier>
from server#here.com
to kdie#localhost
subject "anything goes here"
smtp-server 127.0.0.1
</email-notifier>
(example from http://myzope.kedai.com.my/blogs/kedai/44)
http://pypi.python.org/pypi/collective.logbook is handy too.
You need to add an email-notifier to your event-log-custom in buildout.cfg. Unfortunately there's no way to append it to your existing logging configuration but the following will mimic what plone.recipe.zope2instance does for the event log anyway
event-log-custom =
<logfile>
path ${buildout:directory}/var/log/${:_buildout_section_name_}.log
level INFO
</logfile>
<email-notifier>
from server#here.com
to admin#company.com
subject "[Zope alert - ${:_buildout_section_name_}]"
smtp-server localhost
level error
</email-notifier>