I am using Drupal 8.6.7. Now I am getting below message.
There is a security update available for your version of Drupal. To
ensure the security of your server, you should update immediately! See
the available updates page for more information.
https://www.drupal.org/project/drupal/releases/8.8.1
How to apply above security patches although not using 8.8.1?
The documentation states :
Versions of Drupal 8 prior to 8.7.x are end-of-life and do not receive
security coverage.
The only solution to apply these patches is to upgrade core :
If you are using Drupal 7.x, upgrade to Drupal 7.69.
If you are using Drupal 8.7.x or below, upgrade to Drupal 8.7.11.
If you are using Drupal 8.8.x, upgrade to Drupal 8.8.1.
Related
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
I made a cluster with 3 master and 5 data nodes.The cluster even have 25 working indices and 10 Dashboards.Now I am trying to enable authentication to this cluster.I have seen some articles saying elastic search have security services free from 7.0 version
[link](https://www.elastic.co/blog/security-for-elasticsearch-is-now-free).
But when i am going through tutorial its mentioned we need to enable xpack. xpack.security.enable: true.so is it like we need to have x-pack to fulfill this usecase ?
X-Pack is the name of the module that contains the security code.
For Elasticsearch versions prior to 6.3, X-Pack had to be installed separately as a plugin. Some X-Pack features were free to use (Basic license), some required a commercial license (e.g. Security). Starting with 6.3 the default download contains that X-Pack module already. X-Pack as a product and plugin do no longer exist.
Starting with Elasticsearch version 6.8/7.1 Elastic moved some basic security features from the commercial license into the free Basic tier, only requiring you to configure it.
The parameters for doing so are still prefixed with "xpack", as it is still a setting of an spect from within this module.
Im use a Elasticsearch 5.1.2 (docker installation) and integrated with a project generated with jHipster 4.0.2.
After configure Elasticsearch, Elastic show the message:
java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.1.2]
sn_elasticsearch |
Its posible to upgrade the client version of Spring Data Elastic integration in jHipster project? Someone knows how to?
[]s
spring-data-elasticsearch does not support version 5 yet. It is a work in progress by a team of volunteers (not driven by the Spring Data team).
According to the latest post on GitHub where you can track the issue:
Given that we will look into upgrading elasticsearch to latest version and as #olivergierke suggested it will be released with Kay if we will be able to merge changes before RC1 which is in mid March [2017].
This pull request still require major week or two of a work, its not straight forward merge. We are independent resource(s) willing to contribute on this project wherever we can, anyone who is willing to do the same is more than welcome to contribute.
We will keep posting update from our side about upgrade on the same thread.
I need to upgrade my solr search from 4.7 version to 5.3.1 .
I am working on a linux platform.
Can you please provide me the steps that i need to follow .
Thank you!
I do not think that there is a definitive step by step guide for the upgrade that you are looking for.
I have a 4.3.x SOLR running in a production environment and I am contemplating the leap to upgrade to 5.x. However its clear that a lot has changed and that my upgrade is not going to be straight forward.
Also other priorities in my project have kept me from doing the upgrade.
So rest of the discussion is more a thought process than actual upgrade experience.
Last I researched I found the below links useful
https://support.lucidworks.com/hc/en-us/articles/203776523-How-to-upgrade-between-major-Solr-Versions
https://cwiki.apache.org/confluence/display/solr/Major+Changes+from+Solr+4+to+Solr+5
From the Major changes link you will notice that a lot has changed ..
Most notably there are changes to the index format, SolrJ removal of deprecated API and that the deployment is now as a standalone server instead of a war file.
So I would suggest that you ask yourself the following questions ...
Is it possible to recreate the index from scratch ? How much time does it take to create your complete index ? If your index can be recreated quickly then , I would suggest that you do that using 5.x engine on a separate machine, while your production environment is served by your existing server. Then plan a complete upgrade from 4.x to 5.x by simply pointing your Production instance to the new SOLR engine. This approach will give you a clean slate to start with and a brand new index (but with existing data).
If you have a very large index (e.g. it takes several days to recreate it from scratch), then you may want to perform an upgrade of the live index. In that case I suggest that you consider the following.
The SOLR upgrade guide mentions 4.10 as a version that is 4.x (so I assume its is easy to upgrade from any 4.x to 4.10) and has some features built in to help with the move to 5.x. So first upgrade to 4.10 ensure that your index continues to work properly. Then use the guides mentioned above to upgrade to 5.x
We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.