I couldn't able to setup the perfino java agent in windows server standard.
Passed the "-javaagent:E:\perfino\perfino.jar=server=172.16.11.160,port=8090,name=webserver1" VM argument to tomcat7, my application launched successfully but when I verify the perfino server (172.16.11.160:8090) agent is not listing.
In my tocat logs(info) I saw only "perfino> Agent initialized (build version 26704)" this message, not sure how to debug more.
Appricate your help in advance.
Cheers,
Ashok
The port for connections from VMs is configured with the vmPort option in perfino.properties.
By default, it is set to 8847. If you configure a different port, you have to add the ,port=nnnnn option to the -javaagent parameter. In that case, the setting in perfino.properties and the part value on the agent parameter have to match, otherwise no connection can be made.
Related
I get:
JMX is not enabled to receive remote connections. \
Please see cassandra-env.sh for more info.
and I am not familiar with cassandra-env.sh
I tried nano /etc/cassandra/cassandra-env.sh in the terminal but from there I'm lost
By default, JMX is only enabled from local, so you can't log in remotely. To change that you need to modify the cassandra-env.sh:
https://docs.datastax.com/en/archived/ddacsecurity/doc/ddacsecurity/secureJmxAuthentication.html
Where you see:
if [ "$LOCAL_JMX" = "yes" ]; then
JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT"
You'll need to change to no so that it hits the remote loop. Then you'll need to configure the following params:
-Dcassandra.jmx.remote.port=7199
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=10.101.35.37
If you want SSL then you'll need to configure that as well. JMX is just java, so it's not specific to Cassandra. The configuration is actually found in java documentation:
Remote JMX connection
You didn't provide a lot of detail in your post but I'm guessing that you saw the warning in the Cassandra system.log.
During startup, Cassandra performs certain checks to make sure that the node is configured correctly. One of the checks it performs is to verify that the JMX port is configured.
In your case, you didn't configure JMX for remote access so the WARN was logged by the StartupChecks.java class. There is no reason to be alarmed by the message. It is completely fine to not allow remote JMX access, particularly since you are most likely just trying Cassandra out for the first time.
Remote access isn't necessary for Cassandra to function. Unless you plan to run management commands like nodetool remotely, it's perfectly fine to leave it as-is. You will still be able to run admin commands locally on your Mac. Cheers!
I have installed WebSphere Application Server v7 Stand-alone Edition. I have also created three application server profiles and one administrative agent profile. The hostname parameter was set to 'hostname' when creating these profiles. How can I update this parameter to the actual hostname of the machine?
You can use the wsadmin tool to change the hostname. For instructions, see this link to the IBM Documentation for WAS 7.
You will need to repeat the process for each of the created profiles. Once the change is done, restart the servers for the changes to be correctly reflected.
Stop WAS
Edit the file serverindex.html located under:
#IBM_home$/profiles/$Server_name$/config/cells/$cell_name$/nodes/$node_name$
Replace the old hostname with new hostname under all hostName and host definitions
Start WAS
the request from ihs is passed to plugin then to the application server and server received it.there is no cluster environment here.the server is up and running fine.But the response is not going back to plugin.how to troubleshoot?
(I would have made this a comment, but I don't have enough rep points).
You may need to engage IBM WebSphere Support to assist with this, but typically, for that type of issue, you would need to trace both sides of the connection (IHS plugin and WebSphere). Specifically,
Set LogLevel="Trace" in the plugin-cfg.xml
Set the following trace spec on the AppServer:
=info:com.ibm.ws.webcontainer=all:com.ibm.wsspi.webcontainer*=all:HTTPChannel=all:GenericBNF=all:TCPChannel=all
Reproducing the failure and reviewing the http_plugin.log and trace.log may provide some clues.
Do you receive some type of error in the browser? timeout? Is there anything (firewall, proxy) sitting between the IHS server and WebSphere AppServer?
It could be DNS problem with your WebSphere server. Can you please let us know about your IHS and plugin. Is it installed on same server where WebSphere is or on different server? If IHS and plugin is on different server just check that WebSphere server is able to resolve the IP address of IHS server using hostname. If not try to update host file with IP and hostname of your IHS server. It should work.
Does the client or the plugin not getting the response? Will that the request result in secure connection (i.e HTTPS/SSL...)?
The WAS server should extract most of the ports correctly if IHS/plugin is used in between. If using different webServer/load balancer(LB), the WAS server may not extract the listerning ports on the webServer/LB correctly.
You can take a look at the sample setting in PK55330 where a different web server is used in place of the IHS.
http://www-01.ibm.com/support/docview.wss?uid=swg1PK55330
Regards,
I have a Jenkins server on my local Windows device, but I want to make it invisible to the outside world (office rules regarding servers). The obvious and unsubtle way, which works satisfactorily, is to set up a firewall rule to block incoming access to its port, but I feel there must be a Jenkins setting to stop it advertising its services to anyone but localhost. Can anyone tell me if there is?
Note that setting up user credentials is not a valid solution, as the server being visible but inaccessible without login still violates office rules.
From Starting and Accessing Jenkins you need --httpListenAddress=127.0.0.1 command line parameter:
--httpListenAddress=$HTTP_HOST - Binds Jenkins to the IP address represented by $HTTP_HOST. The default is 0.0.0.0 — i.e. listening on all available interfaces.
For example, to only listen for requests from localhost, you could use: --httpListenAddress=127.0.0.1
If you run your Jenkins as Windows service, you can extend command line arguments in jenkins.xml file in Jenkins home directory.
Similar answer (for Linux-oriented platforms) on ServerFault.
I am having trouble browsing to my team city(JetBrains) from a remote machine. I have followed the install directions and the install went smoothly. I can browse the to application locally on the server, no problem at all. I changed the default server url in the config file to be http://my servername . I can browse to http://my server name and the application shows up no problem locally. The application is alos installed on the default 80 port of the server with no other web server installed.
If I browse to http://my servername from my laptop on the same domian nothing happens. When I run diagnostics it seems to pick up the webserve but it fails to respond.
As a test I uninstalled the app and installed IIS to see if I could browse to the default IIS page remotely. This worked no problems at all. I uninstalled IIS, ensured nothing was hogging port 80 on the server. Reinstalled the applicaiton, configured it exactly the same, still nothing. The application works fine locally, but I get nothing remotely.
I was just wondering if anybody knows anything else I can try? or is there a setting in tomcat I need to tweak?
I just updated TeamCity from 7.0 to 7.1, and now I have the exact same issue.
However, what turned out to be the cause had nothing to do w/ the TeamCity upgrade. It turns out our system administrators had setup a policy update to block all incoming connections other than port 80. When I started my upgrade, I noticed the server wanted to do some system updates. So I let that go first.
I suspect that had I tried to access the TeamCity server after the system update, I'd have realized I could no longer access the website remotely.
But since I only noticed it after the TeamCity update, I assumed it to be the culprit and wasted a bunch of time on that red herring.
The solution for me was to
Open Windows Firewall on the server
Click on the root level option in the left-hand pane
Make sure under each of the profile sections, that inbound connections are allowed.
(#3) was my problem.
Hope this helps someone else out in the future...
Verify that the server is running on port which is not blocked by the firewall. Change the port if necessary.
Tomcat also supports binding to specific IP addresses, in case your machine has multiple IPs, you can configure which one to use in server.xml, like:
<Connector port="80" address="10.10.10.10" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Where 10.10.10.10 is the IP of the server which can be accessed from the remote machine.
Check the server logs to ensure that it's started on the correct IP/port and is accepting connections.
I just faced the same issue when evaluating TeamCity v10.0.
I solved it by changing the 'Server URL' value with the name of my computer that can be used from remote computer.
As they say, "make sure the server is accessible by the URL specified".
To reach this setting:
- Login to TeamCity interface then
- Click on the 'Administration' link
This is well explained in the TeamCity support page:
https://confluence.jetbrains.com/display/TCD10/Configuring+Server+URL
The problem is that TeamCity's default server.xml has localhost as the host name. You need to add an alias for it answer that name as well, as described here:
http://tomcat.apache.org/tomcat-4.0-doc/config/host.html#Host%20Name%20Aliases
Ryan