Mondo Rescue: Using the post-nuke script

Quoting from their site

"Mondo Rescue is a GPL disaster recovery solution"

and have been used in several installations we have performed for our customers. One of the useful option is to exclude some directories (for example /var/log) and this means that all files and sub-directories will not be saved into the archive. This is good as it will save a lot of space but not very good to your system trying to write into an non-existent folder (like /var/log/asterisk).
The way to work around this problem is to use the "post-nuke" phase, when the control is transferred to a post-nuke script. If you will try to find some information about this feature the result is very disappointing as it is mentioned briefly only in the mondoarchive man page
-P tarball
Post-nuke tarball. If you boot into Nuke Mode and everything is restored successfully then the post-nuke script will be sought and executed if found. This is useful for post-restore customization. It is assumed that the tarball (.tar.gz format) will contain not just the post-nuke script (or binary, or whatever it is) but also any files it requires.
The way to solve the dilemma is to create (just before running mondoarchive) an archive with the hierarchy for the needed directories (for example for all of the directories you have excluded with -E). The hierarchy is obtain with find command and should provide a safe way to save all your sub-directories (including the symbolic links). The archive is created using tar command, which will save their owner, group and mode bits.
You could find here here an archive with the post-nuke script (to be placed in /root for example) and an example for the backup script.
The work was based on the post-nuke sample script (located in /usr/share/mondo/post-nuke.sample) and the information found in the Mondo-Devel mailing list archive (mainly this post).

Update #1: location for the archive example have been changed

Linux: power off confirmation

There are situations when you need to configure your Linux machine to be powered off when somebody shortly press the power button. This is usually the case when you will install acpid (Advanced Configuration and Power Interface event daemon).

But what if you need some sort of confirmation that your command have been received and the system is in the shutdown cycle?

Well, all you have to do is to tweak the action parameter from /etc/acpi/events/power.conf and my suggestion could be found bellow.

Let's take a Centos or any RHEL based distribution and test it!

yum install acpid

in /etc/acpi/events/power.conf:

• comment the default action (inserting # as the first character of the line)
• add the following line at the end of the file

action=/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep || (/bin/echo -e \\a >> /dev/console;/bin/sleep 0.25;/bin/echo -e \\aPower button event ! >> /dev/console;/bin/sleep 0.25;/bin/echo -e \\a >> /dev/console;/sbin/shutdown -h now)

All we have now is to restart the acpid service:

service acpid restart

In this way, when the case power button will be pressed shortly, 3 short beeps will be heard (in case your machine have an internal speaker) before the final shutdown command is triggered.

Command logger

Daca aveti nevoie de o implementare rapida a unui "command logger" sub Linux se poate folosi metoda de adaugare a unei trape in /etc/profile [1].

Modificarea care o propun mai jos evita logarea suplimentara in cazul in care exista definit variabila (de Bash) PROMPT_COMMAND.

• de adaugat la sfarsitul fisierului /etc/profile

function log2syslog
{
declare a
a=${PROMPT_COMMAND/"$BASH_COMMAND"/change_me}
if [ "$a" = "$PROMPT_COMMAND" ]
then
logger -p local1.notice -t bash -i "$USER:$UID,$EUID:$SSH_TTY:${SSH_CLIENT/ */}:$PWD:$BASH_COMMAND"
fi
}
trap log2syslog DEBUG

In [2] si [3] sunt mentionate si utilitarul snoopy insa, asa cum am gasit dupa instalarea lui, acesta nu logheaza functiile interne Bash [4]. Astfel incat, pentru moment, am ramas la metoda descrisa in acest post.

Bibliografie:
[1] Bash: History to Syslog
[2] Root Level Activity Logging - Take Two
[3] Logging every shell command
[4] Snoopy Forum - Logging bash internal functions

Recover from a CF SLAX boot error

Daca aveti probleme in a porni un sistem SLAX de pe un Compact Flash (CF) (Boot error sau echivalent) puteti folosi urmatoarea comanda "magica" pentru a restaura functionarea normala:

I:\boot\syslinux\syslinux.exe -ma -d \boot\syslinux I:>NUL

unde I: este identificatorul sub care Windows-ul a montat CF-ul.

Bibliografie:
a more comfortable way to install slax

Tricks for Red Hat Cluster Suite (RHCS) - IP sleeptime

Ma ocupam zilele acestea de configurarea unui cluster Red Hat (RHEL 5.5, system-config-cluster-1.0.57) si am dat de urmatoarea situatie: mutarea unui serviciu de pe un nod pe altul dureaza aproximativ 11 secunde.

Serviciul contine doar definitia unei adrese IP de genul:

<ip address="10.10.10.101" monitor_link="1"/>

iar colegii mei s-au aratat mirati de acest lucru.

Verificand logurile de cluster am gasit ca aproximativ 10 secunde sunt "pierdute" la oprirea serviciului:

Jul  1 12:44:37 node2 clurgmgrd[9896]:  Stopping service service:ipA
Jul  1 12:44:37 node2 clurgmgrd: [9896]:  Removing IPv4 address 10.10.10.101/24 from eth2
Jul  1 12:44:47 node2 clurgmgrd[9896]:  Service service:axigenA is stopped
Jul  1 12:44:47 node2 clurgmgrd[9896]:  Sent remote-start request to 1
Jul  1 12:44:50 node2 clurgmgrd[9896]:  Service service:axigenA is now running on member 1

Am facut o scurta verificare in script-ul asociat resursei IP (ip.sh) si am descoperit cauza:

# XXX Let nfsd/lockd clear their queues; we hope to have a
# way to enforce this in the future
if [ -z "$OCF_RESKEY_sleeptime" ]; then
 sleep 10
else
 if [ "$OCF_RESKEY_sleeptime" -gt "0" ]; then
  sleep $OCF_RESKEY_sleeptime
 fi
fi

Tentatia a fost sa modificam sleep 10 in sleep 3 insa am gasit ca exista parametrul sleeptime care poate fi specificat pentru respectiva resursa:

<parameter name="sleeptime">
 <longdesc lang="en">
  Amount of time to sleep after removing an IP address.
  Value is specified in seconds. Default value is 10.
 </longdesc>
 <shortdesc lang="en">
  Amount of time (seconds) to sleep.
 </shortdesc>
 <content type="string"/>
</parameter>

Am modificat resursa respectiva in fisierul cluster.conf de pe unul din noduri si am vrut sa propagam configuratia catre restul nodurilor (prin intermediul system-config-cluster) insa am avut surpriza sa constatam ca fisierul este considerat invalid.

Dupa cateva cautari am gasit raportul unui bug, raportat inca din Martie 2009. Dupa adaugarea in fisierul cluster.ng a unei reguli de validare pentru parametrul sleeptime totul a fost in regula.

How to generate the patch diff file

Nu sunt familiarizat cu generarea fisierelor de patch pentru programele de tip script si de aceea acest post este destinat mai mult pentru "arhiva".

1. Se copiaza script-ul original cu sufixul .orig (de ex. test.pl.orig)
2. Se fac modificarile in script
3. Se testeaza
4. Se genereaza fisierul de patch prin comanda:

diff -u test.pl.orig test.pl > /tmp/patch.test-pl.txt

Pentru a executa fisierul de patch generat se va rula comanda de mai jos in directorul in care se afla fisierul ce trebuie modificat.
patch -p0 < /tmp/patch.test-pl.txt

How to read/change the ISO volume ID

Am cautat destul de mult timp un utilitar Linux de tip CLI (Command Line Interface) care sa ma ajute sa modific eticheta unui disk CD/DVD (label sau volume ID). Scopul era sa incrementez un contor pentru a putea tine evidenta cate rescrieri fac pe un disk de tip RW.

Daca pentru partea de citire am gasit utilitarul isoinfo (care face parte din pachetul cdrecord) nu am reusit sa rezolv partea de scriere. Dupa cautari insistente am gasit un script in perl care citeste informatiile de identificare (primary volume descriptor) dintr-un fisier de tip iso. Plecand de la acest script am reusit sa rezolv si partea de scriere.

Scriptul se poate descarca de aici iar modul de apelare este urmatorul:

isolabel [iso_file/device] [read/write] [new_label]

Orice fel de observatii sau comentarii sunt binevenite.