I am trying to set up a brand new Ghost blog on a Centos 7 server. I have Nginx, Node and Ghost installed and have written all of the necessary configuration files. It's pretty close to working, but I wanted to use MySQL instead of SQLite, so I created a new (blank) MySQL database called "ghost_db", set up a MySQL user called "ghost", gave the user permission for the database, and added these lines to config.js:
database: {
client: 'mysql',
connection: {
host: 'localhost',
user: 'ghost',
password: 'mypassword',
database: 'ghost_db'
charset: 'utf8'
filename: path.join(__dirname, '/content/data/ghost-dev.db')
},
debug: false
}, ...
When I try to start it, I get an error that suggests I use knex-migrator to initialize the database.
[john#a ghost]$ npm start
> ghost#1.18.4 start /var/www/ghost
> node index
[2017-12-10 00:08:00] ERROR
NAME: DatabaseIsNotOkError
CODE: MIGRATION_TABLE_IS_MISSING
MESSAGE: Please run knex-migrator init ...
However, some comments on Stackexchange suggest that using knex-migrate may be unnecessary for this version of Ghost, and when I run knex-migrator, it also fails:
[john#a ghost]$ knex-migrator init
[2017-12-09 16:21:33] ERROR
NAME: RollbackError
CODE: SQLITE_ERROR
MESSAGE: delete from "migrations" where "name" = '2-create-fixtures.js' and "version" = 'init' and "currentVersion" = '1.18' - SQLITE_ERROR: no such table: migrations
...[omitted]
Error: SQLITE_ERROR: no such table: migrations
I think the problem may be that the "ghost_db" database I initially created is blank. The "ghost-dev.db" file that is pointed to in the config.js seems to be for SQLite, but I get the same error message if I switch config.js back to using an SQLite database. I don't know what the "migrations" table is. I found the schema that I think Ghost expects at [https://github.com/TryGhost/Ghost/blob/1.16.2/core/server/data/schema/schema.js], but I'm not sure how to use that to initialize the tables, etc., except for doing it very laboriously by hand. I'm stumped!
Knex-migrator is new in Ghost 1.0, which also uses a config.<env>.json file for configuration.
It sounds like you added your database config into a file called config.js which was correct <1.0, however it seems you were installing Ghost 1.0 and therefore your new connection details would have needed to live in config.production.json.
You are correct that Ghost-CLI isn't intended for use on CentOS (it's for Ubuntu), but I'd be very surprised if it failed to install Ghost correctly. The issues with other OSs are mainly in the subtle differences between systemd i.e. keeping Ghost running.
The answer for me was just to not create the database at all and let Ghost do it as part of ghost install.
I took an alternate approach which proved successful, which was to install Ghost as an NPM module. The official Ghost instructions label this as an "advanced" process, but it wasn't too difficult to follow the instructions in the excellent nehalist.io and Stickleback blogs. There was also some useful guidance on the HugeServer knowledgebase. I think ultimately the problem was that the Ghost commandline interface (ghost-cli) wasn't designed for Centos 7.
Related
This is the error :
reverie-pc#reveriepc-Latitude-3400:~/VasanthkumarV/prisma$ sudo npm install -g prisma
[sudo] password for reverie-pc:
npm WARN deprecated request#2.88.2: request has been deprecated, see
https://github.com/request/request/issues/3142
/usr/bin/prisma -> /usr/lib/node_modules/prisma/dist/index.js
+ prisma#1.34.10
updated 1 package in 29.734s
(base) reverie-pc#reveriepc-Latitude-3400:~/VasanthkumarV/prisma$ prisma init test
? Set up a new Prisma server or deploy to an existing server? Use existing database
? What kind of database do you want to deploy to? MySQL
? Does your database contain existing data? Yes
? Enter database host localhost
? Enter database port 3306
? Enter database user root
? Enter database password [hidden]
? Please select the schema you want to introspect database_test
Introspecting database database_test 435ms
Created datamodel definition based on 24 tables.
? Select the programming language for the generated Prisma client Prisma JavaScript Client
Created 3 new files:
prisma.yml Prisma service definition
datamodel.prisma GraphQL SDL-based datamodel (foundation for database)
docker-compose.yml Docker configuration file
Next steps:
1. Open folder: cd test
2. Start your Prisma server: docker-compose up -d
3. Deploy your Prisma service: prisma deploy
4. Read more about introspection:url
▸ Syntax Error: Expected Name, found Int "1"
Get in touch if you need help: https://slack.prisma.io/
To get more detailed output, run $ export DEBUG="*"
(node:14055) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated
Generating schema... !
How to resolve this error..and what is the procedure to connect Prisma server with local database (MySQL)?? and what about the prisma deployment??
How to connect prisma with existing db?
It looks like you are using Prisma 1 which is currently in maintenance mode.
Given that this looks like a new project, I'd suggest you take a look at Prisma 2 which includes many improvements and a simpler mental model.
I'm working on a Perl6 project, but having difficulty connecting to MySQL. Even when using the DBIish (or perl6.org tutorial) example code, the connection fails. Any suggestions or advice is appreciated! User credentials have been confirmed accurate too.
I'm running this on Windows 10 with MySQL Server 8.0 and standard Perl6 with Rakudo Star. I have tried modifying the connection string in numerous ways like :$password :password<> :password() etc. but can't get a connection established. Also should note that I have the ODBC, C, C++, and.Net connectors installed.
#!/usr/bin/perl6
use v6.c;
use lib 'lib';
use DBIish;
use Register::User;
# Windows support
%*ENV<DBIISH_MYSQL_LIB> = "C:/Program Files/MySQL/MySQL Server 8.0/liblibmysql.dll"
if $*DISTRO.is-win;
my $dbh = DBIish.connect('mysql', :host<localhost>, :port(3306), :database<dbNameHere>, :user<usernameHere>, :password<pwdIsHere>) or die "couldn't connect to database";
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT *
FROM users
STATEMENT
$sth.execute();
my #rows = $sth.allrows();
for #rows { .print }
say #rows.elems;
$sth.finish;
$dbh.dispose;
This should be connecting to the DB. Then the app runs a query, followed by printing out each resulting row. What actually happens is the application hits the 'die' message every time.
This is more of a work around, but being unable to use use a DB is crippling. So even when trying to use the NativeLibs I couldn't get a connection via DBIish. Instead I have opted to using DB::MySQL which is proving to be quite helpful. With a few lines of code this module has your DB needs covered:
use DB::MySQL;
my $mysql = DB::MySQL.new(:database<databaseName>, :user<userName>, :password<passwordHere>);
my #users = $mysql.query('select * from users').arrays;
for #users { say "user #$_[0]: $_[1] $_[2]"; }
#Results would be:
#user #1: FirstName LastName
#user #2: FirstName LastName
#etc...
This will print out a line for each user formatted as shown above. It's not as familiar as DBIish, but this module gets the job done as needed. There's plenty more you can do with it to, so I highly recommend reading the docs.
According to this github DBIish issue 127
The environmental variable DBIISH_MYSQL_LIB was removed. I don't know if anyone brought it back.
However if you add the library's path, and the file is named mysql.dll, it will work. Not a good result for the scientific method.
So more testing is needed - and perhaps
C:\Program Files\MySQL\MySQL Server 8.0\lib>mklink mysql.dll .\libmysql.dll
Oviously you can create your own lib directory and add that to your path and then add this symlink to that directory.
Hope this helps. I've spent hours..
EDIT: Still spending time - accounting later.
Something very transitory is going on. I reset the machine (perhaps always do this from now on), and still got the missing mysql.dll errors. Tried going into the MySQL lib directory to execute raku from there.. worked. changed directories.. didn't work.
Launched administrator cmd - from home directory, tried the raku command. Worked. Ok - not good, but perhaps consistent. Launched non admin cmd, tried it from the MySQL lib directory, worked. And just for giggles, tried it outside of that directory.. worked.
Now I can't get it not to work. Will explore NativeLibs::Searcher as Valle Lukas suggested!
Maybe the example in the dbiish repository is not valid anymore.
The DBIISH_MYSQL_LIB Env seems to be replaced by NativeLibs::Searcher with commit 9bc4191
Looking at NativeLibs::Searcher may help to find the root cause of the problem.
I want to build a simple app that connects to remote MySQL server. However, I can't make it work.
import ballerina/io;
import ballerina/jdbc;
import ballerina/mysql;
endpoint jdbc:Client jiraDB {
host: "jdbc:mysql://DB-SERVER:3306/jira",
username: "jira",
password: "PWD",
poolOptions: { maximumPoolSize: 5 }
};
type Domain record {
string domain,
string jira,
};
function main(string... args) {
var ret = jiraDB->select("SELECT * FROM `domains`", ());
table domainTable;
match ret {
table tableReturned => domainTable = tableReturned;
error e => io:println("Select data from domains table failed: " + e.message);
}
while(domainTable.hasNext()) {
var domain = <Domain>domainTable.getNext();
match domain {
Domain d => io:println("Domain: " + d.domain);
error e => io:println("Error in get employee from table: "
+ e.message);
}
}
}
The structure of MySQL is not really important. I think it has to do with missing / wrongly used JDBC/MySQL library.
Do you please have any ideas how to make it work on Mac OS X ?
$ ballerina run hello.bal
error: ballerina/runtime:CallFailedException, message: call failed
at ..<stop>(hello.bal:5)
caused by error
at ballerina/jdbc:stop(endpoint.bal:66)
I'm using latest Mac OS X with:
$ ballerina --version
Ballerina 0.980.1
First, the latest ballerina version is 0.981.0. It would be great if you could use the latest version since it would include latest bug fixes and improvements.
In Ballerina, there is a generic jdbc client which can be used to connect to any database which has a jdbc driver. In addition, for mysql and h2 there are two clients implemented specifically for those two databases.
When connecting to mysql, you could either use the generic jdbc client or the mysql specific client. The recommendation is to use the mysql specific client.
In your code snippet, I can see you are using jdbc client. As Anoukh mentioned above, the endpoint configuration is incorrect.
Following is a sample configuration for generic jdbc client endpoint.
endpoint jdbc:Client testDB {
url: "jdbc:mysql://localhost:3306/testdb",
username: "user1",
password: "pass1",
poolOptions: { maximumPoolSize: 5 }
};
And following is a sample configuration of mysql client endpoint.
endpoint mysql:Client testDB {
host: "localhost",
port: 3306,
name: "testDB",
username: "user1",
password: "pass1",
poolOptions: { maximumPoolSize: 5 }
};
In order to use either of the clients, you need to copy the mysql jdbc driver to ${BALLERINA_HOME}/bre/lib.
Even after correcting your configuration and copying the driver, if you still face the issue, please check whether file named ballerina-internal.log is created where you are running your bal file and share. Also please share the mysql database and driver version you are using.
Have you copied the MySQL JDBC driver to the BALLERINA_HOME/bre/lib folder?
You can find the ballerina home using which ballerina command.
You can download the mysql jdbc driver from http://central.maven.org/maven2/mysql/mysql-connector-java/5.1.6/mysql-connector-java-5.1.6.jar
The issue might be in the jiraDB endpoint configurations. As per the API docs, the config for the URL of the database is to be given as url instead of host.
I was not able to connect to Mysql and I faced a driver instance error. I solved it! I'm not sure to post my answer at the good place but I think it will be a good resource to fix some problems with Mysql connections issues in Ballerina.
In my terminal : echo $BALLERINA_HOME
/Library/Ballerina/ballerina-0.990.2
Copy the good jar in the right place !
Go to : http://central.maven.org/maven2/mysql/mysql-connector-java/
I have downloaded the latest stable version (at the time of writing 8.0.15).
Copy the jar in $BALLERINA_HOME/bre/lib/
I had an error with a prior version.
Be careful that your jar have the right extension (the .jar not the repository with the same name).
Also be sure to have fulfilled the recommandations (see the doc of Oracle when installing a jar, i.e setting the classpath)
In your terminal, set the class path :
export CLASSPATH=$CLASSPATH:/Library/Ballerina/ballerina-0.990.2/bre/lib/mysql-connector-java-8.0.15
Then it will work !
I recently uploaded a Symfony2 project to GoDaddy and I'm having trouble accesing it because I get the message:
An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user 'root'#'127.0.0.1' (using password: NO)
Obviously the message is clear, so I checked and rechecked my parameters.yml, and the message don't even match what I have there, which I have changed several times to try to fix. This is my parameters.yml:
parameters:
database_driver: pdo_mysql
database_host: localhost
database_port: null
database_name: database1
database_user: database1user
database_password: mytestpassword
mailer_transport: smtp
mailer_host: 127.0.0.1
mailer_user: null
mailer_password: null
locale: en
secret: RandomTokenThatWillBeChanged
debug_toolbar: true
debug_redirects: false
use_assetic_controller: true
So, the error message doesn't tell me what is my real problem, or it is loading the parameters from some cached version that I haven't found yet. Any ideas of what else could cause or where could a cached version of this data be?
One of the best practice when developing a Symfony application is to
make it configurable via a parameters.yml file. It contains
information such as the database name, the mailer hostname, and custom
configuration parameters.
As those parameters can be different on your local machine, your
testing environment, your production servers, and even between
developers working on the same project, it is not recommended to store
it in the project repository. Instead, the repository should contain a
paramaters.yml.dist file with sensible defaults that can be used as a
good starting point for everyone.
Then, whenever a developer starts working on the project, the
parameters`.yml file must be created by using the parameters.yml.dist
as a template. That works quite well, but whenever a new value is
added to the template, you must remember to update the main parameter
file accordingly.
As of Symfony 2.3, the Standard Edition comes with a new bundle that
automates the tedious work. Whenever you run composer install, a
script creates the parameters.yml file if it does not exist and allows
you to customize all the values interactively. Moreover, if you use
the --no-interaction flag, it will silently fallback to the default
values.
http://symfony.com/blog/new-in-symfony-2-3-interactive-management-of-the-parameters-yml-file
So, is it not possible that your paramaters.yml is overwritten by paramaters.yml.dist?
You can also try to completely clear the cache
In Dev:
php app/console cache:clear
In Production:
php app/console cache:clear --env=prod --no-debug
I have installed Sonar 3.5.1 on a brand new PostgreSQL 9.2 database. The server seems to run fine, but sonar-runner (v2.2) fails with the following error:
Caused by: org.sonar.core.persistence.BadDatabaseVersion: The current batch process and the configured remote server do not share the same DB configuration.
- Batch side: jdbc:postgresql://10.1.0.210/sonar (postgres / *****)
- Server side: check the configuration at http://sonar.kopitoto/system
I am pretty confident that there is no other concurrent installation of Sonar pointing to the same database, because:
This is the first Sonar installation in this organization, ever
The value of sonar.core.id in the DB matches the value returned by the Sonar server:
Getting the value from the DB:
sonar=# SELECT text_value FROM properties WHERE prop_key = 'sonar.core.id';
text_value
----------------
20130525192736
(1 row)
Getting the value from the server:
$ curl http://sonar.kopitoto/api/server
<?xml version="1.0" encoding="UTF-8"?>
<server>
<id>20130525192736</id>
<version>3.5.1</version>
<status>UP</status>
</server>
Sonar-runner's properties:
sonar.host.url: http://sonar.kopitoto
sonar.jdbc.driverClassName: org.postgresql.Driver
sonar.jdbc.password: *****
sonar.jdbc.schema: public
sonar.jdbc.url: jdbc:postgresql://10.1.0.210/sonar
sonar.jdbc.username: postgres
Of course, the password is not five stars, but I checked it twice. If I change it a little bit, the runner fails earlier with authentication error. So a password mismatch is ruled out.
Server's sonar.properties:
sonar.jdbc.username: postgres
sonar.jdbc.password: *****
sonar.jdbc.url: jdbc:postgresql://10.1.0.210/sonar
sonar.jdbc.driverClassName: org.postgresql.Driver
sonar.jdbc.schema: public
Again, the password above is not five stars, but I am pretty sure it is correct. The server logs say nothing about errors, and shows how the database schema is initialized when I stop the thing, drop the database, create an empty one, and then start the Sonar server again.
Am I missing something?
At this point, I am thinking that this is a bug in Sonar (probably in sonar-runner). Unfortunately, Sonar's issue-tracking system is littered with such reports, all closed with "Not a bug" resolution. I guess I will be dismissed similarly if I reopen one of those issues.
So I hope I am really missing something here.