Instalación de los paquetes

Para administrar el servicio usaremos xinetd, así que además de los paquetes propios de TFTP instalaremos a este (atentos al -y que asume que sí a todas las peticiones y no pregunta):

sudo apt-get install xinetd tftpd tftp -y

Configuración

Una vez instalado, creamos el fichero tftp dentro de /etc/xinetd.d/. Por ejemplo:

sudo vi /etc/xinetd.d/

Dentro del fichero indicamos:

service tftp
{
   protocol = udp
   port = 69
   socket_type = dgram
   wait = yes
   user = nobody
   server = /usr/sbin/in.tftpd
   server_args = var/lib/tftpboot -s
   disable = no
}

Como podéis ver, estamos estableciendo un directorio raíz para el servidor, en concreto, /var/lib/tftpboot por lo que deberemos crearlo y darle los permisos, usuarios y grupos oportunos:

sudo mkdir /var/lib/tftpboot
sudo chown -R nobody:nobody /var/lib/tftpboot
sudo chmo7 -R 777 /var/lib/tftpboot

Si os da error de grupo no existente, lo creamos:

sudo addgroup nobody

Reinicamos xinetd para que los cambios surtan efecto:

sudo service xinetd stop
sudo service xinetd start

Pruebas

Pasamos a la parte de las pruebas. Primero intentamos subir un fichero a nuestro servidor. La idea es la siguiente:

• Tenemos un fichero: foto.jpg en nuestro escritorio
• La subo al servidor
• Debe aparecer la foto en el directorio que hemos creado

Los pasos a dar son los siguientes. Comenzamos por iniciar sesión con el cliente de consola en el servidor, paso seguido subimos el fichero y salimos:

tftp localhost
tftp> put foto.jpg
q

La idea es comprobar que el fichero se ha subido al directorio oportuno. Ahora para completar la prueba hacemos el proceso inverso:

cd cualquier_otro_directorio
tftp localhost
tftp> get foto.jpg

La foto debe estar en ese otro directorio.

Posibles problemas

Os comento algunos problemas que pueden apareceros:

• Error code 2: Access violation
• File not found

A priori con el tema de los permisos no deberían salir, pero si aún así, si tenéis problemas, vía comentarios de esta entrada podemos ir resolviéndolos.

La solución es usar un servidor SMTP externo, aquí mismo explicamos cómo hacer uso del servidor SMTP de Gmail para usarlo dentro de WordPress, pero vamos a explicaros un método válido para cualquier aplicación que desarrolléis con PHP.

Lo primero que tenemos que hacer es descargar la clase que se encargará del trabajo, es software libre bajo licencia GPL, hablamos del proyecto PHPMailer. Descargamos la última versión disponible para nuestra versión de PHP (aquí hablaremos de la versión más actual, la que corresponde con PHP 5) y descomprimimos.

La clase tiene otras funcionalidades, pero nosotros como sólo vamos a enviar correo, usaremos el código de los ficheros:

• class.phpmailer.php
• class.smtp.php

El procedimiento es el siguiente: incluimos los ficheros en cuestión, instanciamos un objeto, asignamos sus atributos (asunto, remitente, destinatario, cuerpo del mensaje) y finalmente ejecutamos un método que lo envía.

Veamos un ejemplo completo:

require(‘class.phpmailer.php’);
require(‘class.smtp.php’);
$mail = new PHPMailer();
$body = “Cuerpo del mensaje”;
$mail->IsSMTP();
// la dirección del servidor, p. ej.: smtp.servidor.com
$mail->Host = “direccion_servidor”;
// dirección remitente, p. ej.: no-responder@miempresa.com
$mail->From = “Dirección_remitente”;
// nombre remitente, p. ej.: "Servicio de envío automático"
$mail->FromName = “Nombre_remitente”;
// asunto y cuerpo alternativo del mensaje
$mail->Subject = “Asunto”;
$mail->AltBody = “Cuerpo alternativo
    para cuando el visor no puede leer HTML en el cuerpo”;
// si el cuerpo del mensaje es HTML
$mail->MsgHTML($body);
// podemos hacer varios AddAdress
$mail->AddAddress(“dirección_destino”, “Nombre_destino”);
// si el SMTP necesita autenticación
$mail->SMTPAuth = true;
// credenciales usuario
$mail->Username = “Usuario”;
$mail->Password = “Contraseña”;
if(!$mail->Send()) {
echo “Error enviando: ” . $mail->ErrorInfo;
} else {
echo “¡¡Enviado!!”;
}

Introducción

Como en otros tantos aspectos de las nuevas tecnologías, en el mercado del hosting, tenemos varias posibilidades en cuanto a sistema operativo se refiere. Las dos mayoritarias a día de hoy, GNU/Linux y Microsoft Windows, se reparten una gran cuota de mercado lo que no quiere decir que no existan otras alternativas, como por ejemplo servidores basados en NetBSD o FreeBSD. En este artículo veremos desde el punto de vista de cliente de una empresa de hosting, qué puede hacer que nos decantemos entre una u otra opción.

A priori, cualquier linuxero (entre los que me incluyo) no pensaría en ningún momento en usar un servidor basado en Internet Information Services (el servidor web de Microsoft) sobre un Microsoft Windows Server 2008. Sin embargo, os puedo asegurar que hay circunstancias en las que no sólo es recomendable usar esta opción, sino necesario. De todas maneras si nosotros somos los que elegimos la tecnología a usar y no nos imponen ciertas restricciones (si estamos trabajando para alguien) un poco “especiales”, en líneas generales podríamos decir que la mejor opción es usar GNU/Linux.

Veamos a continuación, desglosados un poco más los detalles que pueden hacer que nos decantemos por una alternativa o por otra.

Precio

Puesto que a la hora de la verdad en todo lo referente a negocios privados, el aspecto más determinante de todos es el presupuesto, comencemos por el precio medio de los hosting. Dado que para poder tener un servidor corriendo bajo Microsoft Windows Server 2003 o 2008, hace falta pagar una licencia comercial y a un precio que no es bajo ni mucho menos, los hosting que ofrecen sistemas Windows suelen ser más caros que los basados en GNU/Linux. Antes de seguir me gustaría aclarar que hay muchas empresas que venden hosting con las dos posibildiades y uno a la hora de contratarlo, elige cuál le interesa.

Siguiendo con el tema económico, hay que contar que en un servicio de hosting, el precio que se paga por un sistema o por otro, no es sólo la licencia del sistema operativo en sí. Hay muchos factores aparte como por ejemplo, el coste del soporte, el gasto energético o la necesidad de comprar licencias de terceros programas, entre otras.

El coste del soporte era una de las excusas esgrimidas por Microsoft sobre el coste real de mantener un servidor en GNU/Linux, porque afirmaban que el soporte era bastante más caro que en GNU/Linux. Sin embargo, debido a la mayor automatización de muchos procesos en GNU/Linux y lo que es más importante, a su mayor difusión, cada vez el soporte es más barato y fácil para este sistema.

En cuanto a los otros factores que hemos también mencionado, el gasto de energía y la necesidad de comprar licencias a terceros, decir de la primera que para ver un consumo de energía real habría que hacer una serie de test y benchamarks con mucha exactitud para poder emitir un juicio objetivo. En el segundo caso, en el de comprar software de terceros, en Windows suele ser más frecuente esta necesidad, aunque en GNU/Linux también puede darse este caso y por supuesto, en ambos se puede utilizar software libre para satisfacer muchas necesidades.

Seguridad

Se ha hablado tantísimo de este aspecto, comparando además a Windows y a Linux, que creo que no es necesario dar mucha información. La seguridad de los sistemas GNU/Linux está más que contrastada, más aún en ambientes de hosting; y además la facilidad de actualización que tiene el software instalado en este sistema hace que ante cualquier versión nueva que tape algún agujero, la actualización sea rápida y no haya de por medio problemas como obligar a reiniciar el servidor.

Este y otros muchos detalles, provenientes de un sistema que nació en un ambiente profesional, hacen de GNU/Linux el ganador por diferencia de este apartado.

Eficiencia

Este aspecto depende mucho del hardware que se use en la máquina en la que resida el servidor así como de la línea que tenga contratado con su ISP (proveedor de servicios de Internet) nuestro servicio de hosting. A priori puede que GNU/Linux distribuya mejor la carga de trabajo que Microsoft Windows, pero es un aspecto que más que preocuparnos a nosotros que somos los que contratamos el host debe preocuparle al que ofrece el servicio.

También es verdad que cada vez son más las aplicaciones web basadas en tecnologías no tan eficientes como PHP, por ejemplo Ruby On Rails o Python (bastante más eficiente que Ruby pero aún así más lento que PHP) con Django o Turbo Gears; que requieren una mayor cantidad de recursos.

Posibilidades y necesidades específicas

En este punto es donde quizás nos tengamos que decantar por una solución Microsoft Windows por obligaciones de los requisitos. Imaginemos que necesitamos usar por obligación una base de datos SQL Server, de Microsoft. Ante este caso, dado que este sistema gestor de base de datos sólo ejecuta en el sistema operativo de Microsoft, estaremos obligados a usar un host con Windows Server que ofrezca esta posibilidad. También es verdad que éste no suele ser el caso más común, por fortuna, y que para muchísimas otras circunstancias, la solución correcta es Linux, por razones casi idénticas. Por ejemplo, a día de hoy, es difícil encontrar un sistema basado en Windows que ofrezca soporte para ejecutar aplicaciones web implementadas con Ruby o Python, dos tecnologías en alza.

Por lo tanto en este apartado, dependiendo de nuestro caso deberemos elegir una plataforma u otra, aunque como repito en la mayor parte de los casos el resultado es favorable para GNU/Linux. De hecho, en mi caso personal, por ejemplo, nunca elegiría trabajar con ASP.NET y SQL Server, por ejemplo, pudiendo trabajar con tecnologías libres que cubren las mismas necesidades ya que además de resultarme más barato, dispongo de una cantidad de documentación y soporte mucho mayor (aparte de que las tecnologías de Microsoft no son código abierto). Sin embargo, si tenemos un encargo profesional y por razones ajenas a nosotros hay que utilizar dichas tecnologías, tendremos que dencantarnos por un host con Windows Server.

Adaptabilidad

Normalmente, las tecnologías libres suelen estar mejor estandarizadas que sus equivalentes propietarias, por lo que de cara a migrar datos de un sistema gestor de base de datos a otro distinto, o a la hora de cambiar el servidor, si estamos operando con un host que trabaje con GNU/Linux, posiblemente se nos presenten menos problemas.

Futuro

Tanto el soporte como las nuevas versiones de software, están prácticamente aseguradas en los dos sistemas. Los costes de actualización de una versión a otra en el caso de software privado, no os repercutirán demasiado, dado que al igual que el coste de la licencia, estos son gastos que paga la empresa a la que contratamos. Por esta razón suelen ser más caros los servicios de host basados en sistemas Windows. Aparte de eso, aunque este es un tema importante a la hora de elegir un servicio de host, el asegurarnos que el software está siempre actualizado y alejado de posibles vulnerabilidades, no existen diferencias de un sistema a otro.

Conclusiones

A lo largo del artículo, habréis observado que para la mayor parte de las necesidades, excepto para las que necesitan expresamente ciertas tecnologías como .NET, podemos usar GNU/Linux por multitud de razones. Comenzando por el precio, terminando en la seguridad y pasando por variedad de otros aspectos como por ejemplo la capacidad de adaptación, GNU/Linux suele ser el más idóneo o en casos extraños, estar al nivel de su rival. También es cierto que como digo haya aplicaciones que por cuestiones de los requisitos necesiten sistemas Windows o en todo caso ejecuten con Mono (no os lo recomiendo si vais a usarlo como un sistema en producción y no en pruebas o de uso personal). En un futuro, también habrá que tener en cuenta aspectos como la virtualización en servidores, tecnología bastante avanzada ya pero que no se ofrece en muchos servicios de host.

Elegido el sistema, tenéis que elegir la empresa de hosting que contratar. En otros artículos os contarán mejor cómo seleccionar a dicha empresa de entre todas las que se ofertan en la red, pero como primer paso os recomiendo no comprobar sólo la cantidad de servicios que ofrecen, sino la calidad de los mismos.

Por último, os dejo unos cuantos enlaces en la sección “En la red”, de servidores web disponibles para GNU/Linux y un poco más de información para que leáis en la red sobre las versiones de servidor de Microsoft Windows y el servidor web que usan, Internet Information Services.

Preparé una máquina virtual con Xen, preparé el almacenamiento en mis módulos SAS, configuré el direccionamiento del mismo y arranqué la máquina. ¿Qué me quedaba por instalar y configurar? Un servidor Samba. Veamos cómo hacerlo.

El siguiente procedimiento vale sobre cualquier distribución de GNU/Linux. Sólo deberéis cambiar ciertos detalles de sistemas de paquetes, pero el método es el mismo y es una solución genial. Multitud de empresas u organizaciones disponen de un servidor Linux y de clientes finales con Microsoft Windows. Tanto si el cliente final es Windows como si es Linux o Mac OS, esta solución provee un método sencillo, robusto y fiable para implantar algo tan necesario como almacenamiento en red (ya sea para copias de seguridad, para trabajo en equipo, para crear un repositorio central o para lo que se busque).

He usado Scientific Linux, por lo que será el mismo procedimiento en Fedora, Red Hat, Cent OS y derivados. En Ubuntu, Debian y derivadas usaremos apt y el resto, sus propios paquetes (o compilaciones del fuente).

Instalación de los paquetes

Lo primero será instalar los paquetes necesarios. Hablamos de:

• samba: servidor SMB
• samba-client: clientes para el protoclo SMB
• samba-common: ficheros comunes a ambos

Hacemos lo siguiente:

yum install samba samba-common

Y en los clientes:

yum install samba-client samba-common

En los clientes Windows no es necesario instalar nada.

Alta de usuarios

Los usuarios de Windows, deberán darse alta con el mismo usuario que usan en Windows, es decir, si se llama “Javier” su usuario Windows, “Javier” deberá ser su usuario Samba. Podéis evitar esto haciendo un conector, yo he implementado uno en .NET que me resuelve esta cuestión pero lo más simple, es usar el mismo nombre.

Veamos, lo primero será crear el usuario:

useradd -s /sbin/nologin nombre-usuario

Indicamos que no puede iniciar sesión en la parte de la shell porque suponemos que a un servidor SAMBA no se van a conectar por SSH o Telnet. Si sí van a hacerlo, sería de la siguiente forma (incluimos la creación de contraseña para el usuario):

useradd -s /bin/bash nombre-usuario
passwd nombre-usuario

Una vez el usuario existe en el sistema, indicamos que es un usuario de SAMBA y creamos su contraseña para acceder al sistema SAMBA.

smbpasswd -a nombre-usuario

Introducimos la contraseña y estará todo listo.

Configuraciones en smb.conf

El fichero smb.conf, controla a través de opciones especificadas en texto plano, como les gusta a los puristas Unix (a mí también), las opciones. Lo editamos con el editor que queramos y cambiamos las opciones según nos interese. Está situado en el directorio /etc/samba.

Veamos los más importantes para una configuración rápida y básica:

• workgroup: grupo de trabajo
• server string: cadena del servidor que anuncia cuando te conectas a modo de anuncio (parecido a lo que hacen los servidores FTP)
• hosts-allow: lista de direcciones que podrán conectarse

Directorios compartidos

Dentro de este mismo fichero, encontramos las directrices que permitirán compartir los directorios. La siguiente orden, hace que cada usuario tenga accesible a través del servidor SAMBA su propio directorio $HOME:

[homes]
        comment = Home Directories
        browseable = yes
        writable = yes
;       valid users = %S
;       valid users = MYDOMAIN\%S

Dejando comentados valid users todos los usuarios por defecto tendrán acceso. Si queremos especificar un directorio más a compartir, simplemente añadiremos:

[nombre_directorio]
        comment = Otro directorio que estamos compartiendo
        path = /ruta/directorio
        public = no
        writable = yes
        browseable = yes

Podemos controlar mediante la política de permisos de directorios de Unix (permisos, grupos y usuarios) quiénes podrán escribir y quienes no sobre dicho directorio.

Inicio, parada y arranque por defecto del servicio

Para iniciar el servicio haremos:

service smb start

Para pararlo:

service smb stop

Y para reiniciarlo:

service smb restart

Ahora deberemos incluirlo en el arranque, para asegurarnos de que todo funciona correctamente tras los diferentes reinicios:

chkconfig smb on

Conexiones desde clientes

Veamos una a una las posibilidades que tenemos para conectarnos (suponiendo que hay direccionamiento y no hay problemas de cortafuegos).

Desde Linux con la terminal

Con smbclient:

smbclient //direccion_maquina/usuario -U usuario

El recurso puede ser el mismo, por ejemplo para su $HOME:

smbclient //direccion_maquina/recurso -U usuario

Desde Linux usando Nautilus (el explorador de ficheros de Gnome)

Nos dirigimos a la barra de direcciones, si tenemos los directorios desplegados en forma de botones en la parte superior, presionamos “Control+L” y listo, aparecerá una barra de direcciones. En dicha barra escribimos: smb://usuario@direccion_servidor/recurso y tras pedirnos la autenticación accederemos.

Desde Windows con la terminal

Abrimos la terminal (cmd.exe) y escribimos:

net use * \\direccion_servidor\recurso /USER:usuario

Tras autenticarnos, ya estaremos en el sistema. El asterisco, sirve para que el sistema elija la primera letra que tenga libre.

Desde Windows con el entorno gráficos

Al igual que hemos hecho antes con Nautilus en Gnome, accedemos al explorador de ficheros de Windows y en la barra de direcciones indicamos:

\\direccion_servidor\recurso

Saldrá una pantalla pidiéndonos los credenciales y estaremos conectados. Otra opción es conectar el recurso en el servidor como una unidad de red.

La virtualización tiene enormes ventajas pero también tiene sus inconvenientes. Uno de los más frecuentes a la vez que importantes que he encontrado (aunque pueda parecer lo contrario), es los problemas de hora. Debido al modelo de ejecución de las máquinas virtuales, es muy frecuentes que éstas soporten problemas de puntualidad en la hora mostrada.

Para evitarlo, es más conveniente aún de lo normal que configuremos el servicio NTP (Network Time Protocol). Este tema ya lo he tratado en equipos Linux en varias ocasiones anteriormente:

• Configurar NTP (hora en red) en nuestro equipo
  
• Definir la zona horaria en nuestro sistema con tzselect
  
• ¿Cómo cambiar la fecha y la hora desde la consola?
  

Pero nunca antes lo había tratado para Windows Server. Veamos, lo primero que tenemos que hacer es crear un script para la shell de Windows, un .bat con el siguiente contenido:

@echo off
echo Configuramos el servicio para que se sincronice con: hora.roa.es
echo.
w32tm /config /manualpeerlist:hora.roa.es,0x8 /syncfromflags:MANUAL /reliable:yes /update
w32tm /resync
echo.
Pause

Una vez hecho esto, nos aseguramos que el script se va a ejecutar de forma periódica por lo que programamos una tarea para esta labor. Para ello entramos en Inicio -> Herramientas administrativas -> Programador de tareas y ahí creamos una tarea nueva que se ejecute cada cierto tiempo (una hora no está mal) y que ejecute el script que acabamos de crear.

Cuenta en servidor compartido

Sin lugar a dudas la más popular. Ofrece un usuario con el que conectarnos a una máquina en la que hay más usuarios con sus datos y aplicaciones web. Tiene la ventaja de ser la más barata pero es la más limitada de todas.

Cuenta de revendedor

Similar a la anterior pero con una particularidad importante, permite crear nuevos usuarios a los que asignarles cuotas de espacio y volumen de transferencia. Como su nombre indica su uso principal es ser revendedores de hosting. A partir de este nivel todos los servicios pueden ser revendidos.

Servidores privados virtuales

Servidor virtual funcionando sobre una máquina física en la que hay más servidores virtuales. Se nos asignan unos recursos de cálculo, memoria y espacio en disco y actuamos remotamente como si tratáramos con un servidor propio. Popularmente llamados VPS (Virtual Private Server).

Servidor dedicado

Servidor físico que lo tenemos alquilado en la empresa de alojamiento. Sus potencialidades son muy similares al anterior pero a diferencia de éste el equipo es a efectos prácticos, “nuestro”. Es la solución más cara.

public static void Main (string[] args)
{
	MailAddress para = new MailAddress("para@direccion.com");
	MailAddress desde = new MailAddress("desde@direccion");
	MailMessage mensaje = new MailMessage(desde, para);
	mensaje.Subject = "Asunto";
	mensaje.Body = @"Cuerpo del correo";
	SmtpClient cliente = new SmtpClient("direccion_servidor", puerto);
	cliente.Credentials = new System.Net.NetworkCredential
("nombre_usuario", "contraseña_usuario");
	Console.WriteLine("Enviando mensaje de correo para: " + para.User
 + " en " + para.Host + " usando el servidor=" + cliente.Host + ".");
      	try {
	  cliente.Send(mensaje);
	  Console.WriteLine("Mensaje enviado");
	}
	catch (Exception ex) {
	  Console.WriteLine("Problemas enviando mensaje: " + ex.ToString());
	 }
}

Tened en cuenta que estamos trabajando con el espacio de nombres del ensamblado: System.Net.Mail.

Como veis el procedimiento es simple:

1. Se crean dos objetos para las direcciones de correo
2. Se crea el mensaje en sí
3. Se instancia el cliente SMTP, inicializando las credenciales
4. Para finalmente llamar al método de envío

Respondemos las dudas y sugerencias en los comentarios.

Para instalar LAMP (Linux Apache MySQL PHP) muchos de vosotros usaríais el selector de paquetes por tareas del gestor de paquetes Synaptic, pero en esta versión de Ubuntu y en la anterior no existe el paquete, así que tendremos que instalarlo manualmente.

La tarea, al igual que en el caso que os mencionaba antes, es bien sencilla, desde la terminal, instalamos el paquete tasksel, el mismo que utiliza Synaptic internamente para realizar esta tarea:

ahornero@6581-D:~$ sudo apt-get install tasksel

Ahora lanzamos la herramienta, ya sea directamente desde la misma terminal o a través de Synaptic, aquí lo veremos con la primera opción que es más directa:

ahornero@6581-D:~$ sudo tasksel

Seleccionamos la tarea LAMP, que se encargará automáticamente de instalarnos todos los paquetes y dependencias necesarias:

y luego no solicitará un contraseña para el administrador de la base de datos:

Una vez terminada la instalación, vamos a comprobar que todo funciona como esperamos, así que crearemos un fichero test.php en el directorio /var/www/, donde por defecto se encuentra nuestra web.

Cambiamos los permisos del directorio,

ahornero@6581-D:~$ cd /var/www/
ahornero@6581-D:/var/www$ sudo chown -R ahornero .
[sudo] password for ahornero: *******

y creamos el fichero test.php incluyendo la siguiente línea,

ahornero@6581-D:/var/www$ nano test.php

Finalmente, reiniciamos el servidor Web

ahornero@6581-D:~$ sudo /etc/init.d/apache2  restart
* Restarting web server apache2 … waiting [ OK ]

¡Y terminamos! Al entrar en la dirección http://localhost/test.php nos tenemos que encontrar algo similar a esto:

Bien, espero vuestros comentarios y dudas.

Estas conexiones las hará un script en PHP por lo que además, deberemos instalar OCI (Oracle Call Interface) para PHP. Suponemos que está ya instalado el servidor web Apache 2 y los componentes básicos de PHP.

Instalación de Oracle instantclient

Antes de instalar el instantclient como tal, debemos instalar la librería libaio, necesaria para gestionar entradas/salidas asíncronas al kernel. La instrucción será (utilizo “#” en el prompt para indicar como superusuario, “$” en caso contrario):

# yum install libaio1

O si usamos una distribución que use APT:

# apt-get install libaio1

Lo siguiente será acceder al portal de descargas de Oracle y descargar los componentes necesarios para el instantclient:

• Basic
• Devel
• SQLPlus

Elegimos la última versión, nuestra arquitectura  y descargamos los paquetes RPM. La instalación será inmediata si tenemos una distribución basada en Red Hat:

# yum install paquete.rpm

En caso contrario, deberemos instalar alien previamente para que convierta los paquetes RPM en paquetes DEB:

# apt-get install alien

# alien paquete.rpm

# dpkg -i paquete.deb

Ahora ya nos tocar configurar el famoso fichero Tnsnames.ora. Este fichero variará de una configuración a otra por lo que sólo vamos a comentar dónde situarlo. Su ruta debe ser: /etc/oracle/tnsnames.ora, en caso de no existir, deberemos crearla.

Para terminar, deberemos crear unas variables de entorno. Para ello accedemos al fichero /root/.bashrc como superusuario e incluimos las siguientes líneas:

export TNS_ADMIN=/etc/oracleexport SQLPATH=/usr/lib/oracle/11.1.0.1/client/binexport LD_LIBRARY_PATH=/usr/lib/oracle/11.1.0.1/client/lib:$LD_LIBRARY_PATHexport PATH=$PATH:$SQLPATH

En algunas distribuciones, también podréis hacer ese cambio en otro fichero: /etc/environment.

Instalación de OCI en PHP

Ahora nos toca la parte de PHP, es decir, instalar los componentes necesarios para poder hacer llamadas a Oracle desde PHP usando el instantclient que acabamos de instalar (con lo fácil que es hacer esto mismo con MySQL o PostgreSQL…, las cosas del software cerrado).

Suponemos que tenemos instalado Apache2 y PHP, pero aún así instalaremos dos paquetes más:

# yum install php-pear php5-dev

# apt-get install php-pear php5-dev

PHP-PEAR es según definen sus siglas: PHP Extension and Application Repository, es decir, un repositorio de extensiones y aplicaciones para PHP que nos permite instalar sin problemas ciertos componentes de PHP que no podemos instalar a través de nuestro gestor de paquetes habitual (me recuerda a CPAN con Perl, pero esa es otra historia para otra entrada).

Ya estamos en disposición de ejecutarlo para instalar OCI:

pecl install oci8

En la terminal nos aparecerá algo así como:

1-1, ‘all’, ‘abort’, or Enter to continue:

Pulsamos “1″ luego ENTER y escribimos las siguientes opciones (debemos saber el PATH exacto de nuestras librerías Oracle, cambiará en función de la versión):

shared,instantclient,/usr/lib/oracle/mi_version/client/lib/

PHP-PEAR descargará, configurará, compilará e instalará el módulo. Finalmente, tenemos que añadir a nuestro fichero php.ini una línea para que cargue la librería dinámica de OCI y puedan hacerse llamadas desde los ficheros PHP.

La ruta del fichero será: /etc/php5/apache2/php.ini y la línea a agregar junto a las demás extensiones la siguiente:

extension=oci8.so

Reiniciamos el servidor web y listo:

services httpd restart

O:

/etc/init.d/apache2 reload

El certificado utilizado es autogenerado y suponemos que tenemos ya instalado Apache.

Instalación de OpenSSL y mod_ssl

Lo primero que necesitamos es tener instalado el software necesario, para ello a través de yum hacemos lo siguiente:

yum install mod_ssl openssl

Generación del certificado

Primero generamos la clave privada, elegimos algoritmo RSA y 1024 bits:

openssl genrsa -out ca.key 1024

Ahora generamos el CSR (Certificate Signing Request), un fichero que crea una entidad para pedirle a una tercera que lo firme, verificando así que los datos de la primera entidad son correctos. De esta forma unas entidades van certificando a otras creando una cadena de certificación, donde la primera entidad de llama la raí­z de certificación.

openssl req -new -key ca.key -out ca.csr

Finalmente, nos autofirmamos el certificado:

openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

Le hemos puesto un período de validez de un año, pero podéis cambiar a vuestro gusto este tiempo. OpenSSL os pedirá una serie de datos sobre el certificado y su entidad emisora (vosotros): correo electrónico, ciudad, país… a través de un interfaz en texto.

Cambio de rutas

El siguiente paso es mover los ficheros de la firma que acabamos de generar a la ruta correcta.

mv ca.crt /etc/pki/tls/certs
mv ca.key /etc/pki/tls/private/ca.key
mv ca.csr /etc/pki/tls/private/ca.csr

Configuración de Apache

Ya estamos listos para comenzar con la configuración de Apache. En las versiones más modernas de Apache, el fichero de configuración viene dividido en varios ficheros separados por temática para un acceso más rápido a la parte deseada. El fichero que vamos a editar es el siguiente: /etc/httpd/conf.d/ssl.conf.

Buscamos las siguientes líneas y le asignamos el valor correcto (no tienen por qué estar seguidas una de la otra):

SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

Host virtual

Para terminar crearemos un host virtual donde indicaremos a Apache dónde buscar las peticiones dirigidas al puerto 443 (las peticiones HTTPS). Definimos un host virtual al final de /etc/httpd/conf/httpd.conf:

NameVirtualHost *:443

Y luego la definición de las características en sí:

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile /etc/pki/tls/certs/ca.crt
        SSLCertificateKeyFile /etc/pki/tls/private/ca.key
        AllowOverride All
        DocumentRoot /var/www/httpsdocs
        ServerName nombresitio.com
</VirtualHost>

Reiniciar el servicio

Para que los cambios tengan validez, deberemos reiniciar el servicio:

service httpd restart

Y ya tendremos listo el sitio seguro. Tened en cuenta que como la firma es autogenerada, los navegadores no la contemplarán como segura y aparecerá la típica pantalla de “Error SSL” o similar, que seguro que conocéis.

• Configurar un servidor FTP en Linux con VSFTPD
• Configurar VSFTPD para conexiones seguras (TLS/SSL/SFTP)

Nuevo fichero de configuración

Para no interferir directamente con el fichero vsftpd.conf vamos a crear otro llamado vsftpd-anon.conf en el que indicaremos expresamente las opciones para el FTP anónimo. Veamos una a una las opciones que incluiremos en dicho fichero y por qué.

Escucha de forma autónoma

listen=YES

El servidor se encargará de escuchar las peticiones por sí mismo. La otra opción, ponerlo a NO, requiere que xinetd se encargue de controlar las llamadas. La configuración extra que requiere no es el objeto de esta entrada, así que dejaremos que VSFTPD trabaje de forma autónoma.

Usuarios locales y acceso anónimos

local_enable=NO
anonymous_enable=YES

No permitimos que los usuarios locales inicien sesión en el servidor y permitimos que existan entradas anónimas.

Escritura

write_enable=NO

Puesto que estamos hablando de un servidor anónimo, lo lógico es que no existan escrituras.

Raíz accesos anónimos

anon_root=/var/ftp

Creamos el directorio /var/ftp, en caso de que no exista ya y con esta opción lo asignamos como raíz para los accesos de usuarios anónimos.

Tasa máxima de subida

anon_max_rate=1048576

Limitamos la tasa máxima de descarga (en bytes por segundo) para conexiones anónimas. En este caso lo he limitado a 1GB/s, dependiendo de vuestra línea deberéis modificar ese valor para evitar que las conexiones de usuarios anónimos os dejen sin velocidad de subida. Si ponemos 0 no existe límite.

Log

xferlog_enable=YES

Activamos el log del sistema (por defecto estará en /var/log).

Dirección y puerto de escucha

listen_address=mi_direccion_ip
listen_port=21

Indicamos la dirección y el puerto de escucha.

Fichero completo

Ya tenemos listo el fichero de configuración al completo. Os lo dejo tal cuál por si queréis copiarlo y pegarlo:

# Obligatorias
listen=YES
local_enable=NO
anonymous_enable=YES
write_enable=NO
anon_root=/var/ftp
# Opcionales
anon_max_rate=1048576
xferlog_enable=YES
listen_address=mi_direccion_ip
listen_port=21

Arranque y parada del servicio

Si ejecutamos la orden: service vsftpd restart, reiniciaremos el servidor VSFTPD con su fichero de configuración original. Para iniciarlo con el que acabamos de crear, deberemos especificárselo en forma de párametro (como usuario root):

vsftpd /etc/vsftpd/vsftpd-anon.conf

Para parar el servicio:

killall vsftpd

Compartir ficheros y directorios

Tenemos dos opciones para poner en el servidor FTP disponibles ficheros y directorios:

1. Copiarlos y pegarlos directamente, con lo que conlleva: pérdida de tiempo y doble consumo de espacio
2. Unir mediante montajes los directorios que queramos compartir

Seguro que también pensáis que más directo que el punto 2, sería crear enlaces simbólicos. VSFTPD no permite el uso de estos enlaces porque al “enjaular” los datos /var/ftp aunque el enlace esté hecho, la llamada al sistema es al directorio real y se cancela la petición.

La solución es usar montajes con el parámetro bind. Para ello sólo tendremos que hacer lo siguiente:

mount --bind /ruta/a/compartir /var/ftp/pub

Con esto tendremos los directorios o carpetas compartidas en el directorio público de nuestro FTP sin tenerlas que haber copiado previamente.

Veamos los pasos a dar.

1. Acceder al sistema

Para poder seguir los pasos, deberemos estar dentro del sistema, en la terminal del mismo. Si no tenemos acceso físico, podemos conectar vía ssh.

$ ssh miusuario@miservidorpgsql

2. Autenticarnos como usuario postgres

Una vez dentro del sistema, podemos hacer las operaciones como root, pero por seguridad o por si no disponemos de tales credenciales, lo mejor es actuar como usuario postgres:

su postgres

3. Permitir conexiones de clientes desde un determinado rango

Llegamos a uno de los puntos importantes de la cuestión, el fichero pg_hba.conf. Su situación exacta dependerá de vuestra instalación, pero lo encontraréis en una de estas dos rutas:

• /var/lib/pgsql/data/pg_hba.conf (en mi instalación lo tengo ahí, utilizo Scientific Linux, una distribución derivada de Red Hat)
• /etc/postgresql/main/pg_hba.conf

Dentro de este fichero, al final del mismo, veremos algo así:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
# "local" is for Unix domain socket connections only
local   all         all                               ident
# IPv4 local connections:
host    all         all         127.0.0.1/32          ident
# IPv6 local connections:
host    all         all         ::1/128               password

¿Qué significa esto? Veamos columna a columna:

• Tipo: básicamente conexión local o conexión remota (host).
• Base de datos: base de datos a las que afecta la regla. Si queremos todas, usamos el comodín all.
• Usuario: usuarios a los que afecta la regla, si queremos que afecte a todos, usamos también all.

Nos paramos ahora en los dos apartados que más atención requieren.

3.a Dirección

En esta columna definimos, las direcciones IP (podemos también usar IPv6), desde las que podremos conectarnos a PostgreSQL. Usaremos la fórmula dirección/máscara:

• Una sola dirección: 150.100.100.100/32
• O un rango (ampliemos el mismo de antes): 150.100.100.0/24 (256 direcciones)

3.b Método

Aunque hay multitud de métodos para utilizar (incluyendo conexiones LDAP, Kerberos o PAM), explico los tres más básicos:

• ident: utiliza el usuario del sistema desde el que se está intentado conectar.
• trust: deja todos los accesos sin necesidad de autenticarse (sólo recomendable para conexiones desde el equipo local).
• password: identificación con usuario/contraseña, es la más típica y es la recomendable para conexiones desde clientes como EMS PostgreSQL Manager.

Una línea de ejemplo, para darle acceso a todos los usuarios, a todas las base de datos, desde el rango de IP explicado antes, usando autenticación con usuario y contraseña, sería la siguiente:

host    all         all         150.100.100.0/24          password

4. Habilitar conexiones al socket desde clientes que no sean el host local

Al igual que en MySQL hay que configurar el bind-adress en my.conf, en PostgreSQL tenemos que hacer algo análogo.

Para versiones 8.x en adelante el procedimiento es el siguiente. Buscamos el fichero postgresql.conf en:

• /var/lib/pgsql/data/postgresql.conf
• /etc/postgresql/8.2/main/postgresql.conf

Y buscar dentro del mismo la siguiente línea:

listen_addresses='localhost'

Para sustituirla, por el comodín (para todas las IP, es una opción segura, tened en cuenta que tenemos también un filtro en el fichero pg_hba.conf.

listen_addresses='*'

O definir algunas direcciones IP en concreto:

listen_addresses='150.100.100.100 150.100.100.101'

5. Reiniciar servicio

Reiniciamos el servicio para que el servidor cargue los nuevos valores (como root):

$ service postgresql restart

6. Abrir entrada en iptables

Finalmente, nos aseguramos de que iptables no corta la entrada (el puerto de PostgreSQL es el 5432 por defecto, si lo cambiáis, cambiadlo aquí también):

iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d ip_cliente \
 --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s ip_cliente --sport 5432 -d 0/0 \
 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

7. Probar

Desde un cliente gráfico o desde el cliente en línea de comandos, probamos la configuración (suponemos que desde el equipo al que estamos dando acceso):

$ psql -h ip_servidor -U miusuario

Y con esto debería ir todo sin problemas. Las posibilidades de PostgreSQL son enormes, empezando por este tipo de configuraciones. Ahora que son  tiempos oscuros para MySQL por culpa de Oracle, no viene mal acordarse de esta base de datos que tantas alegrías ha dado al software libre, PostgreSQL.

Una de las acciones básicas de cara a mejorar la seguridad de un sitio web, es evitar que el servidor devuelva los listados del contenido de los directorios que son públicos. Una solución popular es incluir un fichero index.html vacío en todos los directorios que no deben ser listados o que no tienen un fichero que realice alguna función. Si estamos hablando de un sitio web con cientos o miles de directorios, esta opción queda descartada directamente.

.haccess

La alternativa es simple si estamos usando un servidor web Apache, utilizar las bondades del fichero .htaccess. La opción más directa es deshabilitar todos los listados de directorios en nuestro sitio.

Desactivar listados

En el raíz de nuestro sitio, creamos un fichero .htaccess (o añadimos al que ya tenemos) la siguiente línea:

Options -Indexes

De esta forma evitamos los listados en cualquier directorio de nuestro sitio. La opción contraria, para un directorio en particular o porque queramos habilitar esta característica en un sitio donde el proveedor la tiene deshabilitada por defecto es la siguiente:

Options +Indexes

Estilo de los listados

Si lo que queremos es tener el listado, tenemos dos opciones, mostrar la lista básica de ficheros:

IndexOptions -FancyIndexing

O mostrar más información: fechas de modificación, tamaño de ficheros, iconos…:

IndexOptions +FancyIndexing

Ignorar ciertos tipos de ficheros

Otra opción a tener en cuenta es la de ignorar ciertos tipos de ficheros, de forma que podamos listar por ejemplos el contenido multimedia, obviando los ficheros PHP o HTML. Para este ejemplo usaríamos la siguiente instrucción:

IndexIgnore *.php *.html

Finalmente, podemos mostrar un listado en blanco, es decir, ignorar todos los ficheros. Es otra alternativa a impedir los listados.

IndexIgnore *

Esta tarde he tenido que hacer una excepción, haciendo unas prácticas de una asignatura he interactuado con el repositorio SVN directamente con el comando svn; pienso que usarlo mediante comando es bastante útil, sobre todo en entornos en los que usar una GUI es imposible o para solucionar algún problema, preferimos hacerlo directamente sin una vista sobre una aplicación más pesada. Sea cual sea vuestro caso, a continuación os dejo un breve resumen de los comandos básicos de svn:

svn import

A través de este comando enviaremos de forma recursiva el contenido de una ruta a un servidor SVN. Si omitimos la ruta local se establecerá el directorio actual. Un ejemplo de uso podría ser:

ahornero@6581-D:~/practica$ svn import –username ahornero –password 12987Guh2436 https://ahornero.com/svn/practica

svn checkout o svn co

Este comando se utiliza para hacernos directamente con un árbol de un directorio del repositorio SVN. Un ejemplo de uso podría ser el siguiente:

ahornero@6581-D:~/practica$ svn co –username ahornero –password 12987Guh2436 https://ahornero.com/svn/practica

svn add

Cuando se crea un nuevo archivo o directorio, hemos de indicarselo explicitamente al servidor SVN. Es importante saber que el hecho de indicar no significa subirlo, hasta no hacer un commit no se interactuará con el servidor en este sentido.

svn delete

Análogo a add para eliminar, y uso similar.

svn status

Con este comando imprimiremos el estado de los directorios y archivos. Si hemos hecho cambios locales, se mostrarán los elementos modificados localmente. Si utilizamos el parámetro –verbose, obtendremos información de la revisión de cada elemento. Con el parámetro –show-updates, mostraremos los que están fuera de fecha (out-of-date)

svn update o svn up

Así, sincronizaremos nuestro directorio local con el servidor. Si hemos hecho cambios locales, trataremos de combinar los cambios en el servidor con los cambios en el equipo; es importante destacar que este comando no afecta al servidor, si no al equipo local únicamente.

svn commit o svn ci

Este comando envía recursivamente los cambios al servidor SVN. Se hará entonces un commit de los archivos modificados, añadidos y borrados. Hemos de tener en cuenta que para evitar que afecte a todo el directorio, podemos indicar explícitamente la ruta específica o los archivos afectados, simplemente los añadimos al final del comando.
A través de la opción -m podemos añadir un mensaje determinado, la forma de usar es la siguiente:

ahornero@6581-D:~/practica$ svn commit -m “Registro alpha actualizado”.

svn diff

Este comando es similar al conocido comando diff de UNIX, de hecho, la forma de utilizarlo es similar. Podremos saber que cambios existen entre dos revisiones usándolo svn diff-r revision1:revision2 nombre_archivo. Por ejemplo:

ahornero@6581-D:~/practica$ svn diff -r 145:146 práctica.odt

, lo que retornará los cambios entre la revisión 145 y 146 para el fichero práctica.odt.

Y esto es todo, ¿alguna duda o sugerencia?

• Sobre Debian / Ubuntu / y derivados:

ahornero@6581-D:~$ sudo apt-get install samba smbfs

• Sobre Red Hat / CentOS / Fedora:

ahornero@6581-D:~$ yum install samba smbfs (como superusuario)

Para iniciar, detener o reiniciar el servicio:

ahornero@6581-D:~$ /etc/init.d/samba stop / start / restart

ó

ahornero@6581-D:~$ restart smbd

Y para realizar la configuración de usuarios, acceso a directorios y permisos, recomendamos utilizar la aplicación system-config-samba; por defecto en CentOS viene instalada. Para instalarla en otros servidores Linux:

• Sobre Debian / Ubuntu / y derivados:

ahornero@6581-D:~$ sudo apt-get install system-config-samba

• Sobre Red Hat / CentOS / Fedora:

ahornero@6581-D:~$ yum install system-config-samba

Y esto es todo, ¿alguna duda? Creo que con esto último que os comento se resuelve la gran problemática al usar Samba.