I'm trying to set the GLOBAL time of my MariaDB database to UTC. I've followed the recommendations of their official documentation and default_time_zone="+00:00" in the my.cnf file, however it does NOT work and I get the following error when I start it in the shell: mysql: unknown variable 'default_time_zone=+00:00'.
Does anyone have an idea?
Thanks
Remove the quotes
As the error message states command line client (mysql) complains about unknown variable, since default_time_zone is a server but not a client variable. So you added it in wrong section. Move the entry to the server section:
[server]
default_time_zone=+00:00
Related
We're encountering some errors when starting Nifi 1.16.3 after calling encrypt-config.sh in a secure environment.
For background, Nifi is deployed and managed using an in-house deployment product, and is used as a component within our application stack. In general everything works fine when using Nifi 1.15.1, however, we are encountering issues when using Nifi 1.16.3.
In short, when deploying an instance of Nifi in our system, we first create all settings necessary, including a nifi.properties and bootstrap.conf files.
At this first stage, we set an initial password of nififtw! to sensitive.props.key, which at this moment in time is plain text.
We execute encrypt-config command:
JAVA_HOME=/tech/java/openjdk1.8.0_322
/bin/encrypt-config.sh --key AAAF0313BCC242CC9EC1DD30AD74FB2E --niFiProperties /servers/nifi/default/conf/nifi.properties --loginIdentityProviders /servers/nifi/default/conf/login-identity-providers.xml --bootstrapConf /servers/nifi/default/conf/bootstrap.conf
At this stage, we don't parse in the flow.xml as it doesn't exist yet, however, the protected values in nifi.properties, i.e sensitive.props.key, are encrypted based on the --key.
Nifi starts as expected.
In a later moment, when updating our system, we invoke encrypt-config.sh one more time, but now we attempt to change the propsKey to the same value of they hexkey used. Note that at this stage, we have a flow.xml and we parse in the path as an argument:
JAVA_HOME=/tech/java/openjdk1.8.0_322
/bin/encrypt-config.sh --key AAAF0313BCC242CC9EC1DD30AD74FB2E --niFiProperties /servers/nifi/default/conf/nifi.properties --loginIdentityProviders /servers/nifi/default/conf/login-identity-providers.xml --flowXml /databases/nifi/default/flow.xml.gz --propsKey AAAF0313BCC242CC9EC1DD30AD74FB2E --bootstrapConf ey/servers/nifi/default/conf/bootstrap.conf
No errors are encountered at this stage and the value of sensitive.props.key in nifi.properties is changed accordingly. However, when attempting to start nifi server, we encounter the error bellow:
nifi-bootstrap.log
2022-11-13 06:32:06,488 INFO [main] org.apache.nifi.bootstrap.Command Launched Apache NiFi with Process ID 82873
2022-11-13 06:32:14,269 INFO [NiFi Bootstrap Command Listener] org.apache.nifi.bootstrap.RunNiFi Apache NiFi now running and listening for Bootstrap requests on port 32908
2022-11-13 06:34:06,217 ERROR [NiFi logging handler] org.apache.nifi.StdErr Failed to start web server: Decryption Failed with Algorithm [PBEWITHMD5AND256BITAES-CBC-OPENSSL]
2022-11-13 06:34:06,218 ERROR [NiFi logging handler] org.apache.nifi.StdErr Shutting down...
2022-11-13 06:34:06,945 INFO [main] org.apache.nifi.bootstrap.RunNiFi NiFi never started. Will not restart NiFi
nifi-app.log
2022-11-13 06:34:06,209 INFO [main] org.eclipse.jetty.server.Server Started #119858ms
2022-11-13 06:34:06,209 WARN [main] org.apache.nifi.web.server.JettyServer Failed to start web server... shutting down.
org.apache.nifi.encrypt.EncryptionException: Decryption Failed with Algorithm [PBEWITHMD5AND256BITAES-CBC-OPENSSL]
at org.apache.nifi.encrypt.CipherPropertyEncryptor.decrypt(CipherPropertyEncryptor.java:78)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.decrypt(StandardFlowComparator.java:281)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.lambda$compareProperties$3(StandardFlowComparator.java:291)
at java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compareProperties(StandardFlowComparator.java:289)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:267)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.lambda$compareComponents$1(StandardFlowComparator.java:114)
at java.util.HashMap.forEach(HashMap.java:1290)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:467)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.lambda$compare$5(StandardFlowComparator.java:472)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.lambda$compareComponents$1(StandardFlowComparator.java:114)
at java.util.HashMap.forEach(HashMap.java:1290)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compareComponents(StandardFlowComparator.java:112)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:472)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:94)
at org.apache.nifi.registry.flow.diff.StandardFlowComparator.compare(StandardFlowComparator.java:79)
at org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.compareFlows(VersionedFlowSynchronizer.java:387)
at org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:167)
at org.apache.nifi.controller.serialization.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:43)
at org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1524)
at org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:107)
at org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:819)
at org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:542)
at org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:67)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:1073)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:572)
at org.eclipse.jetty.server.handler.ContextHandler.contextInitialized(ContextHandler.java:1002)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:746)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:379)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1449)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1414)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:916)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:426)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.server.Server.start(Server.java:423)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.server.Server.doStart(Server.java:387)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:1008)
at org.apache.nifi.NiFi.<init>(NiFi.java:170)
at org.apache.nifi.NiFi.<init>(NiFi.java:82)
at org.apache.nifi.NiFi.main(NiFi.java:330)
Caused by: javax.crypto.BadPaddingException: pad block corrupted
at org.bouncycastle.jcajce.provider.symmetric.util.BaseBlockCipher$BufferedGenericBlockCipher.doFinal(Unknown Source)
at org.bouncycastle.jcajce.provider.symmetric.util.BaseBlockCipher.engineDoFinal(Unknown Source)
at javax.crypto.Cipher.doFinal(Cipher.java:2168)
at org.apache.nifi.encrypt.CipherPropertyEncryptor.decrypt(CipherPropertyEncryptor.java:74)
... 62 common frames omitted
As shown in the errors above, the decryption fails when attempting to start the nifi server.
We suspect that when we try to encrypt the flow.xml with a new sensitive.props.key, the re-encryption doesn't happen, even though the value of propsKey in nifi.properties has been replaced and encrypted accordingly to the new password we parse.
After we get the failure described, if we manually change the propsKey in nifi.properties to what it was before (the encrypted version of 'nififtw!'), we manage to start nifi successfully.
Note that the password nififtw! is just one example. The issue happens with any password we might use for the first call of encrypt-config, even if we call encrypt-config again specifying a new propsKey.
We've attempted to modify the arguments used when executing the encrypt-config.sh, i.e. by creating the modified flow.xml and nifi.properties in a /tmp/ directory and manually replacing the older versions, which hasn't worked either.
This issue only arrises in Nifi version 1.16.3.0. We were using version 1.15.1.0 and version 1.11.3.0 and the same logic works perfectly fine.
This is how my nifi.properties looks like:
# security properties #
nifi.sensitive.props.key=<encrypted-key>
nifi.sensitive.props.key.protected=aes/gcm/128
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.additional.keys=
Any idea of what might be causing this issue?
The error that you encountered in nifi 1.16 is appearing because of some changes introduced in nifi starting from 1.16 version.
Starting from nifi 1.16 , NIFI start writing on flow.xml.gz as well as JSON format ( prior to 1.16 this JSON was not there ) flow.json.gz , see the link https://www.mail-archive.com/users#nifi.apache.org/msg15332.html
When 1.16 nifi start it creates both the file, writes onto it and then encrypt it using props key from nifi.properties , when your code run encrypt-config.sh tool it only changes the flow.xml.gz with new props key and JSON flow file still encrypted with old props key,
While next time nifi going to start it try to read props key from nifi.properties , which is the new ( changed props key ) and it successfully able to decrypt the flow.xml.gz but it can not able to decrypt flow.json.gz because JSON file is still encrypted with old props key which is overwritten by new props key on nifi.properties
Solution : from 1.16 onwards "./bin/nifi.sh set-sensitive-properties-key NewSensitivePropertiesKey" tool improved to cover both xml as well as json version of flow file while changing the props key, see JIRA ticket https://issues.apache.org/jira/browse/NIFI-9711 , So while changing the props key you can try using nifi.sh in place of encrypt-config.sh
Regards
Vikas
Im using xampp control panel and from there i start the process for apache and mysql. Then i go to mysql workbench and server status seems to be ok, here is some info
Host: Windows-PC
Socket: C:/xampp/mysql/mysql.sock
Port: 3306
Version 10.1.31-MariaDB mariadb.org binary distribution
Compiled For: Win32(32)
Configuratin File: unknown
Then everytime when i try to add the foreign key for my dummy schema like:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE;
;
ALTER TABLE `puppies`.`animals`
ADD CONSTRAINT `Breed`
FOREIGN KEY (`BreedID`)
REFERENCES `puppies`.`breeds` (`Breed`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
I get the following error
ERROR 1064: You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near
'' at line 2
SQL Statement:
ALTER TABLE `puppies`.`animals`
ADD INDEX `Breed_idx` (`BreedID` ASC) VISIBLE
So what can i do so that xampp will start using mysql syntax over mariaDb?
Or if im wrong in my understanding of the problem, then what should i do so that i dont have to face this kind of issues again when using xampp?
Problem is the word VISIBLE, remove it and it will work.
Index are visible by default.
Your question: "If i remove VISIBLE it works just fine, so why did mysql workbench decided to add visible?"
My answer: The option to mark index invisible is not yet implemented in MariaDB (afaik!).
Update:
The syntax for MariaDB is different, please see this reference: https://jira.mariadb.org/browse/MDEV-7317
Just to add to those who are using Maria DB with MySQL Workbench, you don't need to install mysql. You can just change 'Default Target MySQL Version' from Preferences to 5.7 or 5.6, and the VISIBLE keyword will be removed by workbench.
Here is a link from mysql bugs
https://bugs.mysql.com/bug.php?id=92269
I am using MySQL Workbench and have same problem. Change in the Preferences but it did not work.
Solution: If you export forward-engineer the model you need to change the configuration on another place.
Go to Model > Model Options
Inside the Model Options, go to MySQL
Then change the "Target MySQL Version" to 5.6
I am upgrading from Flyway 5.4 to 7.7.3 and ran into some issue.
flyway -teams -url=jdbc:oracle:thin:#localhost:1521/XE "-user=xxx as SYSDBA" -password=xxx -table=flyway_schema_history_app -encoding=utf-8 -baselineOnMigrate=true migrate
(I have the teams edition license)
Flyway gives me the following error message:
**
ERROR: Unable to parse statement in /flyway/sql/incremental/Build_302_Baseline/V302_106__fosprd_INSERT_Master_eg_pocqueue.sql at line 117 col 1. See https://flywaydb.org/documentation/knownparserlimitations for more information: No value provided for variable substitution: &R. Check your configuration. If this is not a SQLPLus variable intended to be substituted (eg. in a string literal), then you will need to add SET DEFINE OFF in the script beforehand.
Caused by: No value provided for variable substitution: &R. Check your configuration. If this is not a SQLPLus variable intended to be substituted (eg. in a string literal), then you will need to add SET DEFINE OFF in the script beforehand.
**
This is caused by a special character "&" in the SQL statement, however, I have made sure the SQL file is using UTF-8 encoding as well as Unix return (LF).
Also, I keep my callbacks under:
bash-5.0$ pwd
/flyway/sql/callbacks
bash-5.0$ ls
afterBaseline.sql afterEachUndo.sql afterMigrateError.sql afterUndo.sql beforeEachUndo.sql
afterBaselineError.sql afterEachUndoError.sql afterRepair.sql afterUndoError.sql beforeMigrate.sql
afterEachMigrate.sql afterMigrate.sql afterRepairError.sql beforeEachMigrate.sql beforeUndo.sql
This used to be able to run on 5.4 with no issue. But it's giving me this error on 7.7.3, anyone can point me to the right direction?
Thanks
This is due to the changes between versions of flyway's SQLPlus support and the fat you have a teams license.
As indicated in the message, this is related to SQLPlus's variable substitution:
https://flywaydb.org/documentation/database/oracle#variable-substitution
If you are not using SQLPlus features, you could try disabling them:
https://flywaydb.org/documentation/configuration/parameters/oracleSqlPlus
but the recommended solution is to place SET DEFINE OFF in the SQL script before the offending ampersand (with the option of reverting that afterwards)
I am trying to run the example grakn migration "phone_calls" (using python and JSON files).
Before reaching there, I need to load the schema, but I am having trouble with getting the schema loaded, as shown here: https://dev.grakn.ai/docs/examples/phone-calls-schema
System:
-Mac OS 10.15
-grakn-core 1.8.3
-python 3.7.3
The grakn server is started. I checked and the 48555 TCP port is open, so I don't think there is any firewall issue. The schema file is in the same folder (phone_calls) as where the json data files is, for the next step. I am using a virtual environment. The error is below:
(project1_env) (base) tiffanytoor1#MacBook-Pro-2 onco % grakn server start
Storage is already running
Grakn Core Server is already running
(project1_env) (base) tiffanytoor1#MacBook-Pro-2 onco % grakn console --keyspace phone_calls --file phone_calls/schema.gql
Unable to create connection to Grakn instance at localhost:48555
Cause: io.grpc.StatusRuntimeException
UNKNOWN: Could not reach any contact point, make sure you've provided valid addresses (showing first 1, use getErrors() for more: Node(endPoint=/127.0.0.1:9042, hostId=null, hashCode=5f59fd46): com.datastax.oss.driver.api.core.connection.ConnectionInitException: [JanusGraph Session|control|connecting...] init query OPTIONS: error writing ). Please check server logs for the stack trace.
I would appreciate any help! Thanks!
Nevermind -- I found the solution, in case any one else runs into a similar problem. The server configuration file needs to be edited: point the data directory to your project data files (here: the phone_calls data files) & change the server IP address to your own.
Error: - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '#', 1) LIMIT 1' at line 2
Thanks in advance.
I had the same problem.When you are importing whole DB then its quite difficult to find the error.
Check Your 'Option' Column. Problem Could Be In Dumping The Data There.
But I solved it in my way, I didn't import whole DB, I uploaded in pieces.Now what you have to do is
-Import Each Column Manually.
-Then Dump It Manually
There You Go.