I have been using Zabbix for a while now. I tried to configure the telegram media type so as to receive notifications. Due to some error, I'm not receiving any notification. While testing the media type this is the error that appears on the log. Please help me resolve this.
Media type test log
00:00:00.000 [Debug] [Telegram Webhook] URL: https://api.telegram.org/bot/sendMessage
00:00:00.000 [Debug] [Telegram Webhook] params: {"chat_id":"-xyxyxyxyxy","text":"{ALERT.SUBJECT}\n{ALERT.MESSAGE}","disable_web_page_preview":true,"disable_notification":false}
00:00:05.183 [Debug] [Telegram Webhook] HTTP code: 200
00:00:05.184 [Debug] [Telegram Webhook] notification failed: TypeError: cannot read property 'ok' of null
Related
I'm completely new to RabbitMQ and now I'm looking for a configuration error. The client doesn't receive any messages from RabbitMQ and I debugged it as far as possible.
Frontend messages:
Message 1:
CONNECT
login:frontend_listener
passcode:xxx
accept-version:1.0,1.1,1.2
heart-beat:20000,0
Message 2:
ERROR
message:Bad CONNECT
content-type:text/plain
version:1.0,1.1,1.2
content-length:30
Virtual host '/' access denied
There are two vHosts: / and someVhost and there are different users like frontend_listener. Now I found a way to access the log file.
RabbitMQ log file:
2020-02-11 15:50:53.579 [warning] <0.798.0> STOMP login failed for user "frontend_listener"
2020-02-11 15:50:53.579 [error] <0.798.0> STOMP error frame sent:
Message: "Bad CONNECT"
Detail: "Access refused for user 'frontend_listener'\n"
Server private detail: none
...
2020-02-11 15:51:25.349 [info] <0.850.0> Creating user 'frontend_listener'
2020-02-11 15:51:30.374 [info] <0.857.0> Setting permissions for 'frontend_listener' in 'someVhost' to '$', '$', 'client-notification.*'
2020-02-11 15:51:54.980 [warning] <0.867.0> STOMP login failed - not_allowed (vhost access not allowed)~n
2020-02-11 15:51:54.980 [error] <0.867.0> STOMP error frame sent:
Message: "Bad CONNECT"
Detail: "Virtual host '/' access denied"
Server private detail: none
2020-02-11 15:52:56.427 [warning] <0.875.0> STOMP login failed - not_allowed (vhost access not allowed)~n
It reads like the permissions are wrong. Can someone help me out interpreting that correctly?
I try to read it: User frontend_listener wants to access the vHost /, but it hasn't sufficient permissions (don't know what $ here mean other than a part of regular expression). The thing is, that I don't know if that is the correct vHost. How do I find out the URL of each vHost?
I'm asking this because I believe that the mapping to the vHost is wrong or something is missing.
Edit:
After adding host: 'someVhost' to my stomp-config.ts I was able to subscribe to the queues. Now I get the following error in the log:
2020-02-12 16:32:25.913 [error] <0.5159.1> Channel error on connection <0.5149.1> (127.0.0.1:58136 -> 127.0.0.1:15674, vhost: 'someVhost', user: 'frontend_listener'), channel 1:
operation basic.consume caused a channel exception access_refused: access to queue 'stomp-subscription-SZ3-PO1-PbZroPol-WXSQw' in vhost 'someVhost' refused for user 'frontend_listener'
2020-02-12 16:32:26.022 [error] <0.5145.1> STOMP error frame sent:
Message: access_refused
On the frontend I don't get a message or error.
You need to also pass host information in the STOMP CONNECT frame..
this is what the specifications says and clients MUST set this header
host : The name of a virtual host that the client wishes to connect to. It is recommended clients set this to the host name that the socket was established against, or to any name of their choosing. If this header does not match a known virtual host, servers supporting virtual hosting MAY select a default virtual host or reject the connection.
So this is how your CONNET frame should look
CONNECT
login:frontend_listener
passcode:xxx
accept-version:1.0,1.1,1.2
host: someVhost
heart-beat:20000,0
Scope: This is a network with one channel composed of 3 Orgs, 1 anchor peer per organization, 1 CA per org and 1 MSP per org.
I'm facing an issue on my Hyperledger Fabric network related to the TLS handshake process that occurs when I make an invoke call to my chaincode (which is correctly installed and instantiated) through the CLI container.
ORDERER
[core.comm] ServerHandshake -> ERRO 01b TLS handshake failed with error tls: first record does not look like a TLS handshake {"server": "Orderer", "remote address": "192.168.0.23:55806"}
CLI
Error: error sending transaction for invoke: could not send: EOF - proposal response: version:1 response:<status:200 >
I couldn't find a solution to that so any kind of help would be great.
EDIT: I'm also having warnings like this one in the orderer container when I update the anchor peers:
2018-12-12 14:06:00.518 UTC [common.deliver] Handle -> WARN 014 Error reading from 192.168.32.23:43938: rpc error: code = Canceled desc = context canceled
2018-12-12 14:06:00.518 UTC [comm.grpc.server] 1 -> INFO 016 streaming call completed {"grpc.start_time": "2018-12-12T14:06:00.509Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Deliver", "grpc.peer_address": "192.168.32.23:43938", "error": "rpc error: code = Canceled desc = context canceled", "grpc.code": "Canceled", "grpc.call_duration": "8.958614ms"}
2018-12-12 14:06:00.518 UTC [orderer.common.broadcast] Handle -> WARN 015 Error reading from 192.168.32.23:43940: rpc error: code = Canceled desc = context canceled
2018-12-12 14:06:00.518 UTC [comm.grpc.server] 1 -> INFO 017 streaming call completed {"grpc.start_time": "2018-12-12T14:06:00.511Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Broadcast", "grpc.peer_address": "192.168.32.23:43940", "error": "rpc error: code = Canceled desc = context canceled", "grpc.code": "Canceled", "grpc.call_duration": "7.13278ms"}
2018-12-12 14:06:10.328 UTC [comm.grpc.server] 1 -> INFO 018 streaming call completed {"grpc.start_time": "2018-12-12T14:06:05.692Z", "grpc.service": "orderer.AtomicBroadcast", "grpc.method": "Deliver", "grpc.peer_address": "192.168.32.13:40886", "grpc.peer_subject": "CN=peer1.farmer.supply-chain-network.com,L=San Francisco,ST=California,C=US", "error": "context finished before block retrieved: context canceled", "grpc.code": "Unknown", "grpc.call_duration": "4.636199388s"}
Thanks in advance
Seems like the orderer was expecting a tls connection but cli did not connect with tls.
Did you properly specify --tls --cafile <orderer-cert> during invoke?
Here's a interesting problem I started facing since migrating from Heroku to Google Container Engine:
Since moving to GCE, after a few hours after server start/restart/deploy, out of nowhere, my Elixir application can't deliver push notifications to APNS any longer. I'm using the apns4ex library. Here is roughly what I found out so far:
Internally on init, the library opens a :ssl (erlang) socket to APNS and keeps recycling that inside a GenServer process
def connect_socket(host, port, opts, timeout_seconds) do
address = "#{host}:#{port}"
case :ssl.connect(host, port, opts, timeout_seconds * 1000) do
{:ok, socket} ->
APNS.Logger.debug("successfully connected to #{address}")
{:ok, socket}
{:error, reason} ->
APNS.Logger.error("failed to connect to push socket #{address}, reason given: #{inspect(reason)}")
{:error, {:connection_failed, address}}
end
end
Now, from hour x, after attempting to send a message, the library starts receiving the :ssl_closed message/callback to indicate that the SSL connection got closed
def handle_info({:ssl_closed, socket}, %{socket_apple: socket} = state) do
APNS.Logger.debug("ssl socket closed, returning :connect")
{:connect, {:error, "ssl_closed"}, %{state | socket_apple: nil}}
end
How it handles this is that it just let's the connection close and returns :connect, which will then re-connect to APNS (here)
Once push notifications stop working, the debug log always reports the following pattern on every message.
Attempt to send the message
Report "success sending" (nothing is being delivered to the phones. This message is caused by :ssl.send reporting :ok)
Then receive a ssl socket close message
Reconnect to gateway.push.apple.com (:ssl.connect returns :ok)
Repeat
send_package code:
def send_package(socket, packet) do
result = :ssl.send(socket, [packet])
case result do
:ok ->
APNS.Logger.debug("success sending ssl package")
{:error, reason} ->
APNS.Logger.warn("error #{reason} sending ssl package")
end
result
end
In contrast, on successful sending it stops at point 2.
Here is some raw log output from my app when sending a push (notice the last 9 lines showing the pattern I described)
01:41:14.820 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending in poolboy transaction :myapp
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending in poolboy transaction :myapp
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handling cast :send
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 message's payload looks good
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending in poolboy transaction :myapp
01:41:14.822 [debug] [APNS] #PID<0.349.0> success sending ssl package
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 success sending
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handle call :send received :ok
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handling cast :send
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 message's payload looks good
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending message
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [info] Sent 200 in 22ms
01:41:14.823 [debug] [APNS] #PID<0.348.0> success sending ssl package
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 success sending
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handle call :send received :ok
01:41:14.823 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handling cast :send
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e message's payload looks good
01:41:14.824 [debug] [APNS] #PID<0.347.0> success sending ssl package
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e success sending
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handle call :send received :ok
01:41:15.027 [debug] [APNS] #PID<0.348.0> ssl socket closed, returning :connect
01:41:15.029 [debug] [APNS] #PID<0.347.0> ssl socket closed, returning :connect
01:41:15.043 [debug] [APNS] #PID<0.349.0> ssl socket closed, returning :connect
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to gateway.push.apple.com:2195
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to socket
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to gateway.push.apple.com:2195
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to socket
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to gateway.push.apple.com:2195
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to socket
One theory is that GCE is closing the connection for being idle but this doesn't explain why another message after reconnect immediately results in the same pattern. Also why does the socket only close after sending with :ssl.send?
I have same issue with apns4erl, when socket close after trying send message, but problem was on my side, do not remember, it was either in the wrong certificate file or malformed messages
I am using Akka.Remote to communicate between a server-side service application and multiple desktop client applications. The clients send a request message to the server (using Akka.net) and waits for the server to reply with a response message. The client applications are transient, meaning that they often connect to the server, stay connected for some time, disconnect and then reconnect again.
The problem I encountered is that sometimes when a client disconnects from the server actor (by shutting down its ActorSystem) and then reconnects back to the server, it does not receive any replies from the server for some time. After a few minutes the communication works without any problems. I found out that this issue occurs when the server sends a reply to a client that has disconnected during the request and is no longer reachable. The server cannot deliver the response message and it somehow marks the client endpoint as invalid.
In the log (on the server side) I am getting the following messages when the client is disconnected.
[DEBUG] 2016-01-21 13:04:58.6151 received AutoReceiveMessage <Terminated>: [akka.tcp://qb#client:8090/user/qb] - ExistenceConfirmed=True ServerActor
[DEBUG] 2016-01-21 13:04:58.6550 Stopped Akka.Remote.Transport.ProtocolStateActor
[ INFO] 2016-01-21 13:04:58.6550 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. Akka.Event.DummyClassForStringSources
[DEBUG] 2016-01-21 13:04:58.6725 Stopped Akka.Remote.ReliableDeliverySupervisor
[DEBUG] 2016-01-21 13:04:58.6725 no longer watched by [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-2] Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:04:58.6725 Disassociated [akka.tcp://myservice#server:8081] <- akka.tcp://qb#client:8090 Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:04:58.6725 Stopped Akka.Remote.EndpointWriter
And then when the client attempts to reconnect, I get:
[DEBUG] 2016-01-21 13:05:15.5883 ConnectResponse [akka.tcp://qb#client:8090/user/qb] ServerActor
[DEBUG] 2016-01-21 13:05:16.0467 Started (Akka.Remote.Transport.ProtocolStateActor) Akka.Remote.Transport.ProtocolStateActor
[DEBUG] 2016-01-21 13:05:16.0467 Stopped Akka.Remote.Transport.ProtocolStateActor
[ WARN] 2016-01-21 13:05:16.0467 AssociationError [akka.tcp://myservice#server:8081] -> akka.tcp://qb#client:8090: Error [Invalid address: akka.tcp://qb#client:8090] [] Akka.Remote.EndpointWriter
[ INFO] 2016-01-21 13:05:16.0467 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. Akka.Event.DummyClassForStringSources
[DEBUG] 2016-01-21 13:05:16.0643 Stopped Akka.Remote.ReliableDeliverySupervisor
[DEBUG] 2016-01-21 13:05:16.0711 no longer watched by [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-4] Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0711 Disassociated [akka.tcp://myservice#server:8081] -> akka.tcp://qb#client:8090 Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0711 Stopped Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0867 received AutoReceiveMessage <Terminated>: [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-4] - ExistenceConfirmed=True Akka.Remote.EndpointManager
[DEBUG] 2016-01-21 13:05:16.0867 Terminated [akka.tcp://qb#client:8090/user/qb] ServerActor
I suspect that this behavior is a feature of Akka.net, however, I need to implement my system so that clients can disconnect and then reconnect back to the server without the need to wait. Is there any way to disable the quarantine mechanism or to gracefully close the client endpoint on the server so that the client endpoint doesn't get quarantined?
[ INFO] 2016-01-21 13:04:58.6550 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. - that says it all. The node was quarantined which requires a restart of the actor system.
However, IMHO - just upgrade to Akka.NET 1.0.6, which we released on Monday. We made the remoting policy manager much less brittle than it has been historically.
I'm working on an API for my website, using ActiveMQ and Camel in order iPhones to connect via Stomp protocol.
The body of the message is a JSON with different parameters that I will then pass to a PHP web app, for example Post data, and so on.
We got a form on the iphone, with a "textarea". If I submit a simple line, without carriage returns, ActiveMQ and Camel handle it, pass it to my PHP app which save it in DB, and everything is fine.
But when there is a carriage return in the textarea value, encoded as "%0A", ActiveMQ raises an exception, and the PHP app is not called.
In my apache error log, I only have this line :
[Mon May 14 16:08:54 2012] [error] [client 127.0.0.1] An URL must be provided
In my ActiveMQ log I have (I havent pasted all of it, only the first raise) :
2012-05-14 16:42:22,038 | DEBUG | Caused by: [org.apache.camel.RuntimeCamelException - org.apache.camel.component.http.HttpOperationFailedException: HTTP operation failed invoking http//localapi:80/api_dev.php/dispatcher with statusCode: 500] | org.apache.camel.component.jms.EndpointMessageListener | Camel (camel) thread #0 - JmsConsumer[query]
org.apache.camel.RuntimeCamelException: org.apache.camel.component.http.HttpOperationFailedException: HTTP operation failed invoking http//localapi:80/api_dev.php/dispatcher with statusCode: 500
at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1139)
at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:115)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560)
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1056)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1048)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: org.apache.camel.component.http.HttpOperationFailedException: HTTP operation failed invoking http//localapi:80/api_dev.php/dispatcher with statusCode: 500
at org.apache.camel.component.jetty.DefaultJettyHttpBinding.populateHttpOperationFailedException(DefaultJettyHttpBinding.java:143)
at org.apache.camel.component.jetty.DefaultJettyHttpBinding.populateResponse(DefaultJettyHttpBinding.java:61)
at org.apache.camel.component.jetty.JettyContentExchange.doTaskCompleted(JettyContentExchange.java:149)
at org.apache.camel.component.jetty.JettyContentExchange.onResponseComplete(JettyContentExchange.java:86)
at org.eclipse.jetty.client.HttpExchange$Listener.onResponseComplete(HttpExchange.java:887)
at org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:258)
at org.eclipse.jetty.client.HttpConnection$Handler.messageComplete(HttpConnection.java:580)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:314)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211)
at org.eclipse.jetty.client.HttpConnection.handle(HttpConnection.java:254)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
... 1 more
The message's body looks like :
Message:
body={
"session_id":"XXXX",
"method":"post",
"params":{
"post":{
"form_name":{
"field_name":"foo%0Abar"
}
}
},
"url":"/my_object/update",
"query_id":"XXX"
}
My ActiveMQ conf is made with Spring, as I'm not too much (at all) into Java
Thank you for any clue