jupyterhub / the-littlest-jupyterhub

Simple JupyterHub distribution for 1-100 users on a single server
https://tljh.jupyter.org
BSD 3-Clause "New" or "Revised" License
1.01k stars 341 forks source link

TLJH Bootstrap depends on umask set to 022 for successful install #946

Open crutchfield opened 9 months ago

crutchfield commented 9 months ago

Bug description

On a fresh install of tljh the server will not start for the admin (first user).

How to reproduce

  1. Install tljh on Ubuntu 22.04
  2. Sign into JupyterHub as administrator
  3. See server will not start

Expected behaviour

Expected server to start for user.

Actual behaviour

Attempt to launch server times out.

Your personal set up

the-littlest-jupyterhub

Full environment ``` # paste output of `pip freeze` or `conda list` here ```
Configuration ```python # jupyterhub_config.py """ JupyterHub config for the littlest jupyterhub. """ import os from glob import glob from tljh import configurer from tljh.config import CONFIG_DIR, INSTALL_PREFIX, USER_ENV_PREFIX from tljh.user_creating_spawner import UserCreatingSpawner from tljh.utils import get_plugin_manager c = get_config() # noqa c.JupyterHub.spawner_class = UserCreatingSpawner c.JupyterHub.cleanup_servers = False c.JupyterHub.hub_port = 15001 c.TraefikProxy.should_start = False dynamic_conf_file_path = os.path.join(INSTALL_PREFIX, "state", "rules", "rules.toml") c.TraefikFileProviderProxy.dynamic_config_file = dynamic_conf_file_path c.JupyterHub.proxy_class = "traefik_file" c.SystemdSpawner.extra_paths = [os.path.join(USER_ENV_PREFIX, "bin")] c.SystemdSpawner.default_shell = "/bin/bash" c.SystemdSpawner.unit_name_template = "jupyter-{USERNAME}" tljh_config = configurer.load_config() configurer.apply_config(tljh_config, c) pm = get_plugin_manager() pm.hook.tljh_custom_jupyterhub_config(c=c) extra_configs = sorted(glob(os.path.join(CONFIG_DIR, "jupyterhub_config.d", "*.py"))) for ec in extra_configs: load_subconfig(ec) ```
Logs ``` Oct 05 20:15:40 ip-10-90-212-219 systemd[1]: jupyter-xadministrator.service: Failed to load environment files: No such file or directory Oct 05 20:15:40 ip-10-90-212-219 systemd[1]: jupyter-xadministrator.service: Failed to run 'start' task: No such file or directory Oct 05 20:15:40 ip-10-90-212-219 systemd[1]: jupyter-xadministrator.service: Failed with result 'resources'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ The unit jupyter-xadministrator.service has entered the 'failed' state with result 'resources'. Oct 05 20:15:40 ip-10-90-212-219 systemd[1]: Failed to start /opt/tljh/user/bin/jupyterhub-singleuser. ░░ Subject: A start job for unit jupyter-xadministrator.service has failed ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ A start job for unit jupyter-xadministrator.service has finished with a failure. ░░ ░░ The job identifier is 1582 and the job result is failed. ```
welcome[bot] commented 9 months ago

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. welcome You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

SUNKENDREAMS commented 9 months ago

Did you install on your own server or in 'the cloud'?

crutchfield commented 9 months ago

Did you install on your own server or in 'the cloud'?

I installed on an EC2 instance with a Ubuntu 22.04 image.

MridulS commented 9 months ago

Could you look at the logs https://tljh.jupyter.org/en/latest/troubleshooting/logs.html#jupyterhub-logs ? Does that give you any clues?

crutchfield commented 9 months ago

Could you look at the logs https://tljh.jupyter.org/en/latest/troubleshooting/logs.html#jupyterhub-logs ? Does that give you any clues?

It seems to me that permission on the /opt/tljh/user directory is not correct. I am attaching the install log, journal for services, and the transient service for the xadministrator. I am interested in the services extra lines "EnvironmentFile" and "Exec".

journal.jupyterhub.txt traefik.txt xadmin.service.txt xadmin.txt installer.txt

crutchfield commented 9 months ago

I did a fresh install again today using "https://tljh.jupyter.org/bootstrap.py" to install. Again the juypter-singleuser will not spawn a server for any users. I did a chown -R root:jupyterhub-user /opt/tljh and it works (i.e., spawns servers). This is almost certainly not the correct/final solution. But maybe helps identify the root cause.

cmichal2 commented 9 months ago

I think I saw the same thing last week. I think the problem is the umask. In /etc/login.defs, there is:

#UMASK      022
UMASK       027

which I believe is the culprit. I didn't try reinstalling with a umask of 022, but I bet that would fix this problem. Instead, I did;

chmod o+r /opt/tljh/hub/* -R
chmod o+r /opt/tljh/user/* -R
find /opt/tljh/user -type d -exec chmod 755 {} +
find /opt/tljh/hub -type d -exec chmod 755 {} +

Perhaps the installer could explicitly set the umask before it puts files in place?

crutchfield commented 8 months ago

I think I saw the same thing last week. I think the problem is the umask. In /etc/login.defs, there is:

#UMASK        022
UMASK     027

which I believe is the culprit. I didn't try reinstalling with a umask of 022, but I bet that would fix this problem. Instead, I did;

chmod o+r /opt/tljh/hub/* -R
chmod o+r /opt/tljh/user/* -R
find /opt/tljh/user -type d -exec chmod 755 {} +
find /opt/tljh/hub -type d -exec chmod 755 {} +

Perhaps the installer could explicitly set the umask before it puts files in place?

I can verify our umask is 027 in the /etc/login.defs.

crutchfield commented 8 months ago

I am using CIS Ubuntu Linux 22.04 LTS Benchmark - Level 1 version 1.0.0.13 of the OS provided by the Center for Internet Security on an AWS EC2 instance. The umask is 027 by default instead of a common configuration of 022. It appears bootstrap.py depends on the umask to not be the more restrictive 027. I wrapped the bootstrap in a script setting the umask to 022 before calling bootstrap and the install is successful.

For example, `#!/bin/bash

umask 022 /usr/bin/python3 /tmp/bootstrap.py --admin xadministrator`

I suspect a better solution is to modify bootstrap.py to set the umask to 022 since it has a dependency on it to install properly.