Call Us! 1-800-555-5555

Archives

Mover ZCS a un servidor diferente

El siguiente procedimiento muestra los pasos a seguir para migrar un servidor Zimbra, de un servidor a otro, o de un tipo de instalación base a otra.

Lo primero que haremos un backup del sistema actual. Se puede hacer de muchas formas, si el tamaño de nuestra instalación de Zimbra no es muy grande, con un tar será suficiente:

# /etc/init.d/zimbra stop
# tar cf /zimbra.migracion.tar /opt/zimbra

Prepararemos el sistema nuevo, con una instalación de sistema operativo de los soportados por Zimbra, con su mismo nombre, misma ip, etc. Tendremos que hacer una instalación dummy de Zimbra con la misma versión exactamente que hay instalada en el sistema origen:

# ./install.sh -s
# rm -rf /opt/zimbra

Esto nos asegura que cumplimos todos los requerimientos necesarios para la instalación, pero ahora vamos restaurar nuestro backup y a reparar permisos:

# cd /
# tar xf /zimbra.migracion.tar
# cd /opt/zimbra/libexec
# ./zmfixperms

Si los uid/gid’s no son los mismos en los dos sistemas, tendremos que modificar el fichero /opt/zimbra/conf/localconfig.xml.

El último paso sería relanzar el instalador, el que detectará que hay una instalación de Zimbra, y relanzará la configuración para dejar el sistema plenamente operativo (nos preguntará si queremos hacer un upgrade):

# ./install.sh

El post está basado en la información de un post similar de Zimbra, donde tenemos, ademas, mas información.

Links

http://blog.zimbra.com/blog/archives/2007/10/moving-zcs-to-another-server.html

http://www.serverunderground.com/2011/03/zimbra-upgrade/

Post to Twitter

PRVF-4664 : Found inconsistent name resolution entries for SCAN name

Durante la instalación de Oracle 11.2.0.1 Grid Infrastructure, una de las validaciones finales genera este error.  Esto es resultado de que usar un listener de SCAN, pero con resolución de nombres basada en ficheros hosts.  Hay una nota en metalink al respecto que explica la situación y nos dice como resolverlo, [ID 887471.1].

La solución es simple, ignorar el error.

 

Post to Twitter

Migración eBox 1.4 a Zentyal 2.0

Usando el módulo de backup de eBox y Zentyal, es posible realizar una migración de un sistema eBox 1.4 a Zentyal 2.0 de forma correcta. Las herramientas en modo CLI:

# /usr/share/ebox/ebox-make-backup --help
Usage:
/usr/share/ebox/ebox-make-backup  [OPTION]...
/usr/share/ebox/ebox-make-backup  --help

Options:
--config-backup (default backup mode)
--full-backup
--configuration-report --bug-report
--description <description>
--remote-backup <name>
--progress-id (only needed for web framework)
# /usr/share/ebox/ebox-restore-backup --help
Usage:
/usr/share/ebox/ebox-restore-backup  [OPTION]... [--module NAME]...   ARCHIVE_FILE
/usr/share/ebox/ebox-restore-backup  --info ARCHIVE_FILE
/usr/share/ebox/ebox-restore-backup  --help

Options:
--config-restore
--data-restore
--full-restore
--force-dependencies
--delete-backup
--revoke-all-on-module-fail,--no-revoke-all-on-module-fail
--progress-id

Lo primero haremos una backup de la configuración en nuestro eBox 1.4:

#/usr/share/ebox/ebox-make-backup --config-backup --description "eBox 1.4 Migration"
Backup stored into file /var/lib/ebox/conf/backups/790045.tar

Este backup es el que usaremos en el nuevo sistema para restaurar la configuración de cada uno de los modulos. Podemos ver el contenido del backup:

# /usr/share/ebox/ebox-restore-backup --info /var/lib/ebox/conf/backups/790045.tar
eBox 1.4 Migration
Date: 2011-04-02 10:57:55
Backup type: configuration backup
Modules in backup: sysinfo network firewall apache ca dhcp dns ebackup events global l7-protocols logs monitor ntp objects openvpn radius services software squid trafficshaping usercorner users

Ahora, con una instalación limpia de Zentyal 2.0, que por supuesto ha de tener instalados al menos los modulos que queramos restaurar y han de estar activados, procederemos con la restauración de la configuración original.

El primer modulo será el modulo network:

# /usr/share/ebox/ebox-restore-backup --force-dependencies --config-restore --module network /var/lib/ebox/conf/backups/790045.tar

Accedermos al interfaz de gestión por web, y veremos que hay cambios por guardar.  Guardamos, y reiniciamos el sistema para que los cambios del modulo de network tengan efecto.

Los siguientes modulos en restaurar serán los modulos services, objects y firewall:

# /usr/share/ebox/ebox-restore-backup --force-dependencies --config-restore --module services /var/lib/ebox/conf/backups/790045.tar
# /usr/share/ebox/ebox-restore-backup --force-dependencies --config-restore --module objects /var/lib/ebox/conf/backups/790045.tar
# /usr/share/ebox/ebox-restore-backup --force-dependencies --config-restore --module firewall /var/lib/ebox/conf/backups/790045.tar

De nuevo, accederemos al interfaz y guardaremos los cambios.

Podremos ahora acceder a los modulos ya recuperados, configuración de red, configuración de firewall, y podremos comprobar que tenemos la configuración de nuestro sistema original.

Solo faltaría recuperar el resto de modulos, el sistema sería, recuperamos uno, accedemos al interfaz de gestión guardamos cambios y comprobamos que la configuración original está en su sitio.

Links

http://forum.zentyal.org/index.php?topic=2360.msg13418#msg13418

Post to Twitter

Cisco ASA 5505, activar el servicio SSH

Los pasos para activar el servicio SSH son los siguientes:

# conf t
(conf)# passwd cisco
(conf)# ssh x.x.x.x x.x.x.x {inside/outside}
(conf)# crypto key generate rsa modulus {512/768/1024/2048}
(conf)# end
# wr

Post to Twitter

Rutas estáticas persistentes en Solaris 10

Desde la versión Solaris 10 11/06, se ha facilitado la forma de incluir rutas estáticas persistentes en la tabla de rutas.  Del man de route(1M):

-p             Make changes to the network route tables per-
sistent across system restarts. The operation
is applied  to  the  network  routing  tables
first  and, if successful, is then applied to
the list  of  saved  routes  used  at  system
startup.  In determining whether an operation
was successful, a failure to add a route that
already  exists  or to delete a route that is
not in the routing table is ignored. Particu-
lar  care  should be taken when using host or
network  names  in  persistent   routes,   as
network-based  name  resolution  services are
not available at the time routes are added at
startup.

Si queremos añadir una ruta estática:

# route -p add default 10.230.1.1

Post to Twitter

VMware ESXi, backup de la configuración

Es posible, usando las herramientas vSphere CLI hacer un backup de toda la configuración de un hipervisor ESXi, de forma que podamos recuperar su estado de forma completa ante algún problema, o simplemente por una resintalación.  La forma sería la siguiente:

$ vicfg-cfgbackup --server <servidor_esxi> --save <fichero_de_configuración>

Nos pedirá el usuario y la contraseña para poder hacer la descarga de la configuración.

Mas tarde, si necesitaramos restaurar un ESXi, simplemente hariamos:

$ vicfg-cfgbackup --server <servidor_esxi> --load <fichero_de_configuración>

De nuevo nos pedirá el usuario y la contraseña, y esta vez nos pedirá una confirmación de la acción, ya que la restauración de la configuración sobreescribirá la actual sin que podamos volver atrás.

El sistema hará un reboot del sistema de forma automática para aplicar la configuración.

Post to Twitter

vicfg-cfgbackup -h

Command-specific options:
--force
-f
Force the restore of the configuration.
--load
-l
Restore configuration onto the host
--quiet
-q
Do not prompt for user confirmation.
--reset
-r
Resets host, restore to factory settings.
--save
-s
Backup the host configuration.

Common VI options:
--config (variable VI_CONFIG)
Location of the VI Perl configuration file
--credstore (variable VI_CREDSTORE)
Name of the credential store file defaults to <HOME>/.vmware/credstore/vicredentials.xml on Linux and <APPDATA>/VMware/credstore/vicredentials.xml on Windows
--encoding (variable VI_ENCODING, default 'utf8')
Encoding: utf8, cp936 (Simplified Chinese), iso-8859-1 (German), shiftjis (Japanese)
--help
Display usage information for the script
--passthroughauth (variable VI_PASSTHROUGHAUTH)
Attempt to use pass-through authentication
--passthroughauthpackage (variable VI_PASSTHROUGHAUTHPACKAGE, default 'Negotiate')
Pass-through authentication negotiation package
--password (variable VI_PASSWORD)
Password
--portnumber (variable VI_PORTNUMBER)
Port used to connect to server
--protocol (variable VI_PROTOCOL, default 'https')
Protocol used to connect to server
--savesessionfile (variable VI_SAVESESSIONFILE)
File to save session ID/cookie to utilize
--server (variable VI_SERVER, default 'localhost')
VI server to connect to. Required if url is not present
--servicepath (variable VI_SERVICEPATH, default '/sdk/webService')
Service path used to connect to server
--sessionfile (variable VI_SESSIONFILE)
File containing session ID/cookie to utilize
--url (variable VI_URL)
VI SDK URL to connect to. Required if server is not present
--username (variable VI_USERNAME)
Username
--verbose (variable VI_VERBOSE)
Display additional debugging information
--version
Display version information for the script

Post to Twitter

Actualizar VMware ESXi 4.1 a U1

Para actualizar el hipervisor ESXi, lo primero que tendremos que hacer es parar todas las máquinas virtuales, y activar el modo mantenimiento en el hipervisor.

A continuación descargamos el parche update-from-esxi4.1-4.1_update01.zip de VMware.

Será necesario copiar el parche a un datastore que sea visible por el hipervisor, lo copiaremos por ssh.

Y ahora ejecutamos el parcheo:

# esxupdate --bundle=/vmfs/volumes/1.datastore.local/update-from-esxi4.1-4.1_update01.zip update

Despues del reinicio que hará el proceso de parcheo solo nos quedará quitar el modo mantenimiento al hipervisor.

Post to Twitter

VMware vCenter, “This Host or Cluster is not Valid Selection”

Al intentar convertir una template a VM, en el paso donde elegimos el host o cluster al que asignamos la VM nos da el siguiente error:

“This Host or Cluster is not Valid Selection”

El problema es que la templeta hace referencia a una imagen ISO que no existe o esta mal referenciada.

El problema esta documentado por VMware en este link.

La solución es editar manualmente el fichero de definición de la VM para modificar la referencia rota.

Post to Twitter

Page 2 of 1012345...10...Last »