diff --git a/docs/source/getting-started/authenticators-users-basics.md b/docs/source/getting-started/authenticators-users-basics.md index 266ebde2..e5fc9f5c 100644 --- a/docs/source/getting-started/authenticators-users-basics.md +++ b/docs/source/getting-started/authenticators-users-basics.md @@ -22,7 +22,7 @@ Admin users of JupyterHub, `admin_users`, can add and remove users from the user `allowed_users` set. `admin_users` can take actions on other users' behalf, such as stopping and restarting their servers. -A set of initial admin users, `admin_users` can configured be as follows: +A set of initial admin users, `admin_users` can be configured as follows: ```python c.Authenticator.admin_users = {'mal', 'zoe'} @@ -32,9 +32,9 @@ Users in the admin set are automatically added to the user `allowed_users` set, if they are not already present. Each authenticator may have different ways of determining whether a user is an -administrator. By default JupyterHub use the PAMAuthenticator which provide the -`admin_groups` option and can determine administrator status base on a user -groups. For example we can let any users in the `wheel` group be admin: +administrator. By default JupyterHub uses the PAMAuthenticator which provides the +`admin_groups` option and can set administrator status based on a user +group. For example we can let any user in the `wheel` group be admin: ```python c.PAMAuthenticator.admin_groups = {'wheel'} @@ -42,9 +42,9 @@ c.PAMAuthenticator.admin_groups = {'wheel'} ## Give admin access to other users' notebook servers (`admin_access`) -Since the default `JupyterHub.admin_access` setting is False, the admins +Since the default `JupyterHub.admin_access` setting is `False`, the admins do not have permission to log in to the single user notebook servers -owned by _other users_. If `JupyterHub.admin_access` is set to True, +owned by _other users_. If `JupyterHub.admin_access` is set to `True`, then admins have permission to log in _as other users_ on their respective machines, for debugging. **As a courtesy, you should make sure your users know if admin_access is enabled.** @@ -53,8 +53,8 @@ sure your users know if admin_access is enabled.** Users can be added to and removed from the Hub via either the admin panel or the REST API. When a user is **added**, the user will be -automatically added to the allowed users set and database. Restarting the Hub -will not require manually updating the allowed users set in your config file, +automatically added to the `allowed_users` set and database. Restarting the Hub +will not require manually updating the `allowed_users` set in your config file, as the users will be loaded from the database. After starting the Hub once, it is not sufficient to **remove** a user @@ -107,8 +107,8 @@ with any provider, is also available. ## Use DummyAuthenticator for testing -The :class:`~jupyterhub.auth.DummyAuthenticator` is a simple authenticator that -allows for any username/password unless if a global password has been set. If +The `DummyAuthenticator` is a simple authenticator that +allows for any username/password unless a global password has been set. If set, it will allow for any username as long as the correct password is provided. To set a global password, add this to the config file: diff --git a/docs/source/getting-started/config-basics.md b/docs/source/getting-started/config-basics.md index f1438fd7..8b4babe6 100644 --- a/docs/source/getting-started/config-basics.md +++ b/docs/source/getting-started/config-basics.md @@ -44,7 +44,7 @@ jupyterhub -f /etc/jupyterhub/jupyterhub_config.py ``` The IPython documentation provides additional information on the -[config system](http://ipython.readthedocs.io/en/stable/development/config) +[config system](http://ipython.readthedocs.io/en/stable/development/config.html) that Jupyter uses. ## Configure using command line options @@ -63,11 +63,11 @@ would enter: jupyterhub --ip 10.0.1.2 --port 443 --ssl-key my_ssl.key --ssl-cert my_ssl.cert ``` -All configurable options may technically be set on the command-line, +All configurable options may technically be set on the command line, though some are inconvenient to type. To set a particular configuration parameter, `c.Class.trait`, you would use the command line option, `--Class.trait`, when starting JupyterHub. For example, to configure the -`c.Spawner.notebook_dir` trait from the command-line, use the +`c.Spawner.notebook_dir` trait from the command line, use the `--Spawner.notebook_dir` option: ```bash @@ -89,11 +89,11 @@ meant as illustration, are: ## Run the proxy separately This is _not_ strictly necessary, but useful in many cases. If you -use a custom proxy (e.g. Traefik), this also not needed. +use a custom proxy (e.g. Traefik), this is also not needed. Connections to user servers go through the proxy, and _not_ the hub itself. If the proxy stays running when the hub restarts (for -maintenance, re-configuration, etc.), then use connections are not +maintenance, re-configuration, etc.), then user connections are not interrupted. For simplicity, by default the hub starts the proxy automatically, so if the hub restarts, the proxy restarts, and user connections are interrupted. It is easy to run the proxy separately, diff --git a/docs/source/getting-started/faq.md b/docs/source/getting-started/faq.md index e5cd30af..d9b20fe6 100644 --- a/docs/source/getting-started/faq.md +++ b/docs/source/getting-started/faq.md @@ -26,7 +26,7 @@ so Breq would open `/user/breq/notebooks/foo.ipynb` and Seivarden would open `/user/seivarden/notebooks/foo.ipynb`, etc. JupyterHub has a special URL that does exactly this! -It's called `/hub/user-redirect/...` and after the visitor logs in, +It's called `/hub/user-redirect/...`. So if you replace `/user/yourname` in your URL bar with `/hub/user-redirect` any visitor should get the same URL on their own server, rather than visiting yours. diff --git a/docs/source/getting-started/institutional-faq.md b/docs/source/getting-started/institutional-faq.md index c5e88798..d7f1a5dd 100644 --- a/docs/source/getting-started/institutional-faq.md +++ b/docs/source/getting-started/institutional-faq.md @@ -11,7 +11,7 @@ Yes! JupyterHub has been used at-scale for large pools of users, as well as complex and high-performance computing. For example, UC Berkeley uses JupyterHub for its Data Science Education Program courses (serving over 3,000 students). The Pangeo project uses JupyterHub to provide access -to scalable cloud computing with Dask. JupyterHub is stable customizable +to scalable cloud computing with Dask. JupyterHub is stable and customizable to the use-cases of large organizations. ### I keep hearing about Jupyter Notebook, JupyterLab, and now JupyterHub. What’s the difference? @@ -27,14 +27,14 @@ Here is a quick breakdown of these three tools: for other parts of the data science stack. - **JupyterHub** is an application that manages interactive computing sessions for **multiple users**. It also connects them with infrastructure those users wish to access. It can provide - remote access to Jupyter Notebooks and Jupyter Lab for many people. + remote access to Jupyter Notebooks and JupyterLab for many people. ## For management ### Briefly, what problem does JupyterHub solve for us? JupyterHub provides a shared platform for data science and collaboration. -It allows users to utilize familiar data science workflows (such as the scientific python stack, +It allows users to utilize familiar data science workflows (such as the scientific Python stack, the R tidyverse, and Jupyter Notebooks) on institutional infrastructure. It also allows administrators some control over access to resources, security, environments, and authentication. @@ -55,7 +55,7 @@ industry, and government research labs. It is most-commonly used by two kinds of - Large teams (e.g., a department, a large class, or a large group of remote users) to provide access to organizational hardware, data, and analytics environments at scale. -Here are a sample of organizations that use JupyterHub: +Here is a sample of organizations that use JupyterHub: - **Universities and colleges**: UC Berkeley, UC San Diego, Cal Poly SLO, Harvard University, University of Chicago, University of Oslo, University of Sheffield, Université Paris Sud, University of Versailles @@ -99,7 +99,7 @@ that we currently suggest are: guide that runs on Kubernetes. Better for larger or dynamic user groups (50-10,000) or more complex compute/data needs. - [The Littlest JupyterHub](https://tljh.jupyter.org) is a lightweight JupyterHub that runs on a single - single machine (in the cloud or under your desk). Better for smaller usergroups (4-80) or more + single machine (in the cloud or under your desk). Better for smaller user groups (4-80) or more lightweight computational resources. ### Does JupyterHub run well in the cloud? @@ -123,7 +123,7 @@ level for several years, and makes a number of "default" security decisions that users. - For security considerations in the base JupyterHub application, - [see the JupyterHub security page](https://jupyterhub.readthedocs.io/en/stable/reference/websecurity.html) + [see the JupyterHub security page](https://jupyterhub.readthedocs.io/en/stable/reference/websecurity.html). - For security considerations when deploying JupyterHub on Kubernetes, see the [JupyterHub on Kubernetes security page](https://zero-to-jupyterhub.readthedocs.io/en/latest/security.html). @@ -183,7 +183,7 @@ how those resources are controlled is taken care of by the non-JupyterHub applic Yes - JupyterHub can provide access to many kinds of computing infrastructure. Especially when combined with other open-source schedulers such as Dask, you can manage fairly -complex computing infrastructure from the interactive sessions of a JupyterHub. For example +complex computing infrastructures from the interactive sessions of a JupyterHub. For example [see the Dask HPC page](https://docs.dask.org/en/latest/setup/hpc.html). ### How much resources do user sessions take? @@ -192,7 +192,7 @@ This is highly configurable by the administrator. If you wish for your users to data analytics environments for prototyping and light data exploring, you can restrict their memory and CPU based on the resources that you have available. If you'd like your JupyterHub to serve as a gateway to high-performance compute or data resources, you may increase the -resources available on user machines, or connect them with computing infrastructure elsewhere. +resources available on user machines, or connect them with computing infrastructures elsewhere. ### Can I customize the look and feel of a JupyterHub? @@ -217,7 +217,7 @@ your JupyterHub with the various services and tools that you wish to provide to ### How well does JupyterHub scale? What are JupyterHub's limitations? JupyterHub works well at both a small scale (e.g., a single VM or machine) as well as a -high scale (e.g., a scalable Kubernetes cluster). It can be used for teams as small a 2, and +high scale (e.g., a scalable Kubernetes cluster). It can be used for teams as small as 2, and for user bases as large as 10,000. The scalability of JupyterHub largely depends on the infrastructure on which it is deployed. JupyterHub has been designed to be lightweight and flexible, so you can tailor your JupyterHub deployment to your needs. @@ -249,7 +249,7 @@ share their results with one another. JupyterHub also provides a computational framework to share computational narratives between different levels of an organization. For example, data scientists can share Jupyter Notebooks -rendered as [voila dashboards](https://voila.readthedocs.io/en/stable/) with those who are not +rendered as [Voilà dashboards](https://voila.readthedocs.io/en/stable/) with those who are not familiar with programming, or create publicly-available interactive analyses to allow others to interact with your work. diff --git a/docs/source/getting-started/networking-basics.md b/docs/source/getting-started/networking-basics.md index b844afe3..6d4d62d9 100644 --- a/docs/source/getting-started/networking-basics.md +++ b/docs/source/getting-started/networking-basics.md @@ -43,7 +43,7 @@ port. By default, this REST API listens on port 8001 of `localhost` only. The Hub service talks to the proxy via a REST API on a secondary port. The -API URL can be configured separately and override the default settings. +API URL can be configured separately to override the default settings. ### Set api_url @@ -82,13 +82,13 @@ c.JupyterHub.hub_ip = '10.0.1.4' c.JupyterHub.hub_port = 54321 ``` -**Added in 0.8:** The `c.JupyterHub.hub_connect_ip` setting is the ip address or +**Added in 0.8:** The `c.JupyterHub.hub_connect_ip` setting is the IP address or hostname that other services should use to connect to the Hub. A common configuration for, e.g. docker, is: ```python c.JupyterHub.hub_ip = '0.0.0.0' # listen on all interfaces -c.JupyterHub.hub_connect_ip = '10.0.1.4' # ip as seen on the docker network. Can also be a hostname. +c.JupyterHub.hub_connect_ip = '10.0.1.4' # IP as seen on the docker network. Can also be a hostname. ``` ## Adjusting the hub's URL diff --git a/docs/source/getting-started/services-basics.md b/docs/source/getting-started/services-basics.md index 5db9a6cb..ba472fc8 100644 --- a/docs/source/getting-started/services-basics.md +++ b/docs/source/getting-started/services-basics.md @@ -2,7 +2,7 @@ When working with JupyterHub, a **Service** is defined as a process that interacts with the Hub's REST API. A Service may perform a specific -or action or task. For example, shutting down individuals' single user +action or task. For example, shutting down individuals' single user notebook servers that have been idle for some time is a good example of a task that could be automated by a Service. Let's look at how the [jupyterhub_idle_culler][] script can be used as a Service. @@ -114,7 +114,7 @@ interact with it. This will run the idle culler service manually. It can be run as a standalone script anywhere with access to the Hub, and will periodically check for idle servers and shut them down via the Hub's REST API. In order to shutdown the -servers, the token given to cull-idle must have admin privileges. +servers, the token given to `cull-idle` must have admin privileges. Generate an API token and store it in the `JUPYTERHUB_API_TOKEN` environment variable. Run `jupyterhub_idle_culler` manually. diff --git a/docs/source/getting-started/spawners-basics.md b/docs/source/getting-started/spawners-basics.md index c30d89f6..9988c2f8 100644 --- a/docs/source/getting-started/spawners-basics.md +++ b/docs/source/getting-started/spawners-basics.md @@ -1,8 +1,8 @@ # Spawners and single-user notebook servers Since the single-user server is an instance of `jupyter notebook`, an entire separate -multi-process application, there are many aspect of that server can configure, and a lot of ways -to express that configuration. +multi-process application, there are many aspects of that server that can be configured, and a lot +of ways to express that configuration. At the JupyterHub level, you can set some values on the Spawner. The simplest of these is `Spawner.notebook_dir`, which lets you set the root directory for a user's server. This root @@ -14,7 +14,7 @@ expanded to the user's home directory. c.Spawner.notebook_dir = '~/notebooks' ``` -You can also specify extra command-line arguments to the notebook server with: +You can also specify extra command line arguments to the notebook server with: ```python c.Spawner.args = ['--debug', '--profile=PHYS131']