Environment Details :
1- Application Server : IBM Application Server 7.0.11
2- Web Server : IBM HTTP Server ( IHS ) .
When I requested stopped application for example : TETS1 the below error appeared on browser :
SRVE0255E: A WebGroup/Virtual Host to handle /TETS1 has not been defined.
SRVE0255E: A WebGroup/Virtual Host to handle 192.160.107.11:80 has not been defined.
IBM WebSphere Application Server
How can avoid the above message to appeared on browser ( for security wise )
Thank you .
We can add a custom property which says the server is under maintenance.
For example:
Go to your appserver console -> click on servers -> server types -> application servers -> server1 -> webcontainer settings ->webcontainer -> custom properties -> click on new and add custom property.
Give Name : com.ibm.ws.webcontainer.webgroupvhostnotfound
value : Server is under Maintenance, we regret any inconvenience caused
save this and restart server instance [server1]
That's it.. If your application is down, the error message, which you configured in custom property, will display to the user.
This error that you're getting is the default error generated by WebSphere when no web application is bound to the requested context root (in your case, /TETS1).
WebSphere is sending this text back to the client along with HTTP code 404 (Not Found).
The only way for you to override what's being shown to the client is by configuring IHS to display a particular page whenever the response, coming back from WAS, is HTTP 404.
Related
I have a client in NodeJS using the MQTT module (mqtt.js) to communicate with a topic of WebSphere MQ, redirected to a queue : I need the result to be on a queue so I use a topic between the source and the destination (since MQTT protocol communicate only with topics).
So we have :
NodeJS (source) -> Topic of Websphere MQ (intermediate) -> Queue of Websphere MQ (destination)
The problem is that the received messages on the queue of WebsphereMQ are MQHRF2 format but I need MQSTR.
I did not find any property in mqtt.js side to specify the format.
I supposed we can force it with IBM Websphere MQ, but how ? Can I create a channel or anything for this use, that's to say convert the receiving format ?
Thanks in advance for your help !
Configuration :
MQTT.js v3
WebSphere MQ v7.5
Constrains :
WebSphere MQ must be v7.5 (so I can't upgrade to v8 to use mqlight)
Better stay with the module MQTT.js
It works correctly when I publish directly on a topic via the WebSphere MQ explorer. However, it fails when I publish from the NodeJS application.
I tried both methods listing in the comments but I found a weird thing : The result is different according to if I use MQExplorer (what I always used) or the MQ console :
On the MQ Explorer :
On the MQ Console, with the command : amqsbcg QUEUE_MQTT_VERIF MQTTVerification :
As you can see, in the console, the format field is empty, whereas on the MQExplorer it is MQHRF2. The messages are also different.
So the result on the MQConsole is right whereas the MQExplorer still shows a wrong result after the changes.
Note that the result is right only if changes has been done on both :
Subscription : ALTER SUB(APPLE.PRICES) PSPROP(NONE)
Queue : ALTER QLOCAL(PRICES) PROPCTL(NONE)
Maybe the source of the problem is just the display on MQExplorer software ?
EDIT:
The difference between MQExplorer and MQConsole was due to the parameter in MQ Explorer : Window -> Preferences -> WebSphereMQ Explorer -> Message properties -> Uncheck "Display message properties".
When redirecting publications made on a topic to a queue you probably have some definitions like this:-
DEFINE QLOCAL(PRICES)
DEFINE TOPIC(APPLES) TOPICSTR('Price/Fruit/Apples')
DEFINE SUB(APPLE.PRICES) TOPICOBJ(APPLES) DESTCLAS(PROVIDED) DEST(PRICES)
which redirects publications made on the topic string 'Price/Fruit/Apples' to the queue PRICES.
What you will find with such a set up however, is that the topic string is added to the message by the queue manager and thus adds an MQRFH2 header onto the front of your published message.
Message Descriptor (MQMD)
Report :00000000
Message Type :8 (Datagram)
Format :'MQHRF2 '
Priority :0
Persistence :0 (Not Persistent)
Message Id :414D51204D51473120202020202020202D77835720003702
'AMQ MQG1 -w.W .7.'
ReplyToQ :' '
ReplyToQMgr :'MQG1 '
[ 102 bytes] Message Content
<mqps>
<Top>
Price/Fruit/Apples
</Top>
</mqps>
Apples are $2/kilo
To remove this without changing the application reading from the queue, make this alteration to the subscription.
ALTER SUB(APPLE.PRICES) PSPROP(NONE)
This stops the queue manager even putting the topic string into the message in the first place.
From your MQ Explorer screenshot, it can be seen that the MQRFH2 is still present after the SUB is changed to PSPROP(NONE) because there is another property present - mqtt.clientid. Since there are other items in the MQRFH2 as well as the topic string, then the SUB change will not remove those - only the topic string added by the queue manager. In that case, you should try the following.
If alternatively you want to have the topic string there sometimes and only remove it for applications that don't want to see it, you can make a similar change to the queue, which can be over-ridden in application code to force the properties to be delivered to the application, but otherwise they won't be. This would also allow you to read any existing messages that had already been published (the change to the SUB isn't retrospectively applied to messages that are already on the queue).
ALTER QLOCAL(PRICES) PROPCTL(NONE)
This will mean that applications that don't specifically request MQGMO_FORCE_RFH2 will see the message without the MQRFH2. The amqsbcg sample is one such application.
If an application codes MQGMO_FORCE_RFH2 it will still be able to see the properties in an MQRFH2 header because it has explicitly asked for that. You cannot stop that by changing the queue.
Your problem is only now with the way MQ Explorer chooses to display the message. There is a parameter in MQ Explorer : Window -> Preferences -> WebSphereMQ Explorer -> Message properties -> Uncheck "Display message properties" which will stop it forcing them to be an MQRFH2, and then you'll be all good.
I have installed node.js server on shared hosting.I have drupal site in which I am using node.js integration module to connect to node.js server.
But whenever I am trying to broadcast message from admin panel, I am getting this error message "Error reaching the Node.js server "Error reaching the Node.js server at "nodejs/publish" with {"data":{"somecustomdata":"http://www.google.ca"},"channel":"nodejs_user_1","callback":"myowncallback","clientSocketId":""} "%{"data":{"somecustomdata":"http://www.google.ca"},"channel":"nodejs_user_1","callback":"myowncallback","clientSocketId":""}": [404] Not Found." in db log.
Any help would be appreciated.
It is very likely one of two things:
Drupal server is accessing wrong URI.
Node.js Server is not listening to the URI you expect it to.
Of course something less obvious might cause errors, but please verify those two before proceeding.
Best would be to get your Drupal server print in error logs the URI it is trying to access, and manually verify you can access it within your browser, or another tool.
Thanks "alandrev" for your help.I have resolved that issue on the same day but I forgot to add my mistake.Actually I was not configuring the nodejs correctly.I was using the incorrect port number on backend settings in nodejs.config.js file.The correct settings mentioned below:
backendSettings = {
"scheme":"https",
"host":"yourhostname",
"port":"port number which is not already in use",
'sslKeyPath': 'key file path for ssl enabled site otherwise leave empty',
'sslCertPath': 'certificate path for ssl enabled site otherwise leave empty',
'sslCAPath': '',
"resource":"/socket.io",
"baseAuthPath": '/nodejs/',
"publishUrl":"publish",
"serviceKey":"",
"backend":{
"port":443,
"scheme": 'https or http',
"host":"yourhostname",
"messagePath":"/nodejs/message/"},
"clientsCanWriteToChannels":false,
"clientsCanWriteToClients":false,
"extensions":"",
"debug":false,
"addUserToChannelUrl": 'user/channel/add/:channel/:uid',
"publishMessageToContentChannelUrl": 'content/token/message',
"jsMinification":true,
"jsEtag":true,
"logLevel":1};
Solved this same issue by adding "polling" to the transport
backendSettings = {
"scheme":"http",
"host":"localhost",
"port":8081,
"key":"/path/to/key/file",
"cert":"/path/to/cert/file",
"resource":"/socket.io",
"publishUrl":"publish",
"serviceKey":"SERVICE KEY",
"backend":{
"port":80,
"host":"localhost",
"messagePath":"/mysite/nodejs/message/"},
"clientsCanWriteToChannels":true,
"clientsCanWriteToClients":true,
"extensions":"",
"debug":true,
"transports":["websocket","polling",
"flashsocket",
"htmlfile",
"xhr-polling",
"jsonp-polling"],
"jsMinification":true,
"jsEtag":true,
"logLevel":1};
Long shot I guess, with the lack of real information that I am offering at this stage. I'll gladly offer up some more details on how to reproduce the issue - but wanted some fast feedback to see if there was a gotcha somewhere I was missing.
I've a simple ServiceStack hello world application, in which I'm playing with the Facebook Auth Provider:
Vanilla ServiceStack
Vanilla Facebook Auth Proivider
Vanilla User Session
Vanilla OrmLite User Repository
Vanilla OrmLite MySql Db Factory
When debugging on my local machine - on Windows 7 (and 8); everything works a treat. The service launches, the database tables are created and I can login via Facebook and records are inserted to the relevant tables.
When running the service on Ubuntu inside a Vagrant Box (running in Virtual Box as the provider for virtualization, hosted on nginx with mono-fastcgi) - the service launches correctly and I can see that the tables are created in the MySql database. When I hit /auth/facebook I am correctly forwarded to Facebook - but I hit an error when the callback to the service occurs.
This is the current output:
[Auth: 07/30/2013 13:02:47]: [REQUEST: {provider:facebook}] System.NullReferenceException: Object reference not set to an instance of an object at
ServiceStack.ServiceInterface.Auth.FacebookAuthProvider.Authenticate (ServiceStack.ServiceInterface.IServiceBase,ServiceStack.ServiceInterface.Auth.IAuthSession,ServiceStack.ServiceInterface.Auth.Auth) <0x0061e> at
ServiceStack.ServiceInterface.Auth.AuthService.Authenticate (ServiceStack.ServiceInterface.Auth.Auth,string,ServiceStack.ServiceInterface.Auth.IAuthSession,ServiceStack.ServiceInterface.Auth.IAuthProvider) <0x000a7> at
ServiceStack.ServiceInterface.Auth.AuthService.Post (ServiceStack.ServiceInterface.Auth.Auth) <0x00303> at
ServiceStack.ServiceInterface.Auth.AuthService.Get (ServiceStack.ServiceInterface.Auth.Auth) <0x00013> at (wrapper dynamic-method) object.lambda_method (System.Runtime.CompilerServices.Closure,object,object) <0x0004f> at
ServiceStack.ServiceHost.ServiceRunner`1<ServiceStack.ServiceInterface.Auth.Auth>.Execute (ServiceStack.ServiceHost.IRequestContext,object,ServiceStack.ServiceInterface.Auth.Auth) <0x00416>
It is clearly reaching the Service (which I'm accessing via localhost:8080 which maps through to the guest machine on port 80); as the error is wrapped nicely in ServiceStack output.
I don't suppose anyone has any clues?
Okay after an evening of investigation - I've found the root cause.
Line 51 of FacebookAuthProvider.cs calls off to Line 28 of WebRequestExtensions.cs - which in turn calls Line 227 of WebRequestExtensions.cs.
This method call fails at line 255-ish - essentially because Mono by default doesn't trust any SSL certificates by default: as explained here..
Instead of figuring out the correct configuration for Mono - I've taken the nasty route (for the time being at least); of using the following line in my AppHostBase.Configure implementation:
F#
System.Net.ServicePointManager.ServerCertificateValidationCallback <- new RemoteCertificateValidationCallback(fun _ _ _ _ -> true)
C#
System.Net.ServicePointManager.ServerCertificateValidationCallback += (a, b, c, d) => { return true; };
I am now up and running (like a fully-operational Death Star).
I have a SharePoint 2013 installation on a Window 8 machine.
I am trying to create a web application and it is taking forever. The creation process never stops. I checked in application event logs and found this error:
*Machine 'SHAREPOINT2013C (SharePoint - 43000(_LM_W3SVC_1458308317_ROOT))' failed ping validation and has been unavailable since '1/22/2013 3:56:48 AM'.*
Searched the web but could not find anything that works for me.
Can anyone suggest a way to resolve the issue? Thanks a lot in advance.
Below are my findings:
In order to recognize routing targets IIS has to be able to process SPPING HTTP method
To test run this code in Powershell:
$url = "http://your-Routing-Target-Server-Name"
$myReq = [System.Net.HttpWebRequest]::Create($url)
$myReq.Method = "SPPING";
$response = $myReq.GetResponse();
$response.StatusCode
If you get the following error message:
Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (405) Method Not Allowed."
that means that web front end is not set up to process SPPING HTTP method
To resolve the issue run the following commands on each routing target server:
Import-Module WebAdministration
add-WebConfiguration /system.webserver/handlers "IIS:\" -value #{
name = "SPPINGVerbHandler"
verb = "SPPING"
path = "*"
modules = "ProtocolSupportModule"
requireAccess = "None"
}
This will add a handler for SPPING verb to IIS configuration.
Run the test script again to make sure this works.
So this has to do with the Request Management Service that runs on the WFE servers on SharePoint 2013. The Request Management Service is of no value since you only have one server. If you disable this service on your single server farm these messages will go away and your Web Application creation performance will greatly increase.
Mark Ringo
I recently faced this issue, I created new Web Application and it was showing a popup of "It shouldn't take long", then after some time it showed a Connection failure page. I browsed to the virtual directory folder for the new web application and found that the folder was totally empty.
Then what I did to solve this problem:
1. Open IIS
2. Go to Applicatin Pools
3. Select Central Admin application pool and right click and select "Advance Settings".
4. There was a property named "Shutdown Time Limit", it was set to "90" by default. I changed it to 400 and clicked OK.
It restarted the applicaition pool automatically. Then again I created new web application from central admin and it worked for me.
I've found that these events correlate to when the specified application pools are recycled (mine are at a specific time in the morning). It's unfortunate that they're logged in the event viewer and can't really clean it up.
I am attempting to obtain a data feed from yahoo finance. I am doing this with the following code:
System.Net.WebRequest request = System.Net.WebRequest.Create(http://download.finance.yahoo.com/download/quotes.csv?format=sl&ext=.csv&symbols=^ftse,^ftmc,^ftas,^ftt1x,^dJA);
request.UseDefaultCredentials = true;
// set properties of the request
using (System.Net.WebResponse response = request.GetResponse())
{
using (System.IO.StreamReader reader = new System.IO.StreamReader(response.GetResponseStream()))
{
return reader.ReadToEnd();
}
}
I have placed this code into a console application and, using Console.WriteLine on the output I receive the information I require. I have used the 'Run as..' command to execute this using a specific domain account.
When I use this code from within a Page load I receive the following error message "No connection could be made because the target machine actively refused it 76.13.114.90:80".
This seems to suggest that the call is reaching yahoo (is this true?) and that there is something missing.
This would suggest there is an identity difference in the calls between the console application and application pool.
Environment is: Windows Server 2003, IIS 6.0, .net 4.0
"Target machine actively refused it" indicates that the TCP connection itself is not succeeding. This could be due to the fact that the Proxy settings when run under IIS are not the same as those that apply when you run in the console.
You can fix this by setting a WebProxy on your request, that points to the proxy server being used in the environment.
Yes, an active refusal is indication that the target machine is receiving the request and the information in the headers is either incorrect or insufficient to process the request. It is entirely possible that if you had to run this call using a "run as" command in console that the application pool's identity user does not have the appropriate permission or username. You can attempt to change the identity user to this specific domain account to see if that alleviates the problem, but you may have to isolate this particular function into its own application pool in order to protect the rest of the website from having this specification.