Artifactory User Guide

Artifactory User Guide

Table of Content1. Artifactory User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Installing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 OS Service or Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2.1 Installing on Un*x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2.2 Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 RPM Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Deployment on Other Servlet Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.1 Deploying the WAR File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.2 Dedicated Tomcat Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.3 Deploying on JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4.4 Deploying on IBM Websphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Running Behind Apache HTTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6 Changing the Default Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6.1 Running Artifactory on MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7 Upgrading Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7.1 Intermmediate Upgrade to Previous Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Administering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Managing Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.1 Understanding Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.2 Configuring Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.3 Local and Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.4 Local Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5 Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.1 Managing Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.2 Handling Offline Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.3 Handling Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.4 Going Through Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.5 Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.5.6 Importing Shared Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.6 Virtual Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Managing Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.1.1 Recreating the Default Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.2 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.3 Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.4 Managing Security with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.5 Centrally Secure Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3.6 Access Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Managing Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5 Importing and Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.6 Mail Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.1 Global Configuration Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.2 Security Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.7.3 System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.8 Exposing Maven Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.9 The artadmin Command Line Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.10 Clustering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.11 The Artifactory Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.12 System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Working with Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Configuring Artifacts Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Configuring Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Working with Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Gradle Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1.1 Gradle Artifactory Plugin using the snapshot version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Working with Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Using Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Browsing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Attaching and Reading Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.3 Deploying Via the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4 Searching Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.1 Quick Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.2 Class Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.3 POM and XML Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.4 Property Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.5 GAVC Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4.6 Checksum Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5 Manipulating Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5.1 Removing Single Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.5.2 Cleaning-up Complete Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 5 5 6 7 8 8 9 10 10 10 13 15 16 17 19 19 21 21 23 24 24 26 26 28 29 30 31 33 34 36 37 38 39 40 43 45 47 47 49 53 53 54 55 57 57 58 60 61 62 62 63 65 66 69 73 74 78 78 82 84 86 86 87 87 88 89 90 90 90 91

1.6.5.3 Moving Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.6 Updating Your Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7 Artifactory's REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.1 Repository Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.2 Security Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.7.3 System Settings JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Artifactory Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Installing the Artifactory Pro Power Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Artifactory Version Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 Build Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.1 Jenkins (Hudson) Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.2 TeamCity Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.2.1 TeamCity Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.3 Bamboo Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3.3.1 Bamboo Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.4 License Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 LDAP Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.6 Repository Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.7.1 Using Properties in Deployment and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.8 User Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.9 YUM Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.10 P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.11 NuGet Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.12 Repository Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.13 Smart Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.14 Atlassian Crowd Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.15 Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.16 Filtered Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.17 Watches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.18 WebStart and Jar Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1 Dealing with Broken Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91 92 93 128 129 130 131 132 133 135 142 143 152 158 163 170 174 176 178 179 181 200 202 205 208 217 217 219 220 222 223 223 223

Artifactory User Guide

Welcome to the Artifactory User Guide!Please use the left navigation bar to find your way around the Artifactory docs.

This user guide is for Artifactory 2.1.x and higher. The previous 2.0 user guide can be found here.

Installing ArtifactoryBefore you install, please check the system requirements and supported platforms. Artifactory can be installed and run in a couple of ways: 1. On the bundled Jetty container as a standalone server, or as Unix or Windows service 2. Using the RPM distribution, which sets up Artifactory as a service on a bundled Tomcat container - recommended. 3. On other servlet containers as a standard WAR weapp - Tomcat 6 or 7 is recommended. You can also configure Artifactory to run on top of various storage options, for greater performance and ease of maintenance.

RequirementsJDKYou can run Artifactory with JDK 1.6 and above, but we strongly recommend using the latest JDK 1.6 update, preferably JDK 1.6 update 23 and above. When running with JDK 1.6 you wll need JDK version 1.6.04 and above (ealier versions of JDK 1.6 are bundled with a JAXB version which is incompatible with the version used in Artifactory). At least 300MB of allocated Java heap space is recommended, though you should be able to run with less RAM. If you can reserve 1g or more for Artifactory JVM, the recommended JVM option parameters are:

Copyright 2012 JFrog Ltd.

4

-server -Xms1g -Xmx1g -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=8 -XX:NewSize=512m -XX:MaxNewSize=512m -XX:+UseConcMarkSweepGC

Operating SystemsArtifactory has been tested and verified on Windows, Linux, Solaris and MacOS X. You should be able to run Artifactory on other platforms that support JDK 1.5 and above, though we haven't tested them.

BrowsersArtifactory has been tested with Firefox 2.0, Firefox 3.0, Internet Explorer 6, Internet Explorer 7, Safari 3.2 and Google Chrome 1.0.

OS Service or StandaloneBefore installing Artifactory on the bundled standalone Jetty server make sure you have set the JAVA_HOME environment variable to point to a valid JDK 1.5+ home. Then, follow these instructions for installing the standalone version under Windows or Unix.

After successfully installing Artifactory, it should be available locally at: http://localhost:8081/artifactory.

Installing on Un*xUnixWhen using Unix, it is possible to install Artifactory as a Unix service or run it manually. Before you install is recommended you first verify your current environment by running artifactoryctl check under the $ARTIFACTORY_HOME/bin folder (this script is, in fact, a customized Jetty init script).

Installing Artifactory as Linux ServiceIntroduction

Artifactory is packaged with a complete install script that can be used to install it as a Unix service running under a custom user and using the standard Unix directories.Installing

To setup Artifactory correctly as a Linux service run, as root, the $ARTIFACTORY_HOME/bin/install.sh script. Here is the main information about what this script is doing: User creation Creates a user named "artifactory" ($ARTIFACTORY_USER) by default. You can change the default user by editing the $ARTIFACTORY_USER value in /etc/artifactory/default. The install script accepts the user name as its first and only parameter. Creates the folder /etc/artifactory, copies the configuration files there and creates a soft link in $ARTIFACTORY_HOME/etc

etc config etc default

Creates the file /etc/artifactory/default that contains the main environment variables needed for artifactory to run: JAVA_HOME, ARTIFACTORY_USER, ARTIFACTORY_HOME, JAVA_OPTIONS,... The /etc/artifactory/default is included at the top of artifactoryctl and so can include whatever you wish. NOTE: The default max memory is 1GB It copies the file artifactoryctl to /etc/init.d/artifactory

init.d


5

Logs folder Backup folder

Creates /var/log/artifactory folder, makes it writable for the user ARTIFACTORY_USER and creates a soft link $ARTIFACTORY_HOME/logs. Creates the folder $ARTIFACTORY_HOME/backup, so you will need to create a link if you wish this folder to point to somewhere else (like /var/backup/artifactory for example). The script makes $ARTIFACTORY_HOME/backup writable for the user ARTIFACTORY_USER. Create the folder $ARTIFACTORY_HOME/data, so you will need to create a link if you wish this folder to point to somewhere else. The script will make it writable for the user ARTIFACTORY_USER. The script calls add, list (you can see the output), then activate the Artifactory service

Data folder chkconfig calls

After running the script successfully you can test the installation by running: service artifactory check or /etc/init.d/artifactory check And if everything is OK, start artifactory with:

service artifactory start

or

/etc/init.d/artifactory start

You can then check the Artifactory log with:

tail -f $ARTIFACTORY_HOME/logs/artifactory.log

Normally Artifactory will be started as root (when running as a service) and will su internally to the $ARTIFACTORY_USER user. If the $ARTIFACTORY_USER is undefined Artifactory will run as the current user, which is not recommended, especially if the current user is root, due to security considerations.

Running Artifactory Manually on UnixYou can run artifactory manually with artifactory.sh directly to see its behavior. The console will be locked on artifactory process and you can stop it cleanly with crtl+c. You can also try executing

artifactoryctl check|start|stop

to directly run Artifactory as a daemon process, using the environment variable of the shell you are currently in.

Installing on WindowsWindowsWhen using Windows it is possible to install Artifactory as a Windows service or run it manually.

Installing Artifactory as a Windows Service OverviewArtifactory makes use of the Java Service Wrapper components in order to give the user a way to install the application as a Windows Service.


6

RequirementsThe "java" system path is used in the JSW configuration file ( %ARTIFACTORY_HOME%\bin\wrapper.conf). This value can be altered to an environment variable, full-path, etc.

InstallingTo install Artifactory as a Windows service, browse to %ARTIFACTORY_HOME%\bin, and execute the file InstallService.bat.

UninstallingTo uninstall the Artifactory service, browse to %ARTIFACTORY_HOME%\bin, and execute the file UninstallService.bat.

Running Artifactory Manually on WindowsJust execute "artifactory.bat" under the bin folder. This will look for the Java executable and run Artifactory's main class.

RPM InstallationOverviewArtifactory can also be installed as an RPM package on RedHat compatible Linux distributions. The RPM distribution is available starting with Artifactory 2.3.3. The RPM package creates a dedicated user, installs a stripped-down distribution of the Apache Tomcat container configured for Artifactory (on port 8081 by default), and registers this Tomcat as a service (but does not start it immediately). This package effectively replaces the different setup scripts that are included with the Artifactory zip distribution.

RequirementsMust be installed using the root user (or sudo). An environment variable named JAVA_HOME pointing to the installation directory of JDK 1.5+ (the latest JDK 1.6 is highly recommended).

Managed Files And FoldersPurpose Artifactory binary and Tomcat home Artifactory startup script Artifactory home Artifactory etc Artifactory logs Artifactory environment variables Location /opt/artifactory /etc/init.d/artifactory /var/lib/artifactory /etc/artifactory /var/log/artifactory /etc/artifactory/default Ownership root root artifactory artifactory artifactory artifactory

MySQL Additional ConfigurationThe RPM includes a small CLI tool that assists with the configuration of Artifactory to use MySQL as a storage method (recommended). After running the RPM installation process, it will offer you to run the MySQL configuration manually. The tool is located in /opt/artifactory/bin/configure.mysql.sh and requires MySQL to be pre-installed and running.

Installing Artifactory


7

To install Artifactory use:

rpm -ivh artifactory-rpm-.rpm

Running ArtifactoryTo start and stop Artifactory use the init script:

/etc/init.d/artifactory start

or-

/etc/init.d/artifactory stop

Accessing ArtifactoryArtifactory should be available under the following URL: http://localhost:8081/artifactory

Deployment on Other Servlet ContainersGeneralArtifactory is a standard Java EE web application. As such, it can be installed and run on any Servlets 2.5 compliant Container. We specifically verified Artifactory to work seamlessly on Tomcat 6 & 7, Jetty 6 & 7, JBoss 4.x & 5, BEA Weblogic 9, GlassFish v2 & V3, IBM Websphere 6.1 and Resin. Please follow the generic instructions for installing the artifactory.war on any servlet container. There are also more detailed and specific instructions for installing under Tomcat and IBM Websphere and JBoss.

GlassFish requires Artifactory 2.0.1 and above.

Deploying the WAR File"Drop the War": Zero ConfigurationArtifactory can be installed under any Servlet container by simply dropping or installing the artifactory.war file into the containers web applications folder, for example, into Tomcat's webapps folder. All you have to do is deploy the artifactory.war file into your Servlet container, either by hot-deploy or by following the container's standard web application deployment procedures. The artifactory.war file is located under the webapps folder in the artifactory-x.y.x.zip distribution.

It is recommended not to include any version characters in the name of the war file, and leave it just as: artifactory.war, in order not to have version-specific information in the Artifactory base URL and in order to make future upgrades simpler.

The $ARTIFACTORY_HOME FolderEven with zero configuration, it is important to know where the Artifactory home folder is, since this folder stores your configurations and important repository data.


8

When Artifactory runs for the first time, it will set up a default configuration and create all needed files and folders under a $ARTIFACTORY_HOME folder that, if unset, will default to ${user.home}/.artifactory. If you wish to control the location of $ARTIFACTORY_HOME (which you probably do when installing Artifactory on a production server), you can do one of the following: Startup the Servlet Container VM with -Dartifactory.home=$ARTIFACTORY_HOME, pointing to the location of your Artifactory home folder, or Set an $ARTIFACTORY_HOME environment variable pointing to this location. Artifactory will try to create the folder on startup if it does not already exist.

Make sure the folder is writable by the user running the Servlet Container.

Manual DeploymentYou can set up Artifactory on any Servlet container by deploying the war and pointing Artifactory to a dedicated ARTIFACTORY_HOME created by extracting the Artifactory distribution zip. To do this: 1. Extract the Artifactory distribution archive (artifactory-xxx.zip) to a dedicated folder. This folder will be you ARTIFACTORY_HOME (verify this by checking the presence of the $ARTIFACTORY_HOME/etc/artifactory.config.xml file). 2. Start the Servlet Container and specify the location of ARTIFACTORY_HOME by either using a JVM argument or by using an environment variable as explained in the previous section.

Dedicated Tomcat InstanceThis documentation explains the steps for automatic installation under Unix on a dedicated tomcat instance. For manual Installation (on either a dedicated or shared instance) please refer to the Generic WAR Installation documentation.

Automatic Installation on a Dedicated Tomcat InstanceYou can use the automated install script to set up a dedicated Tomcat server for Artifactory.

These instructions have been verified against Tomcat 6, but should work on Tomcat 5 with minor adjustments. You can change the directory names to your liking but you'd need to adjust the install scripts accordingly (currently directory names are hard-coded).

1. Extract the Apache Tomcat download under /opt/tomcat/artifactory. 2. Extract Artifactory standalone /opt/artifactory/current 3. Run (or edit and run) the $ARTIFACTORY_HOME/bin/tomcat-install.sh script. The script will do the following: Run the $ARTIFACTORY_HOME/bin/install.sh script. Replace /etc/init.d/artifactory with $ARTIFACTORY_HOME/misc/Tomcat/artifactory. Replace tomcat's conf/server.xml with $ARTIFACTORY_HOME/misc/Tomcat/server.xml (change its ports if you wish) Create under Tomcat the conf/Catalina/localhost directory and copy the $ARTIFACTORY_HOME/misc/Tomcat/artifactory.xml into it. Replace tomcat's bin/setenv.sh with $ARTIFACTORY_HOME/misc/Tomcat/setenv.sh Change the Tomcat home owner : chown -R artifactory /opt/tomcat/artifactory

The script will change the default Tomcat configuration files and is intended to be used on a newly installed Tomcat only.

4. Start tomcat: service artifactory start, or /etc/init.d/artifactory start Artifactory will be available on this Tomcat instance on port 8081 for HTTP and 8019 for AJP13.


9

A Note About Pre-packaged Tomcat Distributions There have been a reports suggesting there are known problems deploying to automatically Tomcat installed as part of various Linux distros with default security settings. See, for example: http://www.nabble.com/Re%3A-java.lang.NoClassDefFoundError%3A-org-quartz-CronExpression-p13139289.html Please check the specific Tomcat installation you are using or download and install the "standard" Tomcat from the Apache site.

Deploying on JBossJBoss 5.xArtifactory runs out of the box on JBoss 5.x.

JBoss 4.xFor running Artifactory under JBoss 4.x, you'd have to tell JBoss to use the JVM's built-in MBean server. To do this, start JBoss with the jboss.platform.mbeanserver system property set. On Unix, you can do this by adding the following line to the JBoss startup script:

export JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"

It is also recommended to increase the max perm gen size of the JBoss VM to at least 256MB (-XX:MaxPermSize=256m).

Deploying on IBM WebsphereOverviewArtifactory can run under IBM's WebSphere application server (this required specific adjustments in Artifactory in order to "play nicely" with WebSphere's own way of doing things). Please note, that this is not an out-of-the-box feature and requires minimal manual setup. These instructions have been verified against WebSphere 6.1, but should work on WebSphere 7 as well.

SetupBefore deploying Artifactory into WebSphere: 1. Extract the artifactory.war file. 2. Replace the standard web.xml file under %EXTRACTED_WAR_FOLDER%/WEB-INF with the WebSphere-specific web.xml from %ARTIFACTORY_HOME%/misc/websphere. 3. Repackage (zip) the war file. 4. Start WebSphere. 5. Add the following webcontainer custom property and set it to 'true' (see: PK33090):com.ibm.ws.webcontainer.invokefilterscompatibility

6. Save the change and restart WebSphere. 7. Deploy normally into WebSphere.

Running Behind Apache HTTPdSetting up Apache HTTPd as a Front-end to ArtifactoryYou may want to a use Artifactory behind Apache HTTPd. This can be done via two alternative protocols HTTP or AJP:


10

Client ----------> HTTPD ----------> Artifactory HTTP HTTP/AJP

Using AJPThe AJP protocol offers optimized low-level binary communication between the servlet container and Apache with additional support for smart routing and load balancing. It can be used in Apache with mod_proxy_ajp, or with mod_jk - for greater configuration flexibility. The examples below will use mod_ajp which is distributed with Apache by default.

AJP and Jetty The AJP protocol is not recommended for use by Jetty ("It is recommended to NOT use the AJP protocol, and superior performance and clearer semantics will be achieve [sic] using HTTP."). We therefore advise not to use AJP with Jetty, but to use mod_proxy as recommended by Jetty.

Configuring Apache with mod_ajp Installed

The sample virtual host refers to Apache as a reverse proxy to Tomcat, where Tomcat runs with the AJP connector on port 8009:

ServerAdmin [email protected] DocumentRoot "/srv/www/httpd/htdocs" ServerName artifactory.yourdomain.com ErrorLog "logs/artifactory-error_log" ProxyPreserveHost on ProxyPass /artifactory/ ajp://localhost:8009/artifactory/

Reset your cookies Whenever changing the Artifactory context path in Apache make sure to reset your browser's host and session cookies. Having stale context path value cached by cookies can lead to strange UI issues, such as Not authorized to instantiate class errors when switching between tabs.

Configuring Apache with changing the artifactory path

Same setup as above but here the goal is to have http://artifactory.yourdomain.com/repository/ as root URL for Artifactory:

ServerAdmin [email protected] DocumentRoot "/srv/www/httpd/htdocs" ServerName artifactory.yourdomain.com ErrorLog "logs/artifactory-error_log" ProxyPreserveHost on ProxyPass /repository/ ajp://localhost:8009/artifactory/ ProxyPassReverse /repository/ http://artifactory.yourdomain.com/artifactory/ ProxyPassReverseCookiePath /artifactory/ /repository/

Tomcat Configuration


11

On Tomcat you need to configure the AJP connector, which is located by default under $CATALINA_HOME/conf/server.xml:

See here for more configuration options.

Using HTTP ProxyHaving Apache proxy Artifactory via HTTP is the recommended setup when running Artifactory from the default distribution which is Jetty-based. It is required to configure correct redirects using the pass-reverse directive as well as set the base URL in Artifactory itself so that UI links show up correctly.Configuring Apache with mod_proxy_http Installed

The sample virtual host assumes Tomcat or Jetty HTTP connector runs on port 8081. Note that for HTTP redirects to work, you need to set a pass-reverse directive on Apache, or the underlying container base URL will be passed in redirects (in this example to http://localhost:8081/artifactory/).

ServerAdmin [email protected] DocumentRoot "/srv/www/httpd/htdocs" ServerName artifactory.yourdomain.com ErrorLog "logs/artifactory-error_log" ProxyPreserveHost on ProxyPass /artifactory/ http://localhost:8081/artifactory/ ProxyPassReverse /artifactory/ http://localhost:8081/artifactory/

Tomcat Configuration

On Tomcat you need to configure the HTTP connector, which is located by default under $CATALINA_HOME/conf/server.xml:

See here for more configuration options.Configuring a Custom URL Base in Artifactory

When not using AJP, the links produced by Artifactory as well as certain redirects will contain the wrong port. To fix this, configure a custom base URL, by going to Admin:Configuration:General:Custom URL Base. Set the base URL to the value used to contact Artifactory on Apache, for example: http://artifactory.yourdomain.com/artifactory See the General Configuration section for more details about configuring the base URL.

Proxying Apache HTTPs to Artifactory running HTTPYou may want to run Artifactory behind Apache with SSL (HTTPs). This can also be achieved via HTTP or AJP:


12

Client ----------> HTTPD ----------> Artifactory HTTPs HTTP/AJP

Using AJPIf you are not using Jetty (see above: AJP and Jetty), then AJP is recommend since it tells the servlet container everything about the correct base URL and requires zero configuration in Artifactory.Configuring Apache with mod_proxy_ajp Installed and Tomcat

The Apache and Tomcat sample configurations are identical to the one listed on "Using AJP" on this page for non-HTTPs Apache.

HTTPs to HTTP and Jetty Jetty does not support HTTPs to HTTP without a special extended connector that hardcodes the HTTPs scheme (see: http://wiki.eclipse.org/Jetty/Tutorial/Apache - Proxying SSL on Apache to HTTP on Jetty). If you do not use this connector all redirects will use the wrong scheme. We therefore recommend using Artifactory with Tomcat in this case, in favor of the default Jetty-based distribution.

Using HTTP ProxyConfiguring Apache with mod_proxy_http Installed and Tomcat

The Apache and Tomcat sample configurations are identical to the one listed on "Using HTTP Proxy" on this page for non-HTTPs Apache.Configuring a Custom URL Base in Artifactory

When not using AJP, the links produced by Artifactory as well as certain redirects will not only contain the wrong port but will use the http scheme instead of https. To fix this, configure a custom base URL, by going to Admin:Configuration:General:Custom URL Base. Set the base URL to the value used to contact Artifactory on Apache, for example: https://artifactory.yourdomain.com/artifactory See the General Configuration section for more details about configuring the base URL.

Changing the Default StorageOverviewArtifactory comes with a built-in Derby database that can be reliably used to store data for production-level repositories (up to hundreds of gigabytes). Artifactory's storage layer supports pluggable storage implementations (made possible by the underlying Jackrabbit JCR), so you can configure Artifactory to run with almost any JDBC database or even store data completely on the file system.

Once-and-Only-Once Identical Content StorageArtifactory stores identical binary files only once. When a new file about to be stored in Artifactory is found to have the same checksum as an already stored file, Artifactory will not store the new file content, but will make a link to it in the metadata of the newly deployed file. This principal applies regardless of under which repository and path artifacts are deployed - you can deploy the same file to many different coordinates, and as long as an identical content was found in the storage it will be reused.

Changing the Storage Type UsedThe general principal for changing the storage used by Artifactory is to edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file:

artifactory.jcr.configDir=repo/[selected-storage-type]

The path used can be either a relative path to $ARTIFACTORY_HOME/etc or an absolute path, and is expected to contain a repo.xml file (which is a Jackrabbit configuration file).


13

For a JDBC database you will also need to: 1. Download the appropriate JDBC driver and install it in your server's shared lib directory. 2. Create a database instance to which Artifactory will connect (when using an out-of-process database). Database tables will be auto-created. 3. Change the database details in the repo.xml file to match your database.

Backing up your existing installation When changing the storage type for an exiting installation you will need to import the old Artifactory content and configuration from backup. Make sure to back up your older Artifactory system before using a different storage type.

Removing the old $ARTIFACTORY_HOME/data folder If you already run Artifactory before with a different storage type you will need to remove (or move-aside) the existing $ARTIFACTORY_HOME/data folder, or Artifactory will still use part of the old storage definitions and will fail to start up (you will see record not found exceptions on startup). Starting with a clean or no $ARTIFACTORY_HOME/data folder will fix this.

Changes to repo.xml Except for updating the database details in repo.xml, do not make any other changes to the repo.xml file or try to manually replace it with a repo.xml from a newer Artifactory version. All changes to the repo.xml file as part of an Artifactory upgrade are always applied automatically.

When Artifactory is Deployed as a WAR

If you deployed Artifactory as a WAR and have not specified a location for the $ARTIFACTIORY_HOME directory, it will be auto-created by Artifactory under '$user.home/.artifactory'. To use the bundled configuration files for common storage types, you may want to copy the etc/repo folder from the Artifactory distribution to your $ARTIFACTORY_HOME/etc. Then edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file as described above to point at the desired configuration.

The Bundled Storage ConfigurationsOut-of-the-box Artifactory comes with built-in configurations (repo.xml files) for the several storage types, as listed below.

Database Storage TypesThe following configurations use a JDBC database for storage, and manage binaries as blobs with file system blob caching (1Gb by default) 1. 2. 3. 4. 5. derby mysql - Please follow the MySQL-specific instructions postgresql oracle mssql

File System Storage TypesThe following configurations store all binaries as files (in $ARTIFACTORY_HOME/data/filestore), and use a JDBC database for repository metadata management. This setting typcially yields the best performance with large repositories. 1. 2. 3. 4. 5. filesystem-mysql - The recommended setup. Please follow the MySQL-specific instructions. filesystem-derby (the default) filesystem-postgresql filesystem-oracle filesystem-mssql


14

For raw Artifactory data backup, the folder $ARTIFACTORY_HOME/data/filestore needs to be backed up in parallel of a DB dump since both are needed. This does not impact Artifactory's own backup system which is storage-agnostic.

Accessing a Remote DatabaseIn order to avoid network latency issues when reading and writing artifacts data, it is highly recommended to create the database on the same machine on which Artifactory will be running or on a fast SAN disk.

This is critical if the files are served from database blobs and the file system cache size is low.

Running Artifactory on MySQLOverviewThe instructions below describes how to set up Artifactory on MySQL. By using MySQL (over the built-in Derby DB) you can leverage exiting MySQL infrastructure and use the MySQL backup, restore and high-availability features. The setup involves creating the dedicated MySQL database instance and then configuring Artifactory to use that instance.

Please make sure to read the general section about changing the default storage before configuring MySQL.

Create the Artifactory MySQL DatabaseSupported MySQL versions For best performance please use MySQL 5.5 and above with the InnoDB engine (the default with this version). Please note that versions of MySQL below 5.0.3 will not work with Artifactory.

You can use the $ARTIFACTORY_HOME/misc/mysql/createdb.sql SQL script to execute the SQL commands below to create a database. Please review and edit this script before executing it, according to your environment.

[root@pond artifactory]# mysql -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 Server version: 5.0.45 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create database artifactory character set utf8; Query OK, 1 row affected (0.00 sec) mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on artifactory.* TO 'artifactory_user'@'localhost' IDENTIFIED BY 'password'; Query OK, 0 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.00 sec) mysql> quit

Increasing MySQL's Default Packet SizeSince binaries are stored in MySQL, it is extremely important to increase the default packet size used by MySQL (see: max_allowed_packet


15

increase, for reference). We recommend changing this in the /etc/my.cnf file. Create this file if it does not already exist (under the absolute path, not under $ARTIFACTORY_HOME):

# The MySQL server [mysqld] . . # The maximum size of the binary payload the server can handle max_allowed_packet=8M . .

Configure Artifactory to Use the MySQL Database1. Add (or uncomment) the following line in $ARTIFACTORY_HOME/etc/artifactory.system.properties:

artifactory.jcr.configDir=repo/filesystem-mysql

Note: this path is relative to $ARTIFACTORY_HOME/etc. 2. Adjust the connection definitions in the file $ARTIFACTORY_HOME/etc/repo/filesystem-mysql/repo.xml to match the attributes of the Artifactory database you created (if you don't have this file you can grab it from the standalone zip distribution or directly from here .). Jackrabbit uses 3 separate connection configurations for each of the following: a. The basic JCR repository metadata (configured under FileSystem tag) - minimal load and no connection pooling. b. The JCR datastore for all the binaries (configured under DataStore tag) - heavy load and uses connection pooling. c. The JCR workspace metadata (configured under PersistenceManager tag) - minimal load and no connection pooling. For each one of these tags you need to configure the database parameters and username/password to use. The schema and tables will be created on first run of Artifactory against the database. 3. Download the MySQL JDBC driver and copy the mysql-connector-java-x.x.x.jar jar file into the server's shared lib directory ( $ARTIFACTORY_HOME/lib in the standalone version), $TOMCAT_HOME/lib etc. 4. Start Artifactory.

General advice against storing artifacts as BLOBs inside MySQL The suggested configuration keeps all artifacts information in MySQL while storing the artifact binary data on the file system (under $ARTIFACTORY_HOME/data/store). This is the recommended setup. It is possible, but not recommended, to store BLOBs inside MySQL, provided that typical BLOB size is relatively small. This is important because MySQL buffers BLOBs instead of streaming them (this behavior is unrelated to Artifactory http://bugs.mysql.com/bug.php?id=15089). Therefore, using large BLOBs may result in out-of-memory errors with large binaries, depending on your JVM heap size. If you wish to store BLOBs inside MySQL, please use repo/mysql instead of repo/filesystem-mysql, and change the max_allowed_packet above to the maximum artifact size you are planing to store in Artifactory, for example 128M.

Upgrading ArtifactoryUpgrading Artifactory to Version 2.6.x(from 1.3.0-RC, 2.0.x-2.5.x) Storage Type Changes: if you also wish to change the underlying storage type used by Artifactory, please read the following instructions instead. The instructions below assume the upgraded Artifactory will use the existing storage type.

When Running the Artifactory WAR in a Servlet Container1. Unzip the Artifactory distribution archive. 2. Replace the previously deployed artifactory.war file with the archive's webapps/artifactory.war file. On servlet containers such as Tomcat it is also necessary to remove the exploded artifactory webapp directory.


16

Starting with version 2.1.1 Artifactory's only distribution format is a single zip archive (artifactory-x.y.z.zip) that also contains the artifactory.war file in the webapps directory.

When Running Standalone Artifactory1. Unzip the Artifactory distribution. 2. Replace the following files and folders in you current $ARTIFACTORY_HOMEwith the same files from the new version:

artifactory.jar clilib/ (/bin/clilib, in 1.3.0-RCs) lib/ webapps/artifactory.war etc/jetty.xml misc

The misc folder contains configuration files for specialized environments such as a standalone Tomcat server or Websphere. Although these files are not required for runtime, it is recommended to replace this folder as well.

3. Delete Jetty's work folder ($ARTIFACTORY_HOME/work) before starting up Artifactory.

When Running the RPM Installation1. Log in as root (or use 'sudo su -'). 2. Execute 'rpm -U artifactory-x.y.z.rpm'

When upgrading from Artifactory prior to 2.6.0, please make sure to manually stop the current Artifactory service before running the upgrade, and verify the process has exited.

Upgrading From Legacy VersionsIf you would like to upgrade from Artifactory versions below 1.3.0-RC, you will need to upgrade Artifactory to version 2.0.x first. Please follow these steps.

When upgrading from 2.1.x or 2.0.x The Artifactory upgrade process is fully automated. However, the automatic upgrade to this version will likely run longer than you are used to: As part of the performance improvements done for this version we had to upgrade the way artifact metadata is stored and indexed inside Artifactory. The result is much faster searches and significantly improved performance of the whole system under load. However, since repository metadata and index need to be rebuilt, the upgrade process may take some time to complete (this time varies depending on your CPU and disk speed). Artifactory will not serve incoming requests until the automatic upgrade process completes, so you may want to schedule the upgrade accordingly. You can follow the progress of the upgrade process in the the artifactory log file. Preserving Build Information Please also note that using the upgrade process is the only way to move deployed build-information forward. You cannot import an export of 2.1.x with BuildInfo data into 2.3.x. This is a result of a bug that has already been resolved.

Intermmediate Upgrade to Previous VersionsUpgrading to 2.0.0 from 1.3.0-RC1 or 1.3.0-RC2


17

Simply replace the artifactory.war file. If you are running on Tomcat make sure to also remove the exploded artifactory webapp directory.

Upgrading from 1.2.2-rc0 through 1.3.0-beta-6.1This section covers upgrading from the following versions:

1.2.2-rc0 1.2.2-rc1 1.2.2-rc2 1.2.2 1.2.5-rc0 1.2.5-rc1 1.2.5-rc2 1.2.5-rc3 1.2.5-rc4 1.2.5-rc5 1.2.5-rc6 1.2.5 1.2.5u1 1.3.0-beta-1 1.3.0-beta-2 1.3.0-beta-3 1.3.0-beta-4 1.3.0-beta-5 1.3.0-beta-6 1.3.0-beta-6.1

Upgrading Artifactory from older version can be done in two ways: 1. From the UI 2. By using the artadmin command line tool

Upgrading Using the Web UIUpgrading from the UI is supported only when upgrading from version 1.3.0-x. 1. From your old Artifactory installation run Full System Export and save the export to a destination directory. 2. Perform a new clean server installation of the new Artifactory (it should not contain repository data or your customized version of the Artifactory configuration xml file). 3. Install the new Artifactory version, go to Admin/Export&Import/System/Import System, select your previous export target directory and let the import run. That's it!

Upgrading Using the artadmin ToolWhile upgrading from the web UI is easy and straightforward, sometimes the upgrade process can take a long time, especially with very large repositories. In such cases the original web request may time out and the upgrade progress will proceed in the background. Therefore, if you wish to monitor the progress of the upgrade process in the most reliable way and gain access to more advanced dump options, it is recommended to use the artadmin command-line tool. Here are step-by-step instructions: 1. Stop your old Artifactory. 2. Execute the artadmin dump command on the old $ARTIFACTORY_HOME or on a copy of it (recommended):

artadmin dump $ARTIFACTORY_HOME

This will generate a dumpExport folder under the current execution directory with the old repository data in a format suitable for importing into a current Artifactory. NOTE: By default, caches (e.g. repo1) are not exported. To export caches add the --caches parameter. 3. Perform a new clean server installation of the new Artifactory (It should not contain repository data or your customized version of the Artifactory configuration xml file). 4. Start the new Artifactory. 5. Import the dumpExport folder into Artifactory, either from the UI, as explained in the previous section or by running:

artadmin import dumpExport --username admin --password password

The artadmin output will display the progress of the import. NOTE: If the artadmin process is killed, the import will still run in Artifactory.

Important InformationPlease read this carefully before installing or upgrading:


18

1. If you have used a previous version of Artifactory it is highly recommended to: a. Use a fresh version of Artifactory from the distribution archive and not try to patch the previous installation. b. Clear your browser's cache before using the new version. 2. The default Artifactory user for the standalone installation has been changed to artifactory (instead of jetty). You may need to update the provided install script or your file system permissions accordingly.

Important information about the import process During the import binary artifacts are copied over into a working copy and are imported into Artifactory by a background thread. This speeds up the import process dramatically and makes Artifactory ready for serving requests as soon as possible. The background import process will take some time to completes, depending on the size of your repository. During this time Artifactory might perform more slowly than usual (it will still serve any artifact immediately, though). The Artifactory log should provide visible information about the progress of this process.

Repeating the upgrade process Should you wish to repeat the upgrade process from scratch, make sure to remove the $ARTIFACTORY_HOME/data folder from your new Artifactory installation before doing so.

Administering ArtifactoryOverviewThis section describes the Artifactory administration tasks, such as managing repositories, controlling security and configuring scheduled services. General Configuration Managing Repositories Managing Security Managing Backups Importing and Exporting Mail Server Configuration Configuration Files Exposing Maven Indexes The artadmin Command Line Tool Clustering Artifactory The Artifactory Log Files System Information

General ConfigurationOverviewThe Admin:Configuration section lets you set up various parameters that globally affect Artifactory:


19

General Settings1. The server name, displayed on the tile of each page. 2. Custom URL base. By default, URLs generated in Artifactory use context URL returned by your servelt container as a base. A custom URL base is useful when Artifactory is running behind a proxy. In this case the base for URLs generated in Artifactory for links and redirect responses must be specified manually. Another reason to change the base URL would be to have non-request-based operations in Artifactory use the correct address, for example in generated emails. 3. Maximum allowed size for files uploaded via the web interface. 4. The date format for displaying dates inside the web interface. 5. A global offline flag that tells Artifactory to act as if it is not connected to an external network (such as the internet), and therefore, not to query remote repositories (regardless of the offline status of a single remote repository).

Look and Feel Settings (UI Branding)Here you can customize artifactory with your own logo presented on the upper left of the screen and footer text.

You can either upload a logo image or use an exiting image on a remote URL. The uploaded file will be copied into the ARTIFACTORY_HOME/etc/ui folder. For a footer, input the desired text in the 'Additional Footer' field.


20

To make the changes visible you need to save them first.

Add-on SettingsThis configuration setting is for controlling Artifactory's behavior with regards to the Artifactory Add-ons Power Pack. 1. The Server ID is used to activate the Artifactory Add-ons Power Pack on the current Artifactory server. You can leave it empty when using the open source version with no add-ons installed. 2. You can decide whether or not to show available add-ons information in Artifactory's for add-ons you do not have installed. Available add-on information typically looks like this:

As an admin, you can decide whether users will see add-ons information or not. Note that enabling add-ons information display overrides any previous user-specific preference for hiding it (a user will still be able to choose to hide this information again).

Managing RepositoriesThis section explain the common controls available for each repository type. Understanding Repositories Configuring Repositories Local and Remote Repositories Local Repositories Remote Repositories Virtual Repositories

Understanding Repositories Copyright 2012 JFrog Ltd. 21

Local, Remote and Virtual RepositoriesArtifactory hosts two kinds of repositories: local and remote. Both local and remote repositories can be aggregated under virtual repositories, in order to create controlled domains for artifacts resolution and search, as we will see in the next sections.

Managing RepositoriesRepositories can be created, deleted, edited, ordered and aggregated using the administration UI: Admin:Configuration:Repositories

Local RepositoriesLocal repositories are physical locally-managed repositories that one can deploy artifacts into. Artifacts under a local repository are directly accessible via a URL pattern of http://:/artifactory// Artifactory comes with a couple of pre-configured local repositories for deploying internal and external releases, snapshots and plugins.

Remote RepositoriesA remote repositories serves as a caching proxy for a repository managed at a remote URL (including other Artifactory remote repository URLs). Artifacts are stored and updated in remote repositories according to various configuration parameters that control the caching and proxying behavior. You can remove cached artifacts from remote repository caches but you cannot manually deploy anything into a remote repository. Artifacts under a remote repository are directly accessible via a URL pattern of http://:/artifactory// or http://:/artifactory/-cache/ (the second URL will only serve already cached artifacts while the first one will fetch a remote artifact int the cache if it is not already stored). Artifactory comes with pre-configured common remote repositories, which you can, of course, change. Remote repositories configuration can also be imported from another Artifactory instance. JFrog public repository contains up-to-date standard list of remote repositories available on the net.


22

A remote repository acts as a proxy not as a mirror. Artifacts are note stored eagerly in remote repository caches, but are fetched and stored on demand when they are requested by a client. It therefore makes perfect sense for a remote repository to contain zero artifacts immediately after its creation.

Virtual RepositoriesA virtual repository (or "repository group", if you prefer this term) aggregates several repositories under a common URL. The repository is virtual in the sense that you can resolve and get artifacts from it but you cannot deploy anything to it.

The Default Virtual RepositoryBy default, Artifactory uses a global virtual repository that is available at http://:/artifactory/repo This repository contains all local and remote repositories.

Virtual Resolution OrderThe search/resolution order when requesting artifacts from a virtual repository is always: local repositories, remote repository caches and finally remote repositories themselves. The order by which repositories of the same type (local, cache and remote) are queried is governed by the order local, remote and virtual repositories are listed in the configuration (see below). Artifactory's virtual repository configuration includes a "Resolved Repositories" list view that shows the effective repositories order per virtual repository. This is particularly helpful when nesting virtual repositories.

General Resolution OrderManaging the global configuration order is done in the administration UI Admin:Configuration:Repositories. For each lists of repositories (local, remote, virtual) you can reorder using drag-and-drop or select with the up and down arrow buttons. When your order is done you can use the "Save" button, or "Reset" to cancel the reordering. Repositories resolution if also affected by security privileges, include/exclude patterns and snapshots/releases handling policies.

Configuring RepositoriesOverviewThis section covers the controls that are common between all repositories configuration.

Repository Key

The repository identifier needs to be valid XML ID Name, and be unique for the whole Artifactory configuration data. So, repository keys cannot starts with a number, and it is recommended to suffix local repository with "-local".

DescriptionFree text describing the content and goal of the repository. This will help user configuration, UI screens and repository sharing.

Include and Exclude Patterns


23

It is extremely important to use include and exclude patterns for repositories. This is especially important for remote repositories in order to: 1. Avoid Looking up remote artifacts on repositories that will never contain those artifacts, or that contain only a limited range of group ids. 2. Not disclosing sensitive business information that can be derived from your artifact queries to whoever can intercept the queries, including the owners of the remote repository itself. As best practices, it is easier to manage the list of remote repositories used in an organization under one virtual repository ( for example: remote-repos ). In this case, you can globally stop querying remote repositories for companies artifacts by setting an exclude pattern on this virtual repository. Include and exclude filtering is controlled by editing the Includes Pattern and Excludes Pattern values for a repository Admin:General:Repositories:Edit. Specify a comma separated list list of Ant-like patterns to filter-in and filter-out artifact queries. Filtering works by subtracting the excluded patterns (default is none) from the included ones (defaults to everything). for example:

Includes Pattern: org/apache/**,com/acme/** Excludes Pattern: com/acme/exp-project/**

Will cause Artifactory to submit queries to the repository in question for org/apache/maven/parent/1/1.pom and com/acme/project-x/core/1.0/nit-1.0.jar but not for com/acme/exp-project/core/1.1/san-1.1.jar.

Local and Remote RepositoriesOverviewThis section covers the controls that are common between local and remote repositories.

Snapshots and Releases Handling Policy

You can configure whether a local or remote repository handles snapshots and/or release artifacts. The repository will reject deployments that are conflicting with this policy and will not participate in conflicting resolution requests.

Snapshot and release handling are currently supported for artifacts that follow the Maven naming conventions. Support for flexible non-Maven snapshot and release identification will be introduced in the upcoming release of Artifactory.

Repository BlackoutIt is possible, if desired for whatever reasons, to completely black-out a repository by marking its "Blacked Out" flag, making it effectively disabled. A blacked-out repository does not participate in any artifacts resolution and artifacts cannot be downloaded from it or deployed to it.

Suppressing POM Consistency ChecksBy Default, Artifactory tries to keep your repositories healthy by refusing bad POMs that have wrong coordinates (path). If the information groupId:artifactId:version inside the POM does not match the deployed path, Artifactory will reject the deployment. You can disable this behavior by selecting the "Suppress POM Consistency Checks" checkbox.

Local RepositoriesOverviewThis section covers the controls that are specifics to local repositories.

Centrally Controlled Maven Unique Snapshot Policy


24

One of the unique features of Artifactory is you can gain centralized control on how snapshots are be deployed into a repository, regardless of end user-specific settings. This can guarantee standardized format for deployed snapshots within your organization. You can choose between: Non-unique snapshots. Unique snapshots - with unique time-stamp and build number suffix. Deployer-respecting behavior - Artifactory will respect the user snapshot policy, i.e. act as a standard, non-smart, repository.

Maven 3 Only Supports Unique Snapshots Maven 3 has, unfortunately, dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot repository that is using non-unique snapshot, it is recommended to change its Maven snapshot policy to 'Unique' and to remove any previously deployed snapshot from this repository. The unique snapshot name generated by the Maven client on deployment cannot help in identifying the source control changes from which the snapshot was built and has no relation to the time sources were checked out. It is advised to have the artifact itself embed the revision/tag (as part of its name or internally) for clear and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Build Integration support.

Cleaning-up Unique SnapshotsPutting aside the question of usefulness in using unique snapshots (see the section above), you can tell Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique Snapshots value to the maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect on each new snapshot deployment.

Handling Deployed Client ChecksumsChecksum policy determines how Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated checksum (bad checksum). Checksum checking effectively verifies the integrity of the deployed resource.


25

The options are: 1. Verify against client checksums (default) - Until a client has sent a valid checksum for a deployed artifact that matches the server's locally calculated checksum, the artifact will not be available and will return 404 (not found). If the client has sent a checksum that conflicts with the one calculated on the server a 409 (conflict) will be returned until a valid checksum is deployed. 2. Trust server generated checksums - Do not verify against checksums sent by clients and trust the ones store server's locally calculated checksums. An uploaded artifact will be available for consumption immediately, but integrity might be compromised.

Remote RepositoriesThis section describes various aspects of managing remote repositories: Managing Caches Handling Offline Scenarios Handling Checksums Going Through Proxies Advanced Settings Importing Shared Configurations

Managing CachesOverviewThis section examines the settings are used by remote repositories for deciding how to handle remote artifact requests. When a remote artifact is stored in Artifactory it is cached for a certain controlled period of time. For Maven artifacts, this is applicable only for snapshots, since releases are assumed never to change.


26

When a request arrives at Artifactory for an artifact that's caching timeout has expired, Artifactory will check if there is an updated artifact remotely.

We experimented with timeout settings in many different locations before deciding on the default values. It is therefore recommended not to change the defaults, unless there's a compelling reason to do so.

Socket TimeoutThis is the timeout period (for socket and connection) that Artifactory will wait before giving up on retrieving an artifact from a remote repository. After a timeout Artifactory will cache the fact that a retrieval failure has happened for the amount of time defined in "Failed Retrieval Cache Period". Artifactory will answer future requests for that particular artifact with NOT_FOUND (404) for a period of "Failed Retrieval Cache Period" seconds and will not attempt to retrieve it it again until that period expired.

Keep Unused ArtifactsMany cached artifacts in Artifactory remote repository storage are actually unused by any current projects in the organization. To solve this issue you can set an automatic removal of unused artifacts in remote repository caches.

Retrieval Cache Period


27

Defines how long before Artifactory checks for a newer version of a requested artifact in remote repository. Artifactory will not fetch anything but the metadata if no newer version is found.

Failed Retrieval Cache PeriodSee the explanation for Socket Timeout.

Missed Retrieval Cache PeriodThe number of seconds to cache artifact retrieval misses. A value of 0 means no caching. A miss is a 404 response (NOT_FOUND) received from a remote repository that currently does not have the artifact requested. You might want to treat this differently than when failing to retrieve the artifact is due to network problems.

Zapping CachesYou can clean up the Retrieval Cache by selecting a cached file or a folder in Artifacts:Tree Browser and clicking (or selecting, if right-clicking the item) the "Zap Caches" action. You can cleanup both the Retrieval Failures Cache and Missed Retrieval Cache by selecting a cached folder in Artifacts:Tree Browser and clicking (or selecting, if right-clicking the item) the "Zap Caches" action.

Handling Offline ScenariosOverviewArtifactory supports two kind of offline cases: when the whole organization is disconnected from remote repositories and when one or more remote repositories needs to be put offline.

Organization-wide OfflineIn this case, remote repositories serve as caches only and do not proxy remote artifacts. This is common in organizations that are using a separate secured network (such as military or financial institutes) and are disconnected from the rest of the world. In such cases, you can turn on (and off) the Global Offline Mode flag, under Admin:Configuration:General.


28

Single Repository OfflineA less rigid case is where one or more remote repository has become offline for some reason. In this case, it is possible to tell Artifactory to treat the individual remote repository as offline, so that only artifact already present in the cache will be used.

Handling ChecksumsOverviewArtifactory can help you block broken artifacts by activating checksum handling - Artifactory will then query the remote checksum prior to storing the file locally.

Configuring Checksum PoliciesUsing the configuration for a remote repository, you can choose between failing on bad checksums (blocking them), recalculating bad checksums,


29

calculate only missing checksums and accepting bad checksums.

Going Through ProxiesOverviewIn a corporate environment it is often required that, in order to access remote resources, you need to go through a proxy server. Artifactory supports both regular network proxies and NTLM proxies.

Defining ProxiesTo use a proxy you first need to create a proxy definition via Admin:Configuration:Proxies. Fields that do not require any value in your setup can be left blank (e.g. if you are not using authentication credentials or an NTLM proxy).

Checking the "System Default" checkbox, will activate a popup with the question "Do you wish to use this proxy with existing remote repositories (and override any assigned proxies)?":

Pressing "OK" will assign this proxy to all remote repositories (see below). If the proxy is defined as "System Default" then Artifactory will use it for all HTTP queries not related to remote repositories downloads. Only one system default proxy can be defined. The optional redirecting proxy target hosts allows listing host names to which the proxy may redirect requests. The credentials of the proxy will be


30

reused by requests redirected to any of these hosts.

Using ProxiesA remote repository will use a proxy, only if one is selected in the configuration panel for that repository. A "System Default" proxy is assigned by default when creating a new remote repository, but not used by default. A remote repository without a proxy defined will not use any proxy!

Advanced Settings


31

Accelerating DownloadsYou can instruct a remote repository to automatically eagerly retrieve related artifacts, in parallel on the server-side, before requested by the Maven client. The options are: Try and fetch a *.jar immediately when *.pom is queried. Try and fetch a *-sources.jar when *.jar is queried. Having these options on can speeds up first downloads by a factor.

Suppressing POM Consistency ChecksBy Default, Artifactory tries to keep your repositories healthy by refusing bad POMs that were deployed on remote repositories with wrong information. Artifactory will check that the coordinates (path) of POMs retrieved remotely match the groupId:artifactId:version information inside the POM, and will reject POMs that conflict with their path. You can disable this behavior by selecting the 'Suppress POM Consistency Checks" checkbox.

Cleaning-up Unique SnapshotsIf the remote repository managed unique snapshots names (The same groupId:artifactId:version will have many jars and pom with date and build number), you can tell Artifactory to automatically clean up old unique snapshots by setting the repository's Max Unique Snapshots value to the maximum number of unique snapshots of an artifact that should be maintained in the repository. Clean up takes effect each time a


32

new snapshot file name is downloaded and cached.

Remote Repository AuthenticationIf a remote repository requires authentication you can provide a username and password as part of the repository definition.

List Remote Folder ItemsIf you wish to browse the contents of a remote repository that has not been cached yet, you can enable this checkbox. This will allow to navigate the contents of the remote repository via the Simple Browser or List Browser.

Proxying Maven 1 repositoriesTo proxy Maven 1 repositories, simply set the remote repository type to Maven 1.

Connecting from Multi-homed MachinesIf you are running Artifactory on a machine with multiple network interfaces and only specific interfaces can connect to remote repositories, you can specify the interface you wish to use for remote connections under the "Local Address" field.

Importing Shared ConfigurationsOverviewArtifactory "Remote Repository Provisioning" feature allows you to share the configuration details of remote repositories between Artifactory instances. The public JFrog Artifactory instance contains an up-to-date version of most of the common public repositories.

Sharing a Remote Repository Configuration

In the main panel of Admin:Repositories:Remote Repositories:Edit the checkbox "Share Configuration" will tell Artifactory to expose this remote repository configuration to other Artifactory instance. When check, all configuration parameters will be shared from REST API queries except: Connection credentials (username,password) and Proxy configuration.

You can declare a remote repository with a URL pointing to yourself in order to expose access to your Artifactory. Be careful that this remote repository is not usable.

Using Import in Remote Repositories ConfigurationTo create or update remote repositories with a shared configuration from another Artifactory, go to Admin:Repositories:Remote Repositories:Import.


33

You can then enter the artifactory root URL of the server exposing remote repositories configuration. By default it points to JFrog public repository. Then activating "Load" will issue a request to the server.

If you have a "System Default" proxy defined, Artifactory will use it for doing this HTTP query.

A list of remote repositories can be selected and the repository key for each of them can be changed.

Important points to notice: 1. If the repository key already exists, the configuration of the existing remote repository will be modified. 2. If HTTP proxy is used, each of the new repository will have to be associated with the local proxy definition. 3. You will have to add new remote repositories to existing virtual repositories in order for them to be visible to virtual repository requests.

Virtual RepositoriesOverviewArtifactory lets you define a virtual repository that is a collection of local, remote and other virtual repositories under a single logical URL. A virtual repository hides the underlying repositories and lets users work against a single well-known URL, while allowing you to change the participating repositories and their rules without requiring any client-side changes. The main features supported by a virtual repository are: 1. 2. 3. 4. Nesting, Include Exclude patterns filter, Automatic removal of repository references, WebStart automatic signing and JNLP file conversion.

Setting Up a Virtual RepositoryFrom the UI go to Admin:Configuration:Repositories:Virtual Repositories and create a new virtual repository. Add the repositories you wish to be part of the virtual repositories to the virtual repository list of selected repositories.


34

The actual list of effectively resolved repositories (after expanding nested virtual repositories) will be displayed and automatically updated.

The search/resolution order when requesting artifacts from a virtual repository is always: local repositories, remote repository caches and finally remote repositories themselves.

Nesting Virtual RepositoriesThe ability to nest virtual repositories is unique to Artifactory. It allows for greater reuse of virtual repositories between themselves.

Artifactory will detect when overly nesting repositories ends up in an infinite loop and will warn against that.


35

Include Exclude Patterns in Virtual RepositoriesThe coupling of Include/Exclude patterns of Artifactory Configuring Repositories to virtual repositories nesting provides a powerful feature. You can now define in a single virtual repository "remote-repos" the company groupId exclusion, and it will ensure that no requests for internal artifacts will be sent outside. Another example for this feature, is defining virtual repository for a project, and filter undesirable groupId, sources or versions, that won't be visible to developers.

Serving Requests from Other Artifactory InstancesBy setting the 'Artifactory Requests Can Retrieve Remote Artifacts' flag, you can instruct Artifactory whether the virtual repository should include remote repositories in artifacts resolution when answering requests coming from other Artifactory instances. This is useful when deploying Artifactory in a mesh (grid) architecture, where you do not want all remote Artifactories to act as remote proxies for other Artifactory instances.

Currently, to control remote artifacts resolution for other Artifactory instances for the global virtual repository 'repo', you'd have to use the artifactory.artifactoryRequestsToGlobalCanRetrieveRemoteArtifacts system property, which is set to false by default.

Making Sure Artifactory is Your Sole Artifacts ProviderOne very bad practice (sadly heavily used on public POMs), is to add a direct reference to external repository in a POM. When any of

or

are present, Maven will dynamically add external repository URL to the build. This will shortcut Artifactory. The solution until now was the usage of mirrorOf like described here. Artifactory provide at the virtual repository level, an automatic cleanup of POM file. Three level of cleanup policy are configurable: 1. Discard Active References - Will removes repository elements that are declared directly under project or under a profile in the same pom that is activeByDefault. 2. Discard Any References - Will removes all repository elements regardless of whether they are included in an active profile or not. 3. Nothing - Don't removes any repository elements declared in the POM.

Managing Security Copyright 2012 JFrog Ltd. 36

OverviewOne of the main strengths of Artifactory is the strong security model it offers: You can assign role-based or user-based permissions to areas in your repositories (called Permission Targets), allow sub-administrators for theses areas, configure LDAP out-of-the-box, prevent clear text in your Maven's settings.xml, inspect security definitions for a single artifact or folder and more. Artifactory's security is based on Spring Security and can be extended and customized. This section explains the strong security aspects and controls offered by Artifactory: Managing Users Managing Groups Managing Permissions Managing Security with LDAP Centrally Secure Passwords Access Log

Managing UsersOverviewArtifactory users management is available from the web UI under Admin:Security:Users. An administrator needs to create users (unless external authentication, such as LDAP is active) and assign them roles and permissions.

Creating and Editing UsersCreate a new user by clicking the New button next to the users table. Unchecking the "Can Update Profile" checkbox prevents a user from updating his profile details. This can be useful, for example, for creating a shared departmental user, with a signle password shared between all individuals in the same department, while only an administrator can update the password. When external authentication, such as LDAP, is active you can disable the fallback to using internal password by checking the "Disable Internal Password" checkbox.

Passwords are always stored as hashes or encrypted hashes inside Artifactory.

Administrator Users


37

An administrator user is to Artifactory like a root in Unix systems. Administrators are not subject to any security restrictions. It is therefore recommended to create a minimum number of administrators. You can always create less powerful, per-permission-target, administrators inside Artifactory (that are in charge of a specific repository path). See the permissions management section.

The Default Admin Account The default user name and password for the built-in administrator user are: admin/password. You should change the password after the first time you log in. It is possible to recover the default admin account by following these instructions.

The Anonymous UserArtifactory supports the concept of anonymous users. A built-in, unmodifiable 'anonymous' user exists in Artifactory, that can be assigned permissions, just as any regular user. A global "Allow Anonymous Access" flag controls whether this 'anonymous' user is active or not, and must be turned on before you can fine tune the anonymous user permissions. Anonymous access is turned on by default. It can be turned on and off from the Admin:Security:General page:

When the global anonymous access is on, anonymous download requests will be able to download cached artifacts and populate caches, regardless of other permissions definitions.

Users ManagementOther users management such as editing, removing and assigning groups to selected users can be done under Admin:Security:Users

Recreating the Default Admin Account


38

This action is applicable only from version 2.0.6 (including).

Obtaining A Security Configuration File

If your instance of Artifactory is configured to perform backups, you can find the security.xml file at the top backup directory, Make a copy of this file, open up it up with a text editor, change the admin's "password" field to

5f4dcc3b5aa765d61d8327deb882cf99

(which is 'password' in hash) and keep it aside. In case no backup is available, you may contact us for further help.Resetting The Password

Take the modified security configuration file, place it under $ARTIFACTORY_HOME/etc and rename it to: security.xml for versions 2.0.6 - 2.0.8. security.import.xml for versions 2.1.0 - latest. Now restart Artifactory, and the admin password should be reset.

Managing GroupsOverviewGroups are managed in Artifactory from the web UI under Admin:Security:Groups. Create a new group by clicking the New button next to the groups table. A group is a role in artifactory and is used in RBAC (role-based access control) rules.

Default GroupsWhen creating (or editing) a group you can mark it as a default group to which all newly added users from this point will auto-join. This is particularly useful when using external authentication, like LDAP, where users are automatically created on successful login and you want them to automatically be part of a certain group.


39

Managing PermissionsOverviewArtifactory allows you to manage permissions per a Permission Target. A permission target is an concept that denotes a physical (non-virtual) repository and include and exclude patterns on the repository +

Documents

Artifactory User Guide