I tried to connect Strapi to mLab with this database.js config but it doesn't work. I get the error :
ConnectorError: connector "strapi-hook-mongoose" not found: Cannot find module 'strapi-connector-strapi-hook-mongoose'
Here is my database.js config file :
{
"defaultConnection": "default",
"connections": {
"default": {
"connector": "strapi-hook-mongoose",
"settings": {
"database": "strapi-test",
"host": "ds131914.mlab.com",
"srv": false,
"port": "31914",
"username": "root",
"password": "root010101"
},
"options": {
"authenticationDatabase": "strapi-test"
}
}
}
}
What should I do ?
After some search, it appers to me that this database.js config was from an old tutorial (this one). So to solve this probleme, you first need to install npm i -S strapi-connector-mongoose in order to install the right connecter.
Now, you need to change you database.js config for the desire environement. In my case, it was production. So edit config/environement/production/database.js like this :
{
"defaultConnection": "default",
"connections": {
"default": {
"connector": "mongoose",
"settings": {
"client": "mongo",
"host": "ds131914.mlab.com",
"port": "31914",
"srv": false,
"database": "strapi-test",
"username": "root",
"password": "root010101"
},
"options": {
"authenticationDatabase": "strapi-test",
"ssl": false
}
}
}
}
Like this, it should work !
Related
running into a issue using cypress-postgres connecting to the database. Server has multiple databases along with multiple schemas. Tried multiple plugins, but can find a solution that will allow me to specify a particular schema in a database. Server is reachable over the vpn.
Will need to do this with sql database. Any help, better method suggestions welcomed.
Thank You! - Michael Frazier
IE: Database Example.
Error that is returned
no relation for home
Package.json has following dependencies:
name": "tests",
"version": "1.0.0",
"description": "Automated Tests",
"main": "index.js",
"scripts": {
"cypress:open": "cypress open",
"test": "cypress open"
},
"repository": {
"type": "git",
"url":
},
"author": "Michael Frazier
"license": "ISC",
"dependencies": {
"#testing-library/cypress": "^8.0.2",
"#testing-library/vue": "^5.8.2",
"#vue/test-utils": "^1.3.0",
"cypress-commands": "^2.0.1",
"cypress-downloadfile": "^1.2.1",
"cypress-postgres": "^1.1.1",
"cypress-postgresql": "^1.0.8",
"cypress-real-events": "^1.6.0",
"pg": "^8.7.1",
"pg-promise": "^10.5.8",
"yarn": "^1.22.17"
},
"devDependencies": {
"#4tw/cypress-drag-drop": "^2.1.0",
"#babel/core": "^7.15.0",
"#babel/preset-env": "^7.15.0",
"#cypress/skip-test": "^2.6.1",
"#cypress/webpack-preprocessor": "^5.9.1",
"#testing-library/dom": "^8.11.2",
"#types/chai": "^4.2.21",
"#types/jest": "^27.0.1",
"#types/mocha": "^9.0.0",
"cy-mobile-commands": "^0.3.0",
"cypress": "^9.5.3",
"cypress-file-upload": "^5.0.8",
"cypress-fill-command": "^1.0.2",
"cypress-iframe": "^1.0.1",
"cypress-mailosaur": "^2.6.0",
"cypress-mochawesome-reporter": "^2.4.0",
"cypress-msteams-reporter": "^1.0.3",
"cypress-plugin-tab": "^1.0.5",
"cypress-wait-until": "^1.7.2",
"dayjs": "^1.10.6",
"faker": "^5.5.3",
"mysql": "^2.18.1",
"pdf-parse": "^1.1.1",
"webpack": "^5.51.1"
}
}
Cypress.json has DB credentials in following format:
{
"trashAssetsBeforeRuns": true,
"responseTimeout": 30000,
"requestTimeout": 50000,
"defaultCommandTimeout": 4000,
"experimentalSourceRewriting": true,
"experimentalStudio": true,
"projectId": "aycmk8",
"reporter": "cypress-mochawesome-reporter",
"reporterOptions": {
"reportDir": "cypress/report",
"charts": true,
"reportPageTitle": "Melos Report"
},
"db":
{"user": "postgres",
"host": "",
"database": "",
"password": "",
"schemas": "sct",
"port": 5432
}
}
Plugin in cypress\plugins\index.js file:
module.exports = async (on, config) => {
on('task',
{dbQuery: (query)=> require('cypress-postgres')(query.query,query.connection)})
Spec file has following test:
describe("Database Health Tests", function () {
it('should ping the database to ensure its active ', function () {
cy.task("dbQuery", {"query":"select * from home"})
});
Your dbQuery is missing the connection string:
cy.task("dbQuery",
{
query: "select * from home",
connection: "your connection string"
})
If you focusing on description of cypress-postgres in npm, they provided 2-ways to use :
The first way : load your database connection via cypress.json by require('cypress-postgres').
The seconds way : set your database connection by yourself in cy.task.
The first way
This way may make you mistake, the example shows unclear parameter to you :
// In cypress\plugins\index.js
module.exports = on => {
on("task", {
dbQuery:(query)=> require("cypress-postgres")(query.query,query.connection)
});
};
I'm not sure query.connection come from. If you access to the dependency, you will see :
// In require('cypress-postgres')
const pgp = require('pg-promise')();
const postgressConfig = require(require('path').resolve('cypress.json'));
module.exports = function(query,userDefineConnection) {
let connection = postgressConfig.db
if (userDefineConnection!=undefined){
connection=userDefineConnection
}
const db = pgp(connection);
return db.any(query)
}
So you can change query.connection to your variable.
Normally, module in cypress\plugins\index.js received 2-arguments on and config. The config will refer to cypress.json, you can get your database connection via config.env.db :
{
"env": {
"db": {
"user": "postgres",
"host": "localhost",
"database": "postgres",
"password": "mysecretpassword",
"port":5432
}
}
}
Now cypress\plugins\index.js should be :
module.exports = (on, config) => {
// `on` is used to hook into various events Cypress emits
// `config` is the resolved Cypress config
on("task", {
dbQuery: (query) => require("cypress-postgres")(query.query, config.env.db)
})
}
In your *.spec.js :
// ...
it('set "Y" to db', () => {
cy.task("dbQuery", { "query": "select count(*) as num_row from home"
}).then(result => {
expect(result[0].num_row).to.equal('1')
})
})
// ...
The seconds way
This way assign database connection directly in your *.spec.js :
// ...
it('set "Y" to db', () => {
cy.task("dbQuery", {
"query": "select count(*) as num_row from home",
"connection": {
"user": "postgres",
"host": "localhost",
"database": "postgres",
"password": "mysecretpassword",
"port":5432
}
}).then(result => {
expect(result[0].num_row).to.equal('1')
})
})
// ...
I am trying to run Wazuh/Wazuh docker container on ECS. I was able to register task definition and launch container using Terraform. However, I am facing an issue with "Volume"(Data Volume) while registering tak definition using AWS CLI command.
Command: aws ecs --region eu-west-1 register-task-definition --family hids --cli-input-json file://task-definition.json
Error:
ParamValidationError: Parameter validation failed:
Unknown parameter in volumes[0]: "dockerVolumeConfiguration", must be one of: name, host
2019-08-29 07:31:59,195 - MainThread - awscli.clidriver - DEBUG - Exiting with rc 255
{
"containerDefinitions": [
{
"portMappings": [
{
"hostPort": 514,
"containerPort": 514,
"protocol": "udp"
},
{
"hostPort": 1514,
"containerPort": 1514,
"protocol": "udp"
},
{
"hostPort": 1515,
"containerPort": 1515,
"protocol": "tcp"
},
{
"hostPort": 1516,
"containerPort": 1516,
"protocol": "tcp"
},
{
"hostPort": 55000,
"containerPort": 55000,
"protocol": "tcp"
}
],
"image": "wazuh/wazuh",
"essential": true,
"name": "chids",
"cpu": 1600,
"memory": 1600,
"mountPoints": [
{
"containerPath": "/var/ossec/data",
"sourceVolume": "ossec-data"
},
{
"containerPath": "/etc/filebeat",
"sourceVolume": "filebeat_etc"
},
{
"containerPath": "/var/lib/filebeat",
"sourceVolume": "filebeat_lib"
},
{
"containerPath": "/etc/postfix",
"sourceVolume": "postfix"
}
]
}
],
"volumes": [
{
"name": "ossec-data",
"dockerVolumeConfiguration": {
"scope": "shared",
"driver": "local",
"autoprovision": true
}
},
{
"name": "filebeat_etc",
"dockerVolumeConfiguration": {
"scope": "shared",
"driver": "local",
"autoprovision": true
}
},
{
"name": "filebeat_lib",
"dockerVolumeConfiguration": {
"scope": "shared",
"driver": "local",
"autoprovision": true
}
},
{
"name": "postfix",
"dockerVolumeConfiguration": {
"scope": "shared",
"driver": "local",
"autoprovision": true
}
}
]
}
I tried by adding "host" parameter(however it supports Bind Mounts only). But got the same error.
"volumes": [
{
"name": "ossec-data",
"host": {
"sourcePath": "/var/ossec/data"
},
"dockerVolumeConfiguration": {
"scope": "shared",
"driver": "local",
"autoprovision": true
}
}
]
ECS should register the task definition having 4 Data Volumes and associated mount points.
Got the issue.
Removed "dockerVolumeConfiguration" parameter from "Volume" configuration and it worked.
"volumes": [
{
"name": "ossec-data",
"host": {
"sourcePath": "/ecs/ossec-data"
}
},
{
"name": "filebeat_etc",
"host": {
"sourcePath": "/ecs/filebeat_etc"
}
},
{
"name": "filebeat_lib",
"host": {
"sourcePath": "/ecs/filebeat_lib"
}
},
{
"name": "postfix",
"host": {
"sourcePath": "/ecs/postfix"
}
}
]
Can you check on your version of awscli?
aws --version
According to all the documentation, your first task definition should work fine and I tested it locally without any issues.
It might be that you are using an older aws cli version where the syntax was different or parameters were different at the time.
Could you try updating your aws cli to the latest version and try again?
--
Some additional info I found:
Checking on the aws ecs cli command, they added docker volume configuration as part of the cli in v1.80
The main aws-cli releases updates periodically to update the commands but they don't provide much info on what specific versions of each command is changed:
https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst
If you update your aws-cli version things should work
Nature of the issue
My db2 database makes wide use of table schemas for organization, so the table in question is LIVE.TBLADDRESS -
My model uses the "options" to specify the table schema
"options": {
"idInjection": false,
"db2": {
"schema": "LIVE",
"table": "TBLADDRESS"
}
}
the model is in the model-config.json using
,"Tbladdress": {
"dataSource": "x3",
"public": true
}
I get an error when I try to use the explorer to do a simple 'get' or any other API call.
"statusCode": 500,
"name": "Error",
"message": "[IBM][CLI Driver][DB2/LINUXX8664] SQL0204N "DB2X.TBLADDRESS" is an undefined name. SQLSTATE=42704\r\n",
Expected behavior
Once I specified the schema - I'd expect the API to resolve correctly
Actual behavior
The default schema for db user is used at all times...regardless of specified schema in options.
Suggested resolution
Maybe I set it in the wrong place, I will continue to look for the information, It is possible I am missing something.
This is what I "see" using DB Viewer...so you have an idea what I'm referring to.
DEV - host:50000/DEV
-schemas
|-AAA
|-BBB
|-DB2X (this is the schema that the error is referring to...but NOT the one specified in the model)
|-DDD
|-LIVE (this is the correct schema)
|--Tables
|--|-TBLA
|--|-TBLADDRESS
|-ZZZ
If it helps - this happens with manually create models or models generated by discovery scripts.
These are my config files, and model
/common/models/Tbladdress.json
{
"name": "Tbladdress",
"options": {
"idInjection": false,
"db2": {
"schema": "LIVE",
"table": "TBLADDRESS"
}
},
"properties": {
...
}
}
/datasources.json
{
"db": {
"name": "db",
"connector": "memory"
},
"x3": {
"name": "x3",
"connector": "db2",
"username": "...",
"password": "...",
"database": "...",
"hostname": "...",
"port": 50000
}
}
/model-config.json
{
"_meta": {
...
},
"User": {
"dataSource": "db"
},
"AccessToken": {
"dataSource": "db",
"public": false
},
"ACL": {
"dataSource": "db",
"public": false
},
"RoleMapping": {
"dataSource": "db",
"public": false,
"options": {
"strictObjectIDCoercion": true
}
},
"Role": {
"dataSource": "db",
"public": false
}
,"Tbladdress": {
"dataSource": "x3",
"public": true
}
}
http://localhost:3000/explorer/#!/Tbladdress/Tbladdress_findById
{
"error": {
"statusCode": 500,
"name": "Error",
"message": "[IBM][CLI Driver][DB2/LINUXX8664] SQL0204N \"DB2X.TBLADDRESS\" is an undefined name. SQLSTATE=42704\r\n",
"errors": [],
"error": "[node-ibm_db] SQL_ERROR",
"state": "42S02",
"stack": "Error: [IBM][CLI Driver][DB2/LINUXX8664] SQL0204N \"DB2X.TBLADDRESS\" is an undefined name. SQLSTATE=42704\r\n"
}
}
...Headers...
{
"date": "Sun, 18 Feb 2018 05:20:36 GMT",
"x-content-type-options": "nosniff",
"x-download-options": "noopen",
"x-frame-options": "DENY",
"content-type": "application/json; charset=utf-8",
"transfer-encoding": "chunked",
"connection": "keep-alive",
"access-control-allow-credentials": "true",
"vary": "Origin, Accept-Encoding",
"x-xss-protection": "1; mode=block"
}
USING:
loopback-cli v3 to generate express app
loopback-connector-db2 to connect to DB2 v10
Node v8.9.2
Package.JSON dependencies looks like this (as mentioned it's a default install, with one model added - to see if I could get it to work)
"dependencies": {
"compression": "^1.0.3",
"cors": "^2.5.2",
"helmet": "^1.3.0",
"loopback": "^3.0.0",
"loopback-boot": "^2.6.5",
"loopback-component-explorer": "^5.0.0",
"loopback-connector-db2": "^2.1.1",
"serve-favicon": "^2.0.1",
"strong-error-handler": "^2.0.0"
},
Yes - the DB2 connector worked fine when I specified the "LIVE" schema on data discovery - but it does NOT seem to be working when I use the API. I don't know if it's the connector or the loopback app.
For loopback-connector-db2, you must define SCHEMA in the datasources.json config file.
{
"x3": {
"name": "x3",
"connector": "db2",
"username": "...",
"password": "...",
"database": "...",
"hostname": "...",
"port": 50000
},
"x3Live": {
"name": "x3Live",
"connector": "db2",
"schema": "LIVE",
"username": "...",
"password": "...",
"database": "...",
"hostname": "...",
"port": 50000
}
}
Unfortunately, you will need to create a new datasource (e.g. x3Live). Use the old x3 datasource for the models using the DB2X schema, and the new x3Live datasource for the models using the LIVE schema.
I'm writting a micro service with spring-boot. The db is mongodb. The service works perfectly in my local environment. But after I deployed it to the cloud foundry it doesn't work. The reason is connecting mongodb time out.
I think the root cause is the application doesn't know it is running on cloud. Because it still connecting 127.0.0.1:27017, but not the redirected port.
How could it know it is running on cloud? Thank you!
EDIT:
There is a mongodb instance bound to the service. And when I checked the environment information, I got following info:
{
"VCAP_SERVICES": {
"mongodb": [
{
"credentials": {
"hostname": "10.11.241.1",
"ports": {
"27017/tcp": "43417",
"28017/tcp": "43135"
},
"port": "43417",
"username": "xxxxxxxxxx",
"password": "xxxxxxxxxx",
"dbname": "gwkp7glhw9tq9cwp",
"uri": "xxxxxxxxxx"
},
"syslog_drain_url": null,
"volume_mounts": [],
"label": "mongodb",
"provider": null,
"plan": "v3.0-container",
"name": "mongodb-business-configuration",
"tags": [
"mongodb",
"document"
]
}
]
}
}
{
"VCAP_APPLICATION": {
"cf_api": "xxxxxxxxxx",
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 1024
},
"application_name": "mock-service",
"application_uris": [
"xxxxxxxxxx"
],
"name": "mock-service",
"space_name": "xxxxxxxxxx",
"space_id": "xxxxxxxxxx",
"uris": [
"xxxxxxxxxx"
],
"users": null,
"application_id": "xxxxxxxxxx",
"version": "c7569d23-f3ee-49d0-9875-8e595ee76522",
"application_version": "c7569d23-f3ee-49d0-9875-8e595ee76522"
}
}
From my understanding, I think my spring-boot service should try to connect the port 43417 but not 27017, right? Thank you!
Finally I found the reason is I didn't specify the profile. After adding following code in my manifest.yml it works:
env:
SPRING_PROFILES_ACTIVE: cloud
restraunt.json file
`{
"name": "restraunt",
"base": "PersistedModel",
"idInjection": true,
"options": {
"validateUpsert": true
},
"properties": {
"name": {
"type": "string",
"required": true
},
"location": {
"type": "string",
"required": true
}
},
"validations": [],
"relations": {},
"acls": [],
"methods": {}
}`
restraunt.js file
`module.exports = function(Restraunt) {
Restraunt.find({where:{id:1}}, function(data) {
console.log(data);
})
};`
model-config.json file
`"restraunt": {
"dataSource": "restrauntManagement"
}`
datasources.json file
`{
"db": {
"name": "db",
"connector": "memory"
},
"restrauntManagement": {
"host": "localhost",
"port": 0,
"url": "",
"database": "restraunt-management",
"password": "restraunt-management",
"name": "restrauntManagement",
"user": "rohit",
"connector": "mysql"
}
}`
I am able to get,put,post from the explorer which means the sql db has been set up properly but i am not able to 'find' from restraunt.js file.It throws an error.
"Error: Cannot call restraunt.find(). The find method has not been setup. The PersistedModel has not been correctly attached to a DataSource"
Besides that executing code in boot folder, there's a possibility to use event, emitted after attaching the model.
You can write your code right in model.js, not in boot folder.
Looks like:
Model.once("attached", function () {})
Model = Accounts (for example).
I know, this is an old topic, but maybe this helps someone else.
Try installing mysql connector again:
npm i -S loopback-connector-mysql
Take a look at your datasources.json, because mysql's port might be wrong, default port is 3306, also you could try changing localhost to 0.0.0.0.
"restrauntManagement": {
"host": "localhost", /* if you're using docker, you need to set it to 0.0.0.0 instead of localhost */
"port": 0, /* default port is 3306 */
"url": "",
"database": "restraunt-management",
"password": "restraunt-management",
"name": "restrauntManagement",
"user": "rohit",
"connector": "mysql"
}
model-config.json must be:
"restraunt": {
"dataSource": "restrauntManagement" /* this name must be the same name in datasources object key (in your case it is restrauntManagement not the connector name which is mysql) */
}
You also need to execute the migration for restaurant model:
create migration.js at /server/boot and add this:
'use strict';
module.exports = function(server) {
var mysql = server.dataSources.mysql;
mysql.autoupdate('restraunt');
};
you need to migrate every single model you'll use it. you also need to migrate the default models (ACL, AccessToken, etc...) if you're going to attach them to a datasource.
Also in the docs says you can't perform any operation inside the model.js file because the system (at that point) it is not fully loaded. Any operation you need to execute must be inside a .js file in the /boot directory because the system is completely loaded there. You can perform operations inside remote methods because the system is loaded as well.