• Content count

  • Joined

  • Last visited

Community Reputation

19 Good

About Hoopster

  • Rank
    Advanced Member


  • Gender
  1. No Israel??

    Yeah, guess, I had never realized that. My time zone, when selected from the drop-down, only lists the U.S. and Canada and it defaults to the U.S., so, I had never needed to click on the map to select the correct country. The OP is also correct that if you select Istanbul from the drop-down it says you are in Ukraine until you bring up the map and click on Turkey. I suppose something has to be the default with many countries in a given time zone (like you Europeans and your "tiny" countries ). However, selecting Istanbul, one would assume, should default to Turkey. As to what is the default for Jerusalem, that default selection does seem a bit odd given that most would say Jerusalem is in Israel rather than Palestinian Territory, but, I'll stay out of the geo-political fray.
  2. No Israel??

    Actually, I am from the U.S. I was just trying to reproduce the OP's "error." If you select Jerusalem from the drop-down, you get the default of Palestinian Territory. It is only when you bring up the map and click on Israel that it changes to Israel. Yes, I know where it is I just had not clicked on it.
  3. No Israel??

    I see the same thing as the OP - To my knowledge, no special plugin is installed. Edit: Oops, yes, I have the Dynamix Date/Time plugin installed. I've had it installed for a while and forgot the map comes from the plugin. To me it just became "base" unRAID.
  4. I also upgraded from 6.3.5 without removing any plugins. Preclear, Unassigned Devices, S3 Sleep (disabled and not in use prior to upgrade) etc. were installed and caused me no upgrade issues. They continue to work without problems on 6.4.0. The plugins were all updated to the latest prior to the upgrade. Obviously, it is not mandatory for everyone that they be removed prior to upgrading, but, that may be necessary is some cases. There appear to be several variables at play here.
  5. unRAID OS version 6.4.0 Stable Release Available

    I can confirm the same issue with 6.3.5 and prior. Every time i exited a VM, a manual browser refresh was required to see if it had really stopped. Starting or forcing a VM stop refreshes the status. I always found this inconsistency a bit odd, but, it was not introduced in 6.4.0. It's been there a while.
  6. I followed these instructions to the letter on my main and backup servers. After running the indicated commands, modifying the go file and executing these commands on each server, moving files between the two servers is now possible without a password prompt. After rebooting my backup server, all the appropriate SSH files persist and the backup from main to backup server runs without a password prompt. Success! Thanks to @ken-ji and @tr0910 for this information. Combining Ken-Ji's instructions above and the intermediate tests in the original post and tr0910's sample script, automating rsync backup via ssh works great. Now it's on to refining my backup script and automating it via the User Scripts plugin. The unRAID community, as always, comes through again.
  7. @ken-ji The above was added to the original post based on a comment you made regarding permissions. I see that after following your instructions, there are three files in .ssh. authorized_keys has 600 permission, yet you indicated it should have 644 permissions.; id_rsa has 700 permissions, yet you indicated the key file should have 600 permissions; known_hosts is also in .ssh with 600 permissions. This is what is see in .ssh: -rw------- authorized_keys -rwx------ id_rsa -rw------- known_hosts rsync in both directions without password is working now (I have yet to reboot either server) with the above permissions. The inclusion of chmod g-rwx,o-rwx -R /root/.ssh in the go file would seem to indicate that all files in .ssh should have rwx permissions for group and other users, but, it appears that is not being set. Only owner permissions are set. If specific file permissions are important, I just want to make sure the proper permissions are being set. I apologize for all the replies/questions; however, in case others want to go down the rsync backup path, I want to make sure that the correct information is in this thread. I thank you and @tr0910 for all your great work to get this properly documented.
  8. Thanks for this. These are very clear instructions. I followed them on both servers and I am able to rsync in either direction between servers without a password prompt. Of course, when repeating the instructions on server two "server1" info is replaced with "server2" info and vice versa. I think most people will figure that out if I did These instructions work perfectly! I have not yet rebooted either server as I have an additional question related to your follow-up post below. "Server1" in my case is named "medianas" and "Server2" is called "backupnas." When I generated the ssh keys on each server I named them "medianas_key" and "backupnas_key." Even though these keys are being copied to the file id_rsa in the go file (as per your instructions) and "id_rsa" is the key file referenced in my rsync commands, are you saying that since the keys generated by ssh-keygen are not named "id_rsa" that I need to take the additional steps you mentioned, or, is everything OK since "id_rsa" is the file being created in /root/.ssh by the go file commands? I am assuming that since the generated keys (even though they are not called id_rsa) are being copied to "id_rsa" in /root/.ssh that this will work without creating /root/.ssh/config and specifying the identity files. Is this correct?
  9. Obviously, I am still trying to wrap my head around SSH and public/private keys and how they work. Thanks for your patience as I learn. There is no file named id_rsa in the /boot/config/ssh folder on either server. These files exist in /boot/config/ssh folder on both servers: ssh_host_rsa_key ssh_host_rsa_key.pub is it one (or both) of these files that need to be copied to /root/.ssh by a go file entry as in your example? EDIT: OK, reading this again, is "id_rsa" a placeholder for "whatever file name I created" in the ssh-keygen step in the OP? If so, I generated a file called "MediaNAS-rsync-key. Is it this file that should be copied to /root/.ssh? Are you saying that I need to maintain a copy of "Name of my id_rsa file" in the /root/.ssh/config folder (and that his folder must be created on every reboot?)
  10. Thanks I will give this a try later tonight when I return home. I appreciate the suggestion and will report the results.
  11. Resurrecting this topic since I never completely automated my rsync project between servers and now wish to do so. Everything I did manually worked and I assumed there would be no issues; bad assumption! I have changed motherboards in my "remote" server and it now has IPMI capabilities, so, my script now closely resembles the script developed by the OP. Both servers are still on the same local network as I am not moving the backup server off site until I can get the process fully automated locally. My problem is the same stated by Skulker. After rebooting the "remote" server, ssh will not work to the remote server without a password. - I am not using the SSH Config plugin - may do so when everything is working before adding another variable - both unRAID servers are running 6.4.0 stable release. - Everything works as expected until the remote server is rebooted. I do not want this server running constantly. I power it on once a week via IPMI to receive backup files from the main server and then power it off via IPMI when done. I have verified that the permissions are correct as per the updates in the original post . I had to add a "mkdir /root/.ssh" line to my go file before copying the files from /boot/config/sshroot to /root/.ssh. Without this, the server was inaccessible. I could ping it but that was it; no GUI, no PuTTY. I had to modify the go file on the flash drive with my laptop and reboot the remote server via IPMI My go file on the "remote" server contains the following and the server reboots properly: # Copy files back to /root/.ssh folder and set permissions for files mkdir /root/.ssh cd /root/.ssh cp /boot/config/sshroot/* /root/.ssh/ chmod 600 MediaNAS-rsync-key.pub chmod 644 authorized_keys After reboot, the .ssh folder is recreated, the files are copied correctly and with the correct permissions; however, no ssh operations from "local" to "remote" server work without prompting for root password. If I delete the .ssh folders on both servers and redo all steps as outlined in the original post, ssh without password works again, but, after a reboot, I am back to square one. Since the automated script will involve powering the remote server on and off (reboot) via IPMI this is a huge problem. The files survive the reboot, the ability to ssh without a password does not. Any ideas?
  12. unRAID OS version 6.4.0 Stable Release Available

    That's the array disk usage indicator. It should have a percentage used number in the gray area. Mine shows 31% under the green bar. Check your display settings and try toggling the "show array utilization indicator" setting to see if it changes.
  13. unRAID OS version 6.4.0 Stable Release Available

    Unassigned Devices is working perfectly for me. I have an SSD mounted via UD which hosts two VMs and they are working fine. UD still shows on the main page, same as always, for me I don't know what the solution to your issue may be, but, I don't see either of your problems with UD.
  14. unRAID OS version 6.4.0 Stable Release Available

    I have all of those plugins (other than server layout) running without issue on my two servers both of which were upgraded today to 6.4.0. Unless there is an issue with the server layout plugin, I don't think plugins is the source of your problem. My backup server had been running all the RCs as well with lots of plugins without issue.
  15. Container for No-IP dynamic DNS updates

    Hmm, well it appears that this docker is likely working, but, it does not do what I hoped it would do. I just read this on the docker hub page for this docker: "This is a simple Docker container for running the No-IP2 dynamic DNS update script. It will keep your domain.ddns.net DNS alias up-to-date as your home IP changes. " Apparently, it is only looking to see if the the router reports an IP address change. If I understand this correctly, Instead of forcing an update to the dynamic IP address registered with No-IP.com at the set interval (whether or not IP address has changed), it is only checking to see if it has changed and only updating if it detects a change. It would be better if it could compare the IP address the router is reporting with the IP address registered with No-IP for the specified domain and do an update if they do not match rather than simply checking to see if the router reports an IP address change. I am not sure whether that 2-way communication is possible through the No-IP2 script. In my case, if the above is correct, due to another router to which I no longer have access also configured to update the same domain name, I have no way through this docker of overriding the changes made by that router. It looks like I will have to register a different ddns domain and uninstall the No-IP docker as its functionality is no different than what the UnifI docker already allows me to do as far as updating dynamic DNS IP address changes on the USG router. If your router does not manage No-IP dynamic DNS, then this docker should work for you.

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.