When trying to configure connected assets in AEM, on the Sites instance, the connected configuration save option gets disabled after the initial setup.
Not able to save subsequent edits to the configuration, even when trying with admin credentials.
Is there any configuration to check why the save is disabled? Where under the jcr is this configuration stored?
The configuration is stored under the node /conf/global/settings/dam/remotedam/configuration/jcr:content
We can directly make edits to the properties under this node. However the remote assets instance password is stored as encrypted value. In case edit is required on the password filed, the best option as of now seems to be delete the jcr:content node at this path and reconfigure it through the UI.
Deleting the jcr:content node at this path is the only option I could find to enable the save option on the UI.
This certainly is a bug in this newly introduced feature in AEM 6.5. Hopefully will get addressed in a service pack.
As indicated in the answer - https://stackoverflow.com/a/56945996/1592801,
You don't need to delete the configuration node
Re-entering the password works - and that is working as designed.
The save button is disabled, because there have been no edits in the form to save. Once you make a change, you should be able to see the button enabled.
Related
I'm running jira in openshift using the basic image from atlassian: https://hub.docker.com/r/atlassian/jira-software
So far most things work fine.
I installed a plugin using the web ui which worked as well.
But now I'm running into an issue when a pod is restarted. The pod uses the image and naturally (as specified) my plugin is not installed anymore. I can install the plugin via webservice calls and register it as an osgi module for jira. But I don't want to do this manually. Building a pipeline or jon for this is quite easy (I'm thinking jenkins or ansible tower). But I so far I didn't find a way to trigger this pipeline after the pod is started (or better after jira is started).
Anyone got an idea how to handle this?
Thanks and best regards. Sebastian
Why not create a custom image based on the Atlassian image with everything you need installed?
As far as I know, there isn't a way to trigger a pipeline when a Pod is started; only Webhook, Image Change, and Config Change triggers are available. You'll need to write a Jenkinsfile to script all of the installation and setup you want, but then that can be triggered in one of the three ways mentioned.
I'm thinking an Image Change trigger would work best for you, so when the latest version of Atlassian's image comes out, you can run your pipeline to set everything up on the latest version.
Also, just curious, but do you have some persistent storage attached to the Jira pod? If not, you'll lose everything in Jira if the Pod dies; that means tickets, boards, comments, everything.
Update:
Looking at this page, it looks like most of the stuff you're trying to persist is stored in jira-home, so maybe mounting that as a persistent volume will be a good solution for you.
You're correct that the tickets are stored in the database, but I'm guessing the database connection settings are getting wiped when the Pod is cycled.
The jira-home directory stores your application and database connection settings, as well as a subdirectory for your plugins.
dbconfig.xml
This file (located at the root of your JIRA home directory) defines
all details for JIRA's database connection. This file is typically
created by running the JIRA setup wizard on new installations of JIRA
or by configuring a database connection using the JIRA configuration
tool.
You can also create your own dbconfig.xml file. This is useful if you
need to specify additional parameters for your specific database
configuration, which are not generated by the setup wizard or JIRA
configuration tool. For more information, refer to the 'manual'
connection instructions of the appropriate database configuration
guide in Connecting JIRA to a database.
jira-config.properties
This file (also located at the root of your JIRA home directory)
stores custom values for most of JIRA's advanced configuration
settings. Properties defined in this file override the default values
defined in the jpm.xml file (located in your JIRA application
installation directory). See Advanced JIRA configuration for more
information.
In new JIRA installations, this file may not initially exist and if
so, will need to be created manually. See Making changes to the
jira-config.properties file for more information. This file is
typically present in JIRA installations upgraded from version 4.3 or
earlier, whose advanced configuration options had been customized
(from their default values).
plugins/
This is the directory where plugins built on Atlassian's Plugin
Framework 2 (i.e. 'Plugins 2' plugins) are stored. If you are
installing a new 'Plugins 2' plugin, you will need to deploy it into
this directory under the installed-plugins sub-directory.
'Plugins 1' plugins should be stored in the JIRA application
installation directory.
This directory is created on JIRA startup, if it does not exist
already.
When I run Keycloak, I'd like it to load my LDAP configuration (user federation) automatically when it is run, so I don't have to enter it manually. Is there any way to do this with Keycloak? I'm using the containerized version 7.0.0, if it matters. I am also running in standalone mode. Thanks
You should be able to create your realm from a template that has your LDAP configuration in it.
From what I understand from your question, you want to use LDAP as your user Federation server, so you should have an LDAP up and running before starting your Keycloak container, and the container should start with the LDAP configuration.. to do this, I'll suggest a method that is a bit cumbersome at first, but it will give you a better grasp on how to configure Keycloak in the future.
Start by downloading keycloak from the website and run it without putting it in a container.. set up your Realm, clients and everything apart from the LDAP configuration.
Copy the Keycloak.json file outside of the directory, we're going to use that later
Get back to your web interface, configure your LDAP server, and save the configuration.
Now copy the keycloak.json file again, and place both versions in a text comparison tool, Diffmerge for example, and see the difference in the configuration related to your LDAP, that should be added to your container's keycloak.json.
A good practice using keycloak container is to create your whole configuration, and replace the default one, this way your container will start every time with your Realms, clients and all other pre-configured attributes.
OK so I think I figured it out. In Keycloak I had to export the realm via the standalone.sh script as specified in the documentation. Using the kcadm.sh admin CLI did not export the whole realm. Then I could import the realm using the admin CLI later. Thanks for your help it lead me to this answer.
I am trying to use buildpublisher in the ccnet.config to copy some files over after the build. I am able to do this locally on the server but if I try to copy it over to another server that is on the same network it doesnt go. I think it has to do with security settings but I am not seeing anything in the Documentation about setting a user/pass security setting or anything. Any suggestions on what do do?
<buildpublisher>
<sourceDir>C:\Build\Publish\</sourceDir>
<publishDir>\\remoteserver\Site</publishDir>
<cleanPublishDirPriorToCopy>true</cleanPublishDirPriorToCopy>
<useLabelSubDirectory>false</useLabelSubDirectory>
<description>Build publish</description>
</buildpublisher>
You need to share the \remoteserver\Site directory. Also make sure the user (or service account) that runs the CruisControl.Net service has read/write permissions on the shared directory. We use nant to copy files from Clear Case to another server with this method.
I am trying to create a new mail session in the weblogic console. I am acquiring the lock and
activating the changes to make it visible in the session. I am also able to use it in the
current session. But the problem is that mail session change is lost when I restart my
server. I have to reconfigure the mail session to use it again.
The weblogic server is running in production mode.
Please help.
Thanks & Regards,
Sujeet
It was happening because of a custom script which was overwriting the changes to config.xml upon restart.
In order to make configuration changes through the WLS console, obtain a lock on the editable collection of Configuration MBeans for all servers in the domain. The lock is obtained by clicking the Lock & Edit button.
After performing configuration changes you click the Save or the Finish button. However the changes do not take effect immediately. You have to click the Activate Changes button in the Change Center so that the configuration changes are distributed to each of the servers in the domain. Some changes require a server restart in order to take effect.
The configuration changes are saved in the config.xml file which is located in the path: your_domain_name\config.
You should see a mail-session element in the config.xml:
<mail-session>
<name>MailSession-0</name>
</mail-session>
Is there a way to change the configuration store location for the OSGi Configuration Admin service? I'd like to have the properties files exist in another bundle so they'd exist in source control & in the deployment rather than the OSGi store.
In the end I decided to use Apache Felix File Install to update the configuration properties of a Configuration Admin ManagedService. This seems to work passably well.
It's a little kludgy because when the files are updated the new configuration properties get pushed to the managed service without regard to their being correct values. This means that on next startup the values will still be bad & need to be set to defaults.
It should work for now.
The Config Admin implementations cannot do this, at least not in a portable way via the specification. Instead you need a "management agent" that pushes configuration data into Config Admin via the API; it can derive that configuration data from any source it wishes.
FileInstall is a very simple example of a management agent. If it does not do exactly what you want then it is not too difficult to write your own.
The ManagedServices will still need to perform validation of incoming configuration data and dynamically react to new configuration data. OSGi is a dynamic platform and Config Admin is designed to allow for on-the-fly reconfiguration of a running system.