How to test claims-config.xml file WSO2 Identity Server - wso2

WSO2 documentation states that claims are read from the claim-config.xml file only once here: https://docs.wso2.com/display/IS570/Adding+Claim+Mapping
"The claims configured in <IS_HOME>/repository/conf/claim-config.xml file get
applied only when you start the product for the first time, or for any newly
created tenants. With the first startup, claim dialects and claims will be
loaded from the file and persisted in the database. Any consecutive updates to
the file will not be picked up and claim dialects and claims will be loaded
from the database."
The documentation makes it seem like you only have "one chance" to see how your claim-config.xml works. I'm in the process of developing and debugging the file though - is there a way to force WSO2 to read from the claim-config.xml file again or delete relevant data from the database to force claim-config.xml to be read?
I'd like to avoid completely uninstalling the product and reinstalling every time I want to observe a change I made to the claim-config.xml file.
Things I have tried:
Completely deleting the database files (WSO2CARBON_DB.h2.db) from \repository\database. This prevented the WSO2 server from starting up.
Deleting the entries from the IDN_CLAIM table from the H2 database. This started the server, but I wasn't able to login.

Completely deleting the database files (WSO2CARBON_DB.h2.db) from
\repository\database. This prevented the WSO2 server from starting up.
If you are okay with completely resetting databases, you can delete above files. As #senthalan wrote in comments, then you need to start the server with '-Dsetup' flag. It recreates DB, re-populates the configuration and starts the server.
sh wso2server.sh -Dsetup

Related

ColdFusion 2018 scheduled tasks not working

We have recently began migrating to ColdFusion 2018 Enterprise, but have found that the scheduled tasks do not work. Although the relevant cfm file works if run in the browser on the same server, if we try and run it as a scheduled tasks then it does not work (although it will say it has run successfully on the screen).
The log file just contains a single line for each run:
Information","DefaultQuartzScheduler_Worker-5","11/20/20","12:48:18","","Task default.takename triggered."
From what I understand there should be additional lines for the http request etc, however.
We have tried various usernames and passwords, including admin accounts to make sure it is not a permissions issue but nothing seems to make any difference.
We have also tried outputting to a file but nothing ever populates the file, although it does update the file's modified date with the date/time the tasks ran (or create a new file if necessary).
Does anyone have any experience with this type of problem?
This ended up being an IIS permissions issue. We resolved it by enabling anonymous authentication for both the directory that the relevant cfm files are contained in, as well as the "jakarta" directory that I believe ColdFusion uses for some integration requirements. Scheduled tasks then ran as expected.

WSO2 IS: claim-config.xml - Is it read only once, or every time the server is started up?

The WSO2 IS documentation reads:
"The claim dialects configured in /repository/conf/claim-config.xml file get applied only when you start the product for the first time, or for any newly created tenants. With the first startup, claim dialects and claims will be loaded from the file and persisted in the database. Any consecutive updates to the file will not be picked up and claim dialects and claims will be loaded from the database."
Does this mean claim-config.xml is a file to seed the database and is only run once? If it is only for seeding the database, that means the only way to update claims after the very first start of the server is to edit the database directly or update claims via the console, correct?
I'm trying to figure out the best way to update my claims for service providers in WSO2 IS.
I discovered that the claim-config.xml is only run once. After the database is seeded, the file is not read anymore. Subsequent changes to the claim configuration are written to the WSO2CARBON_DB file which is located at WSO2_INSTALL_LOCATION\repository\database
When WSO2 IS starts in the first time, or when creating a new tenant It reads the claim-config.xml file and populates the claims into the database. Then you can manage the claims as below methods,
From management console. Please refer the documentation [1] for more
details.
Using ClaimMetadataManagementService. Please refer the
documentation [2] for more details.
[1] https://docs.wso2.com/display/IS570/Configuring+Claims
[2] https://docs.wso2.com/display/IS570/Managing+Claims+with+APIs

Django email log file "sent" growing

I have a sent file that keeps growing on my staging server. It stores a log of all emails sent and I don't know what's causing this behaviour, it doesn't look like a feature from the Django framework (1.8).
I can't find any reference of this log file in the source code. It's an issue for several reasons, including the fact that it causes the server to run out of disk space.
Maybe I'm missing something obvious in the Django config. I don't see how to fix this issue besides running a cron task to delete that file regularly. I'm open to better ideas.

WSO2 EMM mysql database setup

I am using WSO2 EMM 1.1.0. The documents talk about using a MySQL instead of H2 https://docs.wso2.com/display/EMM110/Setting+up+MySQL. It talks about editing the master-datasource.xml file and updating the WSO2_CARBON_DB, WSO2_EMM_DB and WSO2AM_DB databases. It then gives steps on priming those db's. But the master-datasource.xml file also contains the WSO2_IDENTITY_DB, SOCIAL_CACHE, SOCIAL_CASSANDRA_DB and JAGH2. I expect all of those can be moved to MySQL as well but I don't see the database scripts to set them up. What is the proper procedures to set up a system that uses MySQL instead of H2? Not to mention that the emm database had the database name hard coded into the setup script "USE WSO2EMM_DB" thus nullifying the master-datasource.xml file.
Thanks,
Brian
It is mentioned in this documentation[1] under the topic 'How to migrate from H2 to MySQL'
[1] - https://docs.wso2.com/display/EMM110/Upgrading+from+a+Previous+Release
You need to configure WSO2EMM_DB, WSO2AM_DB and WSO2CARBON_DB and WSO2IDENTITY_DB if you are going ahead with a larger deployment. H2 is setup just for make the out of the box experience better. You can create those DBs, Configure master_datasources.xml properly for all above DBs. And then run the server with the flag -Dsetup. It will get the configurations done automatically.
If it fails, you can also go to SERVER_HOME/dbscripts folder and find all the scripts for all above databases. Run them separately and run the server in the usual way which mentioned in our documentation.

Copying Embedded H2 database data to another registry instance

I have a local Gov. registry 4.6.0 setup with standard out of box H2 embedded database where I added lots of artifact types and data to each custom artifact type.
I want to copy all data from my local H2 database to another Gov. registry 4.6.0 instance which is running on a server.
I do not want to repeat this on the registry instance running on the server and have to recreate the custom artifact types and have to re add the data that I have locally.
I could not find any documentation that allows me to do that.
Is there any way to do this?
Also how can I connect to and browse the embedded H2 database? Is there some script to run?
Thanks
There are actually two options,
H2 database can be found at /repository/database directory. You can simply copy this directory in to other server and replace it. To do that, 1st stop both server, then copy the directory and replace it with other server's directory. Then restart both.
Registry check-in check-out client. More detail are in docs
You can connect to H2 database and browser it. In this blog, It has been explained. You can go through it.
One way is to use the Check-in client that is shipped with WSO2 GReg. You can use the the Check-in client to take a dump of the registry (with -f option), and then check-in that dump to the new registry db.