LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
LinkBack Search this Thread
Old 01-23-2014, 10:52 AM   #1
psimon
LQ Newbie
 
Registered: Dec 2013
Distribution: Debian Stable
Posts: 18

Rep: Reputation: 2
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:
  • Complete reconfiguration using 'dpkg' (this will hopefully fix messed up permissions)
  • Repair permissions of users' home directories using 'chmod'
  • Clear /tmp, /var/tmp, APT cache, ~/.thums, ~/.thumbnails, KDE cache to free up disk space

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.
 
Old 01-23-2014, 09:01 PM   #2
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, FreeBSD
Posts: 3,925
Blog Entries: 5

Rep: Reputation: Disabled
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.
 
1 members found this post helpful.
Old 01-24-2014, 10:38 AM   #3
psimon
LQ Newbie
 
Registered: Dec 2013
Distribution: Debian Stable
Posts: 18

Original Poster
Rep: Reputation: 2
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.
 
Old 01-24-2014, 11:04 AM   #4
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, FreeBSD
Posts: 3,925
Blog Entries: 5

Rep: Reputation: Disabled
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.
 
2 members found this post helpful.
Old 01-29-2014, 02:29 PM   #5
psimon
LQ Newbie
 
Registered: Dec 2013
Distribution: Debian Stable
Posts: 18

Original Poster
Rep: Reputation: 2
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.
 
Old 01-29-2014, 05:35 PM   #6
Habitual
Senior Member
 
Registered: Jan 2011
Distribution: Slack14_64_Multilib
Posts: 2,725
Blog Entries: 3

Rep: Reputation: 627Reputation: 627Reputation: 627Reputation: 627Reputation: 627Reputation: 627
Quote:
Originally Posted by psimon View Post
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.
Before it gets to "before all else fails", check out http://relax-and-recover.org/

Peace.
 
Old 01-30-2014, 11:33 AM   #7
yooden
Member
 
Registered: Dec 2013
Distribution: Debian Wheezy/Jessie # XFCE
Posts: 52

Rep: Reputation: Disabled
Don't use bash for scripts, esp. not for something like this. Use Bourne Shell (sh).
 
Old 02-08-2014, 09:09 AM   #8
psimon
LQ Newbie
 
Registered: Dec 2013
Distribution: Debian Stable
Posts: 18

Original Poster
Rep: Reputation: 2
I'd prefer Bourne Shell as well, but BASH has more advanced programming features (loop control, logical statements, switches, case-like statements, etc.).
 
Old 02-08-2014, 10:29 AM   #9
yooden
Member
 
Registered: Dec 2013
Distribution: Debian Wheezy/Jessie # XFCE
Posts: 52

Rep: Reputation: Disabled
Quote:
Originally Posted by psimon View Post
I'd prefer Bourne Shell as well, but BASH has more advanced programming features (loop control, logical statements, switches, case-like statements, etc.).
If you need those, pick a real programming language. The difference is small and only few people know about it, so using bash scripts is confusing and errors are likely to happen.
 
Old 02-08-2014, 10:33 PM   #10
Tadaen
Member
 
Registered: Sep 2005
Distribution: Debian Testing / Gnome
Posts: 121

Rep: Reputation: 25
Quote:
Originally Posted by yooden View Post
Don't use bash for scripts, esp. not for something like this. Use Bourne Shell (sh).
Would love to hear the reasoning behind this. I use bash exclusively and have had zero trouble. Only trouble I have had I caused by not knowing enough, syntax errors and such.

Quote:
If you need those, pick a real programming language. The difference is small and only few people know about it, so using bash scripts is confusing and errors are likely to happen.
Not even sure what you mean by this...

Last edited by Tadaen; 02-08-2014 at 10:40 PM.
 
Old 02-10-2014, 02:34 AM   #11
yooden
Member
 
Registered: Dec 2013
Distribution: Debian Wheezy/Jessie # XFCE
Posts: 52

Rep: Reputation: Disabled
Quote:
Originally Posted by Tadaen View Post
Would love to hear the reasoning behind this.
The Bash delta (ie. what you can do with Bash but not with Bourne) is small, much smaller than the Perl/Python/Ruby/etc. delta. I see little point to learn the extension of a glorified batch language when other languages are so much more powerful. The main advantage for Perl/Python/Ruby/etc. is the availability of huge library collections (CPAN: 124,000, PPI: 38,000, Gems: 60,000).

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.)

Last edited by yooden; 02-10-2014 at 02:38 AM.
 
1 members found this post helpful.
Old 02-10-2014, 03:40 AM   #12
pan64
Senior Member
 
Registered: Mar 2012
Location: Hungary
Distribution: debian i686 (solaris)
Posts: 4,000

Rep: Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003Reputation: 1003
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.
 
Old 02-10-2014, 11:16 AM   #13
psimon
LQ Newbie
 
Registered: Dec 2013
Distribution: Debian Stable
Posts: 18

Original Poster
Rep: Reputation: 2
Quote:
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.
Well, I tried to run this exact script with Bourne shell as an interpreter - lot's of errors came up and finally it failed. It included loops, if and case statements. So if sh failed with these - let's say essential - programming expressions, I guess Bourne Shell can only interpret the simplest batch files written in BASH.
Quote:
If you need those, pick a real programming language.
Why isn't BASH a real programming language? It's true that it's a scripting language, but Perl, JavaScript, etc. are scripting ones as well.
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.
 
Old 02-11-2014, 03:19 AM   #14
yooden
Member
 
Registered: Dec 2013
Distribution: Debian Wheezy/Jessie # XFCE
Posts: 52

Rep: Reputation: Disabled
Quote:
Originally Posted by psimon View Post
Well, I tried to run this exact script with Bourne shell as an interpreter - lot's of errors came up and finally it failed. It included loops, if and case statements.
Not sure what you are trying to say. There is of course an infinite number of Bash scripts that will not run in Bourne.

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:
So if sh failed with these - let's say essential - programming expressions, I guess Bourne Shell can only interpret the simplest batch files written in BASH.
You already know that that is wrong, Bourne has loops and ifs of course. Also, what you call essential, I call tomato. Perl does not have a case keyword, Ruby does not have increment operators. I'm sure all the langauges we mention are turing-complete, so in a sense nothing essential is missing in any of them.

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:
Why isn't BASH a real programming language? It's true that it's a scripting language, but Perl, JavaScript, etc. are scripting ones as well.
You mean they are interpreted? I don't see a problem with that, in a comparison a couple of years ago Perl beat C++ in terms of speed for most applications. OTOH, people have put much more brains into speeding up Perl vs. Bash, and I would guess that Bash programmer would exec more often (grep etc.).

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:
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.
This is not necessarily about you. I used to program in C in my spare time (Motif even) for a couple of years, it was fun exactly because it was a puzzle; I still wouldn't pick C to start a new program. If you never use libraries, and won't ever use them in the future, this particular argument does not apply to you, but I still think it applies to Bash in general. In many cases, easy access to RDBMSs alone is reason to pick or drop a language, as is XML handling.

Quote:
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.
Yes, that particular argument does not apply to highly homogenous environment. From my experience in a heterogenous environment, Perl is more common than Bash however. (I was looking out for Bash because I prefer it very much over Bourne or Ksh as an interactive shell.)

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.
 
Old 02-11-2014, 01:48 PM   #15
yo8rxp
Member
 
Registered: Jul 2009
Location: Romania
Distribution: Ubuntu 10.04 Gnome 2
Posts: 53

Rep: Reputation: 13
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 !
 
  


Reply

Tags
bash, debian, recovery, script


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to end the bash script using commands in bash not manually by pressing ctrl+c Sanpreet Singh Linux - Newbie 1 07-03-2013 01:04 PM
[SOLVED] Converting Script from Linux (GNU) Bash 4 to Solaris Bash 2.05 - Any cheat sheet? oly_r Solaris / OpenSolaris 6 05-03-2013 08:25 AM
How to get some bash scripts into a simple bash script with some echo and if statement. y0_gesh Programming 3 03-01-2012 09:46 AM
SSH connection from BASH script stops further BASH script commands tardis1 Linux - Newbie 3 12-06-2010 08:56 AM
[SOLVED] Using a long Bash command including single quotes and pipes in a Bash script antcore Linux - General 9 07-22-2009 11:10 AM


All times are GMT -5. The time now is 06:57 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration