Können wir nicht einfach eine Umgebungsvariable einführen, die man in start_jupyter-jsc.sh setzt. Z.B. JUPYTER_JSC_ARGS Dann können wir es ein und ausschalten, wenn wir testen ohne dass es User stört.
In dem Zuge können wir auch JUPYTER_LOG_DIR in JUPYTER_JSC_LOGDIR umgenennen. Ich glaube, dass ein Prefix "JUPYTER_JSC" deutlicher macht, welche Umgebungsvariablen JSC-spezifisch sind. (eventuell sollten wir JUPYTER_LOG_DIR aber aus historischen Gründen noch eine Weile bestehen lassen)
Wir müssen eventuell auf "ICP" für die Kommunikation zwischen JupyterLab und Kernel umstellen: ConnectionFileMixin.transportany of 'tcp'|’ipc’ (case-insensitive)
https://jupyter-notebook.readthedocs.io/en/stable/config.html
jupyter-notebook.readthedocs.io
Config file and command line options — Jupyter Notebook 6.2.0 documentation
Kommunikation geht dann über einen FileSocket der geschützt werden kann. Problem ist, dass dieses Transport-Flag entweder für alle Kernel eingeschaltet ist oder für keinen Kernel. Leider unterstützen nicht alle Kernel "icp". (mit "tcp" kann man im "schlimmsten" Fall einer Kommunikation zwischen Jupyter Notebook Server und Kernel eines anderen Users zuhören - aber keine Befehle absetzen. Die Ports sind ja schon bound und man kann nur noch mit "listen" sich anhängen)
jupyterhub version 1.3.0 != jupyterhub-singleuser version 1.1.0. This could cause failure to authenticate and result in redirect loops!
I think ssh is the best way. SSH needs a key just to login, but not to check if the node is working
Example during production with a fake key:
$ ssh -i .ssh/id_rsa juwels11.fz-juelich.de dalvarez@juwels11.fz-juelich.de: Permission denied (publickey).
Example during maintenance with a fake key:
$ ssh -i .ssh/id_rsa juwels11.fz-juelich.de
_ _ ___ _______ _ ____ *
| | | | \ \ / / ____| | / ___| Juelich Wizard *
*
2020-11-19T14:00+0200
Known issues: https://apps.fz-juelich.de/jsc/hps/juwels/known-issues.html
2021-04-15T18:00+0200
During the next maintenance, the default communication library used by ParaStationMPI will change from verbs to UCX. To enable that changes already please load "mpi-settings/UCX-plain" after loading ParaStationMPI
2021-03-02T08:00+0200
RW access to $DATA is enabled again after incident 2021-01-26
Please validate your data on the recovered file system. The restored data from tape can be found at /p/largedata_restore. Please note that the retrieval is on-going and the accessible data is hence limited. The /p/largedata_restore file system is mounted read-only.
More information is communicated to data project members via e-mail.
+------------------------------------------------------------------------------+ | System is in maintenance. Sorry, not available for production. | +------------------------------------------------------------------------------+ dalvarez@juwels11.fz-juelich.de: Permission denied (publickey).
So using a fake key and a fake user allows you to check that:
the node is reachable
the node is in maintenance (or not)
There is a third case: a node is in production but in a faulty state (eg: GPFS not mounted). That should happen very rarely, and I would not bother with it.
To double check, I would suggest also to cross check the DNS RR, to see if the login you are connecting too, is indeed supposed to be user-reachable:
$ dig +short juwels.fz-juelich.de | xargs -n1 dig +short -x | sed s/'.$'//g | sort juwels02.fz-juelich.de juwels03.fz-juelich.de juwels05.fz-juelich.de juwels06.fz-juelich.de juwels07.fz-juelich.de juwels08.fz-juelich.de
Best, Damian
Mir fällt gerade auf, dass jupyterlab-control ist noch nicht auf JupyterLab 3.x portiert ist.
(das sollte laut Dokumentation mit python -m jupyterlab.upgrade_extension .
funktionierten)
https://jupyterlab.readthedocs.io/en/stable/extension/extension_migration.html
Ich mache gerade Erklärvideos. Dafür habe ich einen neuen Benutzer angelegt und wollten den Jupyter-JSC First-Login aufnehmen. Das ganze hin-und-her hat dazu geführt, dass mir nach dem Klick auf den Confirm-Link in der Email angezeigt wurde, dass der Confirmation-Token ausgelaufen sei und nicht mehr gültig. Trotzdem konnte ich mich dann jedoch bei Jupyter-JSC einloggen ... upps ... da ist noch was faul.
[D 2021-05-31 16:50:33.003 SingleUserNotebookApp pdf:163] bibtex output: ['bibtex', 'notebook']
This is BibTeX, Version 0.99d (TeX Live 2020)
The top-level auxiliary file: notebook.aux
I found no \citation commands---while reading file notebook.aux
I found no \bibdata command---while reading file notebook.aux
I found no \bibstyle command---while reading file notebook.aux
(There were 3 error messages)
[I 2021-05-31 16:50:33.003 SingleUserNotebookApp pdf:190] PDF successfully created
breuer1: /p/scratch/ccstao/unicore-jobs/607c82b4-1d27-4a3e-afa2-ad8e372a983f/stderr
Könnte das gleiche Problem sein, wie wir es schon vom Terminal kennen (NGINX)
Tim Kreuzer (5af9288e) at 28 Mar 11:57
Merge branch 'jupyter-staging' into 'jupyter-production'
... and 1 more commit
Tim Kreuzer (9ec05b0f) at 28 Mar 11:56
remove test login of jusuf + juwels
Tim Kreuzer (9d8e2eee) at 27 Mar 18:47
fix link to jupyter-jsc website
Tim Kreuzer (1170d704) at 27 Mar 18:47
Tim Kreuzer (d8f626a5) at 27 Mar 16:42
update nfs ip