Trying to set up JDBCQueryMonitor monitor. When I'm setting up the monitor in the same manner as in documentation: http://docs.opennms.org/opennms/releases/latest/guide-admin/guide-admin.html#_jdbcquerymonitor, it's shown as "Not Monitored" in Interface.
According to https://wiki.opennms.org/wiki/FAQ-Configuration#Q:_Why_are_some_services_listed_as_Not_Monitored.3F it should be defined by status attribute in config file. But it's already set to "on"...
The "Not Monitored" on the service means basically, you have assigned a service but Pollerd has
not found a service configuration for the given service name
the IP interface does not match a Polling package which has a service configuration for the given service name
You should check the following things:
Click in the Node Detail Page in the Web UI on the IP interface where your JDBC service is assigned. In the top you will find the matching "Polling Packages" which are applied on this IP interface.
Check in the poller-configuration.xml if you have a service configuration for your JDBC service in the defined "Polling Packages". The service name is important, check if you don't have typos here.
Additionally and a often seen problem. People define the service configuration but miss the class mapping at the bottom of the poller-configuration file. Please verify if you have the configuration entry with something like:
<service name="OpenNMS-DB-Event-Limit" ...
and also assigning the monitoring class with
<monitor service="OpenNMS-DB-Event-Limit" class-name="org.opennms.netmgt.poller.monitors.JDBCQueryMonitor" />
at the bottom of the poller-configuration.xml file.
Related
When I accessed this URL http://my.domain.com:9763/services/Test_DataService.SOAP12Endpoint, I received the message bellow:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<soapenv:Reason xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Text xml:lang="en-US">
The endpoint reference (EPR) for the Operation not found is /services/User_DataService.SOAP12Endpoint and the WSA Action = null. If this EPR was previously reachable, please contact the server administrator.
</soapenv:Text>
</soapenv:Reason>
I tested the WSO2 DSS 2.7 and 3 local and remote with Oracle RDS on Amazon (the same error on all cases).
What's happening?
It looks like you are accessing the service in a wrong way.
As you might know, WSO2 Data Services Server uses Axis2 services to expose your data service as a web service.
So, you should know how to invoke Web (Axis2) services from a client.
When you successfully create a data service, you should be able to see the relevant service in the services list. Then you can use the "Service Dashboard" to view the service's WSDL and manage QoS
Following error from Axis2 usually indicate that you are not invoking the web service properly.
The endpoint reference (EPR) for the Operation not found is /services/User_DataService.SOAP12Endpoint and the WSA Action = null. If this EPR was previously reachable, please contact the server administrator.
You should be able to test the service from in-built Try It feature from Service Dashboard. soapUI is also a great tool to test Web Services. You can just point the WSDL in soapUI and create a project. You can then manually invoke listed service operations under the soapUI project.
I hope this helps!
I am trying to start an application in Websphere 8, and keep on getting the following error.
From the message, it means we are missing the bindPassword, but we never have to define in WAS 6.1
Currently we are using Standalone LDAP registry. Does anyone have any idea where I should start looking to fix this error?
UserManagemen E com.ibm.ws.wim.management.UserManagementProcess handleNo
tification CWWIM6004E Initialization of the dynamic reload manager failed.
com.ibm.websphere.wim.exception.MissingInitPropertyException: CWWIM0004E The initialization property 'bindPassword' is missing from the configuration.
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initializeEnvironmentProperties(LdapConnection.java:194
7)
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initializeServers(LdapConnection.java:1904)
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initialize(LdapConnection.java:1832)
at com.ibm.ws.wim.adapter.ldap.LdapAdapter.initialize(LdapAdapter.java:235)
at com.ibm.ws.wim.RepositoryManager.initialize(RepositoryManager.java:610)
at com.ibm.ws.wim.RepositoryManager.<init>(RepositoryManager.java:131)
In regards to ".... never have to define in WAS 6.1"
The requirement for a LDAP bind password is enforced by the LDAP server, this is not a WAS requirement
If in fact you didn't define it in WAS v6.1, the LDAP server in use for WAS V6.1 didn't require it.
Based on the error, you've either changed LDAP servers or the LDAP server configuration has changed (or both)
As mentioned in the other post, you can troubleshoot this using a tool like ldapsearch
The technote at http://www-01.ibm.com/support/docview.wss?uid=swg21470063 discusses obtaining "must gather" and troubleshooting these types of issues (refer to the "collecting data manually" section)
You must check your ldap connection to the ldap server
User IBM WebSphere Console, Security settings, LDAP and take note about the LDAP connection settings.
Use a tool like ldapsearch in order to check the connection via shell command line.
It is possible that these bind password is not correct.
If you are using un Novell eDirectory Server you must take special attention in the bind user creation ( field password )
I need to put a crossdomain.xml file in my Windows Azure Web Role. But where ?
I tried to put it in : F:\sitesroot\0
But my Unity3D Web App says : Exception: Unable to connect, as no valid crossdomain policy was found.
I don't know what I am missing. Unity uses by default port (843).
Where to put the crossdomain.xml
Any help is welcome !
CrossDomainPolicy.xml must be at the root of your application.
If you are using single Web Role just add CrossDomainPolicy.xml at the root of your application and set it up correctly as below:
Depends on how many "sites" sections you have in your role's ServiceDefinition.csdef , you will get that many \sitesroot\0 and \sitesroot\1 and CrossDomainPolicy.xml will be distributed to all depend on your role solution settings.
Once I discussed this in my following blog:
Silverlight front end calling to WCF Service, all in one Windows Azure Web Role Sample
You mentioned port 843, which sounds like it would need the Flash protocol, which is a TCP socket listener on port 843 that responds with the cross domain policy when it receives the text <policy-file-request/>. Do you need to be doing that? Does your app use sockets?
Avkash's answer is correct for where the XML file should go if you just need to serve it via port 80 from your web app, but if you need to do raw sockets, you'll need to be running something on the server that handles that.
When configuring the global security for Websphere Application Server, no matter you choose Federated Repositories, LDAP registry or custom registry, there is a property named 'Server user identity' to be setup. According to the official explanation, this is used for authentication during server to server communication. Does it mean when server communicating with each other within one cell, authentication is required and this value would be used there? And does this value only impact internal process, like within same cell? Or it can also be between cells? If it's not leveraged like this way, then how does 'Server user identity' work?
Kinda don't understand this. Please help me figure it out. Thanks in advance
Until WAS 6, a single user identity was required, namely 'primary administrative user', for both administrative access and internal process communication . This user, by definition, had to exist on the configured user registry.
From version 6.1 onwards, WAS requires an administrative user, distinguished from the server user identity, so that administrative actions can be audited separately.
For all practical purposes, if you are using version 6.1+, and you are not in a mixed-release cell (cell containing profiles of older versions of WAS in addition to current versions), you may just go ahead with automatically generated internal user id. An internally-generated server ID also adds a further level of protection to the server environment because the server password is not exposed.
For mixed-release cells you may check infocenter here for details on how to configure server user id in this case.
Server user id is used for server to server communication in a cell. I could not find any documentation that implies this parameter is also related with cross cell communication.
If i am hosting a WCF service so that someone(i.e someone whom i know) can consume my service, but what if someone else(i.e someone whom i don't know) consumes it then would do i? How do i prevent that?How can this be achieved?
Can it be done through service throttling or what are the other ways of achieving this?
If you want some some clients to be able to use (or view) your service and some clients to not be allowed to use (or view) your service then you need to setup authentication on your service so that only clients that you allow can access (or view) your service.
I don't know your entire scenario, but transport security with Basic authentication would probably be enough. To enable that you would disable Anonymous access in IIS, configure IIS to use Basic Auth and then in the binding configuration set:
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
Set your mex binding to use the secure binding instead of the default mexHttpBinding.
You would also need an SSL certificate for your site (if using WSHttpBinding).
UPDATE: Here's a sample, Custom Secure Metadata Endpoint that demonstrates how to implement a service with a secure metadata endpoint.
No, there's no mechanism in WCF to allow certain clients from using your service while prohibiting others. You'll need to approach this from a different angle.
One way is to not automatically publish your metadata from your service - e.g. make it almost "invisible" - and then distribute the necessary metadata information in the form of one or several WSDL and one or several XSD files to those clients you want to connect to your service. If your metadata is not available, someone just browsing to your service address will not get any information about what to call.
The metadata exchange is controlled by the <serviceMetadata> behavior, and by having a "mex" endpoint on your service. Remove both and your service is invisible.
The other way would be to prohibit any external users to access your WCF server based on firewalls and network rules. This cannot be done by WCF, but your network administrator could limit which IP's have physical access to the machine where your WCF service runs.
Marc
UPDATE:
In order to ship metadata to those users who should be able to call your service, you can do one of two things:
1) Using svcutil.exe /t:metadata (path+name of your service assembly), you can extract the metadata from your service assembly (e.g. MyServiceLibrary.dll). This will give you one or several WSDL and one or several XSD files, which you need to ship to your intended users. They can put these files somewhere on their harddisk and then in the "Add Service Reference", instead of entering the URL to discover the service, they can type in the name of the main WSDL (which imports all other files) and they'll get their client proxy.
Or:
2) With the service up and running, you could "Add New Project" to your solution, choose a Class Library (MyService.Client), then do a "Add Service Reference" and enter your service URL. This will create all the necessary files and everything in your new class library. Compile this class library and ship that assembly MyService.Client.dll to the users you want to allow access to your service.
With both solutions, you don't need to have metadata exchange enabled, and someone else cannot just walk up to your service and get all the information needed in order to call it.