I installed the CEP ( Proton ) through the official documentation, https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/CEP_GE_-_IBM_Proactive_Technology_Online_Installation_and_Administration_Guide
After that, I watched this recommended video to learn more about CEP. https://edu.fiware.org/pluginfile.php/653/mod_resource/content/1/CEP-Tutorial.mp4
But I can't check engine instance state, because appears this error in response:Could not read instance state, message: Error activating jmx proxy:
It seems that JMX is not properly configured.
As described in the installation guide, in the Apache Tomcat users configuration file you need to add manager-jmx role, and add it to the manager user name:
<tomcat-users>
...
<role rolename="manager-jmx" />
<user username="manager" password="manager" roles="manager-gui,manager-status,manager-script,manager-jmx" />
...
</tomcat-users>
You need to enable JMX access on Apache Tomcat, by adding it to CATALINA_OPTS, as described in the installation guide.
You also need to specify the JMX service port in the ProtonAdmin.properties file, as described in the same installation guide.
Related
In ejabberd 18.01-2, installed in lxc container Ubuntu 18.04 Bionic LTS using apt, I'm trying to setup mod_http_upload.
In the section listen, I have
listen:
-
port: 5444
module: ejabberd_http
tls: true
request_handlers:
"/upload": mod_http_upload
In the configuration file, commented port was 5444, however, in the current documentation, it is 5443, so I am not sure which one is right.
In the modules section, I have
modules:
mod_http_upload:
host: "upload.ejabberd.forumanalogue.fr"
max_size: infinity
thumbnail: true
put_url: "https://ejabberd.forumanalogue.fr:5444/upload"
docroot: "/ejabberd/upload"
When I start the service, I can see an odd message in the logs
2019-11-11 21:02:35.287 [warning] <0.367.0>#ejabberd_pkix:handle_call:255 No certificate found matching 'upload.ejabberd.forumanalogue.fr': strictly configured clients or servers will reject connections with this host; obtain a certificate for this (sub)domain from any trusted CA such as Let's Encrypt (www.letsencrypt.org)
It is strange because I have a signed wildcard certificate.
certfiles:
- "/etc/letsencrypt/live/forumanalogue.fr/*.pem"
I can see the service with my client (Gajim) but when I try to send a file to another local account, I receive an error Access denied by service policy, see the complete log:
<iq xml:lang='en' to='foo#forumanalogue.fr/gajim.HCLJ4BZI' from='upload.ejabberd.forumanalogue.fr' type='error' id='1dd35274-90e9-4b3b-9608-0fab59afe34e'>
<request xmlns='urn:xmpp:http:upload'>
<filename>a.out</filename>
<size>27232</size>
<content-type>application/octet-stream</content-type>
</request>
<error code='403' type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Access denied by service policy</text>
</error>
</iq>
I had to enable debug logging in order to see something. It is quite verbose, but I think that the relevant part, which is non redundant with the client message, is
2019-11-11 20:53:08.329 [debug] <0.501.0>#mod_http_upload:process_slot_request:544 Denying HTTP upload slot request from foo#forumanalogue.fr/gajim.HCLJ4BZI
Thank you for your help.
I tried with ejabberd 18.01, a configuration similar to yours, and it works for me.
Looking at the source code, that "process_slot_request:544 " error means that the account attempting to use the upload feature is not allowed by the "local" Access rule in the vhost it sended it to. Probably it's a remote account. Remote to that upload service. In other words, the service upload.whatever can only be used by accounts like user12#whatever.
In your case, you are attempting to use upload.ejabberd.forumanalogue.fr from account foo#forumanalogue.fr, which is not local to that upload service.
Several ideas, I hope one of them suits your specific setup:
A) don't mess with vhosts. If it's forumanalogue.fr, keep it that everywhere
B) use #HOST# in host and put_url options
C) Or if you really want to mess with hosts, then add Access rights so accounts in that vhost are considered "local" to the upload service.
I am trying to use UploadObjectExample.java code to upload a file to OCI object storage. I am running into connection timeout error while connecting to the object storage URL. The same config file is used by OCI CLI to successfully upload files to OCI config.
Here is the Error log:
Exception in thread "main" com.oracle.bmc.model.BmcException: (-1, null, true) Timed out while communicating to: https://objectstorage.us-ashburn-1.oraclecloud.com (outbound opc-request-id: 1EB5AA4A7FD64D58A54F876AD0C9E83B)
at com.oracle.bmc.http.internal.RestClient.convertToBmcException(RestClient.java:572)
at com.oracle.bmc.http.internal.RestClient.put(RestClient.java:380)
at com.oracle.bmc.objectstorage.ObjectStorageClient.putObject(ObjectStorageClient.java:1053)
at com.oracle.bmc.objectstorage.transfer.internal.SimpleRetry$1.apply(SimpleRetry.java:34)
at com.oracle.bmc.objectstorage.transfer.internal.SimpleRetry$1.apply(SimpleRetry.java:26)
at com.oracle.bmc.objectstorage.transfer.UploadManager.singleUpload(UploadManager.java:111)
at com.oracle.bmc.objectstorage.transfer.UploadManager.upload(UploadManager.java:73)
at UploadObjectExample.main(UploadObjectExample.java:74)
Caused by: javax.ws.rs.ProcessingException: java.net.SocketTimeoutException: connect timed out
at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:284)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:278)
at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$0(JerseyInvocation.java:753)
at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
at org.glassfish.jersey.internal.Errors.process(Errors.java:229)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:752)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:445)
at org.glassfish.jersey.client.JerseyInvocation$Builder.put(JerseyInvocation.java:334)
at com.oracle.bmc.http.internal.ForwardingInvocationBuilder.put(ForwardingInvocationBuilder.java:141)
at com.oracle.bmc.http.internal.RestClient.put(RestClient.java:377)
Please test curl -v https://objectstorage.us-ashburn-1.oraclecloud.com from the same machine where the Java client times out, just to make sure there are no connection issues. If it works fine you may try to change the timeout value in ClientConfiguration. You can see more details here: https://github.com/oracle/oci-java-sdk/issues/92
Before creating a support ticket you might also try to create a new issue on github/oci-java-sdk.
without knowing more about the config file (I do not suggest you post it here), your home region and other elements it is very hard to help.
I would suggest you open a support ticket at https://support.oracle.com, making sure that you select the Cloud tab and the Service as "Oracle Cloud Infrastructure".
Are you using a proxy? If so, you may need to use the OCI Java SDK ApacheConnector.
This was an issue with the proxy. This was resolved by using the ash7 proxy.
I have an instance of Tomcat 8.0.9, running on GNU/Linux 2.6.32-642.6.2.e16.x86_64, that responds with "401 Unauthorized" when I try to access the manager UI, no matter what I try.
I know Tomcat is running, because I get that page.
I know it is that specific instance of Tomcat, because if I shut it down and revisit the URL (https: //host.name:port/manager/html), I get a connection refused.
The browser doesn't even prompt me for username and password; it just goes straight to the "401 Unauthorized" page.
The server's catalina.out log even reports that it has deployed the manager webapp (paraphrased):
*.a few seconds ago* INFO [localhost-startStop-1] o.a.c.s.H.deployDirectory Deploying web application directory /path/to/webapps/manager
*milliseconds later* INFO [localhost-startStop-1] o.a.c.s.H.deployDirectory Deployment of web application directory /path/to/webapps/manager has finished in 22 ms
I started with the Apache docs (https: //host.name:port/docs/manager-howto.html), and then with several versions of this question on SO for troubleshooting, including one that seems to have the most answers.
Since I've never used the manager before, my go-to theory is that 'obvious' was exactly what I was missing; however, I tried all of the obvious stuff below:
I restarted Tomcat, multiple times in this process, verifying that a reload of the URL was indeed firing a connection refused with the server stopped, and then back to the 401 error with the server started.
I added admin-gui to the user's roles:
<role rolename="admin-gui" />
<role rolename="manager-gui" />
<user username="tomcat" password="s3cret" roles="admin-gui,manager-gui" />
The XML above is not inside a comment block - if I edit it in Gvim with syntax highlighting turned on, this is very obvious.
tomcat-users.xml is owned by tomcat, and is readable (it's mode 775, in fact). I know it's being read, because if I add nonsense elements to it, catalina.out reports this on startup.
I also added the other role to tomcat-users.xml, just in case (manager-jmx, admin-script, etc.). (I'm still not sure what's supposed to happen if you left those out, misspelled them, etc. I imagine the manager webapp wouldn't recognize rolenames outside its specific set, but naturally I can't confirm this yet.)
The following element exists in server.xml, inside an Engine element:
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" />
</Realm>
In case it's relevant, there's also this, earlier in server.xml:
<GlobalNamingResources>
<Resource auth="Container" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase" />
</GlobalNamingResources>
In the Tomcat startup script, CATALINA_HOME points to the exact install path of Tomcat. There is no TOMCAT_HOME or JAVA_HOME, but JRE_HOME points to a symbolic link that points to an actual Java install (I followed that link and confirmed).
In the manager webapp, META-INF/context.xml, the Valve element is commented out.
Is there even a report of why I'm unauthorized, that gives me more information? I've tried scouring the manager webapp directory in the hopes there was yet another log there. (There isn't.)
I am working on a Notification Service using IBM MQ messaging provider with JBoss eap 6.1 environment. I am successfully able to send messages via MQ JCA provider rar i.e. wmq.jmsra.rar file. However on consumer part my current configuration looks like this
#MessageDriven(
activationConfig = {
#ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
#ActivationConfigProperty(propertyName="destination", propertyValue="F2.QUEUE"),
#ActivationConfigProperty(propertyName="providerAdapterJNDI", propertyValue="java:jboss/jms/TopicFactory"),
#ActivationConfigProperty(propertyName="queueManager", propertyValue="TOPIC.MANAGER"),
#ActivationConfigProperty(propertyName="hostName", propertyValue="10.239.217.242"),
#ActivationConfigProperty(propertyName="userName", propertyValue="root"),
#ActivationConfigProperty(propertyName = "channel", propertyValue = "TOPIC.CHANNEL"),
#ActivationConfigProperty(propertyName = "port", propertyValue = "1422")
})
My problem is that consumer of this service does not want to add any port numbers, hostName, queueManager properties in these beans. Also they do not want to use ejb-jar.xml to externalize these configs. I have researched and found that we can add a domain IBM Message Driven Bean but with no success. Any suggestions on what I can do here to externalize all these configurations ?
EDIT: Adding --> The JCA resource adapter is deployed at consumer end if it makes it any easier.
Thanks
You can actually externalize an MDBs activation spec properties to the server configuration file.
Create the ejb-jar.xml file, but do not put the actual value in the file, use a property placeholder:
<activation-config-property>
<activation-config-property-name>hostName</activation-config-property-name>
<activation-config-property-value>${wmq.host}</activation-config-property-value>
</activation-config-property>
Do this for all of the desired properties.
Ensure that property replacement for Java EE spec files (ejb-jar.xml, in this case) is enabled in the server configuration file:
<subsystem xmlns="urn:jboss:domain:ee:1.2">
<spec-descriptor-property-replacement>true</spec-descriptor-property-replacement>
Then, in the server configuration file, provide values for your properties:
<system-properties>
<property name="wmq.host" value="10.0.0.150"/>
Once your MDBs are packaged, you will not need to change any of the files in the MDB jar - just provide the properties in the server configuration.
you can avoid to add host name, port number and so on in MDB, you just want to define destinationType in MDB, and rest of the thing u can configure in your application server, like Activation Specification, Queues and Queue Connection Factories.
I have done the same thing but i used IBM Websphere Application Server.
I am recording a https session of a JSF based web app on JMeter and it's not working.
Target application is hosted on: AWS
JMeter version: 2.9 r1437961
Browser: Chrome version 29.0.1547.65
Java: java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.04.1)
OpenJDK Server VM (build 20.0-b12, mixed mode)
OS: Ubuntu 12.04
Proxy server config:
Port: 8084
Target Controller: Test Plan > Thread Group
Capture HTTP headers is checked.
HTTP Sample settings:
Type: not selected. Follow Redirects and Use KeepAlive checked.
URL patterns to exclude:
1. Added Suggested Excludes
2. .*\.jsf
Exceptions that are getting thrown (from JMeter.log):
ERROR - jmeter.protocol.http.proxy.Proxy: java.net.SocketException: Connection closed by remote host
at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1377)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:62)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.apache.jmeter.protocol.http.proxy.Proxy.writeToClient(Proxy.java:404)
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:218)
ERROR - jmeter.protocol.http.proxy.Proxy: Problem with SSL certificate? Ensure browser is set to accept the JMeter proxy cert: Connection closed by remote host java.net.SocketException: Connection closed by remote host
at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1377)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:62)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.apache.jmeter.protocol.http.proxy.Proxy.writeToClient(Proxy.java:404)
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:218)
The steps I am following are:
1. Set proxy server pointing to 8084.
2. Change proxy settings from chrome:
Set https proxy to 8084.
3. Disabled all chrome extensions and chrome account.
4. Started jmeter proxy server and hit https://url/login
5. Certificate confirmation page appears on browser. Meanwhile, jmeter.log shows:
2013/09/11 13:16:30 INFO - jmeter.protocol.http.proxy.Daemon: Creating Daemon Socket on port: 8084
2013/09/11 13:16:30 INFO - jmeter.protocol.http.proxy.Daemon: Proxy up and running!
2013/09/11 13:22:39 INFO - jmeter.protocol.http.proxy.Proxy: Proxy will remove the headers: If-Modified-Since,If-None-Match,Host
2013/09/11 13:22:39 INFO - jmeter.protocol.http.proxy.Proxy: Opened Keystore file: /home/abhijeet/Automation_Dev/LoadAutomation/Jmeter/apache-jmeter-2.9/bin/proxyserver.jks
2013/09/11 13:22:39 INFO - jmeter.protocol.http.proxy.Proxy: KeyStore for SSL loaded OK and put host in map (clients4.google.com)
2013/09/11 13:22:39 INFO - jmeter.protocol.http.proxy.Proxy: Opened Keystore file: /home/abhijeet/Automation_Dev/LoadAutomation/Jmeter/apache-jmeter-2.9/bin/proxyserver.jks
2013/09/11 13:22:39 INFO - jmeter.protocol.http.proxy.Proxy: KeyStore for SSL loaded OK and put host in map (translate.googleapis.com)
2013/09/11 13:22:40 INFO - jmeter.protocol.http.sampler.HTTPHCAbstractImpl: Local host = abhijeet-desktop
2013/09/11 13:22:40 INFO - jmeter.protocol.http.sampler.HTTPHC4Impl: HTTP request retry count = 1
2013/09/11 13:22:40 INFO - jmeter.protocol.http.sampler.HTTPHC4Impl: Setting up HTTPS TrustAll scheme
2013/09/11 13:22:40 INFO - jmeter.protocol.http.proxy.FormCharSetFinder: Using htmlparser version: 2.0 (Release Build Sep 17, 2006)<br>
6. Thread group starts showing unknown requests to these domains:
1. translate.googleapis.com
2. clients4.google.com
3. www.google.co.in
4. www.google.com
5. ssl.gstatic.com
6. safebrowsing.google.com
7. alt1-safebrowsing.google.com
8. clients4.google.com
9. www.gstatic.com
.
.
n all other requests going to the target application.
(For every request the above exceptions are thrown)
I believe, the google domain requests above are getting recorded because chrome is dynamically searching the keywords on google, while I am typing the url string in the address bar. But I don't want these requests to get recorded in the Thread Group.
Also, I tried the solutions from these pages but they didn't work for me:
Link 1
Link 2
Link 3
I don't understand, why is JMeter not able to use the fake certificate that it already has. I checked the SSL settings in chrome and I could not find any JMeter certificates. Need help!!
To do it in chrome/IE we have to place the certificate into 'Trusted Root Certificates Store'
Double click the certificate created
Certificate Import Wizard opens
Click Next
Select Second radio button (Place All Certificates in the following store)
Click Browse and select 'Trusted Root Certificates Authorities'. Click Next
Click Finish
Check your certificate installed in Chrome Settings (under Http/SSL) - Manage certificates.. (Trusted Root Certificates Authorities Tab)
This should at cure the exceptions thrown as your screenshot shows.
I have the same problem and solve it to trust the certificate. Just like you when i look at the
Options > Advanced > Certificates > View Certificates ==> Authorities
and couldn't see a name ApacheJMeterRootCertificate.crt or a related name, but i realize that there is a name something like
_DO NOT INSTALL unless this is your certificate
I click this object and 'Edit_Trust' both item under this object. I share my screenshot. I hope this can be help you and others.
I use Firefox. At chrome there should be similar way to edit the certificate.
jmeter 2.12 has good support for HTTPS. Under the WorkBench, just select Add -> Non-Test Elements -> HTTP(S) Test Script Recorder. This version worked first time for me.
Latest versions of Google Chrome made difficult to bypass security settings to avoid security Threats as Phishing or Man-in-the-middle attacks.
I have successfully configured Google Chrome (v.54.0) to allow JMeter Self-Signed Certificate for HTTP(S) Recording.
Here the instructions (on Windows):
Open MMC console (SUPER + R, Type mmc, Press Enter)
Select File Add/Remove Snap-in
Select Certificates Snap-in for Current User
Select Trusted Root Certification Authorities >> Certificates
Right-click over Certificates folder and select All Tasks >> Import...
Import JMeter Self-Signed certificate using the wizard keeping the default options.
Once installed, right-click over JMeter Self-Signed certificate and select Properties
On General tab, make sure Enable for all purposes option is selected
On Cross-Certificates, include the URL of the application you want to record (make sure you enter the full url, e.g. https://www.live.com)
Close all windows.
Done. You should now be able to reach the destination bypassing Chrome security alert and start recording.