feat: add Project Nomad container and install scripts#1909
Conversation
CrazyWolf13
left a comment
CrazyWolf13
left a comment
There was a problem hiding this comment.
Thanks for your contribution, just looked at this project last week, really interesting!
|
|
||
| # Refresh non-user files from tarball | ||
| cp /opt/nomad/install/management_compose.yaml /opt/project-nomad/compose.yml | ||
| cp /opt/nomad/install/start_nomad.sh /opt/project-nomad/start_nomad.sh 2>/dev/null || true |
There was a problem hiding this comment.
| cp /opt/nomad/install/start_nomad.sh /opt/project-nomad/start_nomad.sh 2>/dev/null || true | |
| cp /opt/nomad/install/start_nomad.sh /opt/project-nomad/start_nomad.sh |
remove this for all occurences
|
|
||
| fetch_and_deploy_gh_release "nomad" "Crosstalk-Solutions/project-nomad" "tarball" | ||
|
|
||
| # Refresh non-user files from tarball |
| fi | ||
|
|
||
| if check_for_gh_release "nomad" "Crosstalk-Solutions/project-nomad"; then | ||
| msg_info "Updating ${APP}" |
There was a problem hiding this comment.
| msg_info "Updating ${APP}" | |
| msg_info "Updating Nomad" |
| msg_info "Installing NVIDIA Container Toolkit" | ||
| curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg 2>/dev/null || true | ||
| curl -fsSL https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list 2>/dev/null \ | ||
| | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \ | ||
| | tee /etc/apt/sources.list.d/nvidia-container-toolkit.list > /dev/null 2>&1 || true | ||
| $STD apt update 2>/dev/null || true | ||
| $STD apt install -y nvidia-container-toolkit 2>/dev/null || true | ||
| if command -v nvidia-ctk &>/dev/null; then | ||
| nvidia-ctk runtime configure --runtime=docker 2>/dev/null || true | ||
| systemctl restart docker 2>/dev/null || true | ||
| fi | ||
| msg_ok "NVIDIA Container Toolkit configured" |
There was a problem hiding this comment.
@MickLesk shouldn't this be part of the initial setup_hwaccel call?
| "interface_port": 80, | ||
| "documentation": "https://www.projectnomad.us/install", | ||
| "website": "https://www.projectnomad.us", | ||
| "logo": "https://raw.githubusercontent.com/Crosstalk-Solutions/project-nomad/main/admin/public/project_nomad_logo.webp", |
There was a problem hiding this comment.
can you use a logo from selfh.st/icons
| $STD docker compose pull | ||
| $STD docker compose up -d --force-recreate |
There was a problem hiding this comment.
No Docker Installs. Only Bare Metal
MickLesk
left a comment
MickLesk
left a comment
There was a problem hiding this comment.
No Docker Installs. Only Bare Metal. If its not possible with this tool -> Tool will not added
The tool is collection of docker containers. Also, docker tools exist on the in the repository, so not clear where the boundary between good and not-good. |
…, use selfhst logo
|
It have an full Dockerfile? I dont see any reason to add docker? The Only Scripts in Our Repo Using Storage are Tools like HomeAssistant or CasaOS/Kasm/Cosmos (which deploy more containers) Or add more information, what the tool deploy and what not. |
|
@MickLesk I see these community-scripts as a convenience mechanism, and same goes for this attempt – I run one script – I got project up and running among all my other projects, installing docker LXC and then setting up Nomad there isn't convenient way. I'm happy to add more information, do you have recommendations on how this information should be provided? Thank you. |
|
I need to agree with @MickLesk here. The philosophie of our scripts is that we cut the second virtualisation layer of Docker for all our scripts, apart from the Docker Container management scripts. So you can rework your script as a Bare Metal install, wich is totally fine. But it will not be added as a docker compose stack. |
|
@michelroegl-brunner thanks for looking into this, and just to better understand, what is the issue with "second virtualization layer"? Also, my understanding was that philosophy of this whole project was to reduce friction for folks entering self-hosting, making self-hosting more accessible, so adding more projects, especially very popular ones (I'm talking about my other attempt at submission – Odyssues) is what makes community scripts – community, and attracts more people to try thing in self hosting. |
|
We currently Maintain over 400 Scripts. The four of us wich a here. All in our spare time. So we might as well decide what we want to add and what not. There is nothing wich speaks against that app per se. Just that zhe philosophiy of our Project has ever been that we do things in a certain way. One of wich is we dont do docker comopse stacks as scripts. It is simple enough to spin up a docker lxc and deploy any compose stack there. It is just one command. As for the other PR. Also these rules exist for a Reason. To many times we did a script for a So feel free to adhere to our standards or, if you wish to, fork our repo and publish the script there and Maintain it. We have a open licence wich allowes that. We do things we maintainers agreed upon, and that will not change for one single app, regardles of who is the creator. We did the same with openclaw or whatever it is called nowadays as well. |
|
@michelroegl-brunner thank you for the response. I'm not asking to reconsider this submission, I understand the reasons. Just more curious in general, do you think expanding maintainers pool would be helpful? Maybe for each new submission there could be assigned maintainers (and some of you guys could be among that "pool of sponsors") and they would look after and maintain scripts they're sponsoring, and if scripts is unmaintained for some time (maybe few months) it gets removed. That way it will be more community effort, and less pressure on just four of you. |
|
We tried that approach. There would be no scripts left sadly. But as i said, if you consider installing the app(s) nativley it might get merged! |
|
@alexindigo More people would definitely help, but so far only few people reached out wanting to join and help us out. We already somewhat do this, user-submitted scripts have an author field, and authors are generally expected to maintain/fix their scripts over time. As micheal already said, such an attempt would probably create much more backlash than actually helping us, we have tried a few times to remove older, less used scripts, which most of the time ended with long dialogues and a lot of negativity spread just for trying to reduce the workload on us. I hope you can consider sorting out a dockerless installation, Project Nomad looked promising to me as well. |
4 participants
✍️ Description
Add Project N.O.M.A.D. — a self-contained offline-first knowledge server with AI chat (Ollama), offline Wikipedia (Kiwix), Khan Academy courses (Kolibri), maps, and more. Runs via Docker Compose.
🔗 Related PR / Issue
Link: #
✅ Prerequisites (X in brackets)
🏗️ arm64 Support (X in brackets)
🛠️ Type of Change (X in brackets)
README,AppName.md,CONTRIBUTING.md, or other docs.🔍 Code & Security Review (X in brackets)
Code_Audit.md&CONTRIBUTING.mdguidelinesAppName.sh,AppName-install.sh,AppName.json)📋 Additional Information (optional)
Nomad uses Docker Compose internally. The install script mirrors upstream install_nomad.sh closely, with substitutions for ProxmoxVED infrastructure (setup_docker, setup_hwaccel). GPU passthrough enabled (NVIDIA only).
📦 Application Requirements (for new scripts)
🌐 Source