I recently migrated our server from ColdFusion 7 Enterprise to ColdFusion 10 Standard and now our event gateways aren't working. When I try to start them, it says:
Unable to start event gateway instance: Event Gateway Service is not
enabled.
I do have "Enable ColdFusion Event Gateway Services" checked in the "Gateway Settings" page. When I turn the setting on and off, it says "Event Gateway Started.". Yet it still won't start my services. When I click start, I get the "Unable to start..." error.
I've seen a few posts about this problem, on Adobe's site, but no solutions. Both threads end with a comment that "it's working now!", but do not explain how the problem was fixed.
Unable to start event gateway instance: Event Gateway Service is not enabled., (service IS enabled)
Event Gateway Service/Instance Not Working
Am I totally forgetting a setting on the server or something?
I figured it out. If you are using Standard and not Enterprise you will have to make sure you are only entering 1 in the thread. I was entering 8 like on our old server. When I was clicking update it was not really updating even though it said it was. After I updated it with 1 thread and restarted the server. It worked. I didn't even have to click start services, they came up on their own. I'm assuming since the answer was so simple why no one updated their own answer on the adobe forums, which was super annoying.
You need to start the Event Gateway Service in CF Administrator, and then will likely need to restart ColdFusion service.
This could be caused by the insufficient privileges for the the directories you're trying to watch.
Check the service account of the Coldfusion Application Server service and see if it has sufficient privileges (i.e. local system account might not have access to the directories you're trying to watch)
Related
We continually add and remove IP's of servers that use the SMTP relay service and we do it manually, in the admin console.
We've looked at the documentation, and we don't see any reference to setting these rules in the API.
Is this possible to do?
Edit.- To do this in the console, you can folllow the procedure that is described in support.google.com/a/answer/2956491 (first step, point 8). –
I haven't found any command to do it in the Admin SDK API. I don't know if there will be something else.
I am trying to connect to an external API from .net.
It is working as expected from other machines.
But we are not getting any respond from the API call when trying from the server.
We have tried accessing the api url on the browser and it failed with the same no response error.
This is what we have done so far.
We have checked VPC firewall and tried some firewall rules ( Google Cloud firewall) and made sure that there is no blocking to this API.
We have checked Windows firewall and it is switched off now. We also made sure that there is no rules to block this API. However to test it further, we are now switched it off.
Checked that we are able to connect to other websites from the server.
Checked whether we can access the API from other machines. We are able to connect to the API successfully using the tokens from the server.
We have also installed Wireshark to analyze the incoming and outgoing packets from the server. From this analysis, we were able to find that there are network packets sending to this API and it is trying the retransmits the packets, but there is no acknowledgement packet received. This might be of the below two scenarios.
The acknowledgement packet sent from the API server lost in transition.
The data that we have sent from the server to the API lost in transition.
Contacted the API technical team and made sure that the IP is not getting blocked on their end.
Tried contacting Google Support but we have not received much help from them as ours are in "Bronze plan"
This was working without any issues from the server in the past. Not sure what is happening now.
Thank you in advance for all the helps.
Thank you Jeffrey and Patrick for your kind reply. As suggested by Patrick, I am adding here my comments as an answer to close this post. We were able to identify the issue from the wireshark analysis. It was the API provider who was blocking the IP. We have contacted them again with the results and they confirmed this. Thank you very much.
I am configuring our API Manager, but running into troubles authenticating via OAuth, seems to be an issue with the API Key Manager. I haven't dug into it yet, but does this come with the API Manager (as I have assumed) or is this a separate installation?
I had the same issue when using the wso2 api manager on a Amazon hosted machine, turn out that Thrift was not working correctly because some problem with multicasting and broadcasting.
What I did to get it working was to switch from ThriftClient to WSClient. If you have a huge amount of requests coming in then Thrift is the recommended solution from wso2 but in any "normal" case you will not have any differences between thrift and WS.
Here is how you switch:
Shut down the API Manager
Open up <api manager install dir>\repository\conf\api-manager.xml
Find ThriftClient
Change this to
<KeyValidatorClientType>WSClient</KeyValidatorClientType>
Start the API Manager
You may get some Warnings while starting up but, try it before you jump to the conclusion that it doesn't work.
Hope it helps!
you can use APIM manager product in a distributed setup as keymanger,gateway,store,publisher..but all functionality come in a single distribution.. ..
Go through the documentation for further guides
I was facing the same issue. Everything started when I created my own jks in order to use SSL without a self-signed certificate. I successfully created the jks and changed it in the carbon file. When I started the server, everything seemed ok; but when I used SOAPUI to test an API call, I got this (in the logs of the api manager):
APIAuthenticationHandler API authentication failure due to Unclassified Authentication Failure
I started digging what was the problem by enabling Debug level in the log4j.properties file, and then tried again a tested with SOAPUI and I got:
APISecurityException: Could not connect to <my api ip address> on port 10397
Then, I read the comment of OneMuppet and I checked that file and I found that the Thrift config has a host option, so I uncommented it:
<KeyValidatorClientType>ThriftClient</KeyValidatorClientType>
<ThriftClientPort>10397</ThriftClientPort>
<ThriftClientConnectionTimeOut>10000</ThriftClientConnectionTimeOut>
<ThriftServerPort>10397</ThriftServerPort>
This Line --> <ThriftServerHost>localhost</ThriftServerHost>
<EnableThriftServer>true</EnableThriftServer>
Save, restarted the server and everything start working correctly.
I got the same below issue after my installation, when i try to invoke the api service it is throwing below error:
900900 Unclassified Authentication Failure Error while accessing backend services for API key validation
After some random checks i have seen the axis2.xml file in /repository/conf/axis2 there it is refering a differnt ip's instead. I change these ip's to my local ip and restarted. The issue is resolved now.
I was facing the same issue. when I was trying to setup API Manager as an API Gateway in a different machine as per the steps given here,
https://docs.wso2.com/display/AM250/Publish+through+Multiple+API+Gateways
Once the setup is done and when I am trying to use this gateway URL, I was getting the below response,
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
After changing the KeyValidatorClientType value to WSClient from ThriftClient on the <api manager install dir>\repository\conf\api-manager.xml
It started working fine. And I was able to get the expected response.
If you changed the admin password, then you also have to update the repository/conf/api-manager.xml file with the new password. The 2 places I have changed (so far) are:
<AuthManager>
and
<APIKeyManager>
but there are other admin usernames in that file. No doubt, I'll get to them....
I apologize in advance if the question is ridiculous.
I have an asmx service running in Azure (HTTP - no SSL).
I have a WPF app that loads a X509Certificate2 and adds it to the request by doing the following:
X509Certificate2 cert = new X509Certificate2("...");
webRequest.ClientCertificates.Add(cert);
In the web service I get the certificate by
new X509Certificate2(this.Context.Request.ClientCertificate.Certificate)
And then I load a cert (that I have both uploaded to the Azure control panel and added to my service definition file) by using the following sample:
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySubjectName, certName, true);
And then I validate by doing the following:
clientCert.Thumbprint == certs[0].Thumbprint
Now unfortunately I get an exception (System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle) as soon as I do
Request.ClientCertificate.Certificate
So I have a few questions. How do I avoid the exception. This answer states I need to modify an IIS setting, but how can I do that in Azure?
In any case is this even the proper way to do certificate authentication?
Thanks!
You can use command scripts to modify IIS, in combination with appcmd.exe.
For a quick example (disabling timeout in an application pool), take a look at this sample by Steve Marx.
In this example, you'd call DisableTimeout.cmd as a startup task. For more info on creating startup tasks, you can watch this episode of Cloud Cover Show. There should be a lab on startup tasks in the Platform Training Kit as well.
Just remember that any type of IIS configuration change should be made via an automated task at startup. If you manually change IIS via RDP, those changes won't propagate to all of your instances, and won't remain persistent in the event of hardware failure or OS update.
You can remote into your azure instances to manage IIS. As for a way to do it globally for all instances at once, I'm not sure. That would be an interesting side project though.
http://learn.iis.net/page.aspx/979/managing-iis-on-windows-azure-via-remote-desktop/
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.