Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Backing Up, Restoring, and Updating the SC

This section provides information and recommendations for securely backing up and restoring the SC. In this section, the MSP is used as the dumpconfig, restoreconfig and flashupdate server.

Backing Up and Restoring Configurations

The dumpconfig command uses the FTP protocol to save the current platform and domain configurations to the MSP server. The restoreconfig command uses either the FTP or HTTP protocol to restore a previously saved configuration to the SC from the MSP server.

For complete descriptions and usage of the dumpconfig and restoreconfig commands, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.

All stored platform and domain configuration information is included in the dump file. This information includes the MD5 hash of the platform and domain administrator passwords, the OBP password, and the SNMP community strings.

The dump file is not encrypted. Hence the MD5 hash of the platform and domain administrator passwords and the non-encrypted OBP password and SNMP community strings are transmitted in clear text during the dumpconfig operation. For this reason, the dump files are saved on the MSP, thus ensuring that the insecure transmission of information is restricted to the private SC network, thus minimizing exposure to network snooping.

When a restoreconfig operation is carried out, the entire saved configuration is restored. This includes the platform administrator and domain administrator passwords. It is essential to ensure that the passwords are known before this operation is carried out. Refer to "Configuring Platform Administrator Settings" on page 14 and "Configuring Domain Administrator Settings" on page 25.

The Apache Web Server on the MSP is configured such that the /msp directory is made available to the SC. All backup and restore operations to the MSP must be contained in this directory. Because the backup files created during a dumpconfig are not differentiated by name or date, it is important that separate directories be created for each backup for version control and tracking. The recommended solution is to create a directory for each dumpconfig using the year, month, day, and hour. For example: the dumpconfig performed on July 16th, 2001 at 7 p.m. would be stored in a directory called 2001071619.

Backing Up Platform and Domain Configurations

Although the MSP is configured to respond to HTTP, it does not normally respond to FTP because the FTP service is disabled during MSP setup. To perform a dumpconfig, the FTP service needs to be enabled on the MSP.

After saving configurations, disable the FTP service again on the MSP. The MSP is configured such that a user ID and password are required for this operation, and the user ID should be used only for dumpconfig and restoreconfig operations.

To Back Up Configurations on the MSP

  1. To enable the FTP service on the MSP, log in to the MSP using Secure Shell, then su to root.

  2. Edit the file /etc/inetd.conf, and uncomment the following FTP entry:

    #ftp stream tcp6  nowait root /usr/sbin/in.ftpd in.ftpd -l
  3. Send the inetd daemon a SIGHUP signal with the following commands:

    # ps -ef | grep inetd
      root  221   1 0  Jun 08 ? 0:00 /usr/sbin/inetd -s -t
    # kill -HUP 221
  4. Create a directory with the appropriate time and date stamp on the MSP.

    Before the actual dumpconfig command can be run, a directory on the MSP must be created with the appropriate time and date stamp. Based on the example (July 16th, 2001 at 7 p.m. would be stored in a directory called 2001071619), the following directory would be created:

    # mkdir /msp/2001071619
    # chown msphttp:mspstaff /msp/2001071619
    # chmod 770 /msp/2001071619
  5. At the SC, dump the configuration using FTP with a user name and password.

    NOTE

    The following example assumes a user name "blueprints" and password "t00lk1t" on the MSP.

    The command and results should be similar to the following:

    ds7-sc0:SC> dumpconfig -f ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619
    Created: ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619/ds7-sc0.nvci
    Created: ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619/ds7-sc0.tod

  6. When the dump is complete, conclude the process by disabling the FTP entry in the /etc/inetd.conf by commenting out the following line in the /etc/inetd.conf:

    ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l
  7. Send the inetd daemon a SIGHUP signal in the following manner:

    # ps -ef | grep inetd
      root 221 1 0  Jun 08 ?  0:00 /usr/sbin/inetd -s -t
    # kill -HUP 221
  8. Confirm that the FTP service is disabled by executing the following commands:

    # ftp localhost
    ftp: connect: Connection refused
    ftp> quit

Restoring Platform and Domain Configurations

When it is necessary to restore configuration settings, first ensure that at least the platform administration password contained in the chosen dump file is known by the platform administrators. With the release of 5.13, it is possible for a platform administrator to reset the domain passwords without knowing the old ones. Ideally, of course, both the domain and platform passwords contained in the dump file should be known.

To avoid the necessity of enabling the FTP service on the MSP for this operation, we recommend that you use restoreconfig operation using HTTP. As with the dumpconfig operation, a user ID and password are required for this operation, and the user ID should only be used for dumpconfig and restoreconfig operations.

Restoring configuration settings using HTTP is documented in Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual. The only considerations are ensuring that the appropriate backup directory is available through the web server and that the passwords used for the domain and platform administrators, in the configuration being restored, are known.

Updating the SC

The flashupdate feature updates the firmware running on the SC, the CPU/Memory boards, and the I/O assemblies. The update is initiated by using the flashupdate command on the SC. The source flash image can be on a server or another board of the same type. This section describes updates executed from an image on a server. The MSP is used as the server for flashupdate images.

To avoid the necessity of enabling FTP on the MSP for this operation, we recommend that you carry out the flashupdate operation using HTTP.

The MSP is configured such that a user ID and password are required for this operation, and the user ID should only be used for flashupdate operations.

CAUTION

It is important to be sure of the authenticity and integrity of the flash images before they are loaded from the server using the flashupdate command. Loading a corrupted or malicious image can cause damage to hardware, and may compromise security.

It is recommended that the RTOS be updated whenever SCapp is updated. When a new firmware is released, SCapp is normally only tested with the RTOS included with the firmware update. If an RTOS flash fails, then a service call to Sun is required to replace or repair the SC. In order to establish whether a RTOS flash is necessary, refer to the product release notes accompanying the image and the flashupdate command documentation in the Sun Fire 6800/4810/4800/3800 Platform Administration Manual.

To Update the SC

  1. Download the latest flashupdate for the SC from the Product Patches section of the SUNSOLVE ONLINE Web site at:

    http://sunsolve.sun.com

  2. Make a note of the checksum listed for the patch in the Patch Checksums section of the SUNSOLVE ONLINE Web site, similar to the following:

    111346-02.zip
       MD5: 5e84f09ebf5743eb5426b5be6c6a777f
       SysV Sum: 7075  13729
       Sum: 43381  13729
  3. Confirm that the checksum of the file matches the checksum listed on the SUNSOLVE ONLINE Web site, using the following commands:
    # sum 111346-02.zip
    7075 13729 111346-02.zip
    # sum -r 111346-02.zip
    43381 13729 111346-02.zip

    A more robust file integrity check is to use the MD5 hash value listed for the patch. For more information about downloading and using MD5 hashes to verify patch integrity, refer to the Sun BluePrints OnLine article titled The Solaris™ Fingerprint Database - A Security Tool for Solaris Software and Files.

  4. Unpack the files containing the patch and place them in a subdirectory under the Apache Web Server document root directory /msp as follows:

    # cd /msp
    # unzip 111346-02.zip
    Archive: 111346-02.zip
      creating: 111346-02/
     inflating: 111346-02/Install.info 
     inflating: 111346-02/VERSION.INFO 
     inflating: 111346-02/copyright   
     inflating: 111346-02/sgcpu.flash  
     inflating: 111346-02/sgpci.flash  
     inflating: 111346-02/sgrtos.flash 
     inflating: 111346-02/sgsc.flash  
     inflating: 111346-02/README.111346-02
  5. Follow the instructions in the Install.info file.

    In our example, sc-app, SB0, SB2, IB7, and IB9 are to be updated from version 5.11.6 to 5.11.7. The RTOS will be updated from release 17 to 17B. Not all system boards are powered up, so the all option cannot be used.

    The following example downloads and installs the flashupdate file from the MSP:

    ds7-sc0:SC> flashupdate -f http://blueprints:t00lk1t@192.168.100.10/111346-02 SB0 SB2 IB7 IB9 scapp rtos

    The RTOS flash image will be upgraded automatically during the next boot. The ScApp flash image will be upgraded automatically during the next boot. After this update you must reboot each active domain that you have upgraded. After this update, the system controller will automatically reboot itself. Do you want to continue? [no] y

    Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgcpu.flash
    Validating ............ Done
    
    Programming PROM 0 on /N0/SB0
    Erasing   ............ Done
    Programming ............ Done
    Verifying  ............ Done
    
    Programming PROM 1 on /N0/SB0
    Erasing   ............ Done
    Programming ............ Done
    Verifying  ............ Done
    
    Programming PROM 0 on /N0/SB2
    Erasing   ............ Done
    Programming ............ Done
    Verifying  ............ Done
    
    Programming PROM 1 on /N0/SB2
    Erasing   ............ Done
    Programming ............ Done
    Verifying  ............ Done
    
    Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgpci.flash
    Validating .... Done
    
    Programming PROM 0 on /N0/IB7
    Erasing   .... Done
    Programming .... Done
    Verifying  .... Done
    
    Programming PROM 0 on /N0/IB9
    Erasing   .... Done
    Programming .... Done
    Verifying  .... Done
    
    Rebooting the SC to automatically update flash image.

    The SC reboots, and the flashupdate proceeds as follows:

    Copyright 2001 Sun Microsystems, Inc. All rights reserved.
    
    RTOS version: 17
    ScApp version: 5.11.6
    SC POST diag level: off
    
    Auto Flashupdate
    
    Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgrtos.flash
    
    Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgsc.flash
    Validating .................................................... Done
    
    Updating: RTOS
    Erasing   ........... Done
    Programming ........... Done
    Verifying  ........... Done
    
    Updating: ScApp from version 5.11.6 to version 5.11.7
    Erasing   .................................................... Done
    Programming .................................................... Done
    Verifying  .................................................... Done
    
    Flashupdate completed successfully.
    The SC is being rebooted to use the new images.

    The SC then reboots with the new image.

  6. Halt the Solaris OE image running in each domain gracefully by using the shutdown command.

    You must perform this step before issuing the setkeyswitch off command.

  7. For each domain affected by the updates, set the keyswitch to the off position by issuing the setkeyswitch off command from the domain shell.

    In the following example, domain-a is affected:

    ds7-sc0:A> setkeyswitch off
    
    This will abruptly terminate Solaris in domain A.
    Do you want to continue? [no] y
  8. Set the domain keyswitch to the on position using the following setkeyswitch on command:

    ds7-sc0:A> setkeyswitch on

The flashupdate operation is now complete. At this point, the domain boots itself either to the OBP prompt or Solaris OE. In either case, the flashupdate operation is now complete.

  • + Share This
  • 🔖 Save To Your Account