I followed those instructions from the article https://www.jhipster.tech/tips/025_tip_create_new_authority.html and I added a new authority "ROLE_CLIENT" After that, I restarted my project, An error has appeared :
2021-07-13 00:22:46.592 WARN 3596 --- [ restartedMain] iguration$LoadBalancerCaffeineWarnLogger : Spring Cloud LoadBalancer is currently working with the default cache. You can switch to using Caffeine cache, by adding it and org.springframework.cache.caffeine.CaffeineCacheManager to the classpath.
2021-07-13 00:22:46.806 ERROR 3596 --- [ gateway-task-1] t.j.c.liquibase.AsyncSpringLiquibase : Liquibase could not start correctly, your database is NOT ready: Validation Failed:
1 change sets check sum
config/liquibase/changelog/00000000000000_initial_schema.xml::00000000000001::jhipster was: 8:06225dfc05215e6b13d8a4febd3fd90f but is now: 8:2272077bd3e9baf389312f0e018e5795
liquibase.exception.ValidationFailedException: Validation Failed:
1 change sets check sum
config/liquibase/changelog/00000000000000_initial_schema.xml::00000000000001::jhipster was: 8:06225dfc05215e6b13d8a4febd3fd90f but is now: 8:2272077bd3e9baf389312f0e018e5795
at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:299)
at liquibase.Liquibase.lambda$update$1(Liquibase.java:237)
at liquibase.Scope.lambda$child$0(Scope.java:160)
at liquibase.Scope.child(Scope.java:169)
at liquibase.Scope.child(Scope.java:159)
at liquibase.Scope.child(Scope.java:138)
at liquibase.Liquibase.runInScope(Liquibase.java:2370)
at liquibase.Liquibase.update(Liquibase.java:217)
at liquibase.Liquibase.update(Liquibase.java:203)
at liquibase.integration.spring.SpringLiquibase.performUpdate(SpringLiquibase.java:321)
at liquibase.integration.spring.SpringLiquibase.afterPropertiesSet(SpringLiquibase.java:275)
at org.springframework.boot.autoconfigure.liquibase.DataSourceClosingSpringLiquibase.afterPropertiesSet(DataSourceClosingSpringLiquibase.java:46)
at tech.jhipster.config.liquibase.AsyncSpringLiquibase.initDb(AsyncSpringLiquibase.java:118)
at tech.jhipster.config.liquibase.AsyncSpringLiquibase.lambda$afterPropertiesSet$0(AsyncSpringLiquibase.java:93)
at tech.jhipster.async.ExceptionHandlingAsyncTaskExecutor.lambda$createWrappedRunnable$1(ExceptionHandlingAsyncTaskExecutor.java:78)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
By the way, I am using microservices architecture and JWT authentication.
This is normal: a Liquibase changeset is supposed to be immutable.
This is why Liquibase records md5 checksum with each changeset entry in the database changelog table to detect differences between what is currently in the changelog and what was actually ran against the database.
When you modified authority.csv, the checksum of the changeset changed and Liquibase rightly complained.
So, you have 3 alternative solutions:
Create a separate changeset to insert only your new authority (preferred way in production)
Clear the checksum column of your changeset in your use a db client like DBeaver to connect to your db and delete the MD5SUM column for your changelog row in DATABASECHANGELOG table. Look at https://docs.liquibase.com/concepts/basic/databasechangelog-table.html
Drop your database to restart from scratch, this could work for a dev database if you don't care about yourdata
Final advice: learn more about Liquibase from official docs also from JHipster doc
Related
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
In Fauxton, I've setup a replication rule from a CouchDB v1.7.1 database to a new CouchDB v2.3.0 database.
The source does not have any authentication configured. The target does. I've added the username and password to the Job Configuration.
It looks like the replication got stuck somewhere in the process. 283.8 KB (433 documents) are present in the new database. The source contains about 18.7 MB (7215 docs) of data.
When restarting the database, I'm always getting the following error:
[error] 2019-02-17T17:29:45.959000Z nonode#nohost <0.602.0> --------
throw:{unauthorized,<<"unauthorized to access or create database
http://my-website.com/target-database-name/">>}:
Replication 5b4ee9ddc57bcad01e549ce43f5e31bc+continuous failed to
start "https://my-website.com/source-database-name/ "
-> "http://my-website.com/target-database-name/ " doc
<<"shards/00000000-1fffffff/_replicator.1550593615">>:<<"1e498a86ba8e3349692cc1c51a00037a">>
stack:[{couch_replicator_api_wrap,db_open,4,[{file,"src/couch_replicator_api_wrap.erl"},{line,114}]},{couch_replicator_scheduler_job,init_state,1,[{file,"src/couch_replicator_scheduler_job.erl"},{line,584}]}]
I'm not sure what is going on here. From the logs I understand there's an authorization issue. But the database is already present (hence, it has been replicated partially already).
What does this error mean and how can it be resolved?
The reason for this error is that the CouchDB v2.3.0 instance was being re-initialized on reboot. It required me to fill-in the cluster configuration again.
Therefore, the replication could not continue until I had the configuration re-applied.
The issue with having to re-apply the cluster configuration has been solved in another SO question.
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...
I upgraded OpsCenter from 5.1.3 to 5.2.0 (and then to 5.2.1). I had a scheduled backup to local server and an S3 location configured before the upgrade, which worked fine with OpsCenter 5.1.3. I made to no changes to the scheduled backup during or after the upgrade.
The day after the upgrade, the S3 backup failed. In opscenterd.log, I see these errors:
2015-09-28 17:00:00+0000 [local] INFO: Instructing agents to start backups at Mon, 28 Sep 2015 17:00:00 +0000
2015-09-28 17:00:00+0000 [local] INFO: Scheduled job 458459d6-d038-41b4-9094-7d450e4bac6f finished
2015-09-28 17:00:00+0000 [local] INFO: Snapshots started on all nodes
2015-09-28 17:00:08+0000 [] WARN: Marking request d960ad7b-2ccd-40a4-be7e-8351ac038c53 as failed: {'sstables': {u'solr_admin': {u'solr_resources': {'total_size': 155313, 'total_files': 12, 'done_files': 0, 'errors': [u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', shortened for brevity.
The S3 location no longer appears in OpsCenter when I edit the scheduled backup job. When I try to re-add the S3 location, using the same bucket and credentials as before, I get the following error:
Location validation error: Call to /local/backups/destination_validate timed out.
Also, I don't know if this is related, but for completeness, I see some of these errors in the opscenterd.log as well:
WARN: No http agent exists for definition file update. This is likely due to SSL import failure.
I get this behavior with either DataStax Enterprise 4.5.1 or 4.7.3.
I have been having the exact same problem since updating to OpsCenter 5.2.x and just was able to get it working properly.
I removed all the settings suggested in the previous answer and then created new buckets in us-west-1, us-west-2 and us-standard. After this I was able to successfully able to add all of those as destinations quickly and easily.
It appears to me that the problem is that OpsCenter may be trying to list the objects in the bucket that you configure initially, which in my case for the 2 existing ones we were using had 11TB and 19GB of data in them respectively.
This could explain why increasing the timeout for some worked and not others.
Hope this helps.
Try adding the remote_backup_region property to the cluster configuration file under the [agents] heading in "cluster-name".conf. Valid values are: us-standard, us-west-1, us-west-2, eu-west-1, ap-northeast-1, ap-southeast-1
Does that help?
The problem was resolved by a combination of 2 things.
Delete the entire contents of the existing S3 bucket (or create a new bucket as previously suggested by #kaveh-nowroozi).
Edit /etc/datastax-agent/datastax-agent-env.sh and increase the heap size to 512M as suggested by a DataStax engineer. The default was set at 128M and I kept doubling it until backups became successful.
I am running Liferay 6.2 on WebLogic 12c server.
Out of nowhere it just stopped working.
This is the last thing I see before it throws a flurry of exceptions
<Jan 10, 2014 2:53:28 PM EST> <Notice> <LoggingService> <BEA-320400> <The log fi
le C:\Oracle_2\Middleware\user_projects\domains\liferay\servers\AdminServer\logs
\AdminServer.log will be rotated. Reopen the log file if tailing has stopped. Th
is can happen on some platforms, such as Windows.>
<Jan 10, 2014 2:53:28 PM EST> <Notice> <LoggingService> <BEA-320401> <The log fi
le has been rotated to C:\Oracle_2\Middleware\user_projects\domains\liferay\serv
ers\AdminServer\logs\AdminServer.log00369. Log messages will continue to be logg
ed in C:\Oracle_2\Middleware\user_projects\domains\liferay\servers\AdminServer\l
ogs\AdminServer.log.>
The errors are shown here http://www.pastebin.ca/2532946
Anyone have any ideas on this?
As you can see in the log files (see below excerpt of your log file), Liferay is not able to either get a handle to the HSQL database or the HSQL db might be corrupted when you updated it.
13:11:16,769 WARN [C3P0PooledConnectionPoolManager[identityToken->uArzPQ2m]-HelperThread-#4][BasicResourcePool:1851] com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask#933b16 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (3). Last acquisition attempt exception:
java.sql.SQLException: error in script file line: 15 unexpected token: AVG
So you need to answer below questions:
Did you use any Client tool to make changes to your HSQL db?
If yes, did you close the connection to HSQL database before starting Liferay?
If not, Liferay won't be able to acquire lock on your db and fail to start.
If not, did you make DB changes directly in the HSQL db file?
This is NOT Recommended. Rollback your changes and try to use HSQL client to make your db changes
HTH!
P.S. Is this issue duplicate of: https://stackoverflow.com/questions/21052236/weblogic-wont-start. If so, please delete that one.