I'm configured a node locally and can access via http://localhost:47100/ignite however when i execute a command like getting the node version to try read and write to a cache i get the following response ÿ|h2—Ÿ™Lá·šŠHpT«Ã
My setup is very basic - I have a single Ignite node running on a Windows machine. The node is using one of the sample cache examples when starting the node.
Should i be using a separate port or do i need to enable REST API?
Enter into your IGNITE_HOME folder
Copy folder IGNITE_HOME/lib/optional/ignite-rest-http into IGNITE_HOME/lib
Start-up one node
bin/ignite.sh -i
or
bin/ignite.bat -i
Check with netstat -tna ... listening port on 8080
Check on your browser http://localhost:8080/ignite?cmd=version
Ports 47100 and 47500 are used by Ignite for internal communication and discovery. By default REST API (when enabled) binds to port 8080.
If you need to change the port used for HTTP REST, you can do it by either setting IGNITE_JETTY_PORT system property or by providing a path to the Jetty configuration file in ConnectorConfiguration object which is set to IgniteConfiguration:
<bean id="ignite.cfg" class="org.apache.ignite.configuration.IgniteConfiguration">
<property name="connectorConfiguration">
<bean class="org.apache.ignite.configuration.ConnectorConfiguration">
<property name="jettyPath" value="/path/to/jetty/configuration.xml"/>
</bean>
</property>
...
Note that the system property overrides the port value set in Jetty XML configuration.
Related
Though, I've setup SSL between all Ignite Nodes and whole Ignite Cluster is secured, I'm able to access the data through JDBC thin client without passing any SSL configs. Does it mean though the cluster is secured we can connect without passing any ssl config/cert?
I want no one can connect to the Ignite Cluster until and unless required ssl certs provided, is that possible to achieve?
You need explicitly enable SSL for thin protocols:
https://www.gridgain.com/docs/latest/developers-guide/thin-clients/getting-started-with-thin-clients#enabling-ssltls-for-thin-clients
<property name="clientConnectorConfiguration">
<bean class="org.apache.ignite.configuration.ClientConnectorConfiguration">
<property name="sslEnabled" value="true"/>
</bean>
</property>
I currently have a WildFly 9 cluster up and running with access to my application over port 8080, I would like to set up SSL and have access only on port 8443, but I cannot seem to find any documentation for where the security realm and https listener are placed in Domain mode.
I have the keystore and certificate all set up and was able to get https working in a demo using standalone mode, but I need to be able to do it in domain mode.
Can anyone help me out and share how they've accomplished this?
Solved it! It turns out for some reason JBoss was not registering my Security Realm and HTTPS listener. To do this you need to use bin/jbosscli and the commands:
RUN THE "CONNECT" COMMAND FIRST
/host=master/core-service=management/security-realm=SSLRealm/:add()
---where SSLRealm is the name of the realm
/host=master/core-service=management/security-realm=SSLRealm/server-identity=ssl/:add(keystore-path=Keystore.jks, keystore-relative-to=jboss.domain.config.dir, keystore-password=password)
---this assumes the keystore lives in the domain/configuration directory
Restart the server.
I then ran into issues figuring out the command to register the HTTPS listener, but I found the WildFly web console at serverURL:9990 has a way to do it too:
Once logged in to the webconsole
Configuration->Profiles->for each profile which is used->Undertow->HTTP->View
From there
HTTP Server->default-server->view
Finally
HTTPS Listener->ADD enter a name like: default-https, Security Realm: the name chosen for the security realm (for this example SSLRealm), Socket Binding: https and click save
Restart again
You should now have access at your serversURL:8443
To set it up on slave servers you should only need to copy the keystore to each slave servers domain/configuration and then add the security realm replacing /host=master/ with /host=slave/ in the command. And then restart the server.
Double check the Domain.xml file on the slave has the https listener you created originally in the webconsole (it should automatically be put into all of the clusters domain.xml files)
I have a WebLogic docker container. The WLS admin port is configured at 7001. When I run the container, I use --hostname=[hosts' hostname] and expose the 7001 port at a different host port using -p 8001:7001 for example. The reason I do the port mapping is because I would want to run multiple WLS containers on the same host.
I have some applications that I deploy on this WebLogic. These applications use an external SDK (which I don't control) to get the application url using JMX (getURL operation of RuntimeServiceMBean).
This is where it gets wrong. The URL comes out as http://[container's IP]:7001. I would want it to retrieve http://[hosts' hostname]:8001 - i.e. the hostname I used to start the container and the port at which 7001 is mapped i.e. 8001.
Is there a way this could be done?
When the container is started, you should start WebLogic after adjusting the External Listen Address of your AdminServer. You can use WLST Offline for that from within a shell script, passing parameters with docker run -e KEY=VALUE, then later read these from inside the WLST script. Modify your AdminServer External Listen Address, exit(), then you can start AdminServer.
Here's an example on how to create the extra Network Channel with proper External Listen Address.
Our architecture is:
external users<---https--->web server(Apache HTTP server)<----->webapp server (tomcat)
We fail to pass the IBM AppScan, which is used to detect any security defects in webapp server, because it finds our tomcat server.xml file is not added the secure="yes" attribute in our port.
However the secure="yes" attribute should not be added to the tomcat server.xml file because we do not need a secure connection between web server and webapp server.
How can we fix the issue?
Are there any secure="yes" attribute can be added to the configuration file of web server(Apache HTTP server)?
Thanks & Regards,
Gordon
If your users are accessing Tomcat (indirectly) through Apache httpd using TLS (https:// URL) then it is entirely appropriate to set secure="true" in your <Connector>. This tells your web application that the request being received is secure even when it is not (e.g. you are using plain-HTTP between httpd and Tomcat).
So, if you have set scheme="https" on your <Connector> then you probably want to also set secure="true".
This is not a configuration change that you can make on the Apache httpd side... it must be done in Tomcat.
I installed ActiveMQ 5.5.0 on my Windows machine, and it had a web console (http://localhost:8161/admin) working out of the box.
Then I installed ActiveMQ (same version) on a remote Linux box (IP: AAA.BBB.CCC.DDD), but whenever I point the browser to
http://AAA.BBB.CCC.DDD:8161/admin
I get the "Unable to connect" error in the browser.
The network connection is there, I can connect to AAA.BBB.CCC.DDD via ssh and to another web application running on the same server.
Therefore I think that the cause of the problem is wrong configuration of the embedded Jetty server of ActiveMQ.
How can fix the problem, i. e. enable the access to the web console from a remote browser?
In your ActiveMQ config file you should see something like:
<import resource="${activemq.base}/conf/jetty.xml"/>
This starts up an embedded Jetty container with the web console.
If you start the broker on the console, you should see the following if everything works
INFO | ActiveMQ WebConsole initialized.
INFO | Initializing Spring FrameworkServlet 'dispatcher'
INFO | ActiveMQ Console at http://0.0.0.0:8161/admin
into /opt/activemq/apache-activemq-5.16.3/conf
open jetty.xml
change
<property name="host" value="127.0.0.1"/>
to
<property name="host" value="0.0.0.0"/>
restart activemq
I used this approach on a linux server running in VM but can be applied to any instance
Check whether 8161 port is opened for external connection. Also check whether another service creating a conflict.
If there is a conflict
change the jetty port in the {activemqfolder}/conf/jetty.xml.
locate the line that contains the 8161 and change it to the desirable port
To enable external connections to the port (in this instance i choose 8169) use
sudo iptables -I INPUT -p tcp --dport 8169 -j ACCEPT
Proceed to start the activemq ie {activemqfolder}/bin/activemq console to see the messages