hasown

Members
  • Posts

    15
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hasown's Achievements

Newbie

Newbie (1/14)

7

Reputation

  1. I've installed and rebooted but all I get is the following when I try running "docker compose" or "docker-compose": docker: 'compose' is not a docker command. I see this when I run "docker" [...] Management Commands: builder Manage builds compose* Docker Compose (Docker Inc., v2.0.1) config Manage Docker configs container Manage containers context Manage contexts [...] EDIT: Nevermind, got it working. I'd earlier manually created the cli-plugins folder in my ~/.docker in an attempt to install Compose v2 manually, and it seemed to cause some issues. Deleted it and everything works now.
  2. FYI, the current version of Docker Compose supports both v2 and v3. The recommended way to write compose files is to omit the "version" tag at the top entirely. Compose will then read the yml and interpret all v2 and v3 features.
  3. Thanks. I wish unraid allowed user installation of docker plugins but this will do for now.
  4. Docker Compose v2 is now primarily a plugin for docker instead of a standalone application. The directions on compose's github are as follows: How would I do this in unraid? None of these locations exist in unraid. I see a "plugins" folder in my docker folder but putting docker-compose there and then chmod +x does nothing (I also tried the "plugins/storage" folder and the "plugins/storage/ingest" folder). I also tried creating the "cli-plugins" folder in $HOME/.docker (which is linked to /boot/config/plugins/dockerMan/), but that didn't work either.
  5. I'm trying to set up a registry proxy for the docker daemon. According to the instructions here, it is normally set using a systemd file. I have found that in unraid, simply setting the environment variables in a shell window and then using '/etc/rc.d/rc.docker restart' will properly get docker using the registry proxy. My question is: How can I set the environment variables globally on boot so that the docker daemon recognizes them upon startup? Setting the variables in my go file or in profile.sh does not work. After a reboot, the variable is set (from profile.sh only), but docker doesn't use it until I manually restart it from the command line. EDIT: For anyone else who ever wants to do this, I figured it out. There's a file on the flash drive at /boot/config/docker.cfg. Add the below lines to that file and your docker daemon will use a proxy. export HTTP_PROXY="http://proxy.example.com" export HTTPS_PROXY="https://proxy.example.com"
  6. Good to know. Regardless though, hopefully the code in this thread can eventually imitate the normal webui spinup instead of the emergency spinup.
  7. Oh I understand that it's a dangerous way to spec a server; I would never do it myself. But I think the webui staggers it exactly to avoid this scenario out of an abundance of caution, so that's why I started posting in the thread. But thank you for the bash code as is and any future improvements.
  8. That's my concern. To give some more solid numbers: when all my disks are spun down and I press the spinup button in the webui, my UPS slowly increases output from ~300w to ~420w over about 2-3 minutes. The disks stagger the spinup and the power draw is gradual. If I use the bash code, my UPS immediately jumps to ~700w because 24 hard disks are spinning up at once. Then the power decreases to the normal draw of ~420w. My UPS and PSU can handle a 700w draw, but I think this code might be dangerous in its current state for people who don't have that extra power capacity in their servers.
  9. I have no experience in this, but inspecting the code in the webui for the spinup button shows the following onclick event. So at the very least it appears to me that the button is limiting the spinup to the array? The bash in this thread doesn't do that. And again, the webui button staggers the spinups, versus the bash in this thread which does it all at once. It's very noticeable if you have more than a few disks; you could easily reproduce it yourself, I would think, just by pressing the webui button and watching the disk states, and then spinning down the disks and trying the same thing with the script. function onclick(event) { toggle_state('Device', 'array*', 'up') }
  10. It's not. The webui spins up disks one at a time. The above bash code spins them all up at the same time. I can see the difference in power draw on my UPS, and the noise from the server is noticeably different as well. And as mentioned above, it also spins up my Unassigned Devices drives, which the normal webui spinup doesn't.
  11. So I gave this a whirl in my profile.sh, and it works. But it spins up all 22 disks in my array and also the 2 Unassigned Devices disks I have, all at the same time. Unraid via the webui does a staggered spinup of 1 disk at a time. Is spinning up all 24 disks in my chassis at the same time safe? If not, is there a way to imitate the webui spinup?
  12. Keeping it but otherwise classifying it as abandonware is what the concerns are about.
  13. I would rather automate backups to a local network share rather than unraid.net. I doubt I'll even install the unraid.net plugin as I already have remote access set up to my satisfaction. Disappointed to hear that this plugin's auto-backup for flash will be deprecated in favor of a cloud solution.
  14. Just wanted to say thanks for the script; I used it on unRAID 6.9.0-beta35 and successfully swapped a keyfile. Was sweating a bit the first time I brought the array down and back up, but it went perfectly. Did all 15 data disks, 2 cache pool disks, and 2 nvme pool disks.
  15. I used the tarball method shared by beckp and it works in 6.9.0 beta 35. Simply one line in the go file and one tarball stored on the flash drive, and now my unRAID dynamically pulls the encryption key off of a local server when needed.