Have you tried turning it off and on again?
Para abacar la semana, me ha tocado lidiar con un servidor Tomcat 5 recién montado, con una de las tareas más usuales que te pueden pedir: «cambiar la aplicación por defecto de Tomcat para que muestre mi_aplicación, además de responder por el puerto 80 en lugar del 8080».
La documentación oficial explica perfectamente cómo hacer ésto.
Una pregunta que me ronda por la cabeza es si es realmente necesario realizar algún tipo de actuación, al migrar una aplicación de un servidor a otro, en cuanto al certificado SSL estándar (de los que no realizan validación contra la autoridad certificadora, una vez emitido el certificado) se refiere, si no cambia el dominio y se mantiene el entorno (léase, si migramos de un servidor Red Hat/Apache a un CentOS/Apache, por ejemplo).
Pongamos el ejemplo de una página web con un certificado SSL para el dominio www.midominio.com. De esta manera, al entrar a https://www.midominio.com, se validará el certificado SSL. Si tenemos este certificado en un servidor en Amazon EC2 que resuelve el dominio www.midominio.com, y queremos migrar este servidor a un nuevo hosting, por ejemplo RackSpace, ¿tendríamos que realizar alguna actuación con el certificado SSL? Para generarlo, bien que tuvimos que generar una petición CSR desde el servidor de Amazon EC2. ¿O bien bastaría con copiar los archivos .key y .crt al nuevo servidor en RackSpace?
Vuelvo a usar por enésima vez la misma imagen para un post sobre MongoDB. Esta vez, veremos cómo actualizar todo un clúster mongo de la versión 2.0.1 a la 2.0.4.
En primer lugar revisaremos qué posibilidades tenemos para actualizar mongo con
yum search mongo
A continuación, miraremos la versión de mongo que nos ofrece yum, para confirmar que coincide con la deseada:
yum info mongo-10gen
Paquetes disponibles
Name : mongo-10gen
Arch : x86_64
Version : 2.0.4
Una vez estemos seguros, seguiremos el proceso descrito en este otro post, que básicamente sigue estos pasos cuando se tiene un entorno con ReplicaSets y Sharding:
Si partimos de un entorno con sharding y replica sets, es posible que tengamos un entorno con un único mongos y un único config_server, cuando idealmente deberíamos tener 3 config_servers y tantos mongos como servidores de aplicaciones que conectan con mongo (idealmente, cada servidor de aplicaciones tendrá su propio mongos local). Ésta no es una situación extraña, puesto que se recoge en la documentación oficial de mongo, «Upgrading from one config server to three«.
Si ya se dispone de un entorno en producción como el anterior, se deberá seguir el siguiente proceso para añadir los config_servers y mongos extras:
En este post se trata de dar una idea de los que pueden ser los primeros pasos a dar tras la instalación de un servidor Apache con PHP.
En primer lugar, podríamos mirar el archivo de configuración del php en busca de las líneas correspondientes a la gestión de la visualización de los mensajes de error. Se recomienda que ambos parámetros estén a Off si se quiere evitar que tras un error en el servidor, se le muestre al usuario el código relativo al error, o incluso el fragmento de código php que lo ha provocado:
display_errors = Off
display_startup_errors = Off
Con el comando «virsh» se pueden gestionar las máquinas virtuales en un entorno qemu-kvm. Para ello, únicamente tendremos que conectar, ya sea de forma remota o como en el ejemplo, de forma local, mediante virsh:
[root@server ]# virsh -c qemu:///system
Bienvenido a virsh, la terminal de virtualización interactiva.
Ingrese: ‘help’ para obtener ayuda con los comandos
‘quit’ para salir
virsh #
Hoy tengo el placer de publicar un post escrito por Gabriel Becerra Gottlieb especialmente para este blog. A disfrutarlo.
¿A cuántos de vosotros más de una vez se os ha quedado colgado un Linux y habéis tenido que hacerle un “botonazo”?
Pues debéis saber que Linux cuenta con la posibilidad de apagar el sistema de forma “segura” delante de un cuelgue inesperado o un kernel panic con las llamadas “Las Magic Keys o Claves Mágicas”.
Como todos sabemos, los kernel panic, son los sucesos más preocupantes en un Linux puesto que dependiendo del sistema de ficheros o volumen de información que se maneje, puede provocar una pérdida de información de muy difícil solución, aquí es donde entra esa tecla que acostumbra a pasar desapercibida en nuestros teclados, la tecla “Pet Sys” (en algunos teclados no existe como tal pero es la misma que la de “Impr Pant”). En muchas distribuciones vienen activadas por defecto, pero podéis activarlas en todas.
Listado
rpm -qa --qf "%-20{NAME} %-10{VERSION} %12{SIZE} %{SUMMARY}\n"
Checkear un paquete concreto:
rpm -q nombrepaquete
Más info:
Leo en twitter un comando para conocer de forma rápida si una máquina Linux es de 32 o 64 bits. Únicamente bastará con ejecutar en la terminal el siguiente comando:
getconf LONG_BIT
Ésto nos devolverá un escueto «32» o «64», que es justo lo que queríamos saber.
Fuente: http://twitter.com/#!/linuxtotal
Hoy me lanzo a la piscina con un paso a paso para instalar un servidor LAMP (Linux, Apache, Mysql, Php) y realizar los primeros pasos, en entornos tipo servidor Red Hat (Fedora, CentOS, etc.). Hay muchas formas de hacer ésto, pero la descrita a continuación siempre me suele funcionar:
Primer paso, instalar todos los componentes con yum:
yum install -y httpd php mysql-server mysql php-mysql