[ARVADOS] updated: 1.3.0-1881-gee341f1fc
Git user
git at public.curoverse.com
Mon Nov 18 21:11:42 UTC 2019
Summary of changes:
doc/Rakefile | 6 +
doc/_config.yml | 6 +-
doc/_includes/_navbar_left.liquid | 4 +-
doc/admin/User account states.odg | Bin 0 -> 12087 bytes
doc/admin/activation.html.textile.liquid | 187 +--------------------
....textile.liquid => logging.html.textile.liquid} | 6 +-
doc/admin/migrating-providers.html.textile.liquid | 2 +-
doc/admin/troubleshooting.html.textile.liquid | 75 +--------
.../user-management-cli.html.textile.liquid} | 0
....liquid => user-management.html.textile.liquid} | 4 +-
doc/api/methods/users.html.textile.liquid | 6 +-
doc/css/images.css | 5 +
doc/install/cheat_sheet.html.textile.liquid | 89 +---------
lib/config/generated_config.go | 2 +-
14 files changed, 31 insertions(+), 361 deletions(-)
create mode 100644 doc/admin/User account states.odg
mode change 100644 => 120000 doc/admin/activation.html.textile.liquid
copy doc/admin/{troubleshooting.html.textile.liquid => logging.html.textile.liquid} (95%)
mode change 100644 => 120000 doc/admin/troubleshooting.html.textile.liquid
copy doc/{install/cheat_sheet.html.textile.liquid => admin/user-management-cli.html.textile.liquid} (100%)
copy doc/admin/{activation.html.textile.liquid => user-management.html.textile.liquid} (98%)
mode change 100644 => 120000 doc/install/cheat_sheet.html.textile.liquid
via ee341f1fc2579fdf28a8b8f07918f9ae195b0727 (commit)
from 98e4a92f007533b2924604e4f83da9a6d15e0ef3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
commit ee341f1fc2579fdf28a8b8f07918f9ae195b0727
Author: Peter Amstutz <pamstutz at veritasgenetics.com>
Date: Mon Nov 18 15:38:25 2019 -0500
15577: Rename some files, symlink old names
More tweaks based on feedback
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <pamstutz at veritasgenetics.com>
diff --git a/doc/Rakefile b/doc/Rakefile
index c3888c5f6..63dc16d25 100644
--- a/doc/Rakefile
+++ b/doc/Rakefile
@@ -3,6 +3,12 @@
#
# SPDX-License-Identifier: CC-BY-SA-3.0
+# As a convenience to the documentation writer, you can touch a file
+# called 'no-sdk' in the 'doc' directory and it will suppress
+# generating the documentation for the SDKs, which (the R docs
+# especially) take a fair bit of time and slow down the edit-preview
+# cycle.
+
require "rubygems"
require "colorize"
diff --git a/doc/_config.yml b/doc/_config.yml
index 76c967ac4..bcb66fdb3 100644
--- a/doc/_config.yml
+++ b/doc/_config.yml
@@ -156,15 +156,15 @@ navbar:
- admin/upgrading.html.textile.liquid
- admin/config-migration.html.textile.liquid
- Users and Groups:
- - admin/activation.html.textile.liquid
+ - admin/user-management.html.textile.liquid
- admin/reassign-ownership.html.textile.liquid
- - install/cheat_sheet.html.textile.liquid
+ - admin/user-management-cli.html.textile.liquid
- admin/group-management.html.textile.liquid
- admin/merge-remote-account.html.textile.liquid
- admin/migrating-providers.html.textile.liquid
- user/topics/arvados-sync-groups.html.textile.liquid
- Monitoring:
- - admin/troubleshooting.html.textile.liquid
+ - admin/logging.html.textile.liquid
- admin/metrics.html.textile.liquid
- admin/health-checks.html.textile.liquid
- admin/management-token.html.textile.liquid
diff --git a/doc/_includes/_navbar_left.liquid b/doc/_includes/_navbar_left.liquid
index cba6c46e4..d3ac2932d 100644
--- a/doc/_includes/_navbar_left.liquid
+++ b/doc/_includes/_navbar_left.liquid
@@ -11,9 +11,9 @@ SPDX-License-Identifier: CC-BY-SA-3.0
{% for entry in section %}
<li><span class="nav-header">{{ entry[0] }}</span>
<ol class="nav nav-list">
- {% for item in entry[1] %}
+ {% for item in entry[1] %}
{% assign p = site.pages[item] %}
- <li {% if p.url == page.url %} class="active activesubnav" {% elsif p.title == page.subnavsection %} class="activesubnav" {% endif %}>
+ <li {% if p.url == page.url or p.title == page.title %} class="active activesubnav" {% elsif p.title == page.subnavsection %} class="activesubnav" {% endif %}>
<a href="{{ site.baseurl }}{{ p.url }}">{{ p.title }}</a></li>
{% endfor %}
</ol>
diff --git a/doc/admin/User account states.odg b/doc/admin/User account states.odg
new file mode 100644
index 000000000..866e07aeb
Binary files /dev/null and b/doc/admin/User account states.odg differ
diff --git a/doc/admin/activation.html.textile.liquid b/doc/admin/activation.html.textile.liquid
deleted file mode 100644
index cce83c70b..000000000
--- a/doc/admin/activation.html.textile.liquid
+++ /dev/null
@@ -1,186 +0,0 @@
----
-layout: default
-navsection: admin
-title: User management
-...
-
-{% comment %}
-Copyright (C) The Arvados Authors. All rights reserved.
-
-SPDX-License-Identifier: CC-BY-SA-3.0
-{% endcomment %}
-
-{% comment %}
-TODO: Link to relevant workbench documentation when it gets written
-{% endcomment %}
-
-This page describes how user accounts are created, set up and activated.
-
-h2. Authentication
-
-"Browser login and management of API tokens is described here.":{{site.baseurl}}/api/tokens.html
-
-After completing the log in and authentication process, the API server receives a user record from the upstream identity provider (Google, LDAP, etc) consisting of the user's name, primary email address, alternate email addresses, and optional unique provider identifier (@identity_url@).
-
-If a provider identifier is given, the API server searches for a matching user record.
-
-If a provider identifier is not given, no match is found, it next searches by primary email and then alternate email address. This enables "provider migration":migrating-providers.html and a "pre-activated accounts.":#pre-activated
-
-If no user account is found, a new user account is created with the information from the identity provider.
-
-If a user account has been "linked":{{site.baseurl}}/user/topics/link-accounts.html or "migrated":merge-remote-account.html the API server may follow internal redirects (@redirect_to_user_uuid@) to select the linked or migrated user account.
-
-h3. Federated Authentication
-
-A federated user follows a slightly different flow. The client presents a token issued by the remote cluster. The local API server contacts the remote cluster to verify the user's identity. This results in a user object (representing the remote user) being created on the local cluster. If the user cannot be verified, the token will be rejected. If the user is inactive on the remote cluster, a user record will be created, but it will also be inactive.
-
-h2. User activation
-
-This section describes the different user account states.
-
-!(full-width){{site.baseurl}}/images/user-account-states.svg!
-
-notextile. <div class="spaced-out">
-
-# A new user record is not set up, and not active. An inactive user cannot create or update any object, but can read Arvados objects that the user account has permission to read (such as publicly available items readable by the "anonymous" user).
-# Using Workbench or the "command line":{{site.baseurl}}/install/cheat_sheet.html , the admin invokes @setup@ on the user.
-If "Users.AutoSetupNewUsers":config.html is true, this happens automatically during user creation, so in that case new users start at step (3).
-The setup method adds the user to the "All users" group.
-If "Users.AutoSetupNewUsersWithRepository":config.html is true, a new git repo is created for the user.
-If "Users.AutoSetupNewUsersWithVmUUID":config.html is set, the user is given login permission to the specified shell node
-# User is set up, but still not yet active. The browser presents "user agreements":#user_agreements (if any) and then invokes the user @activate@ method on the user's behalf.
-# The user @activate@ method checks that all "user agreements":#user_agreements are signed. If so, or there are no user agreements, the user is activated.
-# The user is active. User has normal access to the system.
-# From steps (1) and (3), an admin user can directly update the @is_active@ flag. This bypasses enforcement that user agreements are signed.
-If the user was not yet set up (still in step (1)), it adds the user to the "All users", but bypasses creating default git repository and assigning default VM access.
-# An existing user can have their access revoked using @unsetup@ and "ownership reassigned.":reassign-ownership.html .
-Unsetup removes the user from the "All users" group and makes them inactive, preventing them from re-activating themselves.
-"Ownership reassignment":reassign-ownership.html moves any objects or permission from the old user to a new user and deletes any credentials for the old user.
-
-notextile. </div>
-
-User management can be performed through the web using Workbench or the command line. See "user management at the CLI":{{site.baseurl}}/install/cheat_sheet.html for specific examples.
-
-h2(#user_agreements). User agreements and self-activation
-
-The @activate@ method of the users controller checks if the user account is part of the "All Users" group and whether the user has "signed" all the user agreements.
-
-User agreements are accessed through the "user_agreements API":{{site.baseurl}}/api/methods/user_agreements.html . This returns a list of collection records.
-
-The user agreements that users are required to sign should be added to the @links@ table this way:
-
-<pre>
-$ arv link create --link '{
- "link_class": "signature",
- "name": "require",
- "tail_uuid": "*system user uuid*",
- "head_uuid: "*collection uuid*"
-}'
-</pre>
-
-The collection should contain a single HTML file with the user agreement text.
-
-Workbench displays the clickthrough agreements which the user can "sign".
-
-The @user_agreements/sign@ endpoint creates a Link object:
-
-<pre>
-{
- "link_class": "signature"
- "name": "click",
- "tail_uuid": "*user uuid*",
- "head_uuid: "*collection uuid*"
-}
-</pre>
-
-The @user_agreements/signatures@ endpoint returns the list of Link objects that represent signatures by the current user (created by @sign@).
-
-h2. User profile
-
-The fields making up the user profile are described in @Workbench.UserProfileFormFields@ . See "Configuration reference":config.html .
-
-The user profile is checked by workbench after checking if user agreements need to be signed. The values entered are stored in the @properties@ field on the user object. Unlike user agreements, the requirement to fill out the user profile is not enforced by the API server.
-
-h2(#pre-activated). Pre-setup user by email address
-
-You may create a user account for a user that has not yet logged in, and identify the user by email address.
-
-1. As an admin, create a user object:
-
-<pre>
-$ arv --format=uuid user create --user '{"email": "foo at example.com", "username": "foo"}'
-clsr1-tpzed-1234567890abcdf
-$ arv user setup --uuid clsr1-tpzed-1234567890abcdf
-</pre>
-
-2. When the user logs in the first time, the email address will be recognized and the user will be associated with the existing user object.
-
-h2. Pre-activate federated user
-
-1. As admin, create a user object with the @uuid@ of the federated user (this is the user's uuid on their home cluster, called @clsr2@ in this example):
-
-<pre>
-$ arv user create --user '{"uuid": "clsr2-tpzed-1234567890abcdf", "email": "foo at example.com", "username": "foo", "is_active": true}'
-</pre>
-
-2. When the user logs in, they will be associated with the existing user object.
-
-h2. Auto-setup federated users from trusted clusters
-
-By setting @ActivateUsers: true@ for each federated cluster in @RemoteClusters@, a federated user from one of the listed clusters will be automatically set up and activated on this cluster. See configuration example in "Federated instance":#federated .
-
-h2. Activation flows
-
-h3. Private instance
-
-Policy: users must be manually set up by the admin.
-
-Here is the configuration for this policy. This is also the default if not provided.
-(However, be aware that developer/demo builds such as "arvbox":{{site.baseurl}}/install/arvbox.html are configured with the "Open instance" policy described below.)
-
-<pre>
-Users:
- AutoSetupNewUsers: false
-</pre>
-
-# User is created. Not set up. @is_active@ is false.
-# Workbench checks @is_invited@ and finds it is false. User gets "inactive user" page.
-# Admin goes to user page and clicks "setup user" or sets @is_active@ to true.
-# On refreshing workbench, the user is able to self-activate after signing clickthrough agreements (if any).
-# Alternately, directly setting @is_active@ to true also sets up the user, but skips clickthrough agreements (because the user is already active).
-
-h3(#federated). Federated instance
-
-Policy: users from other clusters in the federation are activated, users from outside the federation must be manually approved.
-
-Here is the configuration for this policy and an example remote cluster @clsr2 at .
-
-<pre>
-Users:
- AutoSetupNewUsers: false
-RemoteClusters:
- clsr2:
- ActivateUsers: true
-</pre>
-
-# Federated user arrives claiming to be from cluster 'clsr2'
-# API server authenticates user as being from cluster 'clsr2'
-# Because 'clsr2' has @ActivateUsers@ the user is set up and activated.
-# User can immediately start using Workbench.
-
-h3. Open instance
-
-Policy: anybody who shows up and signs the agreements is activated.
-
-<pre>
-Users:
- AutoSetupNewUsers: true
-</pre>
-
-"Set up user agreements":#user_agreements by creating "signature" "require" links as described earlier.
-
-# User is created and auto-setup. At this point, @is_active@ is false, but user has been added to "All users" group.
-# Workbench checks @is_invited@ and finds it is true, because the user is a member of "All users" group.
-# Workbench presents user with list of user agreements, user reads and clicks "sign" for each one.
-# Workbench tries to activate user.
-# User is activated.
diff --git a/doc/admin/activation.html.textile.liquid b/doc/admin/activation.html.textile.liquid
new file mode 120000
index 000000000..5e599a6b5
--- /dev/null
+++ b/doc/admin/activation.html.textile.liquid
@@ -0,0 +1 @@
+user-management.html.textile.liquid
\ No newline at end of file
diff --git a/doc/admin/troubleshooting.html.textile.liquid b/doc/admin/logging.html.textile.liquid
similarity index 95%
copy from doc/admin/troubleshooting.html.textile.liquid
copy to doc/admin/logging.html.textile.liquid
index 3eb43c00e..45dc11d75 100644
--- a/doc/admin/troubleshooting.html.textile.liquid
+++ b/doc/admin/logging.html.textile.liquid
@@ -1,7 +1,7 @@
---
layout: default
navsection: admin
-title: Error Logging
+title: Logging
...
{% comment %}
@@ -10,6 +10,10 @@ Copyright (C) The Arvados Authors. All rights reserved.
SPDX-License-Identifier: CC-BY-SA-3.0
{% endcomment %}
+Most Arvados services write JSON-format structured logs to stderr, which can be parsed by any operational tools that support JSON.
+
+h2. Request ids
+
Using a distributed system with several services working together sometimes makes it difficult to find the root cause of errors, as one single client request usually means several different requests to more than one service.
To deal with this difficulty, Arvados creates a request ID that gets carried over different services as the requests take place. This ID has a specific format and it's comprised of the prefix "@req-@" followed by 20 random alphanumeric characters:
diff --git a/doc/admin/migrating-providers.html.textile.liquid b/doc/admin/migrating-providers.html.textile.liquid
index 6503f691b..6dd0d866e 100644
--- a/doc/admin/migrating-providers.html.textile.liquid
+++ b/doc/admin/migrating-providers.html.textile.liquid
@@ -1,7 +1,7 @@
---
layout: default
navsection: admin
-title: "Changing login providers"
+title: Changing upstream login providers
...
{% comment %}
Copyright (C) The Arvados Authors. All rights reserved.
diff --git a/doc/admin/troubleshooting.html.textile.liquid b/doc/admin/troubleshooting.html.textile.liquid
deleted file mode 100644
index 3eb43c00e..000000000
--- a/doc/admin/troubleshooting.html.textile.liquid
+++ /dev/null
@@ -1,74 +0,0 @@
----
-layout: default
-navsection: admin
-title: Error Logging
-...
-
-{% comment %}
-Copyright (C) The Arvados Authors. All rights reserved.
-
-SPDX-License-Identifier: CC-BY-SA-3.0
-{% endcomment %}
-
-Using a distributed system with several services working together sometimes makes it difficult to find the root cause of errors, as one single client request usually means several different requests to more than one service.
-
-To deal with this difficulty, Arvados creates a request ID that gets carried over different services as the requests take place. This ID has a specific format and it's comprised of the prefix "@req-@" followed by 20 random alphanumeric characters:
-
-<pre>req-frdyrcgdh4rau1ajiq5q</pre>
-
-This ID gets propagated via an HTTP @X-Request-Id@ header, and gets logged on every service.
-
-h3. API Server error reporting and logging
-
-In addition to providing the request ID on every HTTP response, the API Server adds it to every error message so that all clients show enough information to the user to be able to track a particular issue. As an example, let's suppose that we get the following error when trying to create a collection using the CLI tools:
-
-<pre>
-$ arv collection create --collection '{}'
-Error: #<RuntimeError: Whoops, something bad happened> (req-ku5ct9ehw0y71f1c5p79)
-</pre>
-
-The API Server logs every request in JSON format on the @production.log@ (usually under @/var/www/arvados-api/current/log/@ when installing from packages) file, so we can retrieve more information about this by using @grep@ and @jq@ tools:
-
-<pre>
-# grep req-ku5ct9ehw0y71f1c5p79 /var/www/arvados-api/current/log/production.log | jq .
-{
- "method": "POST",
- "path": "/arvados/v1/collections",
- "format": "json",
- "controller": "Arvados::V1::CollectionsController",
- "action": "create",
- "status": 422,
- "duration": 1.52,
- "view": 0.25,
- "db": 0,
- "request_id": "req-ku5ct9ehw0y71f1c5p79",
- "client_ipaddr": "127.0.0.1",
- "client_auth": "zzzzz-gj3su-jllemyj9v3s5emu",
- "exception": "#<RuntimeError: Whoops, something bad happened>",
- "exception_backtrace": "/var/www/arvados-api/current/app/controllers/arvados/v1/collections_controller.rb:43:in `create'\n/var/lib/gems/ruby/2.3.0/gems/actionpack-5.0.7.2/lib/action_controller/metal/basic_implicit_render.rb:4:in `send_action'\n ...[snipped]",
- "params": {
- "collection": "{}",
- "_profile": "true",
- "cluster_id": "",
- "collection_given": "true",
- "ensure_unique_name": "false",
- "help": "false"
- },
- "@timestamp": "2019-07-15T16:40:41.726634182Z",
- "@version": "1",
- "message": "[422] POST /arvados/v1/collections (Arvados::V1::CollectionsController#create)"
-}
-</pre>
-
-When logging a request that produced an error, the API Server adds @exception@ and @exception_backtrace@ keys to the JSON log. The latter includes the complete error stack trace as a string, and can be displayed in a more readable form like so:
-
-<pre>
-# grep req-ku5ct9ehw0y71f1c5p79 /var/www/arvados-api/current/log/production.log | jq -r .exception_backtrace
-/var/www/arvados-api/current/app/controllers/arvados/v1/collections_controller.rb:43:in `create'
-/var/lib/gems/ruby/2.3.0/gems/actionpack-5.0.7.2/lib/action_controller/metal/basic_implicit_render.rb:4:in `send_action'
-/var/lib/gems/ruby/2.3.0/gems/actionpack-5.0.7.2/lib/abstract_controller/base.rb:188:in `process_action'
-/var/lib/gems/ruby/2.3.0/gems/actionpack-5.0.7.2/lib/action_controller/metal/rendering.rb:30:in `process_action'
-/var/lib/gems/ruby/2.3.0/gems/actionpack-5.0.7.2/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
-/var/lib/gems/ruby/2.3.0/gems/activesupport-5.0.7.2/lib/active_support/callbacks.rb:126:in `call'
-...
-</pre>
diff --git a/doc/admin/troubleshooting.html.textile.liquid b/doc/admin/troubleshooting.html.textile.liquid
new file mode 120000
index 000000000..88f52eafa
--- /dev/null
+++ b/doc/admin/troubleshooting.html.textile.liquid
@@ -0,0 +1 @@
+logging.html.textile.liquid
\ No newline at end of file
diff --git a/doc/install/cheat_sheet.html.textile.liquid b/doc/admin/user-management-cli.html.textile.liquid
similarity index 100%
copy from doc/install/cheat_sheet.html.textile.liquid
copy to doc/admin/user-management-cli.html.textile.liquid
diff --git a/doc/admin/activation.html.textile.liquid b/doc/admin/user-management.html.textile.liquid
similarity index 98%
copy from doc/admin/activation.html.textile.liquid
copy to doc/admin/user-management.html.textile.liquid
index cce83c70b..e42a40e52 100644
--- a/doc/admin/activation.html.textile.liquid
+++ b/doc/admin/user-management.html.textile.liquid
@@ -38,7 +38,7 @@ h2. User activation
This section describes the different user account states.
-!(full-width){{site.baseurl}}/images/user-account-states.svg!
+!(side){{site.baseurl}}/images/user-account-states.svg!
notextile. <div class="spaced-out">
@@ -53,7 +53,7 @@ If "Users.AutoSetupNewUsersWithVmUUID":config.html is set, the user is given log
# The user is active. User has normal access to the system.
# From steps (1) and (3), an admin user can directly update the @is_active@ flag. This bypasses enforcement that user agreements are signed.
If the user was not yet set up (still in step (1)), it adds the user to the "All users", but bypasses creating default git repository and assigning default VM access.
-# An existing user can have their access revoked using @unsetup@ and "ownership reassigned.":reassign-ownership.html .
+# An existing user can have their access revoked using @unsetup@ and "ownership reassigned":reassign-ownership.html .
Unsetup removes the user from the "All users" group and makes them inactive, preventing them from re-activating themselves.
"Ownership reassignment":reassign-ownership.html moves any objects or permission from the old user to a new user and deletes any credentials for the old user.
diff --git a/doc/api/methods/users.html.textile.liquid b/doc/api/methods/users.html.textile.liquid
index e297b48ac..4c33f2afe 100644
--- a/doc/api/methods/users.html.textile.liquid
+++ b/doc/api/methods/users.html.textile.liquid
@@ -127,7 +127,7 @@ table(table table-bordered table-condensed).
h3. setup
-Set up a user. Adds the user to the "All users" group. Enables the user to invoke @activate at .
+Set up a user. Adds the user to the "All users" group. Enables the user to invoke @activate at . See "user management":{{site.baseurl}}/admin/activation.html for details.
Arguments:
@@ -137,7 +137,7 @@ table(table table-bordered table-condensed).
h3. activate
-Check that a user has is set up and has signed all the user agreements. If so, activate the user. Users can invoke this for themselves. See "user management":{{site.baseurl}}/admin/activation.html#user_agreements for details.
+Check that a user has is set up and has signed all the user agreements. If so, activate the user. Users can invoke this for themselves. See "user agreements":{{site.baseurl}}/admin/activation.html#user_agreements for details.
Arguments:
@@ -147,7 +147,7 @@ table(table table-bordered table-condensed).
h3. unsetup
-Remove the user from the "All users" group and deactivate the user.
+Remove the user from the "All users" group and deactivate the user. See "user management":{{site.baseurl}}/admin/activation.html for details.
Arguments:
diff --git a/doc/css/images.css b/doc/css/images.css
index 73a1119f3..50c59f947 100644
--- a/doc/css/images.css
+++ b/doc/css/images.css
@@ -13,3 +13,8 @@ img.screenshot {
margin-left: 2em;
margin-bottom: 2em;
}
+
+img.side {
+ float: left;
+ width: 50%;
+}
diff --git a/doc/install/cheat_sheet.html.textile.liquid b/doc/install/cheat_sheet.html.textile.liquid
deleted file mode 100644
index 33969ea8f..000000000
--- a/doc/install/cheat_sheet.html.textile.liquid
+++ /dev/null
@@ -1,88 +0,0 @@
----
-layout: default
-navsection: admin
-title: User management at the CLI
-...
-{% comment %}
-Copyright (C) The Arvados Authors. All rights reserved.
-
-SPDX-License-Identifier: CC-BY-SA-3.0
-{% endcomment %}
-
-Initial setup
-
-<pre>
-ARVADOS_API_HOST={{ site.arvados_api_host }}
-ARVADOS_API_TOKEN=1234567890qwertyuiopasdfghjklzxcvbnm1234567890zzzz
-</pre>
-
-In these examples, @x1u39-tpzed-3kz0nwtjehhl0u4@ is the sample user account. Replace with the uuid of the user you wish to manipulate.
-
-See "user management":{{site.baseurl}}/admin/activation.html for an overview of how to use these commands.
-
-h3. Setup a user
-
-This creates a default git repository and VM login. Enables user to self-activate using Workbench.
-
-<pre>
-arv user setup --uuid x1u39-tpzed-3kz0nwtjehhl0u4
-</pre>
-
-h3. Deactivate user
-
-<pre>
-arv user unsetup --uuid x1u39-tpzed-3kz0nwtjehhl0u4
-</pre>
-
-When deactivating a user, you may also want to "reassign ownership of their data":{{site.baseurl}}/admin/reassign-ownership.html .
-
-h3. Directly activate user
-
-<pre>
-arv user update --uuid "x1u39-tpzed-3kz0nwtjehhl0u4" --user '{"is_active":true}'
-</pre>
-
-Note this bypasses user agreements checks, and does not set up the user with a default git repository or VM login.
-
-
-h2. Permissions
-
-h3. VM login
-
-Give @$user_uuid@ permission to log in to @$vm_uuid@ as @$target_username@
-
-<pre>
-user_uuid=xxxxxxxchangeme
-vm_uuid=xxxxxxxchangeme
-target_username=xxxxxxxchangeme
-
-read -rd $'\000' newlink <<EOF; arv link create --link "$newlink"
-{
-"tail_uuid":"$user_uuid",
-"head_uuid":"$vm_uuid",
-"link_class":"permission",
-"name":"can_login",
-"properties":{"username":"$target_username"}
-}
-EOF
-</pre>
-
-h3. Git repository
-
-Give @$user_uuid@ permission to commit to @$repo_uuid@ as @$repo_username@
-
-<pre>
-user_uuid=xxxxxxxchangeme
-repo_uuid=xxxxxxxchangeme
-repo_username=xxxxxxxchangeme
-
-read -rd $'\000' newlink <<EOF; arv link create --link "$newlink"
-{
-"tail_uuid":"$user_uuid",
-"head_uuid":"$repo_uuid",
-"link_class":"permission",
-"name":"can_write",
-"properties":{"username":"$repo_username"}
-}
-EOF
-</pre>
diff --git a/doc/install/cheat_sheet.html.textile.liquid b/doc/install/cheat_sheet.html.textile.liquid
new file mode 120000
index 000000000..7917e28b3
--- /dev/null
+++ b/doc/install/cheat_sheet.html.textile.liquid
@@ -0,0 +1 @@
+../admin/user-management-cli.html.textile.liquid
\ No newline at end of file
diff --git a/lib/config/generated_config.go b/lib/config/generated_config.go
index 68dea169f..cdc89552f 100644
--- a/lib/config/generated_config.go
+++ b/lib/config/generated_config.go
@@ -525,7 +525,7 @@ Clusters:
# The cluster ID to delegate the user database. When set,
# logins on this cluster will be redirected to the login cluster
- # (login cluster must appear in RemoteHosts with Proxy: true)
+ # (login cluster must appear in RemoteClusters with Proxy: true)
LoginCluster: ""
# How long a cached token belonging to a remote cluster will
-----------------------------------------------------------------------
hooks/post-receive
--
More information about the arvados-commits
mailing list