Using the latest JFrog products?
JFrog Platform User Guide
JFrog Mission Control 3.x Documentation
To get the latest version, go to the JFrog Unified Platform
- Created by Adi Atzmony on Jan 27, 2020
Installation
Cause | From version 2.0 standalone ZIP installations have been deprecated from Mission Control. |
Resolution | For a full list of installation options, please refer Installation and Upgrade |
Cause | Disk which is storing Elasticsearch data has exceeded 95 % storage |
Resolution | 1. Stop the services 2. Clear space on disk used to store elasticsearch data 3. Start the services 4. Change elasticsearch indices setting to RW (read-write), curl -u<username>:<password> -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}' Default username and password for internal elasticsearch is admin. |
Debug Log configuration
Cause | From version 3.5.x the logback.xml has a different way to enable debug logging. |
Resolution | Please use the samle config below in order to have JFMC server microservice debug logging enabled (this will be write to the jfmc-server-debug.log file: <?xml version="1.0" encoding="UTF-8"?> <!-- add loggers configuration --> If needed - change the org.apache.http package to INFO in order to exclude traffic from the debug log file. |
Disaster Recovery
Cause | The DR target is not able to decrypt passwords since it does not have the same Master Key as the DR Master service. |
Resolution | Sync over the Artifactory Master Key from the DR Master to your Target Artifactory service. This will allow all passwords to be properly decrypted once your security settings are replicated to the Target. For details, please refer to Master Key Encryption in the JFrog Artifactory User Guide. |
Scripting
Cause | In version 2.0, Mission Control made significant changes in how configuration scripts are written. These changes are not backwards compatible, so any scripts written for Mission Control version 1.x will not work. For details, please refer to Configuration Scripts. |
Resolution | You need to migrate your scripts to work with Mission Control 2.0 and above. While the migration process is not automatic, it is quite simple. For details please refer to Migrating Scripts from Version 1.x to Version 2.x. |
Cause | Previous to Mission Control version 2.0, implementing a Star Toplogy was very complex, cumbersome and error-prone. |
Resolution | A new configuration block was introduced in Mission Control version 2.0 to make implementing a Star Toplogy, using either push or pull replication, very simple. For details, please refer to Star Toplogy. |
Cause | Previous to Mission Control version 2.0, implementing a Full Mesh Toplogy was very complex, cumbersome and error-prone. |
Resolution | A new configuration block was introduced in Mission Control version 2.0 to make implementing a Star Toplogy, using either push or pull replication, very simple. It is now much easier to implement a Full Mesh by configuring each node with its own Star Topology. For details, please refer to Star Toplogy. |
Cause | The default layout for any new repository is maven-2-default . |
Resolution | When creating a new repository in a script, modify the repoLayoutRef field to the correct layout for your repository type. |
Cause | When updating a repository using a script, any parameter that is not explicitly specified is updated to the default value of that parameter. |
Resolution | When updating a repository using a script, specify all the parameter for that repository that don't take the default value, even those that shouldn't change. |
Cause | Mission Control scripts are maintained in one of its internal databases which cannot be accessed form outside of Mission Control. |
Resolution | To access Mission Control scripts, configure a Git repository to which Mission Control will synchronize all its scripts as described under Git Integration. This also allows you to create and modify your scripts using any external editor. |
Graphs
Cause | After adding a service to the system, it can take up to 15 minutes before Mission Control displays any data samples. |
Resolution | Just wait up to 15 minutes, and you should then see data for the new added service. |
Cause | To preserve historical data for deleted services, Mission Control stores the data under a fictitious service named <deleted_service_name>_old_xx (e.g. art1_old_01, art1_old_02. XX will be incremented if you delete and re-add a service with the same name. |
Resolution | When viewing graphs for all services, these deleted will still appear, however, you may also focus on a specific service. |
Metrics Data Collection
Cause | The default frequency of data collection is set to 15 minutes for data from Artifactory. It may be needed to change the frequency for various reasons. |
Resolution | To change, run this query on the host: localhost:8085 in the example is the end-point of insight services TASKPULLINSIGHT is the task performing the data collection for Artifactory every 15 minutes schedule below is the crontab settings for 30 minutes - change this as needed. curl "http://localhost:8085/services/JFIS/jobs" -X PUT -d '{"callback_url":"/api","retry_count":3,"service_id":"{service_node_id}","schedules":[{"schedule":"\t0 0/30 * 1/1 * ? *","name":"Insight pull metrics task","id":"TASKPULLINSIGHT","type":"cron"}],"name":"Insight loader Task","id":"TASKPULLINSIGHT","params":{"action":"run_scheduler","schedule_id":"TASKPULLINSIGHT"},"request_id":"","group":""}' -H "Content-Type:application/json;charset=UTF-8" |
Groups
Cause | From version 2.0, Groups have been deprecated in Mission Control. |
Resolution | Previous to version 2.0, creating Groups was a convenient way to run scripts on a number of Artifactory services at once since each script could only perform one action at a time. From version 2.0, scripting is much more flexible and you can specify any number of services on which a script should act. |
REST API
Cause | In version 2.0, Mission Control implemented a major upgrade of the REST API which is not backwards compatible with previous versions. |
Resolution | You need to update your scripts to use the new REST API. For details, please refer to the updated Mission Control REST API page, especially the Version Mappings section that describes how to map endopints from previous versions to version 2.0 and above. |
Services
Cause | Mission Control extracts storage information about managed Artifactory services using a REST API call. |
Resolution | In some cases, the REST API call may take time to return. Wait a few moments and refresh the screen. |
Admin Password
Cause | Need to change the admin password |
Resolution | Run the following set of commands to remove the current admin user (Applied to Docker Install): PostgreSQL 1. Login in to the PostgreSQL container. docker exec -ti jfmc_postgres_1 bash 2. Login to database. psql -U jfmc mission_control 2. Remove the existing admin user. delete from jfmc_server.mc_user where username = 'admin'; 3. Restart the Mission Control service. docker restart jfmc_server_1 MongoDB (JFMC version < 3.4) 1. Login in to the Mongo container. docker exec -ti jfmc_mongodb_1 bash 2. Remove the existing admin user. mongo -u mission_platform -p "password" "mission_platform" --eval 'db.users.remove({ "username": "admin" }, { "justOne": true})' 3. Restart the Mission Control service. docker restart jfmc_server_1 |
- No labels
JFrog.com | Documentation | Featured | Have a question? Want to report an issue? Contact JFrog support