Versionup 4 -> 5[edit]
pip install -U jupyterlab
pip install -U jupyter
pip install -U jupyter_client
pip install -U jupyter_core
pip install -U jupyter-events
pip install -U jupyter-lsp
pip install -U jupyter-console
pip install -U jupyter_server
pip install -U jupyter_server_terminals
pip install -U jupyterlab-language-pack-ja-JP
pip install -U jupyterlab-widgets
pip install -U jupyter-telemetry
pip install -U jupyterhub-ltiauthenticator
pip install -U dockerspawner
pip install -U notebook
npm install -g configurable-http-proxy
v5用設定ファイルの追加・修正部分[edit]
860 ## Hook for constructing subdomains for users and services. Only used when
861 # `JupyterHub.subdomain_host` is set.
862 #
863 # There are two predefined hooks, which can be selected by name:
864 #
865 # - 'legacy' (deprecated) - 'idna' (default, more robust. No change for _most_
866 # usernames)
867 #
868 # Otherwise, should be a function which must not be async. A custom
869 # subdomain_hook should have the signature:
870 #
871 # def subdomain_hook(name, domain, kind) -> str:
872 # ...
873 #
874 # and should return a unique, valid domain name for all usernames.
875 #
876 # - `name` is the original name, which may need escaping to be safe as a domain
877 # name label - `domain` is the domain of the Hub itself - `kind` will be one of
878 # 'user' or 'service'
879 #
880 # JupyterHub itself puts very little limit on usernames to accommodate a wide
881 # variety of Authenticators, but your identity provider is likely much more
882 # strict, allowing you to make assumptions about the name.
883 #
884 # The 'idna' hook should produce a valid domain name for any user, using IDNA
885 # encoding for unicode usernames, and a truncate-and-hash approach for any
886 # usernames that can't be easily encoded into a domain component.
887 #
888 # .. versionadded:: 5.0
889 # Default: 'idna'
890 # c.JupyterHub.subdomain_hook = 'idna'
1070 ## Allow every user who can successfully authenticate to access JupyterHub.
1071 #
1072 # False by default, which means for most Authenticators, _some_ allow-related
1073 # configuration is required to allow users to log in.
1074 #
1075 # Authenticator subclasses may override the default with e.g.::
1076 #
1077 # @default("allow_all")
1078 # def _default_allow_all(self):
1079 # # if _any_ auth config (depends on the Authenticator)
1080 # if self.allowed_users or self.allowed_groups or self.allow_existing_users:
1081 # return False
1082 # else:
1083 # return True
1084 #
1085 # .. versionadded:: 5.0
1086 #
1087 # .. versionchanged:: 5.0
1088 # Prior to 5.0, `allow_all` wasn't defined on its own,
1089 # and was instead implicitly True when no allow config was provided,
1090 # i.e. `allowed_users` unspecified or empty on the base Authenticator class.
1091 #
1092 # To preserve pre-5.0 behavior,
1093 # set `allow_all = True` if you have no other allow configuration.
1094 # Default: False
1095 # c.Authenticator.allow_all = False
1096
1097 ## Allow existing users to login.
1098 #
1099 # Defaults to True if `allowed_users` is set for historical reasons, and False
1100 # otherwise.
1101 #
1102 # With this enabled, all users present in the JupyterHub database are allowed to
1103 # login. This has the effect of any user who has _previously_ been allowed to
1104 # login via any means will continue to be allowed until the user is deleted via
1105 # the /hub/admin page or REST API.
1106 #
1107 # .. warning::
1108 #
1109 # Before enabling this you should review the existing users in the
1110 # JupyterHub admin panel at `/hub/admin`. You may find users existing
1111 # there because they have previously been declared in config such as
1112 # `allowed_users` or allowed to sign in.
1113 #
1114 # .. warning::
1115 #
1116 # When this is enabled and you wish to remove access for one or more
1117 # users previously allowed, you must make sure that they
1118 # are removed from the jupyterhub database. This can be tricky to do
1119 # if you stop allowing an externally managed group of users for example.
1120 #
1121 # With this enabled, JupyterHub admin users can visit `/hub/admin` or use
1122 # JupyterHub's REST API to add and remove users to manage who can login.
1123 #
1124 # .. versionadded:: 5.0
1125 # Default: False
1126 # c.Authenticator.allow_existing_users = False</pre>
1144 ## Is there any allow config?
1145 #
1146 # Used to show a warning if it looks like nobody can access the Hub,
1147 # which can happen when upgrading to JupyterHub 5,
1148 # now that `allow_all` defaults to False.
1149 #
1150 # Deployments can set this explicitly to True to suppress
1151 # the "No allow config found" warning.
1152 #
1153 # Will be True if any config tagged with `.tag(allow_config=True)`
1154 # or starts with `allow` is truthy.
1155 #
1156 # .. versionadded:: 5.0
1157 # Default: False
1158 # c.Authenticator.any_allow_config = False
1264 ## Let authenticator manage roles
1265 #
1266 # If True, Authenticator.authenticate and/or .refresh_user
1267 # may return a list of roles in the 'roles' field,
1268 # which will be added to the database.
1269 #
1270 # When enabled, all role management will be handled by the
1271 # authenticator; in particular, assignment of roles via
1272 # `JupyterHub.load_roles` traitlet will not be possible.
1273 #
1274 # .. versionadded:: 5.0
1275 # Default: False
1276 # c.Authenticator.manage_roles = False
1277
1278 ## The prompt string for the extra OTP (One Time Password) field.
1279 #
1280 # .. versionadded:: 5.0
1281 # Default: 'OTP:'
1282 # c.Authenticator.otp_prompt = 'OTP:'
1331 ## Prompt for OTP (One Time Password) in the login form.
1332 #
1333 # .. versionadded:: 5.0
1334 # Default: False
1335 # c.Authenticator.request_otp = False
1336
1337 ## Reset managed roles to result of `load_managed_roles()` on startup.
1338 #
1339 # If True:
1340 # - stale managed roles will be removed,
1341 # - stale assignments to managed roles will be removed.
1342 #
1343 # Any role not present in `load_managed_roles()` will be considered
1344 # 'stale'.
1345 #
1346 # The 'stale' status for role assignments is also determined from
1347 # `load_managed_roles()` result:
1348 #
1349 # - user role assignments status will depend on whether the `users` key
1350 # is defined or not:
1351 #
1352 # * if a list is defined under the `users` key and the user is not listed, then the user role assignment will be considered 'stale',
1353 # * if the `users` key is not provided, the user role assignment will be preserved;
1354 # - service and group role assignments will be considered 'stale':
1355 #
1356 # * if not included in the `services` and `groups` list,
1357 # * if the `services` and `groups` keys are not provided.
1358 #
1359 # .. versionadded:: 5.0
1360 # Default: False
1361 # c.Authenticator.reset_managed_roles_on_startup = False
1727 ## Allow login from all users in these UNIX groups.
1728 #
1729 # .. versionchanged:: 5.0
1730 # `allowed_groups` may be specified together with allowed_users,
1731 # to grant access by group OR name.
1732 # Default: set()
1733 # c.LocalAuthenticator.allowed_groups = set()
7136 #------------------------------------------------------------------------------
7137 # DummyAuthenticator(Authenticator) configuration
7138 #------------------------------------------------------------------------------
7139 ## Dummy Authenticator for testing
7140 #
7141 # By default, any username + password is allowed
7142 # If a non-empty password is set, any username will be allowed
7143 # if it logs in with that password.
7144 #
7145 # .. versionadded:: 1.0
7146 #
7147 # .. versionadded:: 5.0
7148 # `allow_all` defaults to True,
7149 # preserving default behavior.
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
