Installation customization (AEN 4.1.1)
======================================

.. raw:: html

    <div class="section" id="id1">
    <h2>Sudo configuration<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h2>
    <p>If your organization&#8217;s IT security policy does not allow root access or
    has restrictions on the use of sudo, you may customize your Anaconda
    Enterprise Notebook&#8217;s (AEN) install to meet their requirements after
    running the installation routine.</p>
    <p>Your organization may choose to implement any or all of the following:</p>
    <ol class="arabic simple">
    <li>Remove root access for AEN service account (Note: this restricts AEN
    from managing user accounts)</li>
    <li>Configurable sudo command</li>
    <li>Restrict sudo access to all processes</li>
    </ol>
    <p>These customizations must be done in a terminal window after copying the
    files to the AEN Server instance.</p>
    <div class="section" id="remove-all-root-access-from-the-aen-service-account">
    <h3>1. Remove all root access from the AEN service account<a class="headerlink" href="#remove-all-root-access-from-the-aen-service-account" title="Permalink to this headline">¶</a></h3>
    <p>This restricts AEN from managing user accounts because root access is
    required for <code class="docutils literal"><span class="pre">useradd</span></code>.</p>
    <p>Modify <code class="docutils literal"><span class="pre">/etc/sudoers.d/wakari_sudo</span></code> to read:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span>Defaults:wakari !requiretty, visiblepw
    Runas_Alias    OP = ALL,!root
    wakari ALL=(OP) NOPASSWD: ALL
    </pre></div>
    </div>
    <p><strong>Note</strong>: If you used a service account name other than wakari, that
    name should appear instead of wakari in the file above.</p>
    <p>Next, modify the file
    <code class="docutils literal"><span class="pre">/opt/wakari/wakari-compute/etc/wakari/config.json</span></code>, setting to read:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span><span class="s2">&quot;MANAGE_ACCOUNTS&quot;</span><span class="p">:</span> <span class="n">false</span><span class="p">,</span>
    </pre></div>
    </div>
    <p><strong>NOTE</strong>: Using this option means that the IT department must create and
    manage all user accounts at the OS level. After an OS-level account
    exists, an AEN account using the same name may be created on the main
    AEN webpage. The password chosen on the AEN webpage is not linked in any
    way to the OS-level password for the account. Alternatively, the system
    can be configured to use LDAP for authenticating users.</p>
    <p>If you wish to allow public user access to projects, an account must
    also be created for the public to use, for example, <code class="docutils literal"><span class="pre">public</span></code> or
    <code class="docutils literal"><span class="pre">anonymous</span></code>. Create the public account and specify the name in the
    following two configuration files:</p>
    <p>Locate the file <code class="docutils literal"><span class="pre">/opt/wakari/wakari-compute/etc/wakari/config.json</span></code>
    and modify the line:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span><span class="s2">&quot;ANON_USER&quot;</span><span class="p">:</span> <span class="s2">&quot;public&quot;</span>
    </pre></div>
    </div>
    <p>Next, locate the second file
    <code class="docutils literal"><span class="pre">/opt/wakari/wakari-server/etc/wakari/config.json</span></code> and modify the
    line:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span><span class="s2">&quot;ANON_USER&quot;</span><span class="p">:</span> <span class="s2">&quot;public&quot;</span>
    </pre></div>
    </div>
    <p>The <a class="reference internal" href="../admin/configuration-files.html"><span class="doc">Configuration Files</span></a> page has more information about these configuration keys.</p>
    </div>
    <div class="section" id="alternative-sudo-command">
    <h3>2. Alternative sudo command<a class="headerlink" href="#alternative-sudo-command" title="Permalink to this headline">¶</a></h3>
    <p>You may configure AEN to use an alternative to <code class="docutils literal"><span class="pre">sudo</span></code>, provided it supports the same execution semantics.</p>
    <p>In your terminal window, navigate to the AEN files, locate the file
    <code class="docutils literal"><span class="pre">/opt/wakari/wakari-compute/</span></code> <code class="docutils literal"><span class="pre">etc/wakari/config.json</span></code></p>
    <p>and modify the line:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span><span class="s2">&quot;AEN_SUDO_CMD&quot;</span><span class="p">:</span> <span class="s2">&quot;/path/to/alternative/sudo&quot;</span><span class="p">,</span>
    </pre></div>
    </div>
    <p>If the alternate <code class="docutils literal"><span class="pre">sudo</span></code> command is available on the <code class="docutils literal"><span class="pre">PATH</span></code> then the full path is not required.</p>
    <p>The alternative <code class="docutils literal"><span class="pre">sudo</span></code> must be configured to give the service account permission
    to run commands on behalf of the Anaconda Enterprise users.</p>
    </div>
    <div class="section" id="restrict-sudo-access-to-a-single-executable">
    <h3>3. Restrict sudo access to a single executable<a class="headerlink" href="#restrict-sudo-access-to-a-single-executable" title="Permalink to this headline">¶</a></h3>
    <p>The <code class="docutils literal"><span class="pre">sudoers</span></code> configuration, by default, allows Anaconda Enterprise to run any
    command as a particular user. This allows Anaconda Enterprise to initiate processes
    as the logged in end user.  If more restrictive control is required it should, in
    the first instance, be implemented via a suitable <code class="docutils literal"><span class="pre">sudoers</span></code> policy.</p>
    <p>If that is not possible or practical then it is also possible to route all
    Anaconda Enterprise id-changing operations through a single gatekeeper.  This
    gatekeeper wraps the desired executable and provides an alternate way to log,
    monitor, or control which processes can be initiated by Anaconda Enterprise on
    behalf of another user.</p>
    <p>This gatekeeper is a special case configuration that should only be used if required.</p>
    <p>To configure Anaconda Enterprise accordingly modify
    <code class="docutils literal"><span class="pre">/etc/sudoers.d/wakari_sudo</span></code> to contain</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span>Defaults:wakari !requiretty, visiblepw
    Runas_Alias    OP = ALL,!root
    wakari ALL=(OP) NOPASSWD: /path/to/gatekeeper
    </pre></div>
    </div>
    <p>Locate the file <code class="docutils literal"><span class="pre">/opt/wakari/wakari-compute/etc/wakari/config.json</span></code></p>
    <p>and modify the line:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span><span class="s2">&quot;AEN_SUDO_SH&quot;</span><span class="p">:</span> <span class="s2">&quot;/path/to/gatekeeper&quot;</span>
    </pre></div>
    </div>
    <p>The <code class="docutils literal"><span class="pre">gatekeeper</span></code> can be as simple as a script which could have contents such as:</p>
    <div class="highlight-default"><div class="highlight"><pre><span></span>#!/bin/bash
    first_cmd=$1
    if [ &#39;bash&#39; == $1 ]; then
        shift
        export HOME=~
        export SHELL=/bin/bash
        export PATH=$PATH:/opt/wakari/anaconda/bin
        bash &quot;$@&quot;
    else
        exec $@
    fi
    </pre></div>
    </div>
    </div>
    </div>
