Recovery script in BASH
Hi everyone!
I'm writing a Debian GNU/Linux recovery script. It's primary goal is to fix as much system errors as possible if the system won't boot properly. What I've already included:
However, some questions came up while working on it: First, should it be run from single-user mode (init 1) or from a rescue CD? Second, is there a safe way to run fsck on the root (/) filesystem if the system is in single-user mode? And what other common problems can turn up with a Debian system which can be easily fixed from a script? Thank you for your help in advance. |
It's extremely difficult to anticipate all the problems you can run into. That's, of course, the first thing to consider when developing your recovery script.
Do you have a set of "known problems" you encounter repeatedly? Is that what your bullet point list is? I recommend running it from a rescue CD. You can keep your recovery script directly on it. You can remount / ro (read-only) in single-user mode, and then fsck it. What other common problems? Who knows? To be frank, this is what proper root cause analysis is for. |
Thank you for your answer!
I don't really have a list of "known problems", I'd rather want to make this a script that fixes errors caused by eg. a failed update, user error (for example chmod -R 000 /*), or improper software installation. |
I think your goal is a good one, but it sounds (to me) like what you're really interested in is a DR (disaster recovery) solution. To me, filesystem dumps or images are a better, cleaner approach. You recover from the dump / image, and everything's in precisely the state it was at the time it was taken.
|
Well, anomie I know that backups are the most important parts of the recovery, but they require disk space and attention. One would run my program if all else fails and has no backups, so (s)he could give it a try and see if it recovers the system. I'd like to maximize the chance that it fixes the problem.
|
Quote:
Peace. |
Don't use bash for scripts, esp. not for something like this. Use Bourne Shell (sh).
|
I'd prefer Bourne Shell as well, but BASH has more advanced programming features (loop control, logical statements, switches, case-like statements, etc.).
|
Quote:
|
Quote:
Quote:
|
Quote:
The small delta leaves at best a small window of usefulness, ie. only a very restricted area where bash scripts fit better than either Bourne or Perl/Python/Ruby/etc. Obviously I don't think that this window exists at all, ie. there is no program that couldn't be written better with either Bourne or Perl/Python/Ruby/etc. The difference between Bourne and Bash is difficult to detect. That alone would prohibit use of Bash in any environment where you collaborate with others. My blind guess is that the majority of Bash scripts out there are in fact Bourne scripts with the wrong hashbang, because not even the author knows the difference. In fact, I've had a discussion like this one with a colleague in which he mixed up Bourne and Bash consistently. The knowledge about the Bash delta is also obscure, which aggrevates the previous point. Knowledge about Perl/Python/Ruby/etc. is much more common than knowledge about the Bash delta, and knowledge about pure Bourne is probably even more widespread. In any kind of heterogenous environment (ie. anything but pure Linux environments) Bash scripts are completely out of the question. (Ksh sadly is not, since it is Posix.) While Bash is probably available for most if not all Unixes, the hassle to install clean versions everywhere is just not worth it. BTW, I don't use bash regularly, but the same is true for my favorite, Zsh. (Though a case could be made that Zsh would be less confusing on the name alone.) |
remember, using a (full) backup will allow to restore the full system, using any algorithm to select and save only a small part of the information will restrict you to restore only that part of the system. Any other kind of damage will remain unrecoverable.
|
Quote:
Quote:
I know that BASH doesn't have as many libraries as others and it isn't as powerful, but it fully suits my needs, and it's unnecessary to have loads of unused libs, functions, etc. And one more advantage of BASH: it's found on nearly every Linux box, even the simplest ones. This is not true for Python, Ruby or Pearl. |
Quote:
My point was that there is a huge number of simple scripts hashbanging Bash although they would run just as well in Bourne. Remember that this is only an argument about the confusion, ie. people are not even clear about the difference. Quote:
What I call the Bash Delta is also not necessarily about simple differences in syntax. If it can easily be translated from Bash to Bourne, then it's not part of that Bash Delta. That is not a trick, I'm just describing how to go about without Bash. Quote:
No, Bash is just not as powerful as the other languages are. Stuff like inline regexes, OOP, reflection etc. are missing in Bash. Perl's hash structures alone would let me pick it over Bash every time. Sure, these features may not be required for simple things, but my argument is that you can do most of these simple things in Bourne anyway. If it gets more complicated, you shouldn't pick something that carries you only a couple of baby steps ahead. Quote:
Quote:
On the other hand, the most common Linux shell might very well be Busybox, which runs Bourne, but not Bash. By using Bash, you give away too much while gaining little. |
Hmm , sounds like you surely will cause more problems than can fix !
sometimes recovery scripts worth busting brain for , sometimes not.... if running server with alot of aliases, users , ISP config3 , cpanel , it simply aint worth ! best of it in my experience was to make daily snapshots using dd or mdadm raid in small sizes,, like / partition to have a decent 5 GB , /boot like 50 Megs and /var is the main problem , it is the place where using dd will result in copying alot of useless zeroes ! Another bad but good idea is to mount /var folders into separate folders like logs , www, mail , etc, into another small spaces to make dd faster and more useful , but it could run off available space quickly ! Repairing can consume time , it is nerve wrecking , and except servers , just for desktop PC it is simply not worth ! My desktop has a small SSD 60 gb drive , just clone it to some iso file onto a second 1 TB drive , and this is it , on weekly or monthly bases it is enough !any time can restore it using live cd ! i can show ya my server back-up script comprising main server , back up -server and client side , it is working great but in recovery terms it is a damn pain into the arse ! when sh..t happens it requires lot of work to restore ! |
All times are GMT -5. The time now is 10:28 AM. |