summaryrefslogtreecommitdiffstats
path: root/perl-install/wizards.pm
blob: 9a262a2160997fe39e51a48aa05ecdf2b8695f90 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
package wizards;
# $Id$

use strict;
use c;
use common;

=head1 NAME

wizards - a layer on top of interactive that ensure proper stepping

=head1 SYNOPSIS

    use wizards;
    use interactive;

    my $wiz = wizards->new({

               allow_user => "", # do we need root
               defaultimage => "", # wizard icon
               init => sub { },    # code run on wizard startup
               name => "logdrake", # wizard title
               needed_rpm => "packages list", # packages to install before running the wizard
               pages => {
                         {
                             name => "welcome", # first step
                             next => "step1",   # which step should be displayed after the current one
                             pre =>  sub { },   # code executing when stepping backward
                             post => sub { },   # code executing when stepping forward;
                                                # returned value is next step name (it overrides "next" field)
                             end => ,       # is it the last step ?
                             default => ,       # default answer for yes/no or when data does not conatains any fields
                             no_cancel => , # do not display the cancel button (eg for first step)
                             no_back => ,   # do not display the back button (eg for first step)
                             ignore => ,    # do not stack this step for back stepping (eg for warnings and the like steps)
                             interactive_help_id => , # help id  (for installer only)
                             data => [],    # the actual data passed to interactive
                         },
                         {
                          name => "step1",
                          data => [
                                   {
                                       # usual interactive fields:
                                       label => N("Banner:"),
                                       val => \$o->{var}{wiz_banner},
                                       list => [] ,
                                       # wizard layer variables:
                                       boolean_list => "", # provide default status for booleans list
                                   },
                                   ],
                      },
                     },
           });
    my $in = 'interactive'->vnew;
    $wiz->process($in);

=head1 DESCRIPTION

wizards is a layer built on top of the interactive layer that do proper
backward/forward stepping for us.

A step is made up of a name/description, a list of interactive fields (see
interactive documentation), a "complete", "pre" and "post" callbacks, an help
id, ...

The "pre" callback is run first. Its only argument is the actual step hash.

Then, if the "name" fiels is a code reference, that callback is run and its
actual result is used as the description of the step.

At this stage, the interactive layer is used to display the actual step.

The "post" callback is only run if the user has steped forward.


Alternatively, you can call safe_process() rather than process().
safe_process() will handle for you the "wizcancel" exception while running the
wizard.  Actually, it should be used everywhere but where the wizard is not the
main path (eg "mail alert wizard" in logdrake, ...), ie when you may need to do
extra exception managment such as destroying the wizard window and the like.

=cut


sub new {
    my ($class, $o) = @_;
    bless $o, $class;
}


sub check_rpm {
    my ($in, $rpms) = @_;
    foreach my $rpm (@$rpms) {
        next if $in->do_pkgs->is_installed($rpm);
        if ($in->ask_okcancel(N("Error"), N("%s is not installed\nClick \"Next\" to install or \"Cancel\" to quit", $rpm))) {
            $::testing and next;
            if (!$in->do_pkgs->install($rpm)) {
                local $::Wizard_finished = 1;
                $in->ask_okcancel(N("Error"), N("Installation failed"));
                $in->exit;
            }
        } else { $in->exit }
    }
}


# sync me with interactive::ask_from_normalize() if needed:
my %default_callback = (complete => sub { 0 });


sub process {
    my ($o, $in) = @_;
    local $::isWizard = 1;
    local $::Wizard_title = $o->{name} || $::Wizard_title;
    local $::Wizard_pix_up = $o->{defaultimage} || $::Wizard_pix_up;
    #require_root_capability() if $> && !$o->{allow_user} && !$::testing;
    check_rpm($in, $o->{needed_rpm}) if ref($o->{needed_rpm});
    if (defined $o->{init}) {
        my ($res, $msg) = &{$o->{init}};
        if (!$res) {
            $in->ask_okcancel(N("Error"), $msg);
            die "wizard failed" if !$::testing;
        }
    }
    
    my @steps;             # steps stack

    # initial step:
    my $next = 'welcome';  
    my $page = $o->{pages}{welcome};
    while ($next) {
        local $::Wizard_no_previous = $page->{no_back};
        local $::Wizard_no_cancel = $page->{no_cancel} || $page->{end};
        local $::Wizard_finished = $page->{end};
        defined $page->{pre} and $page->{pre}($page);
        die qq(inexistant "$next" wizard step) if is_empty_hash_ref($page);
        
        # FIXME or the displaying fails
        my $data = defined $page->{data} ? (ref($page->{data}) eq 'CODE' ? $page->{data}->() : $page->{data}) : [];
        my $data2;
        foreach my $d (@$data) {
            $d->{val} = ${$d->{val_ref}} if $d->{val_ref};
            $d->{list} = $d->{list_ref} if $d->{list_ref};
            #$d->{val} = ref($d->{val}) eq 'CODE' ? $d->{val}->() : $d->{val};
            if ($d->{boolean_list}) { 
                my $i;
                foreach (@{$d->{boolean_list}}) { 
                    push @$data2, { text => $_, type => 'bool', val => \${$d->{val}}->[$i], disabled => $d->{disabled} };
                    $i++;
                }
            } else {
                push @$data2, $d;
            }
        }
        my $name = ref($page->{name}) ? $page->{name}->() : $page->{name};
        my %yesno = (yes => N("Yes"), no => N("No"));
        my $yes = ref($page->{default}) eq 'CODE' ? $page->{default}->() : $page->{default};
        $data2 = [ { val => \$yes, type => 'list', list => [ keys %yesno ], format => sub { $yesno{$_[0]} }, 
                     gtk => { use_boxradio => 1 } } ] if $page->{type} eq "yesorno";
        my $a;
        if (ref $data2 eq 'ARRAY' && @$data2) {
            $a = $in->ask_from_({ title => $o->{name}, 
                                 messages => $name, 
                                 (map { $_ => $page->{$_} || $default_callback{$_} } qw(complete)),
                                 if_($page->{interactive_help_id}, interactive_help_id => $page->{interactive_help_id}),
                               }, $data2);
        } else {
            $a = $in->ask_okcancel($o->{name}, $name, $yes || 'ok');
        }
        # interactive->ask_yesorno does not support stepping forward or backward:
        $a = $yes if $a && $page->{type} eq "yesorno";
        if ($a) {
            # step forward:
            push @steps, $next if !$page->{ignore} && $steps[-1] ne $next;
            my $current = $next;
            $next = defined $page->{post} ? $page->{post}($page->{type} eq "yesorno" ? $yes eq 'yes' : $a) : 0;
            return if $page->{end};
            if (!$next) {
                if (!defined $o->{pages}{$next}) {
                    $next = $page->{next};
                } else {
                    die qq(the "$next" page (from previous wizard step) is undefined) if !$next;
                }
            }
            die qq(Step "$current": inexistant "$next" page) if !exists $o->{pages}{$next};
        } else {
            # step back:
            $next = pop @steps;
        }
        $page = $o->{pages}{$next};
    }
}


sub safe_process {
    my ($o, $in) = @_;
    eval { $o->process($in) };
    my $err = $@;
    if ($err =~ /wizcancel/) {
        $in->exit(0);
    } else { 
        die $err if $err;
    }
}

1;
/mnt/ka/ka</strong></span> directory, and see all new files available. All those files are needed to do a <span class="bold"><strong>KA</strong></span> duplication process. We will explain now the rule of each of them.i You can modify all them, those files will be copied onto the directory <span class="bold"><strong>/tmp/stage2</strong></span> of the client node.
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643805"></a>2.1.1. ka-d.sh</h4></div></div></div><p>
This is the master script to declare a node as a golden node. This script takes a lot of arguments.
</p><pre class="screen">
-h, --help : display this message
-n num : specify the number of (destination) nodes
-x dir : exclude directory
- -X sdb : exclude sdb for the replication
+ -X sdb|sdc : exclude sdb for the replication
-m drive : copy the master boot record (for windows) of this drive
-M drive file : use 'file' as master boot record (must be 446 bytes long) for the specified drive
-D partition : also copy partition 'partition'
@@ -209,53 +211,42 @@ mount -o loop -t squashfs rescue.sqfs /mnt/ka</pre><p>
-d delay : delay beteween the release of 2 clients (1/10 second)
-r 'grub|lilo' : choose the bootloader (you can add mkinitrd options)
- ie: ka-d.sh -n 3 -p sda /tmp/desc -X sdb -r 'grub --with=ata_piix --with=piix'</pre><p>
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522775"></a>2.1.2. replication.conf</h4></div></div></div><p>
+ ie: ka-d.sh -n 3 -p sda /tmp/desc -X 'sdb|sdc' -r 'grub --with=ata_piix --with=piix'</pre><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643844"></a>2.1.2. replication.conf</h4></div></div></div><p>
This file contain all variables needed by other scripts. It also tries to get information like IP address.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522788"></a>2.1.3. fdisk_to_desc</h4></div></div></div><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643856"></a>2.1.3. fdisk_to_desc</h4></div></div></div><p>
This script generate the description table of the hard drive disk in the <span class="bold"><strong>/tmp/desc</strong></span> file.
This file must follow some rules: one line per partition, with two fields : type of partition and size in megabytes.
The type can be linux, swap, extended. Other types can be obtained by appending their hexadecimal number to 'type'.
For example linux is the same as type83. The size is either a number of megabytes, or the keyword fill (to take all
available space). The logical partitions must have the logical keyword.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522812"></a>2.1.4. gen_modprobe_conf.pl</h4></div></div></div><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643880"></a>2.1.4. gen_modprobe_conf.pl</h4></div></div></div><p>
This script create a basic output like the content of the<span class="bold"><strong>/etc/modprobe.conf</strong></span> file. Drawbacks
this file must be updated for each new modules available in the kernel (based on the <span class="bold"><strong>kernel/list_modules.pm</strong></span> file).
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522837"></a>2.1.5. ka-d-client</h4></div></div></div><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643903"></a>2.1.5. ka-d-client</h4></div></div></div><p>
The <span class="bold"><strong>ka-d-client</strong></span> binary file is used to get stage2 with the <span class="bold"><strong>KA</strong></span> method, and after
get the whole system. The important argument is the <span class="bold"><strong>-s</strong></span> session name. A <span class="bold"><strong>KA</strong></span>
can only connect to a specific session (getstage2, kainstall ...). The code source is available in the ka-deploy-0.92 SRPM.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522872"></a>2.1.6. ka-d-server</h4></div></div></div><p>
- The <span class="bold"><strong>ka-d-server</strong></span> binary file is used to be a <span class="bold"><strong>KA</strong></span> golden node server.
- Like the <span class="bold"><strong>ka-d-client</strong></span> the session arguments is an important parameter (<span class="bold"><strong>-s session_name</strong></span>).
- The code source is available in the ka-deploy-0.92 SRPM.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522906"></a>2.1.7. ka_replication.sh</h4></div></div></div><p>
- Script launched on the <span class="bold"><strong>KA</strong></span> client (after getting stage2 and probing modules), to do the full process of the
- <span class="bold"><strong>Ka</strong></span> duplication.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643938"></a>2.1.6. ka-d-server</h4></div></div></div><p>
+ The <span class="bold"><strong>ka-d-server</strong></span> binary file is used to be a <span class="bold"><strong>KA</strong></span> golden node server. Like the <span class="bold"><strong>ka-d-client</strong></span> the session arguments is an important parameter (<span class="bold"><strong>-s session_name</strong></span>). The session name will be <span class="bold"><strong>getstage2</strong></span> to retrieve the stage2 (after the PXE boot) and will be <span class="bold"><strong>kainstall1</strong></span> at duplication process step. If you want to do more than one duplication process of nodes at the same time, you should synchronize the ka_sesion name between the server and the client. The code source is available in the ka-deploy SRPM.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2643986"></a>2.1.7. ka_replication.sh</h4></div></div></div><p>
+ Script launched on the <span class="bold"><strong>KA</strong></span> client (after getting stage2 and probing modules), to do the full process of the <span class="bold"><strong>Ka</strong></span> duplication.
This script call other scripts to prepare the node (prepare_node.sh), configure the bootloader (make_initrd_grub or make_initrd_lilo).
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522931"></a>2.1.8. store_log.sh</h4></div></div></div><p>
- Basic script to store the log of the <span class="bold"><strong>KA</strong></span> duplication process on an FTP server. Adjust to feet your need, and uncomment
- the line <span class="bold"><strong>#store_log.sh</strong></span> in the <span class="bold"><strong>/mnt/ka/ka/ka_replication.sh</strong></span> file.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522960"></a>2.1.9. bootable_flag.sh</h4></div></div></div><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644011"></a>2.1.8. store_log.sh</h4></div></div></div><p>
+ Basic script to store the log of the <span class="bold"><strong>KA</strong></span> duplication process on an FTP server. Adjust to feet your need, and uncomment the line <span class="bold"><strong>#store_log.sh</strong></span> in the <span class="bold"><strong>/mnt/ka/ka/ka_replication.sh</strong></span> file.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644040"></a>2.1.9. bootable_flag.sh</h4></div></div></div><p>
Script to set bootable an HDD using fdisk. First arg must be the HDD device.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522972"></a>2.1.10. make_initrd_grub</h4></div></div></div><p>
- Restore and reload the Grub bootloader in the <span class="bold"><strong>/mnt/disk</strong></span> directory. It's a very basic script, and perhaps
- use the <span class="bold"><strong>restore_bootloader</strong></span> of the Mandriva Linux Rescue should be a better idea.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2522996"></a>2.1.11. make_initrd_lilo</h4></div></div></div><p>
- Restore and reload the lilo bootloader in the <span class="bold"><strong>/mnt/disk</strong></span> directory. Again it's a very basic script, perhaps we should use the
- <span class="bold"><strong>restore_bootloader</strong></span> of the Mandriva Linux Rescue.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2523020"></a>2.1.12. prepare_node.sh</h4></div></div></div><p>
- This script remove in the futur system the old network's udev rules, old dhcp cache files, launch the script <span class="bold"><strong>gen_modprobe_conf.pl</strong></span> to
- regenerate an uptodate <span class="bold"><strong>/etc/modprobe.conf</strong></span> in the new system, and launch the script to restore the bootloader.
- If you want to do more action on the installed, system, you can modify this script.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2523046"></a>2.1.13. send_status.pl</h4></div></div></div><p>
- Very basic perl script to open the port 12345, and paste the content of the <span class="bold"><strong>/tmp/ka*</strong></span> file. It also
- permit the execution of commands on node, if user send a message from the golden node with the <span class="bold"><strong>exec</strong></span> prefix.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2523070"></a>2.1.14. status_node.pl</h4></div></div></div><p>
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644051"></a>2.1.10. make_initrd_grub</h4></div></div></div><p>
+ Restore and reload the Grub bootloader in the <span class="bold"><strong>/mnt/disk</strong></span> directory. It's a very basic script, and perhaps use the <span class="bold"><strong>restore_bootloader</strong></span> of the Mandriva Linux Rescue should be a better idea. </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644075"></a>2.1.11. make_initrd_lilo</h4></div></div></div><p>
+ Restore and reload the lilo bootloader in the <span class="bold"><strong>/mnt/disk</strong></span> directory. Again it's a very basic script, perhaps we should use the <span class="bold"><strong>restore_bootloader</strong></span> of the Mandriva Linux Rescue.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644099"></a>2.1.12. prepare_node.sh</h4></div></div></div><p>
+ This script remove in the futur system the old network's udev rules, old dhcp cache files, launch the script <span class="bold"><strong>gen_modprobe_conf.pl</strong></span> to regenerate an up to date <span class="bold"><strong>/etc/modprobe.conf</strong></span> in the new system, and launch the script to restore the bootloader. If you want to do more action on the installed, system, you can modify this script.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644126"></a>2.1.13. send_status.pl</h4></div></div></div><p>
+ Very basic perl script to open the port 12345, and paste the content of the <span class="bold"><strong>/tmp/ka*</strong></span> file. It also permit the execution of commands on node, if user send a message from the golden node with the <span class="bold"><strong>exec</strong></span> prefix.
+ </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2644150"></a>2.1.14. status_node.pl</h4></div></div></div><p>
Script to connect to a client node, first arg must be the IP address of the node. You can run command on the node with the <span class="bold"><strong>exec</strong></span> prefix.
- </p></div></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2523090"></a>3. The golden node, KA server</h2></div></div></div><p>
- Now, it is time to build a description of the node partitions. You can use the script
- <span class="bold"><strong>/mnt/ka/ka/fdisk_to_desc</strong></span> as root user, or your favorite text editor,
+ </p></div></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2644169"></a>3. The golden node, KA server</h2></div></div></div><p>
+ Now, it is time to build a description of the node partitions. You can use the script <span class="bold"><strong>/mnt/ka/ka/fdisk_to_desc</strong></span> as root user, or your favorite text editor,
you can write a file like this one:
</p><p>
</p><pre class="screen">
@@ -269,7 +260,7 @@ logical linux fill</pre><p>
partition, and <span class="bold"><strong>/var</strong></span> fills the rest, of course you can adjust
sizes accoding to your system.
</p><p>
- Type the following to start the ka replication server as root user:
+ Type the following to start the ka replication server as root user on the golden node:
</p><p>
</p><pre class="programlisting">
&lt;screen&gt;
@@ -298,15 +289,14 @@ Socket 5 on port 30764 on node40.guibland.com ready.
</p><p>
</p><div class="itemizedlist"><ul type="disc"><li><p><span class="bold"><strong>-r "grub --with=jfs --with=ata_piix"</strong></span>: use grub bootloader and <span class="bold"><strong>--with=jfs --with=piix</strong></span> mkinitrd option in the chrooted system after the <span class="bold"><strong>KA</strong></span> deploiement</p></li><li><p><span class="bold"><strong>-n nb_nodes</strong></span>: specify how many nodes are clients</p></li><li><p><span class="bold"><strong>-p sda/hda desc</strong></span>: specify if you want to duplicate SCSI or IDE storage, and the name of the hdd</p></li><li><p><span class="bold"><strong>-x /tmp</strong></span>: exclude <span class="bold"><strong>/tmp</strong></span> directory</p></li><li><p><span class="bold"><strong>-X sdb</strong></span>: exclude <span class="bold"><strong>sdb</strong></span> hdd for the duplication</p></li></ul></div><p>
</p><p>
- Now the node is waiting for the rest of the nodes to start replication.
- </p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2523240"></a>4. KA client node</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523246"></a>4.1. PXE server (kamethod)</h3></div></div></div><p>
+ Now the golden node is waiting for clients nodes to start replication.
+ </p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2644320"></a>4. KA client node</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644325"></a>4.1. PXE server (kamethod)</h3></div></div></div><p>
We have to configure the PXE to boot by default on <span class="bold"><strong>kamethod</strong></span>.
To do this just edit <span class="bold"><strong>/var/lib/tftpboot/X86PC/linux/pxelinux.cfg/default</strong></span> and set
<span class="bold"><strong>DEFAULT</strong></span> to kamethod:
</p><pre class="screen">DEFAULT kamethod</pre><p>
- So, next time a node boots, the PXE server will force the
- node to boot using the kamethod.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523284"></a>4.2. Stage1 KA method, node waiting stage2 </h3></div></div></div><p>
+ So, next time a node boots, the PXE server will force the node to boot using the kamethod entry.
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644363"></a>4.2. Stage1 KA method, node waiting stage2 </h3></div></div></div><p>
Now, you boot all remaining nodes. The replication process
will start once all nodes are up and waiting on the <span class="bold"><strong>KA</strong></span>
screen.
@@ -315,20 +305,18 @@ Socket 5 on port 30764 on node40.guibland.com ready.
server the message <span class="bold"><strong>Can't reach a valid KA server</strong></span> will appear.
Each node will try five times to reach the <span class="bold"><strong>KA</strong></span> server, after that the node will reboot.
As the node boots on <span class="bold"><strong>kamethod</strong></span>, it will retry until it finds it.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523331"></a>4.3. Stage2, the duplication process</h3></div></div></div><p>
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644410"></a>4.3. Stage2, the duplication process</h3></div></div></div><p>
Once all the nodes have found the <span class="bold"><strong>KA</strong></span> server, the first
duplication process will start. This step duplicates the
- <span class="bold"><strong>rescue_stage2</strong></span> from the <span class="bold"><strong>/mnt/ka</strong></span> directory
- of the golden node, in the client's nodes memory (<span class="bold"><strong>/dev/ram3</strong></span>). Then, nodes chroot their
- memories (the <span class="bold"><strong>/tmp/stage2</strong></span> directory), and launch the <span class="bold"><strong>drvinst</strong></span> command from the rescue disk, to probe all needed their modules (drivers).
- Then, the second step of the duplication starts.
+ <span class="bold"><strong>stage2</strong></span> from the <span class="bold"><strong>/mnt/ka</strong></span> directory
+ of the golden node, in the client's nodes memory (<span class="bold"><strong>/dev/ram3</strong></span> formated as ext2). Then, nodes chroot their memories (the <span class="bold"><strong>/tmp/stage2</strong></span> directory), and launch the <span class="bold"><strong>drvinst</strong></span> command from the stage2, to probe all needed their modules (drivers). Then, the second step of the duplication starts.
</p><p>
The duplication process will clone your drives following
the description you have made (<span class="bold"><strong>/tmp/desc</strong></span> of the golden node).
Nodes will rewrite their partition table, then format their filesystems (ReiserFs, XFS,
- ext2/3, JFS). All new partitions will be mounted in the <span class="bold"><strong>/mnt/disk</strong></span> directory.
+ ext2/3/4, JFS). All new partitions will be mounted in the <span class="bold"><strong>/mnt/disk</strong></span> directory.
Then, the drive duplication process will begin. On a fast Ethernet switch you can reach speeds of 10MBytes/sec.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523401"></a>4.4. Prepare the node</h3></div></div></div><p>
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644480"></a>4.4. Prepare the node</h3></div></div></div><p>
At the end of the duplication process, each node will
chroot its partitions and rebuild its <span class="bold"><strong>/boot/initrd.img</strong></span>,
and <span class="bold"><strong>/etc/modprobe.conf</strong></span> files.
@@ -336,10 +324,10 @@ Socket 5 on port 30764 on node40.guibland.com ready.
SCSI drives and adjusting its network card driver. Before
rebooting, each node reinstalls lilo/grub. All your node are
now ready, and are clone of master node.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523428"></a>4.5. PXE server to local boot</h3></div></div></div><p>
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644507"></a>4.5. PXE server to local boot</h3></div></div></div><p>
Don't forget to change the default PXE boot to <span class="bold"><strong>local</strong></span>
so node after replication will boot localy.
- </p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2523445"></a>5. full log of a KA duplication</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523451"></a>5.1. Golden node side</h3></div></div></div><p>
+ </p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2644524"></a>5. full log of a KA duplication</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644530"></a>5.1. Golden node side</h3></div></div></div><p>
</p><pre class="programlisting">
[root@node40 ka]# ./ka-d.sh -n 1 -p sda /root/desc -X sdb -r "grub --with=jfs --with=ata_piix"
takembr =
@@ -475,7 +463,7 @@ Total data sent = 627 Megs, in 34011 packets
Transfer time = 127.140 seconds, throughput = 4.937 Mbytes/second
The pipeline was emptied in 1.549 seconds
</pre><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2523463"></a>5.2. KA client side</h3></div></div></div><p>
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2644542"></a>5.2. KA client side</h3></div></div></div><p>
Just launch <span class="bold"><strong>/mnt/ka/ka/status_node.pl IPADD</strong></span> to get log of the KA client.
</p><pre class="programlisting">
10.0.1.35&gt; ------| Ka |---- Install starting...