I found it here.
It makes sense but since it seems to be exec'ing every command as a new process, it makes me wonder if something might function strangely.
I found it here.
It makes sense but since it seems to be exec'ing every command as a new process, it makes me wonder if something might function strangely.
I'll try which is the easiest way. At least now I have several alternatives.
You could also pipe the output of the functions at the end of the script in the case statement to a log file. That would take very little work.
I finally used that method. The operation is simple and safe. And, as you said, it required very few changes, a single line. Although I also added a log for the backup function. I didn't even try the alternative of using the exec command. Now omv-regen provides the log with the last output of a regeneration or a backup.
Thanks!!
I finally used that method. The operation is simple and safe. And, as you said, it required very few changes, a single line. Although I also added a log for the backup function. I didn't even try the alternative of using the exec command. Now omv-regen provides the log with the last output of a regeneration or a backup.
I recommend including stderr (2>&1 before the pipe) to the log file.
I recommend including stderr (2>&1 before the pipe) to the log file.
I understood that tee will also log errors when writing to the file.
I understood that tee will also log errors when writing to the file.
Tee logs anything sent to it. Since the pipe is only sending stdout to it, it will not log errors. So, you need to send stderr to stdout for the pipe to send it to tee.
EjecutarRegenera 2>&1 | tee /var/log/omv-regen.log
Thank you. I've still improved it a little more. I have configured the pipeline so that it does not delete old logs and I have configured logrotate for a period of 4 weeks. I think there is a good log now.
Great work with omv-regen! I really admire your hard work.
I just wonder, why it requires to have exactly the same disks set instead of just the same file system with particular UUID. I tried to disable it, but I do not speak Spanish and it was hard for me go understand the script. I tried to comment few lines in "if" at around 1074-1078 line, but failed. It would be great to be able migrate config to another system, or prepare system with omv-regen but without data drives and swap os disk to minimalize downtime.
Great work with omv-regen! I really admire your hard work.
Thank you!
I just wonder, why it requires to have exactly the same disks set instead of just the same file system with particular UUID. I tried to disable it, but I do not speak Spanish and it was hard for me go understand the script. I tried to comment few lines in "if" at around 1069-1073 line, but failed.
Well, I simply needed some kind of check to ensure the filesystems are online and prevent errors during regeneration. I thought that was a valid way to do it. I might re-study it and try changing that to check filesystems and UUIDs instead of disks. But I think that might create conflicts if there are settings in the SMART tab, I'm not sure right now, I'd have to look into it. That was probably the reason for doing it this way, I don't remember.
If you want to disable that control you can do this. Add a line between 1078 and 1079 with ValRegDiscos="" That will make the data disk check always positive.
Regarding the Spanish language, I assume you are referring to the comments in the code. I can add the translation for easier understanding if you think that helps. The rest are variable names, the texts that are printed in the shell or dialog are always in Spanish and English.
It would be great to be able migrate config to another system, or prepare system with omv-regen but without data drives and swap os disk to minimalize downtime.
That's an interesting idea. It could open the doors to other ways of using omv-regen. I have to think about this more carefully.
chente Thank you for writing that script, I didn't realize you were the author. It truly worked great, and saved me a lot of work. A log would be awesome, and in a way, I do see it as a form of backing up the system, to restore it in the event of failure. Installing OMV is easy enough, and then running regenera to restore users, shares, is simple enough. The real beauty, is it can 'backup' the settings while OMV runs, and doesn't need to shut it down. Also the fact that it can be scripted and automated. I plan on setting that up in my system. Thank you again!
A log would be awesome
Logging was added three days ago.
I do not speak Spanish and it was hard for me go understand the script
I just added translations to all the code comments, I hope that helps you understand how it works. The names of functions and variables will remain in Spanish, sorry, make an effort like I do when I read code in English
I haven't created a new version for this. If you want to update your script simply delete it and reinstall it. The settings will be maintained:
sudo rm /usr/sbin/omv-regen
sudo wget -O - https://raw.githubusercontent.com/xhente/omv-regen/master/omv-regen.sh | sudo bash
The names of functions and variables will remain in Spanish, sorry, make an effort like I do when I read code in English
You need to make the script shorter so I can paste the whole thing in google translate
You need to make the script shorter so I can paste the whole thing in google translate
My browser automatically translates everything it sees with the push of a button. I use it continually. Also works on github pages. In the case of reading code it is uncomfortable because some things you want to translate and others you don't. So, button up, button down
My browser automatically translates everything it sees with the push of a button. I use it continually. Also works on github pages. In the case of reading code it is uncomfortable because some things you want to translate and others you don't. So, button up, button down
I was just kidding : ) That said, I did actually look at ways to translate locally in the scripts plugin when I added the download from url option.
Actually it would be good for me to shorten the script. Shellcheck has been crying for a long time every time I try to check
omv-regen now accepts encrypted hard drives during regeneration.
Hi chente,
first of all: A huge respect to your job! Your script is awesome! But I have a problem to use it. My all data is on ZFS pool so the first thing I have to do on freshly installation of OMV is installation of PXE kernel and ZFS plugin. Is this blocking condition to run restore? Because I get two warnings if I run omv-regen regenera. The first is no all disks are connected (but actually they are - what's more - all numbers are correct) but as I have understood this is only warning and it is not a blocker. The second one is I don't have a fresh system. Which is true but I have to install new kernel and ZFS to mount old data. Is there a solution for this situation?
My all data is on ZFS pool so the first thing I have to do on freshly installation of OMV is installation of PXE kernel and ZFS plugin. Is this blocking condition to run restore?
You shouldn't worry about that, when you run the regeneration select the option to install a proxmox kernel. omv-regen will install the same proxmox kernel that was installed on the original system. After that omv-regen will install the ZFS plugin and mount the filesystems including the ZFS pool. Simply follow the prompts, run the regeneration on a clean system and omv-regen will set everything up as it was. You will not be able to run the regeneration if it is not on a clean system.
Regarding existing hard drives, it is effectively just a warning. If you are sure that all data hard drives in the original system are connected, continue ahead.
Hi chente,
long story short: regeneration has successfully finished.
Long story: After fresh install the script started fine, downloaded a lot of data and then finished with no any notification. Just finished. OK, I did a restart and started it again. Started phase 2. But at this point started also little problems. My backup is couple of days old and this was the reason why stopped. Different version of openmediavault-zfs plugin was the reason to be correct. OK so far. I understand the intention to stop in case of critical plugin has different version (6.0.12 vs. 6.0.14 in my case). The script stopped and this is in my humble opinion bad behavior. Much better would be to check plugin versions at the beginning. But anyway... I decided to go to risk: I rewrite version number in ORB_DpkgOMV file to fool your program a bit. Started it again and all finished OK. But one thing was strange: Proxmox kernel did not download and ZFS plugin works fine with the stock one. The Proxmox kernel was the version 5.4.
Don’t have an account yet? Register yourself now and be a part of our community!