I have a 12.0.1 instance and I would like to upgrade to 12.0.2. I followed the guide here https://www.keycloak.org/docs/latest/upgrading/ however I do not seem to have the new option that was added here (https://github.com/keycloak/keycloak/commit/91a51c2dbeb770e0202e89b438fc16963a5eed21) in my UI. If I go to Server Info in the admin panel it shows 12.0.2 as the version.
What am I missing? Do I need to update the client separately? I downloaded the latest archive and copied the files from my old KEYCLOAK_HOME/standalone/ into the new folder and restarted keycloak. The DB was migrated from what I can tell but that UI options is just missing.
Do I need to do something to my existing realm to activate this feature?
Keycloak release 12.0.2 doesn't contain linked KEYCLOAK-16606 change. See the history of the commits: https://github.com/keycloak/keycloak/blob/12.0.2/federation/ldap/src/main/java/org/keycloak/storage/ldap/mappers/UserAttributeLDAPStorageMapper.java You need to build your own custom Keycloak release from the master or wait until change will be released.
Related
I had a catalog of version 1.0.0
I made changes to the catalog with the same version, rancher still shows the old catalog.
I have read that it is because Rancher's caching mechanism.
Ok, I then incremented the version to 1.0.1
Rancher still shows the old one.
Then made increment to 1.0.2, 1.0.4 ..etc. Still the old one.
How to force Rancher to use the real catalog instead of showing some old one??
How to clear calatog cache?
rancher v2.4.3
edit: the only solution currently is to increment version in bigger steps like 1.1.x
Here is what I have found:
Rancher doesnt provide any information about the Catalog cache or any kind of possbility to reset it.But it seems it clears the cache for the catalog once the corresponding repository deleted from the Catalog page.
Clearing the cache:
Delete the helm repository then wait the clear-cache mechanism to take effect. It takes ~1 min. Then readd the repository and it seems to work.
Whether the new catalog is in effect can be checked in the Preview section on the App Launch/Upgrade Form.
To be more specific:
The caches are stored here (at least in case of dockerized Rancher):
/var/lib/rancher/management-state/catalog-cache
So -after the deletion- once you see the corresponding cache folder has been removed you are good to go.
We have a setup where Rancher-2.5.9 is used. In this Deleting a repository is not needed. A catalog refresh works fine (select the catalog, choose the menu option, and click on refresh). I can see the new version pushed a few minute back are available in the dropdown.
But unfortunately the same is not working on another setup where rancher-2.6.3 exists. Need to debug more and see if the issue is there in the setup or in the rancher version.
I am facing the puzzling fact that the information of update sites fail to be updated despite my forcing a reload in Preferences > Install/Updates > Available Software Sites.
I have a local update site (file:/ protocol, on Windows) and an online update site (https://) that I use as staging/test update sites for an open source project that I am maintaining.
I build the update site using an update site project that is stored locally and wiped clean each time I build it. When I have tested the new release in a different Eclipse instance and I have validated my changes, I then upload the entire update site to my server. Then, just to simulate what a user would do, I update the plugin in another Eclipse instance that runs on a different physical machine.
I have (yesterday) built another version, 2.2.0.201702052007 and uploaded it to my server. The previous version was 2.2.0.201702042059.
The problem that I have is that the Eclipse instances (Mars.2 and Neon) on my development machine keep reporting the previous to last version, despite my reloading the update site information. However, the other machine sees the new version without a problem.
This is what I've tried:
Reloading the information of the update site: each time, I get a confirmation message saying "information for [...] has been reloaded from the server" but it turns out that it hasn't been reloaded: I see the older feature version.
Accessing the update site from a different Eclipse instance on a different machine: I see the new version.
Loading the update site's site.xml file from a browser: I see the new version.
Using FileZilla to download the entire update site to a local folder and unzipping content.jar and artifacts.jar so that I can read the XML files embedded in those JAR files: I see no trace of the older version.
Removing the update site, restarting Eclipse and adding the update site again: the problem was still there.
As a last resort, I removed all files of the update site from the server: Eclipse still reported successfully reloading the information from the server.
I shut down the httpd service on the VPS. Eclipse reported success until I restarted it and it then failed. But once the web server was again online, it failed to actually send a request to the web server as it kept saying there was no update site! As a consequence, the online update site now appears empty and restarting Eclipse does not change that.
[EDIT] Even more incomprehensible, the Reload button reports success even when there's no network connection to the update site (network interface disabled).[/EDIT]
There seems to be in the provisioning framework a cache somewhere between the UI and my server that reports an outdated information and feature version in spite of the explicit requests to reload that very information.
Is there any file or folder that I can delete to have the provisioning framework reset itself? If possible, I would altogether disable its cache.
I've found out that Oomph apparently has an action on the update site information retrieval process.
Anyway, I could recover normal operation (for now) and have the information properly reloaded by first deleting the appropriate files in C:\Users\...\.eclipse\org.eclipse.oomph.p2\cache.
By “the appropriate files”, I am referring to the fact that files in that folder are named after the URLs of repositories known to your Eclipse instances.
I have a problem in eclipse with the tfs plugin. I try to login and it stuck in some kind of login loop.
I looked here and in google. Nothing help.
I found this posts:
Eclipse with TFS plugin - looping login
http://social.msdn.microsoft.com/Forums/vstudio/en-US/5e3f8b3a-d623-4401-b9f1-50f1f52ab299/eclipse-tfs-plugin-keeps-signing-in-in-loop-followed-by-there-were-some-problems-message
I tried to clean cookies and password and everything possible in IE
I reinstalled the plugin. I updated everything possible, checked for eclipse indigo last version (3.2.7)
Nothing worked. Anyone can help me?
The forum posts you referenced are about the Team Foundation Service, not the on-premise server. Since the service uses Microsoft Accounts (previously known as Live Id's) it depends on cookies in your browser.
The on-premise version of Team Foundation Server uses your domain account which isn't stored as a cookie, but which is stored in the Windows Credentials Vault by default for Windows processes. Try going through the stored credentials to make sure your username/password or TFS server isn't mentioned there. If it is, either update it or remove it.
Can you verify whether the same account settings are correctly picked up by Visual Studio/Team Explorer (if you have it installed on the same machine)? Eclipse and Team Explorer should use the same credential vault.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1
When we push a new version to our server, the old extensions deployed take some time (<7hours in the docs, but I have seen more) to update themselves. The problem is that these OLD extensions may talk to the NEW services/api deployed on the server, thus raising conflicts. And those are very hard to hunt down...
Any advice?
Thanks.
You can't force autoupdate but you can pass api version along with the server response and have extension notify users to upgrade if it is outdated (response version doesn't match hardcoded into extension version).
UPDATE
Ok I just reread the question and looks like author is talking about the extension gallery. In this case you can't just point a user to the gallery as it doesn't allow you to reinstall an extension without uninstalling first anymore (it used to a while ago). In this case, to force reinstall you would have to either ask users to hit "Refresh now" button on the their chrome://extensions/ page, or download and install your extension's crx directly, which has the following (scary) format:
http://clients2.google.com/service/update2/crx?response=redirect&x=id%3D<EXTENSION_ID_HERE>%26uc%26lang%3Den-US&prod=chrome