I am trying to create a keystore in oracle. Reading from the documentation found here
I verified the compatible string it is above 11.2.0.0. Now the next step I run the Administer key management command
SQL> administer key management create keystore ´/oraclebase/app/oracle/product/12.1.0/dbhome_1/ORA_KEYSTORES´ identified by password;
administer key management create keystore ´/oraclebase/app/oracle/product/12.1.0/dbhome_1/ORA_KEYSTORES´ identified by password
*
ERROR at line 1:
ORA-46604: invalid or missing keystore file name
SQL>
I am getting the above error. I made the entry in sqlnet.ora file. The contents of file is as below.
# sqlnet.ora Network Configuration File: /oraclebase/app/oracle/product/12.1.0/dbhome_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/oraclebase/app/oracle/product/12.1.0/dbhome_1/ORA_KEYSTORES)))
How to resolve this problem.
Also I am not able to enter single quote in terminal.
OS: ubuntu 12.04
Oracle: 12c release enterprise edition
You appear to be using non standard quotes (´) to delimit your string, instead of straight quotes ('):
administer key management create keystore
'/oraclebase/app/oracle/product/12.1.0/dbhome_1/ORA_KEYSTORES'
identified by password;
Related
I am following this terraforming Snowflake tutorial: https://quickstarts.snowflake.com/guide/terraforming_snowflake/index.html?index=..%2F..index#6
When I run the command terraform plan in my project folder, it says:
provider.snowflake.account
Enter a value:
and then
provider.snowflake.username
Enter a value: MYUSERNAME
Which value do I have to enter? I tried entering my snowflake instance link as the account value:
dc70490.eu-central-1.snowflakecomputing.com
as well as dc70490as the account
and then my username MYUSERNAME as the username value.
However, it gives me an error that:
│ Error: could not build dsn for snowflake connection: no authentication method provided
│
│ with provider["registry.terraform.io/chanzuckerberg/snowflake"],
│ on <input-prompt> line 1:
│ (source code not available)
I also tried tf-snow as the username, since we exported this in a previous step of the tutorial
The account name should be without snowflakecomputing.com and the username need not be in caps.
https://quickstarts.snowflake.com/guide/devops_dcm_terraform_github/index.html?index=..%2F..index#3
Edit:
This is what I have used for terraform configuration to Snowflake for successful connection.
provider "snowflake"{
alias = "sys_admin"
role = "SYSADMIN"
region = "EU-CENTRAL-1"
account = "abcd123"
private_key_path = "<path to the key>"
username = "tf-snow"
}
I've been testing the Snowflake provider with version 0.25.10.
From 0.25.10 - to - 0.25.11, 0.25.11 was able to see resources the previous version (0.25.10) couldn't. The current version is 0.26.33.
I'm using Terraform 1.1.2. This is all important, because, along the way I've seen many strange errors depending on the combination.
If in doubt, try 0.25.10 first. I used:
provider "snowflake" {
account = "zx12345"
username = "A_SUITABLE_USER"
region = "eu-west-1"
private_key_path = "./my_private_key.p8"
}
I created a Snowflake user with key/pair authentication. Look at that private key path (Not for production kids), when I put it in a suitable location:
~/.ssh/my_private_tf_key.p8
This was the error:
Terraform v1.1.2
on linux_amd64
Configuring remote state backend...
Initializing Terraform configuration...
Error: could not build dsn
for snowflake connection: Private Key file could not be read: Could
not read private key:
open /home/terraform/keys/tf_london_admin_key.p8:
no such file or directory
with provider["registry.terraform.io/chanzuckerberg/snowflake"],
on main.tf line 27, in provider "snowflake": 27: provider
snowflake" {
Why highlight this? Because, I have no idea how it decided to use that dir, there's not even a /home/terraform/ dir on my system. Completely made up.
So let's just say, I'm not sure this provider is ready for prime time!
Day wasted, (YMMV).
I hope the Chan/Zukerberg combo keep supporting this going forward; I'll open a few issues on GitHub, I'm sure when all the issues are ironed out it'll be good, as I said, probably not for production though.
There is a mistake in the Snowflake tutorial, the path of the ssh key should not be :
export SNOWFLAKE_PRIVATE_KEY_PATH="~/.ssh/snowflake_tf_snow_key"
but
export SNOWFLAKE_PRIVATE_KEY_PATH="~/.ssh/snowflake_tf_snow_key.p8"
Please not that you should run terraform plan to make it work and not sudo terraform plan otherwise it will look for a ssh-key in /root/.ssh/ instead of $HOME/.ssh/ and so the whole process won't work.
I'm facing some issues when I try to run a simple SELECT query on influxdb via the Python library.
I'm trying to run the following query:
influx_client.query('SELECT * FROM "measurements" LIMIT 10;')
Of course I switched to the according database (and connected to the server) before executing the query. Also I tried those variants of the query:
influx_client.query("SELECT * FROM \"measurements\" LIMIT 10;")
influx_client.query("SELECT * FROM 'measurements' LIMIT 10;")
influx_client.query('SELECT * FROM \'measurements\' LIMIT 10;')
influx_client.query('SELECT * FROM {0} LIMIT 10;'.format("measurements"))
influx_client.query("SELECT * FROM {0} LIMIT 10;".format("measurements"))
however they all lead to the same issue.
The result (or more the error) that I get is the following:
influxdb.exceptions.InfluxDBClientError: 403: {"error":"error authorizing query: myuser not authorized to execute statement 'SELECT * FROM \"measurements\" LIMIT 10', requires READ on True"}
I know that my user have the required permissions because when connecting to the DB with a CLI I can execute the query. On top of that I checked the permissions with SHOW GRANTS and I could see that all requirements are satisfied (the user actualy does have all privileges).
I saw some simillar issues already (for instance in this issue) however this does not fit my case since I'm quoting the query.
Informations about the environment:
InfluxDB version: 1.8.0
InfluxDB-python version: 5.3.1
Python version: 3.6.8
Operating system version: CentOS 7
Any ideas ?
There are two things you need to check for the authentication issue:
https configuration with given private key and password certificate Link
Passing the user credentials for the influx db connection (Check the case sensitivity as well.
Have used influx and these are key configuration will lead to authentication issue.
using command CLI you need to provide the user permission to the given database
Using <you-database>
GRANT ALL PRIVILEGES TO <username>
Grant Permission To User
I am trying to wrap my .ipa file using intune wrapping tool and getting below error. Can someone please help.
Warning: Unable to verify system settings for certificate revocation checks. If you would like to enforce certificate revocation checks, run the following commands - 'defaults write com.apple.security.revocation CRLStyle BestAttempt' and 'defaults write com.apple.security.revocation OCSPStyle BestAttempt'
Here is the complete log.
Application packaging in progress...
Version of MACOSX is 10.15.7
Version of XCode installed is Xcode 12.4
Build version 12D4e
Parsing provisioning profile...
Parsing main app provisioning profile...
Parsing extension provisioning profiles...
Checking that main provisioning profile has not expired...
Checking that extension provisioning profiles have not expired...
Checking if signing certificate is valid...
Provided certificate name length matches that of SHA1 hash.
Number of certificates returned by query: 4
Checking certificate at index: 0
Getting certificate common name.
Computing SHA-1 fingerprint of current certificate.
Computing SHA-1 fingerprint of provided certificate.
Checking certificate at index: 1
Getting certificate common name.
Computing SHA-1 fingerprint of current certificate.
Computing SHA-1 fingerprint of provided certificate.
Possible fingerprint match found. Checking if certificate is contained in provisioning profile...
Computing SHA-256 fingerprint of certificate.
Checking if SHA-256 hash exists in provisioning profile.
Certificate was found in the provisioning profile.
Checking if certificate issuer is Apple.
Checking if signing certificate is found in each extension profile...
Creating temporary directories...
Input Parameters
Path to input application: /Users/madansandiri/Downloads/XX-5.2.7-unsigned.ipa
Path to output application: /Users/madansandiri/Downloads/XX-wrapped.ipa
Provisioning profile: /Users/madansandiri/Downloads/Intune_Test.mobileprovision
Certificate: B7 XX XX XA X1 XX XB 2F XX 3C 1A XX 7C BD XX XX XX 57 AD FB
Packager Version: 14.3.5, Packager Build: 2104.5, App Build: 5, Concatenated Build: 2123.8.5
The app's Frameworks directory could not be signed. This may be because it contains files whose format was unrecognized, invalid, or unsuitable.
Cause of the error to be provided for investigation:Error Domain=IntuneAppPackager Code=1 "/usr/bin/codesign exited with an error." UserInfo={Error Description=SignFrameworksError, NSLocalizedDescription=/usr/bin/codesign exited with an error.}
Open keychain on your mac system.
Search for iOS distribution certificate in tab 'certificates' in the keychain and expand the certificate.
Select the private key and do the right-click on it --> Click on option 'Get info'
Go to 'Access Control' tab.
Select 'Allow all applications to access this item'.
Enter the mac login or system admin password and click on the allow to save the changes.
Open terminal on mac system with root access and Execute following two commands in given order.
defaults write com.apple.security.revocation CRLStyle BestAttempt
defaults write com.apple.security.revocation OCSPStyle BestAttempt
Re-run wrapping steps to get successful wrapping instance of ios app.
#If steps given above helped you in order to resolve your issue, then give thumbs-up to this contribution.
I am using alfresco 5.2.3 enterprise with solr6 search services.
Everything works fine when I deploy our application custom code inside the alfresco-platform jar and alfresco-share jar.
Now, when I install alfresco records management amp file, the search stops working. I am not able to search even a single document or folder.
RM amp version: alfresco-rm-enterprise-repo-2.7.0.amp and alfresco-rm-enterprise-share-2.7.0.amp
There are three different instances: repo (where alfresco.war sits), share (where share.war and ADF sits) and index server (where indexes are maintained).
I install alfresco-rm-enterprise-repo-2.7.0.amp on repo, and alfresco-rm-enterprise-share-2.7.0.amp on share. And restart the servers. RM installation is successful without any errors. But search is not at all working after this.
Is it possible that after RM installation, some indexes are corrupted, and we need to conduct reindexing ? Can that resolve this issue ?
NOTE: The versions of alfresco and RM are already in the supported stack as per the alfresco documentation link: https://docs.alfresco.com/5.2/concepts/supported-platforms-ACS.html
Any help would be appreciated.
Finally, the problem is resolved.
The keystore, truststore certificate files were the culprit.
New keystore, truststore files were required to be generated as the communication between ACS and Index server was not happening and resulting into GetModelsDiff 403 error in the logs.
Additionally, we ensured the following settings were put up in ACS and index server files:
ACS alfresco-global.properties:
alfresco.host=alfresco-dev-repo.domain.com
alfresco.port=443
alfresco.protocol=https
share.host=alfresco-dev-repo.domain.com
share.port=443
share.protocol=https
db.ssl_params=&useSSL=true&requireSSL=true&verifyServerCertificate=true&trustCertificateKeyStoreUrl=file:///opt/alfresco-content-services/alf_data/keystore/ssl.truststore&trustCertificateKeyStoreType=JCEKS&trustCertificateKeyStorePassword=kT9X6oe68t
db.url=jdbc:mysql://${db.host}/${db.name}?${db.params}${db.ssl_params}
index.subsystem.name=solr6
dir.keystore=${dir.root}/keystore
solr.host=alfresco-dev-index.domain.com
solr.port.ssl=8983
solr.port=80
solr.secureComms=https
#ssl encryption
encryption.ssl.keystore.location=${dir.keystore}/ssl.keystore
encryption.ssl.keystore.type=JCEKS
encryption.ssl.keystore.keyMetaData.location=${dir.keystore}/ssl-keystore-passwords.properties
encryption.ssl.truststore.location=${dir.keystore}/ssl.truststore
encryption.ssl.truststore.type=JCEKS
encryption.ssl.truststore.keyMetaData.location=${dir.keystore}/ssl-truststore-passwords.properties
Solr Configuration:
solr.in.sh file:
SOLR_PORT=8983
SOLR_SSL_KEY_STORE=/opt/alfresco-search-services/solrhome/keystore/ssl.keystore
SOLR_SSL_KEY_STORE_PASSWORD=kT9X6oe68t
SOLR_SSL_TRUST_STORE=/opt/alfresco-search-services/solrhome/keystore/ssl.truststore
SOLR_SSL_TRUST_STORE_PASSWORD=kT9X6oe68t
SOLR_SSL_NEED_CLIENT_AUTH=true
SOLR_SSL_WANT_CLIENT_AUTH=false
alfresco core > solrcore.properties AND archive core > solrcore.properties
alfresco.secureComms=https
data.dir.root=/opt/alfresco-search-services/solrhome/
alfresco.port.ssl=8443
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
alfresco.baseUrl=/alfresco
alfresco.host=alfdevhostname.domain.com
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.encryption.ssl.truststore.provider=
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.encryption.ssl.keystore.location=ssl.keystore
alfresco.port=80
alfresco.version=5.2.3
alfresco.encryption.ssl.truststore.location=ssl.truststore
No need of touching the files under this location:
/opt/alfresco-search-services/solrhome/templates/rerank/conf
And finally the most important part:
Latest/Updated Certificate files placed under:
/opt/alfresco-search-services/solrhome/keystore
And the same certificate files placed under:
/opt/alfresco-search-services/solrhome/alfresco/conf
and
/opt/alfresco-search-services/solrhome/archive/conf
and on ACS server:
/opt/alfresco-content-services/alf_data/keystore
On top of it, if the issue is still not getting resolved, you can try the following:
Set solr.secureComms=none in alf-global, and alfresco.secureComms=none in archive core and alfresco core, and restart both entities to see if the normal HTTP connection is working without SSL or HTTPS
Validate with infra/netwk team is certificates installed r correct or not
Try pointing directly the IP address of alfresco and solr to each other, instead of host name –as it might be coming through LB
Try Telnet solr host from alfresco repo server, and also vice-versa
Put -Djavax.net.debug=all under alfresco > tomcat/scripts/ctl.sh and see if you get any useful information
Check not just the alfresco.log, solr.log, see access-logs if you can find 404 or 200 status responses. OR curl on solr machine against the URL that is logged in localhost-access logs.
Starting/stopping solr with root user – ideally should be another dedicated user for solr
Ideally certificates should be copied from alfresco (alf_data/keystore) to solr server, not from solr to alfresco server. But if not working, you can try the other way around.
The alfresco.host, share.host, alfresco.port, share.port in alf-global should match with properties in solrhome/alfresco/conf/solrcore.properties + solrhome/archive/conf/solrcore.properties
Try putting debugger on i.e debug statements on from alfresco repo side as well as solr side to capture any unknown or hidden exceptions/errors.
You can also check the solr-admin console page from browser and check the logs from there.
I faced similar issue on Alfresco 6.2.2 with alfresco-insight-engine 2.0.0. Multiple errors like below I had faced one by one after changing the configurations :-
If certificates are not matching between ACS, Solr OR between ACS, Solr and AWS OR certificates generated are incorrect OR certificates compatible only with particular java version OR certificates not added to truststore correctly, then you may get:
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException ,
unable to find valid certification path to requested target ,
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I checked the configuration (certificate) was imported correctly at AWS side. And no restriction was applied at AWS side.
But, finally I was able to resolve with the following combination:
Alfresco side
Server.xml:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
SSLEnabled="true" maxThreads="150" scheme="https"
keystoreFile="/app/tomcat/keystores/ssl.keystore"
keystorePass="pwd" keystoreType="JCEKS"
secure="true" connectionTimeout="240000"
truststoreFile="/app/tomcat/keystores/ssl.truststore"
truststorePass="pwd" truststoreType="JCEKS"
clientAuth="false" sslProtocol="TLS" />
alfresco-global.properties:
index.subsystem.name=solr6
solr.secureComms=https
solr.port=8984
solr.port.ssl=8984
solr.host=domainname
alfresco.context=alfresco
alfresco.host=host
alfresco.port=8443
alfresco.protocol=https
#
share.context=share
share.host=host
share.port=8443
share.protocol=https
#ssl encryption
encryption.ssl.keystore.location=/app/tomcat/keystores/ssl.keystore
encryption.ssl.keystore.type=JCEKS
encryption.ssl.keystore.keyMetaData.location=/app/tomcat/keystores/ssl-keystore-passwords.properties
encryption.ssl.truststore.location=/app/tomcat/keystores/ssl.truststore
encryption.ssl.truststore.type=JCEKS
encryption.ssl.truststore.keyMetaData.location=/app/tomcat/keystores/ssl-truststore-passwords.properties
solr side
solr.in.sh
SOLR_SOLR_HOST=domainname
SOLR_ALFRESCO_HOST=domainname
SOLR_SSL_CUSTOM="-Dsolr.ssl.checkPeerName=false -Dsolr.allow.unsafe.resourceloading=true"
SOLR_OPTS="$SOLR_SSL_CUSTOM"
SOLR_PORT=8984
SOLR_HOST=domainname
SOLR_SSL_KEY_STORE=/app/alfresco-insight-engine/solrhome/keystore/ssl.repo.client.keystore
SOLR_SSL_KEY_STORE_PASSWORD=pwd
SOLR_SSL_KEY_STORE_TYPE=JCEKS
SOLR_SSL_TRUST_STORE=/app/alfresco-insight-engine/solrhome/keystore/ssl.repo.client.truststore
SOLR_SSL_TRUST_STORE_PASSWORD=pwd
SOLR_SSL_TRUST_STORE_TYPE=JCEKS
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=true
solrcore.properties (both cores)
alfresco.encryption.ssl.truststore.location=ssl.repo.client.truststore
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.host=ip-10-233-4-126.ap-east-1.compute.internal
alfresco.encryption.ssl.keystore.location=ssl.repo.client.keystore
alfresco.encryption.ssl.truststore.provider=
alfresco.port.ssl=8443
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
alfresco.port=8080
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.secureComms=https
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
solrcore.properties (under rerank/conf)
alfresco.host=domainname
alfresco.port=8080
alfresco.port.ssl=8443
alfresco.secureComms=https
alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.keystore.location=ssl.repo.client.keystore
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.encryption.ssl.truststore.provider=
alfresco.encryption.ssl.truststore.location=ssl.repo.client.truststore
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties
The alfresco keystore files (used/pointed to by Alfresco) are under /app/tomcat/keystores.
And solr keystore files (used/pointed to by solr) are under /app/alfresco-insight-engine/solrhome/keystore.
NOTE: We have copied the solr keystores files to following locations also: /app/alfresco-insight-engine/solrhome/alfresco/conf , /app/alfresco-insight-engine/solrhome/archive/conf , /app/alfresco-insight-engine/solrhome/templates/rerank/conf
NOTE: If it's just a certificate not added to truststore cacerts, then you can add the certificate to the cacerts using this link: Error - trustAnchors parameter must be non-empty
Other points which can be checked if above does not work:
Check if java version is a supported one (in supported stack) and certificates are correctly getting added to the truststore.
Check the java version from alfresco's admin summary page and verify if certificates get added into the correct java
Check if solr host, port and ssl port is correctly picked up. Verify this location - http://domainname/alfresco/s/enterprise/admin/admin-searchservice , as port might be picked up from here which might not match with the one in alfresco-global.properties file. In case of mismatching properties between alf-global and admin-searchservice URL, you may get “Connection refused” error in alfresco logs when alfresco tries to connect to solr.
If JKS type of certi has become obsolete, try generating PKCS12 or JCEKS type certi.
When solr is running on 8983 (http) as well as 8984 (https/ssl), you may get error "Unsupported or unrecognized SSL message". Try stopping one which is not used.
If https with 8984 solr url is not accessible from browser, then try importing the correct certificate at AWS, and also try adding following entry in /app/alfresco-insight-engine/solr/server/etc/jetty-ssl.xml file: FALSE
I'm using wso2esb 4.9.0 and try to configure the security vault to encrypt passwords, following what is described in the official guide
I modified (commented out) lines in file secret-conf.properties and specified secret providers classes.
I let the default values (especially password and JKS for testing)
I run tool ciphertool from bin folder
Passwords in cipher-text.properties have been encrypted
and references in configuration files have been modified with attribute svns:secretAlias="[cipher-text.key]"
I restarted the server, entered the store/key password, and got the following error :
org.h2.jdbc.JdbcSQLException: Wrong user name or password [8004-140]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:327)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.get(DbException.java:144)
at org.h2.message.DbException.get(DbException.java:133)
at org.h2.engine.Engine.validateUserAndPassword(Engine.java:277)
at org.h2.engine.Engine.getSession(Engine.java:133)
at org.h2.engine.Session.createSession(Session.java:122)
at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:241)
at org.h2.engine.SessionRemote.createSession(SessionRemote.java:219)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:111)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:95)
at org.h2.Driver.connect(Driver.java:73)
at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:278)
at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:182)
at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:701)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:635)
at org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:188)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:128)
at org.wso2.carbon.user.core.claim.dao.ClaimDAO.getDialectCount(ClaimDAO.java:158)
at org.wso2.carbon.user.core.common.DefaultRealm.populateProfileAndClaimMaps(DefaultRealm.java:429)
at org.wso2.carbon.user.core.common.DefaultRealm.init(DefaultRealm.java:105)
at org.wso2.carbon.user.core.common.DefaultRealmService.initializeRealm(DefaultRealmService.java:230)
at org.wso2.carbon.user.core.common.DefaultRealmService.<init>(DefaultRealmService.java:96)
at org.wso2.carbon.user.core.common.DefaultRealmService.<init>(DefaultRealmService.java:109)
at org.wso2.carbon.user.core.internal.Activator.startDeploy(Activator.java:68)
at org.wso2.carbon.user.core.internal.BundleCheckActivator.start(BundleCheckActivator.java:61)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
[2016-08-31 12:11:46,829] ERROR - Activator Cannot start User Manager Core bundle
org.wso2.carbon.user.core.UserStoreException: Cannot initialize the realm.
at org.wso2.carbon.user.core.common.DefaultRealmService.initializeRealm(DefaultRealmService.java:240)
at org.wso2.carbon.user.core.common.DefaultRealmService.<init>(DefaultRealmService.java:96)
I checked both files ./repository/conf/datasources/master-datasources.xml and ./repository/conf/security/cipher-text.properties, the ciper key matches.
Can you tell me what i've missed ?
In-order to enable secure vault, you need to execute ./cipher-tool.sh (for linux and for windows, it is cipher-tool.bat) with the parameter -Dconfigure which will encrypt the values in cipher-text.properties, add the alias to each conf file using the xpath mentioned in cipher-tool.properies and create the secret-conf.properties file. The newly created secret-conf.properties will contain the values for secretRepositories.file.location, etc...