mapViewer widget doesn't show map markers - fiware

Following my previous question Rush installation and integration with Orion Context Broker I have Rush Relayer working properly, but it still doesn't let me show the markers on the mapViewer.
What I get in my instance is:
INFO#21:01:23 clientSocketHttp.cpp[348]: Notification Successfully Sent to localhost:5001/callbacks/23:01:42-1:23:01:45-1
INFO#21:01:23 clientSocketHttp.cpp[359]: Transaction ended
time=2015-01-14T21:01:23.305Z | lvl=INFO | op=RELAY REQUEST | msg=Relay Request received | corr=N/A | trans=7f1d7e00-9c30-11e4-b26a-090df9e0789f | hostname=fiware | component=listener | userID='127.0.0.1' | reqInfo={ url: '/callbacks/23:01:42-1:23:01:45-1', method: 'POST', remoteAddress: '127.0.0.1', headers: { 'x-relayer-host': 'ngsiproxy.lab.fi-ware.org:443', 'x-relayer-protocol': 'https', 'x-relayer-proxy': undefined, 'x-relayer-retry': undefined, 'x-relayer-httpcallback': undefined, 'x-relayer-persistence': undefined, 'x-relayer-traceid': undefined, 'x-relayer-encoding': undefined, 'content-type': 'application/xml' }, responseTime: 8, statusCode: 201, bodyLength: 3323, id: { id: '7f1d7e00-9c30-11e4-b26a-090df9e0789f' } }
Everything seems to work well but I can't see the markers on the mapViewer.

As far as it is Rush related, it would be important to have the traces at the Consumer process, there we could see if there is any problem with the relay itself. The listener just tell us that Rush has created a relay task.
Could you please post that traces?

Related

How to enable NGSIv2 in iotagent-ul helmchart?

I received {"name":"BAD_REQUEST","message":"Request error connecting to the Context Broker: 501"} error when when I send a POST to iotagent-ul deployed via iotagent-ul helm chart.
time=2022-10-08T09:03:18.182Z | lvl=DEBUG | corr=d7ed414d-a132-45ea-b4a3-38ee14a828dc | trans=d7ed414d-a132-45ea-b4a3-38ee14a828dc | op=IoTAgentNGSI.Request | from=n/a | srv=openiot | subsrv=/ | msg=Response {
"error": "NotImplemented",
"description": "Only NGSIv1-based forwarding supported at the present moment. Set explictely legacyForwarding to true"
}
Following the iotagent-ul documentation to enable NGSIv2, it must be set ngsiVersion in contextBroker:
{
host: '192.168.56.101',
port: '1026',
ngsiVersion: 'v2'
}
Since I am using the official fiware helm-chart, I have updated the configmap.yaml to include the ngsiVersion
contextBroker: {
/**
* Host where the Context Broker is located.
*/
host: '{{ .Values.iota.contextBroker.host }}',
/**
* Port where the Context Broker is listening.
*/
port: '{{ .Values.iota.contextBroker.port }}',
/**
* ngsiVersion supported by the Context Broker.
*/
ngsiVersion: '{{ .Values.iota.contextBroker.ngsiVersion }}'
}
Now, I get this error:
time=2022-10-08T18:17:24.614Z | lvl=ERROR | corr=841d2b61-463e-42ff-acd7-d0f4b867b7b3 | trans=841d2b61-463e-42ff-acd7-d0f4b867b7b3 | op=IoTAgentNGSI.DeviceService | srv=openiot | subsrv=/ | msg=Registration error connecting to the Context Broker: {"code":"400","reasonPhrase":"Bad Request","details":"missing isDomain value for registration attribute"} | comp=IoTAgent
According to comments on the question, you are using Orion-LD instead of official Orion. The Orion-LD support to NGSIv2 is limited, so I'd suggest to change your context broker to official Orion newest version (3.7.0 at the moment of writing this).

Suddenly my instance stopped responding to my incoming connections for mysql connections

I had installed mysql on gcp instance for dev and test purposes. Everything was working perfect but suddenly started getting connection timed out error. Firewall is opened on for MySQL connections. It was working perfectly, suddenly it stopped.
Here is the log for the connection
{
inserted: "xxxxxx"
jsonPayload: {
connection: {
dest_ip: "10.142.0.2"
dest_port: 3306
protocol: 6
src_ip: "54.87.222.27"
src_port: 52638
}
disposition: "ALLOWED"
instance: {
project_id: "xxxxxxxx"
region: "us-east1"
vm_name: "stockarea-server"
zone: "us-east1-b"
}
remote_location: {
city: "Ashburn"
continent: "America"
country: "usa"
region: "Virginia"
}
rule_details: {
action: "ALLOW"
direction: "INGRESS"
ip_port_info: [
0: {
ip_protocol: "TCP"
port_range: [
0: "3306"
]
}
1: {
ip_protocol: "UDP"
port_range: [
0: "3306"
]
}
]
priority: 1000
reference: "network:default/firewall:heroku-sql"
source_range: [
0: "0.0.0.0/0"
]
}
vpc: {
project_id: "xxxxxxxx"
subnetwork_name: "default"
vpc_name: "default"
}
}
logName: "projects/pxxxxxxx/logs/compute.googleapis.com%2Ffirewall"
receiveTimestamp: "2020-05-22T18:25:57.341545693Z"
resource: {
labels: {
location: "us-east1-b"
project_id: "xxxxxxxx"
subnetwork_id: "5137290941342062105"
subnetwork_name: "default"
}
type: "gce_subnetwork"
}
timestamp: "2020-05-22T18:25:45.934585080Z"
}
I have MySQL users having permission to get access for different IP address:
+------------------+-----------+
| user | host |
+------------------+-----------+
| client | % |
| stockarea | % |
| debian-sys-maint | localhost |
| mysql.session | localhost |
| mysql.sys | localhost |
| root | localhost |
UPDATE:
I saw MySQL error.log file and saw somebody attacked and has somehow crashed the database. It was throwing error packet getting out of order. I reinstalled the MySQL for now to solve this and continue my development.
Hi I tried to ping your external IP and it works. So all 80, 443, and 3306. I believe your firewall is setup correctly, Please make sure your service is running and listening to those ports.
And finally, please be aware that you should sanitize private inforamtion such as ip address and project ID in public forum

Error validating token. Proxy not authorized in keystone. Keystone authentication

I was trying to incorporate IDM (Docker) latest, and pep-proxy (git example running with node server).
When I started pep-proxy, everything was working as intended.
I've got the following messages:
INFO: Server - Starting PEP proxy in port 80. IdM authentication...
Server - Success authenticating PEP proxy. Proxy Auth-token: d9badf48-16fa-423d-884c-a3e155578791
Now a problem happens. When I enter the wrong token I get this error.
ERROR: IDM-Client - Error validating token.
Proxy not authorized in keystone. Keystone authentication ...
ERROR: Server - Caught exception:
SyntaxError: Unexpected token u in JSON at position 0
As far as I understand I am expecting some return like invalid token, etc.. instead I get this error in pep-proxy and my curl command show->(52) Empty reply from server.
My config.json of pep-proxy:
var config = {};
// Used only if https is disabled
config.pep_port = 80;
// Set this var to undefined if you don't want the server to listen on HTTPS
config.https = {
enabled: false,
cert_file: 'cert/cert.crt',
key_file: 'cert/key.key',
port: 443
};
config.idm = {
host: 'localhost',
port: 3000,
ssl: false
}
config.app = {
host: 'www.google.es',
port: '80',
ssl: false // Use true if the app server listens in https
}
// Credentials obtained when registering PEP Proxy in app_id in Account Portal
config.pep = {
app_id: 'xxxxxx',
username: 'xxxxxx',
password: 'xxxxxx',
trusted_apps : []
}
// in seconds
config.cache_time = 300;
// if enabled PEP checks permissions with AuthZForce GE.
// only compatible with oauth2 tokens engine
//
// you can use custom policy checks by including programatic scripts
// in policies folder. An script template is included there
config.azf = {
enabled: true,
protocol: 'http',
host: 'localhost',
port: 8080,
custom_policy: undefined // use undefined to default policy checks (HTTP verb + path).
};
// list of paths that will not check authentication/authorization
// example: ['/public/*', '/static/css/']
config.public_paths = [];
config.magic_key = 'undefined';
module.exports = config;
IDM logs:
fiware-idm_1 | GET
/user?access_token=7cb25729577c2e01dc337314dcd912ec981dc49b 401 4.445 ms - 116
fiware-idm_1 | Executing (default): SELECT email, 'user' as Source FROM
user WHERE email='pep_proxy_edf60435-7de7-4875-85a9-cf68b8838b8c'
fiware-idm_1 | UNION ALL
fiware-idm_1 | SELECT id, 'pep_proxy' as Source FROM
pep_proxy WHERE id='pep_proxy_edf60435-7de7-4875-85a9-cf68b8838b8c';
fiware-idm_1 | Executing (default): SELECT `id`, `password`,
`oauth_client_id` FROM `pep_proxy` AS `PepProxy` WHERE `PepProxy`.`id` =
'pep_proxy_edf60435-7de7-4875-85a9-cf68b8838b8c';
fiware-idm_1 | Executing (default): INSERT INTO `auth_token`
(`access_token`,`expires`,`valid`,`pep_proxy_id`) VALUES ('a0d54a6f-
8461-4000-bb80-5fb60193bcb4','2018-05-04
11:45:21',true,'pep_proxy_edf60435-7de7-4875-85a9-cf68b8838b8c');
fiware-idm_1 | POST /v3/auth/tokens 201 13.733 ms - 74
The error "SyntaxError: Unexpected token u in JSON at position 0", as stated here, is probably due to some place at the code where JSON.parse is called with an undefined parameter. You are getting this message because the error was not properly treated and the exception is being thrown (exception not treated).
In the Wilma PEP Proxy github, we can see the latest changes at the code and we can guess/infer where this error comes from.
I think you can open an issue at github.

No remote stream using kurento docker image with kurento hello world example on host

I installed a KMS container on my server and I downloaded kurento hello world java application on my server but when I go to my java web application using my server IP adress I have to remote stream and and the following error (in firefox):
ICE failed, see about:webrtc for more details
in the about:webrtc It tells me that there is no STUN and no TURN server specified (and a lot of following output not very clear to me) The problem is that I specified a STUN server on the WebRtcEndpoint.conf.ini.
Here is my docker-compose.yml file:
kurento:
image: fiware/stream-oriented-kurento:latest
volumes:
- ./kurento.conf.json:/etc/kurento/kurento.conf.json:ro
- ./defaultCertificate.pem:/etc/kurento/defaultCertificate.pem:ro
- ./WebRtcEndpoint.conf.ini:/etc/kurento/modules/kurento/WebRtcEndpoint$
ports:
- "8888:8888"
- "8433:8433"
here is my kurento.conf.json file:
{
"mediaServer" : {
"resources": {
// //Resources usage limit for raising an exception when an object creatio$
// "exceptionLimit": "0.8",
// // Resources usage limit for restarting the server when no objects are $
// "killLimit": "0.7",
// Garbage collector period in seconds
"garbageCollectorPeriod": 240
},
"net" : {
"websocket": {
"port": 8888,
"secure": {
"port": 8433,
"certificate": "defaultCertificate.pem",
"password": ""
},
//"registrar": {
// "address": "ws://localhost:9090",
// "localAddress": "localhost"
//},
"path": "kurento",
"threads": 10
}
}
}
}
and my WebRtcEndpoint.conf.ini
; Only IP address are supported, not domain names for addresses
; You have to find a valid stun server. You can check if it works
; usin this tool:
; http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
stunServerAddress=62.71.2.168
stunServerPort=3478
; turnURL gives the necessary info to configure TURN for WebRTC.
; 'address' must be an IP (not a domain).
; 'transport' is optional (UDP by default).
; turnURL=user:password#address:port(?transport=[udp|tcp|tls])
;pemCertificate is deprecated. Please use pemCertificateRSA instead
;pemCertificate=<path>
;pemCertificateRSA=<path>
;pemCertificateECDSA=<path>
and the certificate has been generated with :
certtool --generate-privkey --outfile defaultCertificate.pem
echo 'organization = your organization name' > certtool.tmpl
certtool --generate-self-signed --load-privkey defaultCertificate.pem \
--template certtool.tmpl >> defaultCertificate.pem
sudo chown kurento defaultCertificate.pem
and I went on my https://localhost:8433/kurento to validate the certificate
When I start the kurento container with docker-compose up I can see on the logs that my conf. file has been loaded:
kurento_1 | "websocket":
kurento_1 | {
kurento_1 | "port": "8888",
kurento_1 | "secure":
kurento_1 | {
kurento_1 | "port": "8433",
kurento_1 | "certificate":
"defaultCertificate.pem",
kurento_1 | "password": ""
kurento_1 | },
kurento_1 | "path": "kurento",
kurento_1 | "threads": "10"
kurento_1 | }
.....
kurento_1 | "WebRtcEndpoint":
kurento_1 | {
kurento_1 | "stunServerAddress": "62.71.2.168",
kurento_1 | "stunServerPort": "3478",
kurento_1 | "configPath":
"\/etc\/kurento\/modules\/kurento"
kurento_1 | },
and I start the hello world example with :
sudo mvn compile exec:java -Dkms.url=wss://localhost:8433/kurento
at this point everything seems to work OK, no error output.
When I try to access my web application from a client with https://:8443 the web page is loaded correctly and can start the stream. But I have no remote stream and have the error I printed at the beginning.
UPDATE 1
I changed the version of the kurento image in docker-compose.yml from
image: fiware/stream-oriented-kurento:latest
to:
image: fiware/stream-oriented-kurento:6.6.0
And now it is working sometimes. I have the same error (ICE failed, see about:webrtc for more details) but if I reload the page multiple time, it end up working after some reload. Any suggestion about what I am doing wrong?
UPDATE 2
I realized that when the web application start working (after multiple reload), the next time I access the web applicaiton, it will always work, until I restart the KMS. Then I have to reaload the page multiple time again to have the remote stream.
Now that I realized that, I tried again with image: fiware/stream-oriented-kurento:latest and it has the exact same behavior. I have to reload multiple time the page to make it work. I have no clue why is that, any idea?
Looking into your problem I feel the ICE candidates have not been created properly on both sides.
Have you configured the STUN / TURN in the webApplication (JS)?
If you haven't modify the example I believe they are not configured by default
Check into the options.configuration. Example:
var options = {
........ some options here ....
configuration: {
iceServers:[{
"url": "turn:xxx.xxx.xxx:port",
"username": "xxxxxx",
"credential": "xxxxxx"
}]
}
webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv(options,<callback-here>);
Can you provide logs for both the Firefox ICE candidates generation and KMS ICE generation?
In addition is KMS up and running in the same machine as the tutorial?
More information about kurento_utils used in the hello-world: http://doc-kurento.readthedocs.io/en/stable/mastering/kurento_utils_js.html#using-data-channels
General example of WebRTC configuration the STUN on the Web client side:
https://www.w3.org/TR/webrtc/#simple-peer-to-peer-example

Rush not working on my Orion Context Broker

I have deployed an Orion Context Broker v0.20.0 instance using AWS. I'm trying to show an entity from it on the MapViewer widget of the Fiware Lab Wirecloud Mashup.
It seems like I'm having some kind of trouble with the NGSI source operator. I have configured it with:
NGSI server URL: http://MyORionInstanceIP:1026
NGSI proxy URL: https://ngsiproxy.lab.fi-ware.org (I have also tried ngsiproxy.lab.fiware.org)
I run my Conntext broker instance like this: contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion -t 0-255 -rush localhost:5001, and it works, but when I accept the operator configuration to create the subscription, this is what I read on my Context Broker:
DEBUG#12:07:40 senderThread.cpp[47]: sending to: host='ngsiproxy.lab.fi-ware.org', port=443, verb=POST, tenant='', service-path: '', xauthToken: '', path='/callbacks/14:27:47-1:15:08:34-1', content-type: application/xml
DEBUG#12:07:40 sem.cpp[124]: transactionIdSet taking the 'trans' semaphore for 'changing the transaction id'
DEBUG#12:07:40 sem.cpp[126]: transactionIdSet has the 'trans' semaphore
DEBUG#12:07:40 sem.cpp[181]: transactionIdSet gives the 'trans' semaphore for 'changing the transaction id'
INFO#12:07:40 clientSocketHttp.cpp[154]: Starting transaction to ngsiproxy.lab.fi-ware.org:443/callbacks/14:27:47-1:15:08:34-1
DEBUG#12:07:40 clientSocketHttp.cpp[240]: HTTP-HEADERS: 'X-relayer-host: ngsiproxy.lab.fi-ware.org:443'
DEBUG#12:07:40 clientSocketHttp.cpp[247]: HTTP-HEADERS: 'X-relayer-protocol: https'
DEBUG#12:07:40 clientSocketHttp.cpp[260]: HTTP-HEADERS: 'User-Agent: orion/0.20.0 libcurl/7.19.7'
DEBUG#12:07:40 clientSocketHttp.cpp[268]: HTTP-HEADERS: 'Host: localhost:5001'
DEBUG#12:07:40 clientSocketHttp.cpp[305]: HTTP-HEADERS: 'Content-length: 1141'
DEBUG#12:07:40 clientSocketHttp.cpp[353]: Sending message 18 to HTTP server: sending message of 1370 bytes to HTTP server
WARNING#12:07:40 clientSocketHttp.cpp[358]: Notification failure for localhost:5001 (curl_easy_perform failed: Couldn't connect to server)
INFO#12:07:40 clientSocketHttp.cpp[375]: Transaction ended
I know there is a similar question here, but it hasn't solved my problem so far, neither the Orion documentation.
I really appreciate any help you can provide.
EDIT:
It looks like that rush wasn't event installed, so I did it.
But everytime I try to run the listener it gives me this error:
time=2015-05-07T13:56:17.331Z | lvl=ERROR | op=RESPUSH BUCKET TASKS | msg=Error getting bucket elements | corr=N/A | trans=N/A | hostname=***** | component=retryBuckets | error=[Error: ERR unknown command 'evalsha']
Now, when I accept the operator, this are the traces:
-ORION:
DEBUG#15:04:28 senderThread.cpp[47]: sending to: host='ngsiproxy.lab.fi-ware.org', port=443, verb=POST, tenant='', service-path: '', xauthToken: '', path='/callbacks/13:35:20-1:18:05:22-1', content-type: application/xml
DEBUG#15:04:28 sem.cpp[124]: transactionIdSet taking the 'trans' semaphore for 'changing the transaction id'
DEBUG#15:04:28 sem.cpp[126]: transactionIdSet has the 'trans' semaphore
DEBUG#15:04:28 sem.cpp[181]: transactionIdSet gives the 'trans' semaphore for 'changing the transaction id'
INFO#15:04:28 clientSocketHttp.cpp[154]: Starting transaction to ngsiproxy.lab.fi-ware.org:443/callbacks/13:35:20-1:18:05:22-1
DEBUG#15:04:28 clientSocketHttp.cpp[240]: HTTP-HEADERS: 'X-relayer-host: ngsiproxy.lab.fi-ware.org:443'
DEBUG#15:04:28 clientSocketHttp.cpp[247]: HTTP-HEADERS: 'X-relayer-protocol: https'
DEBUG#15:04:28 clientSocketHttp.cpp[260]: HTTP-HEADERS: 'User-Agent: orion/0.20.0 libcurl/7.19.7'
DEBUG#15:04:28 clientSocketHttp.cpp[268]: HTTP-HEADERS: 'Host: localhost:5001'
DEBUG#15:04:28 clientSocketHttp.cpp[305]: HTTP-HEADERS: 'Content-length: 1141'
DEBUG#15:04:28 clientSocketHttp.cpp[353]: Sending message 1 to HTTP server: sending message of 1370 bytes to HTTP server
INFO#15:04:28 clientSocketHttp.cpp[364]: Notification Successfully Sent to localhost:5001/callbacks/13:35:20-1:18:05:22-1
INFO#15:04:28 clientSocketHttp.cpp[375]: Transaction ended
-Listener:
time=2015-05-07T15:08:12.803Z | lvl=INFO | op=RELAY REQUEST | msg=Relay Request received | corr=N/A | trans=N/A | hostname=Orion-Njoy | component=listener | userID='127.0.0.1' | reqInfo={ url: '/callbacks/13:35:20-1:18:09:06-1', method: 'POST', remoteAddress: '127.0.0.1', headers: { 'x-relayer-host': 'ngsiproxy.lab.fi-ware.org:443', 'x-relayer-protocol': 'https', 'x-relayer-proxy': undefined, 'x-relayer-retry': undefined, 'x-relayer-httpcallback': undefined, 'x-relayer-persistence': undefined, 'x-relayer-traceid': undefined, 'x-relayer-encoding': undefined, 'content-type': 'application/xml' }, responseTime: 1, statusCode: 500, bodyLength: 1141, id: { exceptionId: 'SVR1000', exceptionText: 'Generic Server Error: Error: ERR unknown command \'evalsha\'' } }
time=2015-05-07T15:08:12.803Z | lvl=INFO | op=PERSISTENCE | msg=Persistence Completed | corr=N/A | trans=e1467620-f4ca-11e4-a50f-ebe0dffc0e2e | hostname=Orion-Njoy | component=evPersistence | userID='127.0.0.1' | state='error'
-Consumer:
time=2015-05-07T13:56:17.331Z | lvl=ERROR | op=RESPUSH BUCKET TASKS | msg=Error getting bucket elements | corr=N/A | trans=N/A | hostname=Orion-Njoy | component=retryBuckets | error=[Error: ERR unknown command 'evalsha']
Any ideas, please?
EDIT 2:
I've manage to get it working thanks to the responses. The problem was that I was using redis 2.4, and it's required the 2.6 or supperior version. Now I can see my entities in the Map Viewer.
In case someone runs with the same problem, don't forget to install Rush and follow this instructions to install Redis 2.6:
Thank you all for your assistance.
Maybe the redis version is too old. EVAL/EVALSHA commands were introduced in redis 2.6.
I would check the redis version (>2.6.0)
It seems like the broker is unable to connect to rush, running in the same host and accepting connections on port 5001.
Are you sure rush is running? (and that it is on port 5001?).
The broker doesn't implement notifications (yet) in https itself, but needs rush for this purpose. But of course, rush must be running for this to work ...