> ## Documentation Index
> Fetch the complete documentation index at: https://anaconda.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuring conda in Workbench

As an administrator, it is your responsibility to maintain conda within Data Science & AI Workbench. Similar to how a user must configure conda to understand which channels to attempt to pull packages from when creating environments, Workbench requires configurations in the form of a *system-level* `.condarc` file to understand which channels Workbench *users* have access to when creating environments or installing packages in projects. Configuring conda at the system level overrides any user-level conda configurations.

The system-level `.condarc` file is populated from the `conda:` section of the `anaconda-enterprise-anaconda-platform.yml` configmap file or the `values.yml` helm chart override file. If no modifications are made during installation, the default Workbench `.condarc` file looks like this:

<Accordion title="Default .condarc configuration">
  ```sh theme={null}
  conda:
     channels:
     - defaults
     # List of channels that should be used for channel 'defaults'
     default_channels:
     - https://repo.anaconda.com/pkgs/main
     - https://repo.anaconda.com/pkgs/r
     # URL prefix to add to short channel names
     channel_alias: http://anaconda-enterprise-ap-repository/repository/conda
     # configuration for proxies with SSL inspection
     ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
     # Additional configuration values not included above
     other_variables: {}
  ```

  The default Workbench setup allows all users to have access to all packages from Anaconda’s `main` and `r` channels. However, with the `channel_alias:` set to the internal Workbench repository, conda is still able to access channels created within Workbench (whether via the UI or CLI) when the channel name is invoked in a conda command with the `-c` tag, or listed in a project’s `anaconda-project.yml` configuration file, even if they are not listed in the `.condarc`.

  <Note>
    Anaconda recommends removing the `r` channel if you are not using R language packages.
  </Note>
</Accordion>

To configure conda for workbench, [follow these instructions](/docs/data-science/latest/admin/advanced/settings) to edit the configmap’s `conda:` section to include the channels you need to provide to all Workbench users.

<Note>
  Anaconda recommends listing only `defaults` in the `channels:` list, and listing only necessary channels in the `default_channels:` list. Place the channels you want available to all users in the `default_channels:` list.
</Note>

Here are some example `.condarc` configuration variations that you can use as a template for your own `.condarc` settings.

<AccordionGroup>
  <Accordion title="Using internal Workbench repository channels only">
    If you want to centralize all of your channels to the internal Workbench repository, [mirror](./mirror) the external channels and packages you want into internal Workbench channels. Make your internal channels available to all users by entering them in the `default_channels:` list by name, and leave the `channel_alias:` alone.

    ```sh theme={null}
    # Replace <CHANNEL_NAME> with the name of an internal Workbench repository channel
    conda:
       channels:
       - defaults
       default_channels:
       - <CHANNEL_NAME>
       - <CHANNEL_NAME>
       ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
       channel_alias: http://anaconda-enterprise-ap-repository/repository/conda
    ```
  </Accordion>

  <Accordion title="Using the internal Workbench repository with external channels">
    Similar to the default configurations, if you would like to be able to access the internal Workbench repository channels and still provide access to specific external repository channels, enter the full URL of the external channel location(s) in the `default_channels:` list and leave the `channel_alias:` alone.

    ```sh theme={null}
    # Replace <CHANNEL_URL> with the full URL of an external repository channel
    conda:
       channels:
       - defaults
       default_channels:
       - <CHANNEL_URL>
       - <CHANNEL_URL>
       ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
       channel_alias: http://anaconda-enterprise-ap-repository/repository/conda
    ```
  </Accordion>

  <Accordion title="External repository channels only">
    If you have a repository of channels and packages that are hosted on an external site, you can set the `channel_alias:` to the repository’s fully qualified domain name (FQDN). This setup enables you to invoke channel names in conda commands using the `-c` tag. In this example, we use anaconda.org as an external repository site:

    ```sh theme={null}
    # Replace <ORG_NAME> with your anaconda.org organization name
    # Replace <ORG_CHANNEL> with the name of an anaconda.org channel
    conda:
       channels:
       - defaults
       default_channels:
       - <ORG_CHANNEL>
       - <ORG_CHANNEL>
       ssl_verify: /var/run/secrets/anaconda/ca-chain.pem
       channel_alias: https://conda.anaconda.org/<ORG_NAME>/
    ```
  </Accordion>
</AccordionGroup>

The channels you specify can be *public* or *private*. Private channels require users to authenticate via `anaconda-enterprise-cli` before they can access packages from them. For more information about channel sharing, see [sharing channels](./channels#sharing-channels).

## Configuring a proxy for conda

You can configure Workbench to use a proxy server for conda if your organization’s network security policy requires it.

### Obtain your proxy values

You must know the address of your proxy server and what port you need to communicate over to proceed. Gather this information, and keep it somewhere you can reference quickly.

### Verify proxy values

Test your proxy values by setting them as environment variables from within a Workbench project:

1. Log in to Workbench.

2. Open a session in the project you want to use to test the proxy.

   <Note>
     If the project already has a session open, you’ll need to stop the current session and open a new one.
   </Note>

3. Open a terminal window within JupyterLab.

4. Set and export your proxy variables by running the following commands:

   ```sh theme={null}
   # Replace <PROXY_URL> with the full URL of your proxy server
   # Replace <PORT> with the port number you are using to communicate
   # Replace <PROXY_DOMAIN> with the FQDN of your proxy server
   export http_proxy=<PROXY_URL>:<PORT>
   export https_proxy=<PROXY_URL>:<PORT>
   export no_proxy=*<PROXY_DOMAIN>
   export HTTP_PROXY=<PROXY_URL>:<PORT>
   export HTTPS_PROXY=<PROXY_URL>:<PORT>
   export NO_PROXY=*<PROXY_DOMAIN>
   ```

5. Verify the proxy works by running the following command:

   ```
   conda create --name testenv python
   ```

### Configure global system variables

Once you’ve confirmed your proxy works, follow instructions for [setting global config variables](/docs/data-science/latest/admin/advanced/global_config) to apply those variables to all future sessions, deployments, and scheduled jobs.

The lines you add to the global config should look something like the following, with your specific proxy address and port number substituted in:

```sh theme={null}
http_proxy: http://proxy.example.com:1245/
https_proxy: https://proxy.example.com:1245/
no_proxy: *.example.com
HTTP_PROXY: http://proxy.example.com:1245/
HTTPS_PROXY: https://proxy.example.com:1245/
NO_PROXY: *.example.com
```