I'd like to configure the Adobe Cloud Manager production pipeline to invalidate the whole dispatcher cache. What paths do I have to give at the production pipeline dispatcher invalidation configuration to have that done? Is it possible to give a pattern here that matches everything? The page-invalidate description talks about a path-pattern, but doesn't describe what exactly that means.
We work with statfilelevel=2. It seems the .stat files are very important for that, though the description given here is unfortunately not precise enough, not sure I understand that right.
I tried to configure /content as path - that just touches /mnt/var/www/html/.stat (/mnt/var/www/html is the docroot), which seems to apply to nodes like /* but not like /content/* .
If I give /content/oursite, that touches /mnt/var/www/html/content/.stat , too, but that does seem to apply to nodes like /content/oursite or /content/othersite, but not to pages like /content/oursite/about - for which would /mnt/var/www/html/content/oursite/.stat be relevant, if I understand that right.
Do I seriously have to enumerate a page in each site that has a .stat file, or is there a more sensible way to get everything invalidated? After all, a deployment could easily change the HTML of every page if a component has changed.
If you have ACS commons installed then you can try to use this powerful feature
https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html
Related
Can not find any issues.
I have to add several custom http headers to access my dedicate api-server proxy, but no clues available right now. Did I miss something?
This is a dirty hard coded hack to show you how to get the outcome your looking for it's not a fully vetted solution. This method will compile a new version of kubectl that will add your needed headers. Maybe it will at least give you a idea to run with.
The reason I wanted to do this is because I put my k8s api endpoint on the internet and safeguarded it with Cloudflare Access. To allow Cloudflare access to let me get past the steel wall I needed to pass in two headers one for my client id and the other for client secret. This ended up working like a charm and is one case someone may want to add custom headers.
Steps:
I assume you have Go installed and setup, if not go do that now.
git clone https://github.com/kubernetes/kubernetes.git (could take awhile it's pretty big)
cd kubernetes/staging/src/k8s.io/client-go/transport/
Open file round_trippers.go in your favorite code editor
Search for func (rt userAgentRoundTripper) RoundTrip(req http.Request) (*http.Response, error)
Add your needed headers by adding lines like this req.Header.Set("Bob-Is", "cool")
cd back to root folder kubernetes/
cd cmd/kubectl/
go build custom-kubectl
now test it with ./custom-kubectl get ns --v=9
in that output look for the header you added to the rest calls to K8s api, you should see -H "Bob-Is: cool" in the output
To make this not a hack maybe see if there's a way to add a kubectl plugin you create do to this for you or ask the kind folks in the k8s community how you can make this hacky method a bit cleaner or if there's a reason adding customer headers isn't a good idea. Worst case parameterize your custom kubectl build to pull in a new parameter you add --custom-request-headers and make it a bit more clean.
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
I'm interested in using Hot Module Replacement with a newly created React app.
Facebook Incubator's create-react-app uses Webpack 2 which can be configured to support HMR, however in order to do so, one needs to "eject" the create-react-app project.
As the documentation points out, this is a "one way" operation and cannot be reversed.
If I'm to do this, I want to know what I might be giving up. I've been unable to locate any documentation that explains the potential drawbacks of ejecting.
The current configuration allows your project to get updates from create-react-app core team. Once you eject you no longer get this.
It's kind of like pulling in bootstrap css via CDN as opposed to downloading the source code and injecting it directly into your project.
If you want more control over your webpack, there are ways to configure/customize it without ejecting:
https://www.npmjs.com/package/custom-react-scripts
This is the scenario (CQ5.6). Let's say there is the following node /content/geometrixx/articles, with articles inside of it. In author instance I create a package as a backup of that node. Then I deactivate article1 inside of articles, if I try to access the page I get a 404 page, that is fine. However if I build the backup package again and then replicate it, the deactivated page (article1) is available, that is, I do not get the 404 but instead the article.
Is there a way to replicate a package while preserving deactivated pages? That is, how I avoid re-activation?
Replicating package means that you are replicating every thing available in Package. Which means publish environment will have deactivated pages also. There are several ways to handle it, like:
Simplest way is to add a check in template (as first rule) to see if Env==publish && requested resource ==not activated, if so, return 404 page.
Another way is to create a script to delete all deactivated pages, and run this script on publish after page activation.
Add exclude filters in your package to exclude such pages.
I would recommend to use #1 as this is one time change and will be future proof.
should use treeactivation: http://localhost:4502/etc/replication/treeactivation.html, much safer (since you have 3 options: Only Modified, Only Activated and Ignore Deactivated)
Sometime someone want to change inside something crx directly on environment.
Often it is a cause of unworking state of environment. And often enough hard to find the cause of the problem. And I think it is will be helpful if cq5 crx will have audit log. something like this.
12.12.12 21:03 /etc/blueprints/geometrixx was removed [rollout]
...
maybe CQ5 has something like this already?
Assuming these changes to the repositories are made using crxde lite[/crx/de/index.jsp] or content explorer [/crx/explorer/browser/index.jsp] , there is an indirect way to find out who did it.
The data can be fetched by looking into two different logs request.log and audit.log [these files can be found at \crx-quickstart\logs folder ]
The modifications to nodes are POST requests. These are logged in request.log , the path of the request will only show the interface used or to root node. If you search the time stamp of the POST in audit.log you can find which user did a GET request.
This is not direct way, nor will it tell more of the changes except for which user read the node at the time of the POST .