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

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

Related

Opaque error with self-hosted Sourcegraph and Google Workspace SMTP relay config

Finally deployed a self-hosted Sourcegraph, v3.39.1. I'm running on Google Compute Engine on a Container Optimized OS VM. Got everything working except I'm having difficulty getting SMTP set up though Google Workspace's smtp-relay. When I run a sendTestEmail command, I get back an opaque error:
{
"data": {
"sendTestEmail": "Failed to send test email: EOF"
}
}
Here is a redacted snippet of my config:
"email.address": "myemailaddress#mydomain.com",
"email.smtp": {
"authentication": "PLAIN",
"domain": "mydomain.com",
"username": "myemailaddress#mydomain.com",
"password": "REDACTED",
"host": "smtp-relay.gmail.com",
"port": 587
}
For a quick smoke test, I ran netcat (nc smtp-relay.gmail.com 587) from the container and did sent EHLO mydomain.com. The smtp-relay responded with a "at your service" so I assume that worked. Any one have any other tips? Any logs I can check? (I didn't see anything obvious, but I'm new to Sourcegraph)

Node.js GraphQL API Stops working as soon as I deploy it: "Error validating datasource `db`: the URL must start with the protocol `mysql://"

I build a GraphQL API with Apollo and Prisma ORM which is connected to my hosted MySQL Database (The Database has already content in it).
When I run it on my localhost everything works fine and I can query the Database with GraphQL statements.
As soon as I deploy my node.js project to DigitalOcean (auto deployed with GitHub) it stops working and I get the following error:
{
"errors": [
{
"message": "\nInvalid `prisma.content.findMany()` invocation in\n/workspace/src/schema.js:36:29\n\n 33 const resolvers = {\n 34 Query: {\n 35 memes: (parent, args) => {\nā†’ 36 return prisma.content.findMany(\n error: Error validating datasource `db`: the URL must start with the protocol `mysql://`.\n --> schema.prisma:7\n | \n 6 | provider = \"mysql\"\n 7 | url = env(\"DATABASE_URL\")\n | \n\nValidation Error Count: 1",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"memes"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"clientVersion": "3.6.0",
"stacktrace": [
"Error: ",
"Invalid `prisma.content.findMany()` invocation in",
"/workspace/src/schema.js:36:29",
"",
" 33 const resolvers = {",
" 34 Query: {",
" 35 memes: (parent, args) => {",
"ā†’ 36 return prisma.content.findMany(",
" error: Error validating datasource `db`: the URL must start with the protocol `mysql://`.",
" --> schema.prisma:7",
" | ",
" 6 | provider = \"mysql\"",
" 7 | url = env(\"DATABASE_URL\")",
" | ",
"",
"Validation Error Count: 1",
" at cb (/workspace/node_modules/#prisma/client/runtime/index.js:38689:17)",
" at processTicksAndRejections (internal/process/task_queues.js:97:5)"
]
}
}
}
],
"data": null
}
Here is my schema.prisma file:
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "mysql"
url = env("DATABASE_URL")
}
...
The only thing that is different from the hosted project compared to the local project is that I put .env file and node_modules on the .gitignore file.
So it seems like the project is accessing the wrong DATABASE_URL, but how should the hosted project know the DATABASE_URL in my .env file when the .env file is on .gitignore?
Here is what I do:
Change the DATABASE_URL in my .env file to my local MySQL Database hosted on a docker container
Run npx prisma migrate dev --preview-feature to generate the migration files
Run git add .
Run git commit -m "New Commit"
Run DATABASE_URL=mysql://censored:censored#censored:3306/censored npx prisma migrate resolve --applied "my_migration_folder_name" --preview-feature which succeeds and tells me "Migration my_migration_folder_name marked as applied."
Run git push
I can see that the Migration is successfully created on my MySQL Database but as soon as I run the app and try to query the database it gives me that error.
The code has to be correct because it is working on my localhost even when querying the hosted MySQL Database.
I also double checked that the Model in the schema.prisma file is in sync with my hosted MySQL Database schema.
I'm running out of ideas on what I could try.
EDIT
I actually think it has something to do with the environment variables I set in the settings of my DigitalOcean application.
Before it was set to:
envs:
- key: DATABASE_URL
scope: RUN_AND_BUILD_TIME
value: ${db.DATABASE_URL}
Now I set it to:
envs:
- key: DATABASE_URL
scope: RUN_AND_BUILD_TIME
value: mysql://censored:cesnored#censored:3306/censored
I thought that this will fix the problem but now it tells me that the connection fails because of wrong database credentials even though it is the right link with the right credentials.
I fixed it by clicking "Force rebuild and deploy" on my digitalOcean app.

Disabling the Consul HTTP endpoints

We have enabled ACL's and TLS for Consul cluster in our environment. We have disabled the UI as well. But when I use the URL: http://<consul_agent>:8500/v1/coordinate/datacenters. How can disable the URL's as this?
I tested with adding the following to the consulConfig.json:
"ports":{
"http": -1
}
this did not solve the problem.
Apart from the suggestion provided to use "http_config": { "block_endpoints": I am trying to use the ACL Policy if that can solve.
I enabled the ACL's first
I created a policy using the command: consul acl policy create -name "urlblock" -description "Url Block Policy" -rules #service_block.hcl -token <tokenvalue>
contents of the service_block.hcl: service_prefix "/v1/status/leader" { policy = "deny" }
I created a agent token for this using the command: consul acl token create -description "Block Policy Token" -policy-name "urlblock" -token <tokenvalue>
I copied the agent token from the output of the above command and pasted that in the consul_config.json file in the acl -> tokens section as "tokens": { "agent": "<agenttokenvalue>"}
I restarted the consul agents (did the same in the consul client also).
Still I am able to access the endpoint /v1/status/leader. Any ideas as what is wrong with this approach?
That configuration should properly disable the HTTP server. I was able to validate this works using the following config with Consul 1.9.5.
Disabling Consul's HTTP server
Create config.json in the agent's configuration directory which completely disables the HTTP API port.
config.json
{
"ports": {
"http": -1
}
}
Start the Consul agent
$ consul agent -dev -config-file=config.json
==> Starting Consul agent...
Version: '1.9.5'
Node ID: 'ed7f0050-8191-999c-a53f-9ac48fd03f7e'
Node name: 'b1000.local'
Datacenter: 'dc1' (Segment: '<all>')
Server: true (Bootstrap: false)
Client Addr: [127.0.0.1] (HTTP: -1, HTTPS: -1, gRPC: 8502, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false, Auto-Encrypt-TLS: false
==> Log data will now stream in as it occurs:
...
Note the HTTP port is set to "-1" on the Client Addr line. The port is now inaccessible.
Test connectivity to HTTP API
$ curl localhost:8500
curl: (7) Failed to connect to localhost port 8500: Connection refused
Blocking access to specific API endpoints
Alternatively you can block access to specific API endpoints, without completely disabling the HTTP API, by using the http_config.block_endpoints configuration option.
For example:
Create a config named block-endpoints.json
{
"http_config": {
"block_endpoints": [
"/v1/catalog/datacenters",
"/v1/coordinate/datacenters",
"/v1/status/leader",
"/v1/status/peers"
]
}
}
Start Consul with this config
consul agent -dev -config-file=block-endpoints.json
==> Starting Consul agent...
Version: '1.9.5'
Node ID: '8ff15668-8624-47b5-6e83-7a8bfd715a56'
Node name: 'b1000.local'
Datacenter: 'dc1' (Segment: '<all>')
Server: true (Bootstrap: false)
Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false, Auto-Encrypt-TLS: false
==> Log data will now stream in as it occurs:
...
In this example, the HTTP API is enabled and listening on port 8500.
Test connectivity to HTTP API
If you issue a request to one of the blocked endpoints, the following error will be returned.
$ curl localhost:8500/v1/status/peers
Endpoint is blocked by agent configuration
However, access to other endpoints are still permitted.
$ curl localhost:8500/v1/agent/members
[
{
"Name": "b1000.local",
"Addr": "127.0.0.1",
"Port": 8301,
"Tags": {
"acls": "0",
"build": "1.9.5:3c1c2267",
"dc": "dc1",
"ft_fs": "1",
"ft_si": "1",
"id": "6d157a1b-c893-3903-9037-2e2bd0e6f973",
"port": "8300",
"raft_vsn": "3",
"role": "consul",
"segment": "",
"vsn": "2",
"vsn_max": "3",
"vsn_min": "2",
"wan_join_port": "8302"
},
"Status": 1,
"ProtocolMin": 1,
"ProtocolMax": 5,
"ProtocolCur": 2,
"DelegateMin": 2,
"DelegateMax": 5,
"DelegateCur": 4
}
]

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

rabbitmq 3.3.4 shovel configuration is crashing start process

I'm trying to configure the shovel plugin via the config file (running in docker) but I get this error:
BOOT FAILED
===========
Error description:
{error,{failed_to_cluster_with,[rabbit#dalmacpmfd57],
"Mnesia could not connect to any nodes."}}
The config is set up this way because the destination for shovel will be created on demand when a dev environment is spun up... the source is a permanent rabbitmq instance running that the new, dev environment will attach to.
Here is the config file contents:
[
{rabbitmq_shovel,
[{shovels,
[{indexer_replica_static,
[{sources,
[{broker, [ "amqp://guest:guest#rabbitmq/newdev" ]},
{declarations,
[{'queue.declare', [{queue, <<"Indexer_Replica_Static">>}, durable]},
{'queue.bind',[ {exchange, <<"Indexer">>}, {queue, <<"Indexer_Replica_Static">>}]}
]
}
]
},
{destinations,
[{broker, "amqp://"},
{declarations, [ {'exchange.declare', [ {exchange, <<"Indexer_Replica_Static">>}
, {type, <<"fanout">>}, durable]},
{'queue.declare', [
{queue, <<"Indexer_Replica_Static">>},
durable]},
{'queue.bind',
[ {exchange, <<"Indexer_Replica_Static">>}
, {queue, <<"Indexer_Replica_Static">>}
]}
]
}
]
},
{queue, <<"Indexer_Replica_Static">>},
{prefetch_count, 0},
{ack_mode, on_confirm},
{publish_properties, [ {delivery_mode, 2} ]},
{reconnect_delay, 2.5}
]
}
]
},
{reconnect_delay, 2.5}
]
}
].
[UPDATE]
This is being run in docker but since I couldn't debug the issue in docker I tried booting up rabbit locally with the same config file. I noticed in the logs that the rabbit config system variable I set (RABBITMQ_CONFIG_FILE) isn't reflected in the log and the shovel settings haven't been applied (no surprise huh). I verified the variable with an echo statement and the correct path is displayed: /dev/rabbitmq_server-3.3.4/rabbitmq
=INFO REPORT==== 3-Sep-2014::15:30:37 ===
node : rabbit#dalmacpmfd57
home dir : /Users/e002678
config file(s) : (none)
cookie hash : n6vhh8tY7Z+uR2DV6gcHUg==
log : /usr/local/rabbitmq_server-3.3.4/sbin/../var/log/rabbitmq/rabbit#dalmacpmfd57.log
sasl log : /usr/local/rabbitmq_server-3.3.4/sbin/../var/log/rabbitmq/rabbit#dalmacpmfd57- sasl.log
database dir : /usr/local/rabbitmq_server-3.3.4/sbin/../var/lib/rabbitmq/mnesia/rabbit#dalmacpmfd57
Thanks!