Cambios en la configuración de nginx y php5-fpm en Debian 8 (Jessie)

Josemaría | 23 de mayo de 2015 | 2 comentarios

nginx Hace unos días, tras actualizar la versión de Debian a Jessie, nginx dejó de funcionar correctamente. Servía sin problemas las páginas estáticas pero cuando trataba de interpretar una página php devolvía una página en blanco sin, aparentemente, ningún error. Ni en ficheros de logs, ni por pantalla, ni nada de nada. Parecía más bien un error de php5-fpm que de nginx o, tal vez, de la forma en que se comunican ambos. Probé la comunicación por puertos TCP en lugar de hacerlo por sockets como lo tenía por defecto y el resultado era el mismo… Así que como me pilló entre semana y con mucho trabajo hice una migración de urgencia a apache y lo dejé pendiente hasta que tuviera un ratito libre.
Hoy ya tocaba y la solución ha sido rápida puesto que el “problema” estaba reportado en la bendita lista de bugs de debian desde hace meses, cuando se detectó durante el testing de la nueva versión. Y pongo “problema” entre comillas porque en realidad se trata de un cambio de estructura a partir de la versión 1.6.2 de nginx (la que acompaña a Jessie) y que viene perfectamente documentado en el fichero index.html que se crea por defecto en el directorio /var/www/html (si, esto también cambia y es la nueva ubicación por defecto para las páginas web).
Existe algún otro cambio pero, para resumir, ahora cuando creas un virtual host que necesita usar php en lugar de usar el bloque de configuración que vimos por aquí hace unas semanas tendrás que usar este:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $request_filename;
    }

Añadir repositorios de paquetes extras a un NAS de Synology

Josemaría | 12 de mayo de 2015 | 5 comentarios

nginx Desde hace más de cuatro años centralizo mis copias de seguridad en un DS411j de Synology (producto ya descatalogado y sustituido por el DS414j. Se trata de un NAS de 4 bahías (de las que tengo ocupadas sólo tres con discos de 2 Teras en RAID5) y que poco a poco se ha convertido en un elemento indispensable para muchas otras tareas aparte de las mencionadas copias. Los NAS de Synology vienen con un sistema operativo propio llamado DSM (Diskstation Manager) que no es más que una distribución de Linux adaptada a estos dispositivos. Es verdad que no es tan flexible como usar FreeNAS u Openfiler, por ejemplo, pero el hardware de Synology es compacto silencioso y barato no demasiado caro. Resultón, vaya. Montar algo parecido por tu cuenta saldría bastante más caro y elegir los componentes adecuados llevaría un tiempo considerable si, como yo, no estás demasiado al día en cuanto al hardware que puedes utilizar para ello.

A lo que vamos. DSM es, como hemos dicho, una distribución Linux y como tal viene con sus propios repositorios de paquetes a los que accedemos a través de una aplicación denominada Centro de Paquetes.

Centro de paquetes de Synology DSM

Como suele ocurrir en sistemas similares, sólo encontramos software validado por el fabricante pero, al igual que en cualquier otro Linux, tenemos la posibilidad de añadir repositorios adicionales con software compilado por terceros. El procedimientos es bastante sencillo. En primer lugar entramos en la pantalla de Configuración (botón arriba a la derecha) y en la pestaña de opciones generales nos aseguramos de marcar la segunda opción en el Nivel de Confianza:

Configuración del Nivel de Confianza en DSM

A continuación pulsamos en la pestaña de Orígenes del paquete y hacemos click en el botón de agregar. La ventana emergente que aparece tiene sólo dos campos: un nombre identificativo y la URL del repositorio. En el ejemplo siguiente estoy añadiendo el repositorio de SynoCommunity cuya URL es http://packages.synocommunity.com/

Añadiendo un repositorio de paquetes en DSM

Y listo. Pulsamos aceptar y veremos una nueva opción llamada Comunidad en el menú lateral del Centro de Paquetes. Si pulsamos en ella veremos el nuevo software que tenemos disponible:

Software de terceros en el Centro de paquetes de DSM

Además del anterior yo tengo instalados dos repositorios más: el de Cphub (https://www.cphub.net/) y el de Synobox (http://synobox.fr.nf/synopackages/) pero hay muchos más. Tienes un par de listas con muchos otros repositorios aquí y aquí.

En cualquier momento puedes consultar y eliminar los repositorios añadidos en la pestaña de Orígenes del paquete vista anteriormente:

Repositorios de paquetes instalados en DSM

Además, cada uno de los repositorios instala al ser añadido un certificado que puedes consultar y/o eliminar desde la pestaña correspondiente:

Certificados de los repositorios de paquetes instalados en DSM

Categorías: howto´s, tecnología
Etiquetas: , , , ,

Chuletillas (y XXXXIII) – Extraer el audio a un vídeo usando ffmpeg o mencoder

Josemaría | 11 de mayo de 2015 | 3 comentarios

chuleta Extraer el audio de un vídeo es otra de esas tareas que realizo de vez en cuando y que siempre tengo que buscar para recordar. Aquí queda la chuletilla de rigor para quién le sirva:

ffmpeg -i video_origen.avi -ab 128000 -ar 44100 audio_destino.mp3

Los dos argumentos usados (-ab y -ar) definen el audio bit rate (Tasa de bits) en bits por segundo y el audio sampling rate (Tasa de muestreo) en Herzios respectivamente y son los que van a definir la calidad del audio (y el tamaño del archivo) de salida. Ten en cuenta que si usas valores más altos de los que trae el audio del vídeo original ffmpeg lo que hará será interpolar los datos necesarios y puede que obtengamos peor calidad que en el original. No se puede sacar de donde no hay, que dice el refran 😉 El comando es válido con cualquier formato origen y/o destino cuyos codecs reconozca nuestro sistema: mkv, avi, mp4, mp3, ogg, wav, etc.

Y si prefieres usar mencoder tienes este otro comando que hace lo mismo:

mencoder video_origen.avi -of rawaudio -oac mp3lame -ovc copy -o audio_destino.mp3
NOTA: El segundo comando está sacado de Commandline Fu, un recurso inestimable para todos aquellos que apreciamos las virtudes de la línea de comandos.

Plugins de nginx y php5-fpm para munin

Josemaría | 5 de mayo de 2015 | 4 comentarios

herramientas Vamos a añadir una nueva entrada a las “sagas” sobre munin y nginx que tenemos abiertas desde hace poco. Concretamente vamos a ver como configurar y hacer funcionar los plugins que nos permitan monitorizar nginx y php-fpm desde munin. Como siempre lo haremos en un Debian (versión 7) y puede que en otra distribución algo sea ligeramente distinto.

Lo primero que debemos de hacer es habilitar la publicación de estadísticas tanto en nginx como en php-fpm. La forma de hacerlo en cada uno es distinta. Para nginx basta con que creemos una directiva como la siguiente en el fichero de definición de uno de los virtual hosts del mismo (típicamente en el virtual host por defecto):

location /nginx_status {
	stub_status on;
	access_log off;
	allow 127.0.0.1;
	deny all;
	}

Las dos últimas líneas sirven para evitar conexiones que no vengan de la propia máquina y podemos quitarlas (o modificar las restricciones) si queremos consultar estas estadísticas en tiempo real desde nuestro propio navegador. Habilitar las estadísticas para php-fpm es un poco más complicado. En primer lugar tenemos que habilitar la publicación de estadísticas en el fichero /etc/php5/fpm/pool.d/www.conf. Las estadísticas están deshabilitadas y para corregir esto basta con descomentar la siguiente línea y modificar el path por el que queramos usar:

pm.status_path = /fpm_status

Luego de nuevo en el fichero de configuración en el fichero de virtual host añadimos la siguiente directiva:

location /fpm_status {
	access_log off;
	include fastcgi_params;
	fastcgi_pass unix:/var/run/php5-fpm.sock;
	allow 127.0.0.1;
	deny all;
	}

Aparte del mismo comentario hecho antes sobre las dos últimas líneas, obtserva que en la línea fastcgi_pass se indica que el acceso a fpm está configurado mediante sockets. Si tu accedes a través de puertos TCP tendrás que modificar esa línea por la correspondiente que, típicamente, suele ser esta:

fastcgi_pass 127.0.0.1:9000;

Una vez hecho esto comprobamos que no hemos cometido ningún error (service nginx configtest) pedimos a nginx que vuelva a leer la configuración (service nginx reload) y probamos que todo está correcto desde línea de comando mediante curl:

Probando la publicación de estado de nginx y fpm-php desde curl

NOTA: fpm tiene unas estadísticas mucho más completas detalladas proceso a proceso que podemos consultar con el siguiente comando:

curl http://localhost/fpm_status?full

El segundo paso sería editar el fichero /etc/munin/plugin-conf.d/munin-node para proporcionar a munin-node las variables de entorno oportunas. Hacemos esto añadiendo los siguientes dos bloques al final del mismo:

[nginx*]
env.url http://localhost/nginx_status

[phpfpm_*]
env.url http://localhost/fpm_status
env.ports 80
env.phpbin php-fpm
env.phppool www

En tercer lugar tenemos que decirle a munin-node que añada los plugins correspondientes. Los de nginx vienen “de serie” y basta con que creemos los enlaces a los mismos en el directorio /etc/munin/plugins como ya hemos hecho otras veces:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/nginx_connection_request
ln -s /usr/share/munin/plugins/nginx_connection_request
ln -s /usr/share/munin/plugins/nginx_request
ln -s /usr/share/munin/plugins/nginx_status

Los de php-fpm tenemos que bajárnoslos desde este enlace. Copiamos los cinco plugins en el directorio /usr/share/munin/plugins y luego creamos los enlaces al directorio /etc/munin/plugins:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/phpfpm_average
ln -s /usr/share/munin/plugins/phpfpm_connections
ln -s /usr/share/munin/plugins/phpfpm_memory
ln -s /usr/share/munin/plugins/phpfpm_processes
ln -s /usr/share/munin/plugins/phpfpm_status

Y ya casi hemos terminado. Sólo tenemos ahora que reiniciar el demonio de munin-node (service munin-node restart) y en unos minutos nos aparecerán las nuevas gráficas bajo las etiquetas de nginx y php:

Gráficos de monitorización de munin para nginx y php5-fpm

Daredevil (y mi amor incontenible hacia Netflix)

Josemaría | 14 de abril de 2015 | 1 comentario

nginx Entre el sábado (tres del tirón) y ayer lunes (1) me he visto ya los cuatro primeros episodios de Daredevil, la nueva serie Marvel producida por Netflix, y he de decir que aunque mis expectativas eran altas han quedado, más que colmadas, rebosadas. Y no soy el único, al parecer: la media de la puntuación por episiodio en IMDB va desde el 8,9 del primero hasta el 9,7 del último.

Daredevil Teaser Poster

En estos cuatro episodios se ve violencia cruda (casi, casi del estilo de una película de Tarantino, así que nada de dejarse ir por el entusiasmo y verla con vuestros pequeños), fabulosas y bastante realistas coregrafías en las peleas (donde el bueno del señor Murdock se lleva unas mantas de palos increíbles) y personajes secundarios bien construidos. Foggy Nelson está para invitarlo a salir, Karen Page y Claire Temple tampoco desmerecen… y el Kingpin interpretado por el enorme Vincent D’Onofrio convence desde los escasos minutos en que hace su aparición al final del tercer episodio y llena la pantalla aún sin necesidad de las decenas de kilos extras con que estamos acostumbrados a verlo en los comics. Las referencias al resto del universo Marvel u otros super heroes se han limitado, por el momento, a la mención indirecta a la llamada “Batalla de Nueva York” con que cierra la primera película de Los Vengadores, pero tampoco se han echado en falta, la verdad. Imagino que irá apareciendo alguna referencia adicional a medida que la serie avance y también nexos de unión con futuros productos de la casa (ahí está la señora Temple, por ejemplo).

La serie, para que nadie se llame a engaños, está más enfocada en el plano de los heroes que en el de los super. No esperes superpoderes, deslumbrantes uniformes ni grandes efectos especiales. Es, por simplificar, la historia de un tipo muy duro que reparte caña entre los malos, disfruta mientras lo hace y luego se atormenta por haberlo hecho. Pero todo muy bien contado, de veras.

Visto lo visto, los trece episodios me van a saber a muy poco, creo. Menos mal que a final de año tendremos disponible la serie dedicada a Jessica Jones y el año que viene la de Powerman. Más tarde llegarán Puño de hierro y, finalmente, una quinta serie sobre los Defensores que unirá a los cuatro personajes anteriores y cerrará la saga. ¡Larga vida a Netflix!

Migrando de Apache 2 a nginx: Virtual Hosts

Josemaría | 25 de marzo de 2015 | 4 comentarios

nginxLos ficheros de definición de Virtual Hosts en nginx se almacenan en directorios muy similares a los de apache. Tenemos un directorio llamado sites-available y otro que se llama sites-enabled y ambos están bajo el directorio principal de configuración que es /etc/nginx. En el primero se deberían de guardar todos los virtual hosts del servidor (estén disponibles o no) y en el segundo aquellos que están activos. La forma correcta de activar o desactivar un Virtual Host debería de ser crear un enlace en el segundo directorio al archivo correspondiente del primero, al igual que en Apache. Para desactivarlo temporal o definitivamente borraríamos ese enlace. La diferencia aquí con apache es que no contamos con comandos similares a los a2ensite y a2dissite que hacen estas operaciones de forma cómoda, pero tampoco se nos van a caer los anillos por hacer un enlace manualmente en línea de comando a estas alturas ¿verdad? Bueno, por si acaso, el siguiente comando realizaría un enlace del fichero de definición de Virtual Host llamado miweb del directorio sites-availabe en el directorio sites-enabled:

ln -s /etc/nginx/sites-available/miweb /etc/nginx/sites-enabled/

Veamos ahora el “esqueleto” de configuración más básico en Apache:

<VirtualHost *:80>
	ServerName www.miweb.com
	ServerAlias blog.miweb.com *.miweb.es
	DocumentRoot /var/www/miweb/
	DirectoryIndex index.php index.html index.htm;
</VirtualHost>

Y su equivalente en nginx:

server {
        listen 80;
        server_name www.miweb.com blog.miweb.com *.miweb.es;
        root /var/www/miweb/;
        index index.php index.html index.htm;
}

Puesto que partimos de que conocemos la sintaxis en Apache no deberíamos de encontrar problemas en entender la de nginx ¿verdad? Sólo un detalle adicional sobre estas líneas. Si tenemos un servidor con más de un interfaz y/o dirección IP y queremos que el servidor web sólo atienda a una de ellas en Apache sustituiríamos la primera línea del ejemplo anterior por esta:

<VirtualHost 123.45.67.89:80>

En nginx haríamos lo propio modificando así la segunda línea:

listen 123.45.67.89:80;

Cualquier configuración adicional del Virtual Host se realizaría incluyendo las directrices adecuadas en el interior del bloque de definición. Veamos algunas de las más comunes. Por ejemplo, si queremos dar una ubicación concreta y separada del lugar donde se almacenan los logs de acceso y error, en Apache lo hacíamos con estas líneas:

CustomLog /var/log/apache2/miweb-access.log combined
ErrorLog /var/log/apache2/miweb-error.log
LogLevel warn

Y en nginx lo haríamos así:

access_log /var/log/nginx/miweb-access.log;
error_log /var/log/nginx/miweb-error.log warn;

El formato del log de accesos por defecto en nginx es idéntico al modo combined de Apache. No obstante, tenemos un montón de opciones adicionales que puedes consultar aquí. Los niveles permitidos para el log de error son, además de warn, error, crit, alert, y emerg.

¿Cómo redefinimos las páginas de error que nos mostrará el servidor web? En Apache usábamos la directiva ErrorDocument:

ErrorDocument 404 /errores/404.html
ErrorDocument 500 /errores/500.html
ErrorDocument 502 /errores/502.html
ErrorDocument 503 /errores/503.html
ErrorDocument 504 /errores/504.html

En nginx usamos error_page:

error_page 404 /errores/404.html;
error_page 500 /errores/500.html;
error_page 502 /errores/502.html;
error_page 503 /errores/503.html;
error_page 504 /errores/504.html;

Si queremos redireccionar varios errores a una misma página podemos hacerlo de esta forma:

error_page 500 502 503 504 /errores/500bis.html;

Veamos ahora como se restringe el acceso a ciertos directorios. En Apache, para denegar el acceso a todo el mundo a un directorio del servidor web lo hacíamos de esta forma:

<Directory /secreto>
        Deny from all
</Directory>

Mientras que en nginx haríamos lo mismo así:

location /secreto {
        deny all;
}

Para restringir el acceso a determinados clientes, en Apache “jugamos” con las directrices Order, Deny y Allow. En nginx no existe ninguna directiva similar a Order. Debemos de poner una a una todas las instrucciones deny y allow que necesitemos. El servidor las analizará una a una y en orden hasta encontrar la primera que “cuadre” con la petición que está atendiendo de forma similar a como se comportaría un cortafuegos. Las siguientes reglas son todas válidas:

location /secreto2 {
    deny  192.168.1.1;
    allow 192.168.1.0/24;
    allow 10.1.1.0/16;
    allow 2001:0db8::/32;
    deny  all;
}

Si lo que queremos es restringir el acceso mediante usuario y contraseña con un fichero generado con htpasswd como hacíamos habitualmente con Apache, podemos hacerlo de forma fácil. El fichero de contraseña lo generamos de la misma forma que ya sabemos (tienes que tener instalado el paquete apache2-utils para contar con esta utilidad) e incluir las siguientes directivas:

location /secreto3 {
    auth_basic "Control de Acceso";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

La línea auth_basic sólo aporta un mensaje de texto que aparecerá en la ventana en la que se nos pide el usuario y contraseña. La directiva auth_basic_user_file es la que marca el lugar y el nombre del fichero que contiene los usuarios y las contraseñas (las hashes de estas, en realidad) autorizadas para acceder al directorio /secreto3 de nuestro Virtual Host.

Si nuestro Virtual Host necesita interpretar páginas en PHP, debemos de pasar estas peticiones al módulo adecuado y tenemos que expecificarlo aquí, y no como ocurría en Apache que se hacía de forma automática con sólo tener activo el módulo php5. Yo uso php5-fpm (aunque existen otras alternativas) y para que funcione debemos de incluir un bloque como este:

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
ACTUALIZACIÓN MUY IMPORTANTE: A partir de la versión 1.6.2 de nginx en Debian 8 (Jessie) el anterior bloque de configuración para php ya no es válido y habría que usar en su lugar este otro.
ACTUALIZACIÓN: PHP-FPM puede usarse con puertos TCP o con sockets. Las ventajas de usar sockets te las cuenta brevemente aquí Javier Terceiro.

En Debian hay que instalar el paquete correspondiente (apt-get install php5-fpm) y asegurarse de que el módulo aceptará las peticiones en la dirección que hemos indicado con la directiva fastcgi_pass. Esto lo comprobamos en el fichero de configuración /etc/php5/fpm/pool.d/www.conf y buscando la línea siguiente:

listen = /var/run/php5-fpm.sock
IMPORTANTE: Si necesitas usar de forma imprescindible ficheros .htaccess este no es tu servidor web. nginx está diseñado para ser rápido y eficiente y no soporta nada parecido. Los .htaccess son cómodos para permitir pequeñas personalizaciones de configuración en servidores compartidos, pero en cualquier otro caso son absolutamente prescindibles y desde el punto de vista de la eficiencia son tremendamente negativos. Piensa que por cada petición que se hace al servidor web, este tiene que recorrer todos los directorios del Virtual Host uno por uno en busca de ficheros de este tipo. Aquí te lo explican muy bien y en este enlace y en este otro tienes herramientas automáticas para ayudarte a migrar las reglas que tengas en ellos a nginx.

Chuletillas (y XXXXII) – Eliminar paquetes huérfanos y dependencias no utilizadas en Archlinux y derivadas

Josemaría | 19 de marzo de 2015 | Comentar

chuleta Hace ya años que sólo uso Archlinux o derivadas en mis equipos de escritorio, ya sean estos portátiles o equipos de sobremesa. Empecé con la propia Archlinux para luego pasar a Chakra y, por último, a Manjaro que es actualmente mi favorita.
El siguiente comando nos permite eliminar todos los paquetes huérfanos y dependencias no utilizadas de forma equivalente a como haríamos en una Debian o derivada con apt-get autoremove:

pacman -Rcns $(pacman -Qdtq)

La segunda parte del comando (pacman -Qdtq) es la que realiza el listado de dependencias inútiles mientras que la primera (pacman -Rcns) las recibe y elimina después de mostrárnos la lista en pantalla y pedirnos confirmación.

NOTA: Por aquí dejé hace algún tiempo una chuleta con los primeros pasos a dar con pacman y ccr que sigue siendo válida. ccr es el gestor de paquetes realizados por la comunidad de usuarios (no oficiales, por tanto) de Chakra. En Archlinux y Manjaro se usa yaourt en lugar de ccr pero el funcionamiento de ambas es bastante similar.

Lo más visto por aquí en 2014

Josemaría | 2 de enero de 2015 | Comentar

icono de calendarioEa, otro año más por aqui para hacer una pequeña lista con los temas que más se han leído en el blog durante los últimos doce meses por si a mi lector se le ha pasado alguno por alto. Mi ritmo de publicación ha caído tanto que al final los peperos van a tener razón con eso de la baja productividad del país. Con una media de dos entradas al mes (un tercio menos de lo que publiqué en 2013) este blog está predestinado a extinguirse en un par de años. Menos mal que Google no es tan bueno como dicen (¿tampoco lo sabes ya?¿y se supone que mis lectores tienen un alto perfíl técnico?¡Buffff!) y me sigue permitiendo vivir de las rentas… En fin que allá vamos a hacer el repaso este y con él a sentar buenos propósitos de prolífica actividad para este 2015. Como todos los años, vaya 😉

nginx Por aquello de terminar un año y empezar el siguiente con cambios y nuevos propósitos, ayer comencé a migrar la infraestructura que da soporte a este blog a nginx. Si has pasado por aquí en las últimas horas habrás podido experimentar problemas debido a los cambios. Ahora parece ya casi totalmente estable pero dista aún de estar optimizado y habrá que trabajar un poco mas en ello... Y bueno, ya que estamos, feliz año y tal ;-) (1 comentarios)

Instalando Oracle 11g R2 en Debian 7 Wheezy

Josemaría | 10 de noviembre de 2014 | 5 comentarios

Oracle Preguntadlo por ahí y, posiblemente, cualquier administrador de sistemas coincidirá conmigo en que una instalación de Oracle en Linux es una de las cosas más desagradables e ingratasque puedes querer hacer en estos temas. Máxime si pretendes realizarla en una distribución de Linux no soportada directamente por Oracle (Solaris, Red Hat, Suse y alguna mas…). Pero de vez en cuando toca hacerla, que remedio. En esta entrada vamos a ver de forma guiada y paso a paso una instalación de Oracle 11g R2 (11.2.0.1.0) en una Debian Wheezy (7.7) de 32 bits (haciendo pequeñas anotaciones para que también sirva para una de 64) de forma tan “masticada” que es imposible que te falle nada. ¡Manos a la obra!

Los requisitos hardware iniciales no son demasiado exigentes. Oracle funcionará sin problemas en una máquina con 1,5Gbytes de RAM y 20 Gbytes de disco duro (que son las características de la máquina virtual que voy a usar en este ejemplo). Pero cuidado: la partición de swap debería de ser de aproximadamente 1,5 veces el tamaño de la RAM (algo más de 2Gbytes en este caso), debemos de tener al menos 2Gbytes libres en el directorio /tmp durante el proceso de instalación y los binarios de Oracle ocuparan en su ubicación final algo más de 5 Gbytes, así que si tu disco usa diferentes particiones para estos directorios has de cuidar que el reparto de espacio entre ellos sea el adecuado.

En cuanto al software, partiremos de una Debian recien instalada y sólo con el sistema base aunque, durante el proceso, instalaremos algunos paquetes adicionales y un entorno de ventanas ligero para realizar la instalación desde un entorno gráfico.

Empezaremos por instalar los paquetes de dependencias necesarias que son estos:

apt-get install build-essential sysstat unzip libstdc++5 pdksh numactl expat libaio-dev  unixodbc-dev  lesstif2-dev elfutils libelf-dev

Además, como acabamos de decir instalaremos un entorno de ventanas ligero para realizar la instalación desde el entorno gráfico y un navegador para posteriormente poder acceder a la consola de administración:

apt-get install xfce4 chromium

Vamos ahora a modificar algunos de los parámetros de configuración del kernel editando el fichero /etc/sysctl.conf y añadiendo al final del mismo las siguientes líneas:

kernel.shmmax=536870912
kernel.shmall=2097152
fs.file-max=6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586
fs.aio-max-nr = 1048576
kernel.sem = 250 32000 100 128

Para que tomen efecto las modificaciones en este fichero sin necesidad de reiniciar ejecutamos ahora lo siguiente:

sysctl -p

El instalador de Oracle también nos pedirá que lo ejecutemos desde un runlevel entre el 3 y el 5 mientras que Debian usar el 2 por defecto. Para evitar esta advertencia editaremos el fichero /etc/inittab y, en una de las primeras líneas, hacemos el cambio para usar, por ejemplo, el 3:

id:3:initdefault:

Para modificarlo también en la sesión actual sin necesidad de reiniciar ejecutamos lo siguiente:

telinit 3

Y ahora una pequeña “trampa”. Para que Oracle no se de cuenta demasiado de que estamos haciendo la instalación en una distribución no soportada crearemos unos enlaces en el sistema de ficheros de forma que se encuentre determinados archivos y librerías donde espearía encontrarselos si la instalación se estuviera realizando, por ejemplo, en una Red Hat:

ln -s /usr/bin/basename /bin/basename
ln -s /usr/bin/awk /bin/awk
ln -s /usr/lib/i386-linux-gnu/libpthread_nonshared.a /usr/lib
ln -s /usr/lib/i386-linux-gnu/libc_nonshared.a /usr/lib
ln -s /lib/i386-linux-gnu/libgcc_s.so.1 /lib
ln -s /usr/lib/i386-linux-gnu/libstdc++.so.6 /usr/lib
NOTA: Si estamos instalando sobre una Debian de 64 bits sustituiremos los últimos cuatro enlaces por los siguientes:

ln -s /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a /usr/lib64/
ln -s /usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib64/
ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib64/

Vamos ahora a crear un usuario llamado oracle y un grupo llamado dba. Este será el usuario que usaremos para la instalación y posterior administración de nuestra base de datos. Para hacerlo ejecutamos lo siguiente:

groupadd dba
useradd -d /home/oracle -m -g dba -G dba -s /bin/bash oracle

Para asignarle contraseña a este nuevo usuario:

passwd oracle

Ahora creamos los directorios donde realizaremos nuestra instalación:

mkdir -p /opt/oracle/product/11.2.0.1
mkdir /opt/oraInventory
mkdir /opt/oradata

Y asignamos como propietario y grupo los que acabamos de crear unos instantes antes:

chown oracle:dba -R /opt/oracle /opt/oraInventory /opt/oradata

Alteramos ahora algunas de las limitaciones impuestas a este nuevo usuario que hemos creado editando el fichero /etc/security/limits.conf y añadiendo las siguientes líneas al final del mismo:

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240

Y por último, en lo que a este nuevo usuario se refiere, editamos el fichero /home/oracle/.profile y añadimos sl final las siguientes variables de entorno:

export ORACLE_HOSTNAME=localhost
export ORACLE_OWNER=oracle
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=/opt/oracle/product/11.2.0.1
export ORACLE_UNQNAME=orcl
export ORACLE_SID=orcl
export PATH=$PATH:$ORACLE_HOME/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/i386-linux-gnu:/bin/lib:/lib/i386-linux-gnu/:/usr/lib
NOTA: Si en lugar de estar haciendo la instalación sobre una debian de 32 bits lo estuviéramos haciendo sobre una de 64 tendríamos que modificar la última variable de entorno por la siguiente:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu:/bin/lib:/lib/x86_64-linux-gnu/:/usr/lib64

Y ya casi casi tenemos todos los preparativos listos. Ahora copiamos los archivos de instalación de Oracle de su página de Training Eval y los dejamos en el directorio /tmp de la máquina.

IMPORTANTE: ¡Asegúrate de descargarte los archivos adecuados! Recuerda que en este ejemplo estamos usando la versión 11.2.0.1.0 de 32 o de 64 bits.

Descomprimimos los dos archivos que nos hemos bajado sobre el directorio /home del usuario oracle:

unzip /tmp/linux_11gR2_database_1of2.zip -d /home/oracle
unzip /tmp/linux_11gR2_database_2of2.zip -d /home/oracle

Y luego borramos los .zip para que no nos ocupen espacio:

rm /tmp/linux_11gR2_database*.zip

Ahora ya si cambiamos al usuario oracle para realizar la instalación:

su - oracle

Y entramos en el entorno gráfico:

startx

Ya en las xfce y desde un terminal ejecutamos el instalador de Oracle:

/home/oracle/database/runInstaller

Tomaremos casi siempre los valores por defecto de la instalación a menos que te manejes bien con los conceptos de esta base de datos y sepas lo que estás haciendo. Además, muchos de los valores básicos los tomará de las variables de entorno que hemos creado anteriormente en el profile del usuario oracle.
En el tercer pantallazo tendremos que introducir la contraseña del administrador: la del usuario SYS. No la olvides aunque luego, en uno de los pasos finales, tendremos la opción de cambiarla y/o modificarla.

Oracle

Posteriormente en la comprobación de requisitos nos marcará varios fallos relativos a programas que parece no encontrar pero que, sin embargo, hemos instalado previamente. Esto es normal debido a las diferencias de rutas entre Debian y Red Hat. Estos deberían de ser los únicos errores que se nos presentarán si hemos hecho correctamente todo el proceso anterior. Nos aseguramos de ello y, si es así, marcamos el check de Ignorar todo y proseguimos la instalación.

Oracle

A mitad de la instalación nos aparecerá un error como el del pantallazo siguiente. No pulses ningún botón aún y no te pongas nervioso que tiene solución 😉

Oracle

Abrimos un terminal y editamos uno de los scripts que está usando el instalador. Este: /opt/oracle/product/11.2.0.1/sysman/lib/env_emagent.mk . En torno a la línea 2764 nos encontraremos algo así:

NMEFET_STACKLIBS_LINK=$(LDPATHFLAG)$(ORACLE_HOME)/$(LIBDIR)  $(LDPATHFLAG)$(PRODLIBHOME) $(LLIBNMEMSO) $(LLIBCORE) -Wl,-rpath,$(AGENTRPATH):$(JAVA_RTLINK_PATH) $(LIB_JVM_LINK) -Wl,--allow-shlib-undefined

Debemos de añadir el argumento -lnnz11 de forma que quede así:

NMEFET_STACKLIBS_LINK=$(LDPATHFLAG)$(ORACLE_HOME)/$(LIBDIR)  $(LDPATHFLAG)$(PRODLIBHOME) $(LLIBNMEMSO) $(LLIBCORE) -lnnz11 -Wl,-rpath,$(AGENTRPATH):$(JAVA_RTLINK_PATH) $(LIB_JVM_LINK) -Wl,--allow-shlib-undefined

Salvamos el fichero y, ahora así, volvemos a la ventana de advertencia anterior y pulsamos el botón de Reintentar. La instalación debería de proseguir ahora ya sin problemas.

NOTA: Gracias a Gaius por este “truco de magia” así como por otras importantes referencias que me han ayudado a confeccionar esta chuleta.

En unos minutos accederemos a la ventana final del instalador donde se nos mostrará un resumen y se nos permitirá modificar bloquear y desbloquear usuarios por defecto y/o modificar las contraseñas de los mismos:

Oracle
Oracle

Y, ahora ya si por último, el instalador nos pedirá que lancemos un par de scripts adicionales de forma manual como usuario root (recuerda que toda la instalación desde el entorno gráfico la estamos haciendo con el usuario oracle que hemos creado previamente).

Oracle

Abrimos otro terminal distinto al que estamos usando para el instalador y ejecutamos lo que se nos pide:

su
/opt/oraInventory/orainstRoot.sh
/opt/oracle/product/11.2.0.1/root.sh

Y ya hemos terminado. Ahora para acceder a la base de datos puedes usar SQL*Plus desde la línea de comandos o la consola de administración gráfica desde el navegador a través de la URL https://localhost:1158/em y usando la contraseña del usuario SYS (conectando como SYSDBA) que has proporcionado durante la instalación.

Oracle
Oracle

Unas notas para terminar. La instalación no configura a Oracle para que arranque por defecto tras un reinicio del sistema. Es decir, cada vez que hagamos un reboot de la máquina tendremos que volver a levantar los servicios manualmente. Tres son los componentes básicos a considerar: el llamado “listener” de Oracle (el proceso principal que proporciona la conectividad con las bases de datos), la consola de administración y la propia base de datos en si. Para levantar el primero tenemos disponible un script llamado dbstart en el directorio /opt/oracle/product/11.2.0.1/bin. Habiendo hecho logon con el usuario oracle ejecutamos lo siguiente:

dbstart $ORACLE_HOME

Y para detenerlo:

dbshut $ORACLE_HOME

Para arrancar y parar manualmente la consola de administración tenemos que abrir el script de arranque (en el fichero /opt/oracle/product/11.2.0.1/bin/emctl ) y modificar el shebang para indicar que usaremos bash, que es el shell por defecto que hemos elegido para el usuario oracle:

#!/bin/bash -f

Salvamos el fichero y, ahora si, para arrancar la consola usamos este comando:

emctl start dbconsole

Y para detenerla:

emctl stop dbconsole

Para levantar la base de datos podemos usar SQL*Plus como se nos indica aquí o entrar en el entorno gráfico y hacerlo desde la consola de administración. Si entramos en la consola nos advertirá de que la base de datos no está levantada:

Oracle

Pulsamos el botón de Startup (arriba a la derecha) y en la ventana resultante nos autenticamos usando las credenciales del usuario oracle del sistema operativo:

Oracle

Se nos pedirá confirmación de la operación y, si la damos, la base de datos se levantará y estará ya lista para su uso.

Categorías: bases de datos, howto´s, tecnología
Etiquetas: ,