Categoría: Administración

Comando find en Linux

18.05.09 | by José P. Espinal [mail] | Categories: Administración, Comandos Linux

“¿Cómo encontrar cosas en Linux?", “¿Cómo buscar en Linux?", entre otras preguntas, son las que naturalmente nos formularemos tarde o temprano. Sin más preambulos, comencemos a estudiar el comando find.

Primero, lo primero; debes leerte el man page de find.

Bajo circunstancias normales, de haber sido un man page corto, o de tamaño moderado; ciertamente lo hubiese traducido. Pero el tamaño de ese documento dificulta las cosas.

1. Lo básico:

Si ejecutas find sin pasarle ningún paramentro, intentará encontrar todos los directorios y subdirectorios, ficheros, etc., a partir del lugar donde lo ejecutes.

Evidentemente, ejecutarlo sin pasarle parametros no tendría ninguna utilidad, de modo que el primer parametro que deberiamos pasarle, debe ser la ruta donde se ejecutará la busqueda, y el segundo parametro, el nombre del fichero que queremos buscar.

e.g, Digamos que quiero buscar un fichero llamado pepito.txt , en mi directorio HOME, haría algo como lo siguiente:

# find /home/jespinal/ -name "pepito.txt"

donde /home/jespinal es el nombre de mi directorio HOME, y pepito.txt es el nombre del fichero, el cual encerramos en comillas (""), esto no es realmente obligatorio (a menos que uses caracteres comodines como ‘*’ o ‘?’, los cuales podrian ser interpretados por la consola como una ruta en donde buscar en vez de algo que forma parte del nombre), pero es buena practica porque te permite buscar nombres con espacios de por medio, ej. ‘mi lista.txt’

2. Avanzando un poco

Puede darse el caso donde no sabemos exactamente el nombre del fichero, sino que sabemos que dicho nombre comenzaba con ‘pep’; y no solo eso, sino que tampoco sabemos donde esta ubicado exactamente.

Sencillo, sin importar donde este, obviamente estara en un subdirectorio en algun lugar debajo de nuestro directorio raiz ( / ), asi que empezaremos la busqueda desde ahi. Y ya que no sabemos el nombre exacto del fichero, le daremos a find lo que tenemos (A final de cuentas, quien debe buscar es el, no nosotros :] )

e.g Escribiriamos algo como lo siguiente:

# find / -name "*pep*"

y listo.

Como nota adicional, fijate que delante de ‘pep’ (que eran los unicos caracteres que inicialmente sabiamos que estaban contenidos en el nombre del fichero) he puesto un asterisco ( * ), tambien detras.
El asterisco basicamente significa ‘cualquier cosa’, o ‘cualquier combinacion de texto’.

Estamos diciendole a find que busque, a partir de / (root), algo (ya sea fichero o directorio) cuyo nombre comience con ‘cualquier cosa’ seguida de los caracteres ‘pep’, y que termine con ‘cualquier cosa’.

Dentro de los posibles valores que puede valer el asterisco, esta la posibilidad de que no haya ningun caracter; o sea, si aparece un fichero (o directorio) llamado pepsi.txt, sipep.txt, pep.txt, sopepto.txt, entonces find te lo dira, ya que todos coinciden con el parametro de busqueda que diste para el nombre.

3. Ser mas exigente con la busqueda

Recuerda que find va a buscar lo que le digas que busque, de acuerdo a la manera que se lo digas, y será tan preciso en los resultados como tu lo seas en los parámetros que le pasas.

Si le pasas parámetros poco precisos, no esperes que find te traiga solo resultados de lo que tu estabas esperando.

Imagina que quieres ver los ficheros regulares que tienes en tu directorio HOME.
OJO: dije ficheros regulares, no directorios, no symbolic links (vinculos simbolicos), ni tampoco pipes, FICHEROS!

Para eso solo tienes que indicarle a find el tipo, que es ‘f’,

La tabla de posibles tipos de ficheros es la siguiente:

b bloque especial
c caracter especial
d direcotorio
p tuberia (pipe)
f fichero regular
l vínculo simbolico (leete el man page para que veas unas cuantas especificaciones)
s socket
D Puerta (Solaris)

Para el ejemplo previo, tendríamos que ejecutar algo como esto:

# find /home/jespinal -type f

4. Algunos ejemplos prácticos

a. Buscar a partir del directorio raiz todos los ficheros regulares cuyo nombre termine en .log

# find / -type f -name "*.log"

b. Buscar a partir del directorio raíz todos los ficheros terminados en .tmp y eliminarlos

# find / -type f -name "*.tmp" -delete

Ojo: la opción -delete sirve para eliminar los ficheros que find encuentra a partir de los parametros que le damos (cuidado, cualquier error puede ser letal).

c. Encontrar en el directorio actual ( . ) los ficheros regulares, y copiarlos a /tmp

# find . -type f -exec cp '{}' /tmp \;

Ojo: No te asustes, ahora te explico.

Cuando find encuentra un fichero, su nombre es sustituido por los carácteres ‘{}’, de modo que cuando hacemos el ‘cp {} /tmp’ , es lo mismo que si hicieramos (uno por uno) un ‘cp fichero.txt /tmp’ o ‘cp fichero_regular.zip /tmp’, etc, etc.

Otro dato muy importante, es que para poder ejecutar alguna orden utilizando los nombres de los ficheros que find encuentra, necesitas utilizar -exec.

Los comandos que se pasan a find, utilizando -exec deben ser terminados con un ‘;’.

En el ejemplo previo viste que utilice \; para poder ‘escapar’ ese caracter. Ya que las ordenes que le damos a nuestro sistema mediante la consola son separados por ‘;’ tambien, debemos hacer que la consola ignore el ‘;’ y se lo pase a find

Ej. si ejecutamos

# clear; cd /tmp; ls 

estos comandos serán ejecutados uno a continuación del otro, en el orden que los escribiste, separados por ‘;’ por nuestro sistema. Al utilizar \; , entonces la consola no lo interpreta y se lo envia directamente a find.

(Si esta parte no te quedo muy clara, escribeme, y asi la aclaro mejor)

d. Encontrar en el directorio actual los ficheros (de cualquier tipo) que tengan permisos 644

# find . -perm 664

e. Encontrar en el directorio /usr/src los archivos cuyo nombre terminen en .c (codigo fuente) y cuyo tamaño sea mayor a 100k, e imprimirlos (en pantalla).

# find /usr/src -name '*.c' -size +100k -print

Fijate que nuevamente utilice el caracter comodin ( * ) dentro de comillas, para evitar que el shell lo expanda (interprete).

Es conveniente que se den una ojeada al man page de ‘find’; poco a poco ire agregando mas ejemplos practicos a esta lista. (Si te interesa saber como hacer algo con find, enviame un msg).

--
Jose P. Espinal
http://www.eslackware.com

Configurar un servidor DNS

25.04.09 | by José P. Espinal [mail] | Categories: Networking, Administración

Hay tres configuraciones de servidores de nombres basicas:

  • Un Servidor de Cache, que es un servidor no autoritativo. Obtiene todas las respuestas a consultas de nombres de otros servidores de nombre.

  • Un Servidor Esclavo, el cual es considerado autoritativo porque tiene un base de datos completa y exacta, la cual transfiere de los servidores maestros. Tambien son llamados Servidores Secundarios porque son respaldos a los servidores primarios.

  • El Servidor Maestro es el servidor primario para el dominio. Carga la informacion del dominio directamente desde un fichero en el disco local, mantenido por el administrador del dominio. El servidor maestro es considerado autoritativo para el dominio, y sus respuestas a las consultas son siempre consideradas exactas.

Nota 1: Un servidor autoritativo es aquel que contiene datos maestros acerca de algo, es decir, son la fuente primaria de informacion acerca de algo. En contraste con los servidores de ‘cache’, quienes tienen una copia de la informacion.

Nota 2: La mayoria de los servidores combinan elementos de mas de una configuracion (de las antes mencionadas). Todos los servidores guardan en cache las respuestas, y muchos servidores primarios actuan como servidores secundarios de otros dominios.

Sugerencias:

a. Debes crear un solo servidor maestro para tu dominio. Es la fuente principal de informacion con respecto a este. El hecho de crear mas de un servidor maestro podria socavar la confiabilidad de la informacion.

b. Crea por lo menos un servidor esclavo; asi podras compartir la carga, y proveer respaldo para el servidor maestro.

c. Usa servidores de cache a travez de la red para reducir la carga sobre el servidor maestro y los secundarios.

Para la configuracion de named se requieren hasta 5 ficheros de configuracion.
Todas las configuraciones (Cache, Secundario, Primario) requieren de los siguientes ficheros basicos:

Fichero de configuracion de named, named.conf, el cual define parametros basicos, y apunta a las fuentes de informacion de las base de datos de los dominios, los cuales pueden ser ficheros locales o servidores remotos.

Fichero de sugerencias (hints), o cache, provee los nombres y direcciones de los servidores raiz que son usados durante la inicializacion.

Fichero del host local: Toda configuracion contiene una base de datos de dominio local para resolver el loopback al nombre de host ‘localhost’.

Los otros dos ficheros que son utilizados para configurar named son utilizados unicamente en el servidor maestro. Estos son los dos ficheros que definen la base de datos del dominio:

Fichero de zona el cual define la mayor parte de la informacion. Es utilizado para mapear nombres de hosts a direcciones, identificar el servidor de correo, y proveer una variedad de informacion acerca de otros dominios.

Fichero de zona reversa, el cual mapea direcciones IP’s a hostnames, lo que es exactamente lo opuesto a lo que hace el Fichero de Zona.

Nota 3: Una Zona es el contexto de un dominio sobre el cual un servidor maestro tiene autoridad. El fichero de base de dato de dominio que contiene la informacion acerca de la zona es llamado Fichero de Zona. Una Zona y un dominio NO son la misma cosa. Por ejemplo, todo lo que esta contenido en un fichero de base de datos esta en una misma zona, incluso si el fichero contiene informacion acerca de mas de un dominio. (Es decir, no importa si el fichero de base de datos contiene informacion acerca de varios dominios, aun asi estan en la misma zona).

Para configurar un servidor dns necesitas saber como configurar los cinco ficheros. Por lo cual empezaremos mirando el fichero named.conf, el cual es usado en cada servidor de dominios, y define la configuracion basica.

El Fichero De Configuracion De Named

La estructura de los comandos de configuracion de named.conf es similar a la estructura al lenguaje de programacion C. Un enunciado termina con un punto y coma ( ; ), Las literales son encerrados en comillas ( “” ), y los articulos relacionados estan agrupados en llaves ( {} ). BIND provee tres formas de insertar un comentario las cuales son:

/* Esto seria un comentario (Estilo C) */
// Esto seria otro comentario, estilo C++ 
# Esto seria otro comentario, tipo Shellscript

Existen once enunciados de configuracion validos para BIND 9.x, la cual es la version que trae Slackware (por lo menos, la version que tengo), a continuacion los menciono brevemente con una pequenia descripcion:

Comando Uso
acl Define una lista de control de acceso

(Access Control List)
controls Define el canal de control para el programa de control de named
include Incluye otro fichero dentro del fichero de configuracion.
key Define claves de seguridad para autenticacion.
logging Define que cosas seran registradas y donde seran almacenadas.
lwres Hace que el servidor actue como un servidor lightweight de resolucion.
options Define opciones de configuracion globales y por defecto.
server Define las caracteristicas de un servidor remoto.
trusted-keys Define las llaves de encriptacion DNSSEC para el servidor
view Muestra diferentes vistas de la informacion de la zona a clientes diferentes.
zone Define una zona

En lo adelante estare utilizando ejemplos para ilustrar la funcion y formato de los comandos mas utilizados comunmente.

La sentencia options

La mayoria de los ficheros named.conf empiezan con la sentencia options. Solamente se puede utilizar una sentencia options. La sentencia options define parametros globales que afectan la forma en que opera BIND. Tambien indica los valores por defecto para otras setencias utilizadas en el fichero de configuracion. La opcion mas comunmente utilizada define el directorio de trabajo para el servidor:

options {
        directory "/var/named";
};

La sentencia empieza con el comando ‘options’. Las llaves encierran una lista de opciones, y la palabra directory define el directorio desde el cual named leera (y escribira) los ficheros. El nombre del directorio tambien es utilizado para completar cualquier nombre de fichero especificado en el fichero de configuracion. La parte encerrada entre comillas es la ruta del directorio. Fijate que tanto la opcion directory como las llaves, al final tienen ‘;’.

Mas adelante veras que named escribe varios ficheros diferentes que son usado spara chequear el estado el servidor de nombres. La opcion ‘options’ puede ser utilizada para cambiar las rutas por defecto de los ficheros individuales. Aunque realmente es recomendable mantener el nombre original para cada fichero de status y guardarlos en el fichero identificado por la opcion ‘directory’.

La sentencias zone

Las sentencias zone son las mas importantes en la configuracion del fichero, y constituyen la mayoria del fichero named.conf. Una sentencia zone lleva a cabo las siguientes configuraciones criticas:

  • Identifica una zona que esta siendo servida por un servidor de nombres
  • Define el tipo de servidor de nombre que representa este servidor para esta zona. Un servidor puede ser master o slave. Y debido a que esto se define por zonas, el server puede ser master para algunas zonas mientras lo es slave para otras.
  • Define la fuente de informacion de dominio para una zona. La base de datos de dominio puede ser cargada de un fichero en el disco local o transferida desde un servidor maestro.
  • Define opciones de procesamiento especial para la zona.

Este seria un ejemplo que ilustra todas estas funciones:

zone "eslackware.com" in {
        type master;
        file "eslackware.hosts";
        check−names fail;
        notify yes;
        also−notify { 172.16.80.3; };
        allow−update { none; };
};

La sentencia comienza con el comando ‘zone’. El nombre de la zona es escrita como un literal encerrado en comillas. La palabra clave in quiere decir que esta zona contiene direcciones de IP y nombres de dominios de Internet. Este es el valor por defecto, de modo que no es realmente requerida. Las llaves encierran una lista de opciones para esta zona.

El tipo ‘master’ indica que este es el servidor maestro (master) para el dominio eslackware.com. Otros valores posibles son:

slave: Identifica este servidor como esclavo, para este dominio.
hints: Identifica este como el fichero de hints (pistas) que es utilizado para inicializar el servidor de nombres durante el arranque.
stub: Identifica este como un servidor stub. (Servidores stub son servidores esclavos ’slaves’ que solo cargan los records del servidor de nombres desde el servidor maestro). Esto es principalmente para servidores no recursivos que quieren referir una consulta a otros servidores, de la misma manera que los servidores raiz refieren las consultas a otros servidores. Esto es rara vez utilizado en una red de una empresa.

la opcion ‘file “eslackware.hosts"‘ apunta al fichero que contiene la base de datos de informacion del dominio. Para un servidor maestro, este es el fichero que es creado por el administrador del dominio.

En proximos articulos pienso hacer ejemplos detallados y configuracion paso a paso acerca de la configuracion de los tres tipos de servidores de DNS (master, slave, cache)

--
Jose P. Espinal
http://www.eslackware.com

BIND, DNS Server

16.04.09 | by José P. Espinal [mail] | Categories: Networking, Administración

BIND DNS es un sistema cliente/servidor. El cliente se llama ‘resolvedor’ (resolver , en Inglés), y formula peticiones y envía al servidor de dominios. Cada equipo de la red corre un resolvedor. De hecho, muchos sistemas sólo ejecutan el resolvedor.

Tradicionalmente, el resolvedor BIND no es aplicado como un proceso (que suba con el sistema). Es una biblioteca (o librería, como deseen llamarle) de rutinas de software, llamado el código de resolución, que está vinculada a cualquier programa que requiera de servicio de nombres. La mayoría sistemas Linux usan la implementacion tradicional de resolución, que se denomina ’stub resolver’. Ya que es el más ampliamente usado, es al que le daremos cobertura en este artículo.

El lado servidor de BIND responde las peticiones que vienen del resolvedor.
El nombre del daemon es un proceso que se llama named. La configuración de named es mucho más compleja que la configuración del resolvedor; pero no hay necesidad de correr named en cada equipo.

Debido a que todos los ordenadores de tu red -ya sean clientes o servidores- ejecutan el resolvedor, comenzaremos la configuración de DNS con la configuración del resolvedor.

Los Comandos de Configuracion Del Resolvedor (resolver)

El resolvedor de Linux está configurado por dos tipos de archivos. Un tipo le dice al resolvedor qué servidores de nombres de dominio va a utilizar y en qué orden. Eso lo discutiremos más adelante.

El otro archivo de configuración, /etc/resolv.conf, configura al resolvedor para su interacción con el Sistema de Nombres de Dominio (Domain Name System). Cada vez que un programa que utiliza el resolvedor inicializa, lee el fichero /etc/resolv.conf, y guarda en cache la configuración de dicho archivo, durante el lapso de vida del proceso.

Es decir, por ejemplo; en el momento que levantas Sendmail, este leerá el fichero /etc/resolv.conf y trabajará con esa información durante el tiempo de vida de ese proceso (hasta que finalice de alguna forma). Si le haces algun cambio a /etc/resolv.conf, tendrás que reinicializar Sendmail para que los cambios surtan efecto.

Si no se encuentra el fichero /etc/resolv.conf, una configuración por default será utilizada.

La configuración por default utiliza al sistema local como el servidor de nombres. Esto quiere decir que debes ejecutar named si no crearás un fichero /etc/resolv.conf. Generalmente, es recomendable crear un fichero resolv.conf, incluso si no estás corriendo named en el host local (Este fichero se crea cuando configuramos la red utilizando netconfig en Slackware, si no lo ves, crealo… no duele).

Hay tres razones principales por lo cual deberías crearlo:

Primero, el fichero resolv.conf provee los medios para documentar la configuración en tu sistema; es decir, cualquiera puede ver el fichero y saber la configuración que has utilizado para tu sistema.

Segundo, los valores por default que funcionan en una versión de BIND, pueden cambiar en una futura versión.

Y tercero, aún cuando estés utilizando tu máquina local como servidor de nombres, el fichero resolv.conf te permite configurar servidores de respaldo para incrementar la robustez.

Los Comandos de Configuración del Resolvedor

BIND 9 (quien comenzó a ser incluido en los tiempos de Red Hat 7.2) utiliza los mismos ficheros de configuración que BIND 8. El fichero resolv.conf es un fichero de texto que puede contener la siguiente información:

nameserver direccion-IP 

El comando nameserver define el la dirección IP de un servidor de nombres que debería utilizar el resolvedor. Los servidores son consultados en el orden que aparezcan en el fichero hasta que sea recibida una respuesta o se acabe el tiempo de espera. Por lo general el primer servidor de nombres responde la consulta. La única vez cuando el segundo servidor es consultado es cuando el primero no responde o está fuera de línea. El tercer servidor únicamente responderá las consultas si los primeros dos fallan. Si no se encuentra ningún servidor de dominios en el fichero resolv.conf, el servidor de nombres corriendo en el servidor local es utilizado (En caso de que estés corriendo uno, obviamente).

domain nombre-de-dominio 

El comando domain define el dominio local. El dominio local es utilizado para expandir el nombre de host en una consulta antes de ser enviado al servidor de nombres. Si el comando domain no es utilizado, los valores indicados en el comando search son utilizados. Ahora bien, si ninguno de los dos comandos son indicados en el fichero resolv.conf, el valor derivado del comando hostname es utilizado. Sin importar como sea seteado el valor del dominio local, podrá ser sobreescrito por cualquier individuo si setea la variable de entorno LOCALDOMAIN.

search lista-de-busqueda 

El comando search define una lista de dominios que son utilizados para expandir un nombre de host antes de que se envie la consulta al servidor de nombres. lista-de-busqueda contiene un maximo de seis nombres de dominios, separados por espacio en blanco. La busqueda se hace en cada dominio especificado en la lista hasta que la consulta sea contestada. A diferencia del comando domain, el cual crea una lista de busquedas por defecto la cual contiene unicamente el dominio local, el comando search crea una lista explicita conteniendo cada dominio especificado en la lista-de-busqueda.

options opcion 

La opcion options modifica el comportamiento estandard del resolvedor. Hay diferentes opciones diponibles para BIND:

debug 

Enciende el depurador. Cuando la opcion debug es indicada, el resolvedor imprime mensajes de depuracion a la salida estandard. Estos mensajes son bastante informativos para depurar problemas del resolvedor o del servidor, pero la verdad es que esta opcion es de valor marginal. Encender el depurador en la configuracion basica del resolvedor produce demasiada informacion de salida, en tiempo inapropiado.

ndots:n 

Define el numero de puntos (’.') que indican cuando el resolvedor deberia adjuntar valores extraidos de la lista-de-busqueda al nombre de host antes de enviar la primera consulta al servidor de nombres. Por defecto el resolvedor no modificara un nombre de host si este contiene un punto ‘.’
¿Que es lo que intento decir? (porque imagino que algunos podrian estar confundidos con lo antes dicho)

Por ejemplo, si este fuera mi resolv.conf:

search eslackware.com slackware-es.com # Estos dos dominios constituyen 
                                       # mi lista-de-busqueda

nameserver 208.67.222.222              # Servidor de nombres primario
nameserver 208.67.220.220              # Servidor de nombres secundario
options ndots:1

Y este fuera mi /etc/hosts:

127.0.0.1 localhost
10.0.0.204 pbx pbx
10.0.0.202 slackbox.ejemplo.com slackbox
10.0.0.44 agonzalez.ejemplo.com agonzalez
10.0.0.111 ylaborda.ejemplo.com ylaborda
10.0.0.76 jrobinsonc.ejemplo.com jrobinsonc

La opcion ‘ndots:2′ en mi resolv.conf le esta diciendo al resolvedor que use mi lista de busqueda (los dominios (la que le indique mediante ‘search‘) antes de intentar enviar la primera consulta al primer servidor de nombres, para todos los nombres de host que tengan menos de dos puntos (’.'). De modo que lo que hara es ver si existe pbx.eslackware.com o pbx.slackware-es.com antes de preguntarle al primer servidor de nombres.

En caso de yo hacer ping a ‘agonzales.ejemplo.com’, como este registro contiene una cantidad igual al valor minimo de puntos (’.'), la consulta se envia directamente al primer servidor de nombres.

Realmente esta opcion solo te seria de utilidad si algun componente de tu dominio podria confundir a un top-level domain, y tienes usuarios que consecuentemente suelen truncar (acortar, para los indoctos :P, broma) los nombres de dominio. Entonces cuando alguien escriba el hostname de un equipo en tu dominio, resulta que la consulta seria primero enviada a los servidores raiz, para que estos luego hagan referencia a tu servidor de nombres (horrible, no?).

timeout:n 

Indica la cantidad de tiempo que el resolvedor esperara una respuesta del servidor de nombres antes de reintentar la consulta a travez de un servidorde nombrs diferente.

attempts:n 

Define el numero de veces que el resolvedor reintentara una consulta. El valor por defecto es 2, lo que quiere decir que el resolvedor reintentara una consulta dos veces con cada servidor de nombres antes de retornar un error a la aplicacion.

rotate 

Enciende el round-robin (seleccion en orden recursivo) de servidores de nombres. Normalmente el resolvedor envia la consulta al primer servidor en la lista, y unicamente envia la consulta al segundo servidor si el primero ha fallado. Tradicionalmente el segundo y tercer servidor de nombres fueron definidos para proveer servidores de nombres de respaldo. Estos no fueron concebidos para proveer balance de carga. La opcion rotate configura al resolvedor para compartir la carga de servidores de nombres de manera equilibrada sobre todos los servidores.

no-check-names 

Deshabilita el chequeo de nombres de dominio con respecto al RFC 952, “DOD Internet Host Table Specification.". (Para los que no lo sabian, RFC = Request For Comments, son documentos que describen estandares de como deben hacerse las cosas en internet, mas o menos).

Por defecto, los nombres de dominio que contienen un subrayado (underscore ‘_’), caracteres no-ASCII, o caracteres ASCII de control, son considerados como error. Usa esta opcion para trabajar con hombres de host que contengan subrayado.

inet6 

Esto produce que el resolvedor intente resolver IP’s del protocolo IPv6. La version del protocolo de internet que usamos actualmente es IPv4.
Usa esta opcion si te estas conectando a una red IPv6 experimental.

sortlist lista-de-direcciones 

El comando sortlist define una lista de redes que son preferidas sobre otras. La lista-de-direcciones es una lista de pares de direcciones y mascaras (por ejemplo, 66.128.63.0/255.255.255.0).
¿Para que te seria util esto?, bueno, Imagina que el nombre mp3local.com tenga mas de una direccion asignada a el, y que conoces cual de las dos direcciones tiene una red superior a la otra (mas rapida, menos latencia, lo que sea), pues con esta opcion puedes indicarle al resolvedor que a la hora de hacer una peticion a mp3local.com, tenga preferencia por la red que le indiques en lista-de-direcciones sobre otras las otras.

Consideraciones y Notas finales:

i. Las opciones domain y search son mutuamente excluyentes (o sea, o usas una, o usas la otra; NO las dos). Si mas de una de estas opciones es encontrada, la ultima prevalecera sobre la otra.

ii. La opcion search del fichero resolv.conf de un sistema puede ser sobreescrito a raiz de la ejecucion de un proceso al setear la variable de entorno ‘LOCALDOMAIN’ con una lista separada (por espacios) de dominios de busqueda.

Es decir, no importa lo que hayas puesto en la opcion search de resolv.conf, si alguien (antes de ejecutar algun programa o comando), hace algo como:

# LOCALDOMAIN=eslackware.com
# export LOCALDOMAIN

Lo que hayas puesto en search, no tendra validez.

iii. De igual forma, no importa lo que hayas indicado en resolv.conf utilizando options, si alguien setea la variable de entorno RES_OPTIONS a una lista (separada por espacio) de opciones para el resolvedor, este ultimo conjunto de parametros prevalecera.

Como siempre, espero que esto les haya sido de utilidad.
Proximamente veremos como configurar un servidor de DNS, vayan leyendo :)

--
Jose P. Espinal
http://eslackware.com

DNS Server (1ra parte)

12.04.09 | by José P. Espinal [mail] | Categories: Networking, Administración

Aprovecho la oportunidad para tocar el tema de BIND, el cual es el daemon que nos sirve como DNS Server.

Como no me había visto con la necesidad de configurar uno, solo hasta recientemente fue que hice una investigacion al respecto, sin embargo, creo que ya es hora; para esto me estaré apoyando de varias fuentes de documentación que mencionaré al final.

Entre los servicios más fundamentales en las redes TCP/IP tenemos el servicio de nombres, el cual es el servicio que traduce hostnames a direcciónes IP’s.

Los sistemas Linux usan básicamente dos técnicas para convertir hostnames a direcciónes:
a) La tabla de ‘host’ (/etc/hosts)
b) DNS (Domain Name System)

En el primer caso, el archivo /etc/hosts, es una tabla que traduce nombres a direcciónes. Es un archivo de texto simple en el cual se busca secuencialmente para aparear hostnames con direcciónes IP.

El sistema de Nombres de Dominio (DNS) es una base de datos jerárquica, distribuida por toda la internet a travez de miles de servidores.

Nota: Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que, como su nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo.

El Archivo Hosts

Por ejemplo, el archivo hosts podría contener las siguientes entradas:

127.0.0.1 localhost
10.0.0.202 slackbox.localdomain slackbox
10.0.0.44 agonzalez.localdomain agonzalez
10.0.0.111 ylaborda.localdomain ylaborda
10.0.0.76 jrobinsonc.localdomain jrobinsonc

Cada entrada en el archivo /etc/hosts contiene una dirección IP y los nombres asociados con esa dirección.

La primera entrada en está tabla asigna el nombre ‘localhost’ a la dirección 127.0.0.1. (Cada computador corriendo TCP/IP asigna la dirección de loopback al nombre de host ‘localhost’). La red 127 es una red especial reservada para la red de loopback, y el host 127.0.0.1 es la dirección de loopback reservada para la maquina local.

La dirección de loopback es una convención (es decir, un estandard asumido por acuerdo general) que permite a la PC local referirse a sí misma de forma semejante a como lo hace con otros computadores en la red. Esto simplifica la programación de softwares ya que el mismo código puede ser usado para referirse a cualquier sistema, y ya que la dirección es asignada a la interfaz (lo), ningún tráfico es enviado a la red física.

La segunda entrada en el archivo es para el mismo ’slackbox.localdomain’. La entrada hace referencia al IP 10.0.0.202 y al alias slackbox. Los nombres de alias son usados generalmente para proveer un nombre mas corto, tambien para proveer nombres genericos como mailhost, news, www. Cada computador conectado a la red, que tiene un IP fijo tiene su propio hostname y dirección en la tabla de /etc/hosts.

Cada sistema Linux tiene una tabla ‘hosts’ con las dos entradas discutidas previamente.

Entendiendo DNS

Las limitaciones de la tabla de ‘hosts’ resulta obvia cuando es usada con un gran número de hosts. La tabla de hosts requiere que cada computador tenga una copia local de la tabla, y cada copia debe ser completa porque sólo las computadoras listads en la tabla de hosts local son accesibles por el nombre.

Si tomamos en consideración el Internet como lo conocemos hoy día: Tiene millones de hosts. Una tabla de ‘hosts’ con millones de entradas es muy ineficiente y, lo que es más importante, imposible de mantener. Los hosts son agregados y quitados del internet cada segundo. Ningún sistema podría mantener una tabla tan grande y variante, mucho menos si es distribuida en todos los computadores de la red.

El sistema de DNS rompe con esta problemática eliminando la necesidad de una fuente centralizada para mantener estas tablas, e introduce el concepto de tablas distribuidas de manera jerárquica. Actualmente la información acerca de DNS esta distribuida en decenas de miles de servidores.

Adicionalmente, El sistema de DNS usa una cache local para migrar información a aquellos que la necesiten, sin enviar información innecesaria. Un server de cache empieza con la información necesaria requerida unicamente para alcanzar la raíz de la base de datos jerárquica. Luego guarda todas las respuestas a queries de usuarios que recibe y toda la información adicional requerida para obtener dichas respuestas. De esta forma, construye una base de datos interna de la información que necesita proveer a sus usuarios.

La jerarquía DNS

La jerárquia de DNS puede ser comparada a la jerarquía del sistema de archivos en Linux. Nombres de host en dominios independientes, nombres de archivos paralelo en directorios individuales, y, al igual que el directorio raíz (root) del sistema de archivos, DNS tiene un dominio raíz.

En ambos, el sistema de archivos, y el sistema DNS, los nombres de los objetos revelan la estructura jerarquica arraigada. Los nombres de archivos van desde lo más general, la raíz (/), a lo mas específico, el fichero individual.

Los nombres de dominio comienzan con lo más específico, el host, y van hasta lo mas general, la raíz (.).

Un nombre de dominio que empiece por un host y vaya hasta la raíz se llama nombre de dominio completamente calificado (FQDN -Fully Qualified Domain Name-). Por ejemplo, packages.eSlackware.com es el FQDN de uno de los sistemas en mi red (asumiendo que hubiese tenido uno, llamado ‘packages’).

Los dominios de nivel superior (top-level, TLDs), tales como .org, .edu, .jp y .com son servidos por los servidores raíz. Los dominios de segundo nivel (second-level domain), eSlackware en nuestro ejemplo, es el dominio que ha sido oficialmente asignado a nuestra organizacion. Cuando se te ha asignado oficialmente un dominio por tu dominio padre, un se~nalador es puesto en el dominio padre el cual apunta hacia tu servidor como el servidor responsable por tu dominio. Es esta delegacion de autoridad lo que hace a tu dominio parte del conglomerado de sistema de dominios. La forma de delegar autoridad para subdominios es discutida más adelante.

La analogía del sistema de archivos va mas alla que solo la estructura de los nombres. Los archivos son encontrados al seguir una ruta desde la raíz hasta los directorios subordinados, hasta el directorio destino. La informacion de DNS es encontrada de una manera semejante. Linux aprende la ubicacion del directorio raíz en el proceso de booteo tomandola de lilo.conf (o grub.conf , para quienes usen eso). De manera similar, tu server de DNS localiza los servidores raíz durante el arranque al leer un archivo, llamado ‘hints file’ (archivo de pistas, en espa~nol), el cual contiene los nombres y direcciónes de los servidores raíz. (Vas a crear ese archivo mas adelante). A travez de consultaes, el server puede encontrar cualquier host en el sistema de dominios al empezar en la raíz y siguiendo se~naladores a travez de los dominios hasta que llegue al dominio destino.

Respondiendo Consultas

Para responder una consulta con respecto a la informacion de DNS, el servidor local debe:

a. Tener la respueta a la consulta o
b. Saber cual servidor de dominio la sabe.

Ningun sistema puede tener un completo conocimiento por si solo acerca de todos los nombres en la internet; los servidores saben acerca de sus dominios locales y construyen una cache acerca de otros dominios tomando una consulta a la vez.

Ok, veamos como funciona. Asumiendo que quieres acceder a la dirección http://www.eslackware.com. En efecto, estas pidiendo por el record de dirección para ‘www’ de la base de datos eslackware.com. Una consulta para el record de esa dirección viene al servidor de nombres local. Si el servidor se sabe la dirección de http://www.eslackware.com, respondera la consulta directamente. Si no se sabe la respueta, pero sabe cual servidor maneja eslackware.com, hara la consulta a ese servidor. Si no tiene informacion del todo, hara la consulta a los servidores raíz.

El servidor raíz no responde la consulta directamente. En cambio, le indica al server local cual servidor puede responder las consultaes para eslackware.com. Hace esto enviandole al servidor local un record nombre de dominio que dice el nombre del servidor para eslackware.com y el record de dirección que dice la dirección de ese servidor. El servidor local podra entonces hacer consultaes a eslackware.com y recibe la dirección para http://www.eslackware.com/.

De esta manera, el servidor local se entera de la dirección del host, así como el nombre y la dirección de los servidores para el dominio. Estas respuestas y los cachés se utilizan para responder directamente a consultas sobre el dominio www.eslackware.com sin molestar de nuevo los servidores raíz.

En el próximo artículo estaremos hablando acerca de BIND, y la resolución de dominios.
Todo esto antes de entrar en materia con lo más pesado (la configuración de named) en si mismo.

Cualquier comentario, sugerencia o duda, recuerden escribirme.


Jose P. Espinal
http://eslackware.com

/etc/shadow - Archivo de passwords encriptados

21.09.08 | by José P. Espinal [mail] | Categories: Administración, General

… uff, hasta que por fin me animo a postear :>> , y esta vez estaremos estudiando el archivo ‘/etc/shadow’.

Este es otro de los archivos que, cuando movido por la curiosidad (cuando eres novato), lo abres con un editor de texto y te quedas perplejo preguntandote… “Pero, y que es esto!!??". Lo cierras, y te quedas con la idea en la cabeza: “Aja! y se supone que debi entenderlo, cieto!?". Mi intencion el dia de hoy es tratar de quitarle lo ‘mistico’ o ‘enredado’ a esos archivos, y dar un paseo por la sintaxis del mismo :)

Comencemos con lo esencial: El manual page

Content-type: text/html



SHADOW
Seccion: Formato de Archivos (5)


NOMBRE

shadow - archivo de passwords encriptados


DESCRIPCIÓN
shadow contiene la información encriptada para las cuentas de usuarios y opcionalmente la información de caducidad del password.


Está incluido

Nombre de usuario
Password Encriptado

Dias desde 1 Enero, 1970 que el password fue cambiado
Dias antes de que el password pueda ser cambiado

Dias despues de los cuales el password debe ser cambiado
Dias antes en los que el usuario será advertido antes de que el password expire

Dias despues de 1 Enero de 1970, en los cuales la cuenta será deshabilitada luego del password expirar
Un campo reservado


El password debe ser llenado. El password encriptado consiste en 13 a 24 carácteres del alfabeto de 64 caracteres de a hasta z, A hasta Z, 0 al 9, . y /. Referirse a crypt(3) para detalles acerca de como es interpretada esta cadena.


El dia del ultimo cambio de password es dado como el número de dias desde 1 Enero, 1970. El password no puede ser cambiado nuevamente hasta que esos dias hayan pasado, y debe ser cambiado antes número máximo de dias. Si el número mínimo de dias requerido es mayor que el máximo numero de dias permitido, este password no puede ser cambiado por el usuario.


Una cuenta es considerada como inactiva y deshabilitada si el password no es cambiado dentro de el número de dias especificado luego de que el password expire. Una cuenta tambien será deshabilitada en los dias especificados no obstante la información de expiracion restante.


Esta información trasciende cualquier password o información de tiempo de password presente en /etc/passwd.


Este archivo no debe ser leible por usuarios regulares si se mantendrá la seguridad de los passwords.


ARCHIVOS

/etc/passwd - user account information

/etc/shadow - encrypted user passwords


VER TAMBIEN

chage(1), login(1), passwd(1), su(1), passwd(5), pwconv(8), pwunconv(8), sulogin(8)


AUTOR

Julianne Frances Haugh (jockgrrl@ix.netcom.com)

De modo que tomando como ejemplo la linea correspondiente a mi usuario, en /etc/shadow , tenemos algo como esto:

jespinal:$1$N9L1HjIf$.YbfoPCCZmrqemk4zwYUb4:13918:0:::::0

Se sigue viendo medio feo, pero por lo menos se entiende, ya que sabemos que segun el man page:

Nombre de usuario

jespinal

Password Encriptado

$1$N9L1HjIf$.YbfoPCCZmrqemk4zwYUb4

Dias desde 1 Enero, 1970 que el password fue cambiado

13918

Dias antes de que el password pueda ser cambiado

0

Dias despues de los cuales el password debe ser cambiado

 vacio, es decir, no debo cambiarlo :)

Dias antes en los que el usuario será advertido antes de que el password expire

 tampoco estoy usando este campo 

Dias despues de 1 Enero de 1970, en los cuales la cuenta será deshabilitada luego del password expirar

ya que mi cuenta no va  a expirar, tampoco se usa esto

Un campo reservado

0

Te preguntaras, “Y ya!? es todo?"… respuesta: Si :yes: , es que cuando no nos detenemos a leer nos asustamos por poca cosa :))

Espero que este articulo te haya sido de utilidad, y que te aclare varias dudas.
Proximamente explicare la como es que se genera ese password encriptado (por si necesitas crear un usuario manualmente ;) )

Hasta pronto.

--
Jose P. Espinal
http://blog.slackware-es.com

/etc/passwd - El archivo de passwords

08.08.08 | by José P. Espinal [mail] | Categories: Administración, General

En ocasiones, cuando uno es nuevo en Linux, se le ocurre abrir el archivo /etc/passwd; pero inmediatamente lo hacemos y vemos el formato de ‘eso’ (asi le llamamos en ese momento), lo cerramos rapido con intención de no volver a abrirlo y con la esperanza de nunca tener que editarlo manualmente.

Hoy estaremos estudiando ese archivo de forma detenida, y esperando que la próxima vez que lo abran, sea una experiencia menos traumática.

Dirijanse al directorio /etc/ y abran su archivo ‘passwd’.

Mi /etc/passwd luce algo como así:

root:x:0:0::/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
adm:x:3:4:adm:/var/log:/bin/false
lp:x:4:7:lp:/var/spool/lpd:/bin/false
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/:/bin/false
news:x:9:13:news:/usr/lib/news:/bin/false
uucp:x:10:14:uucp:/var/spool/uucppublic:/bin/false
operator:x:11:0:operator:/root:/bin/bash
games:x:12:100:games:/usr/games:/bin/false
ftp:x:14:50::/home/ftp:/bin/false
smmsp:x:25:25:smmsp:/var/spool/clientmqueue:/bin/false
mysql:x:27:27:MySQL:/var/lib/mysql:/bin/false
rpc:x:32:32:RPC portmap user:/:/bin/false
sshd:x:33:33:sshd:/:/bin/false
gdm:x:42:42:GDM:/var/state/gdm:/bin/bash
apache:x:80:80:User for Apache:/srv/httpd:/bin/false
messagebus:x:81:81:User for D-BUS:/var/run/dbus:/bin/false
haldaemon:x:82:82:User for HAL:/var/run/hald:/bin/false
pop:x:90:90:POP:/:/bin/false
nobody:x:99:99:nobody:/:/bin/false
jespinal:x:500:100:Jose P. Espinal:/home/jespinal:/bin/bash

…a primera vista, ‘espantoso’.

Este archivo incluye varias piezas de información para cada cuenta de usuario en el sistema.
Cada ‘pieza’ de información esta separada de la siguiente por ‘:‘ (dos puntos).

Evaluemos la siguiente línea de mi archivo para que entiendan mejor:

jespinal:x:500:100:Jose P. Espinal:/home/jespinal:/bin/bash

1) Primera pieza (’jespinal’):
Esta corresponde al ‘login name’ o nombre de usuario correspondiente al usuario que describe dicha linea. En este caso es ‘jespinal‘, pues ese es mi usuario :) , simple, no?.

2) La segunda pieza (’x'):
Corresponde al ‘password’ encriptado; sin embargo, esta ‘x‘ no es mi password, sino que asi se coloca porque el verdadero password no se almacena ahi , sino en ‘/etc/shadow’ (luego estudiaremos ese archivo, calma :) ). Toma en cuenta que si se esta haciendo uso de ‘/etc/shadow’ para almacenar los passwords, entonces en ese campo del /etc/passwd NO DEBE haber nada excepto la ‘x’.

3) Tercera pieza (’500′):
Corresponde al ID numérico del usuario. Como sabrás (y si no lo sabias, pues ya si), a cada usuario del sistema se le asigna, ademas del login-name, un ID numerico para identificarlo. Ese campo de /etc/passwd es el que se usa para registrar el ID numerico del usuario en cuestion.

4) Cuarta pieza (’100′):
Corresponde al ID numérico del grupo al cual pertenece el usuario. En mi caso, el usuario ‘jespinal’ tiene como grupo principal el grupo ‘users’, y ese es el ID numerico de ese grupo (luego estudiaremos /etc/group , que es ahi que se manejan los grupos y el ID que le otorgamos a cada grupo).

5) Quinta pieza (’Jose P. Espinal’):
Nombre del usuario, o Comentario; por ejemplo, en el caso del usuario de MySQL, usamos algo como ‘Usuario de MySQL’, aunque si quieres puedes usar ‘Pepito Perez’, el hecho es que sepas para que se usa este campo, el cual tambien puedes dejar vacio (’root’ usa este campo vacio, por lo general).

6) Sexta pieza (’/home/jespinal’):
Aqui se indica el directorio de trabajo inicial de cada usuario (o sea, su ‘home’).

7) Septima pieza (’/bin/bash’):
Indica el interprete de comandos que usara el usuario por default o el primer comando que ejecutara (ej. el usuario shutdown, y halt).

Fijate que en el caso de usuarios que solo se usan para ejecutar ciertos procesos (mail, uucp, news), el shell es ‘/bin/false’, el cual es un shell nulo para que este usuario no tenga otra utilidad mas que servir para que un proceso se ejecute a nombre suyo.

Ya, eso es todo; ves!? no muerde :>>.

Eso es practicamente todo lo relacionado a este archivo. Realmente facil de entender y de editar (si quieres cambiar algo).

Hasta luego; ya sabes: ‘man’ es tu mejor amigo en Linux.

--
Jose P. Espinal
http://www.slackware-es.com

Upgrade de Slackware 12.0 a 12.1

13/05/2008 | por José P. Espinal [mail] | Categorías: Configuración, Administración

Ok. te bajaste el DVD de Slackware Linux 12.1 y ahora te estarás preguntando si es necesario ‘reinstalar’ todo de nuevo, o si habrá una forma menos dolorosa y problemática de disfrutar de la nueva version de Slack. Pues bien, hoy estaremos viendo como hacer un Upgrade desde Slackware 12.0 a 12.1.

Imaginemos que el archivo ISO que descargaste de Slackware se llama slackware-dvd.iso y que lo tienes en /home/pepito/slackware-dvd.iso (Imaginando que tu username es pepito :) ).

Yo personalmente suelo hacer upgrades desde el mismo .iso sin quemarlo en el CD (o DVD), para esto solo tienes que montarlo en un directorio y listo :D

Primero, para hacer el upgrade, pon tu maquina en Single user mode, como root hacemos lo siguiente:

# telinit 1

Ok, ahora vamos a montar la imagen ISO de Slackware en el directorio /mnt/tmp haciendo lo siguiente: (como root)

# mount /home/pepito/slackware-dvd.iso -o loop /mnt/tmp

Con esto ya esta montada la imagen (read only, acuerdate, pero para nuestros fines esta bien).

A continuacion, entra al directorio ’slackware’ dentro de /mnt/tmp ,

# cd /mnt/tmp/slackware

Ahora bien,

Primero, para que las cosas no se pongan agrias en el proceso de upgrade, actualicemos en primer lugar las librerias compartidas de glibc.

# upgradepkg a/glibc-solibs-*.tgz

Actualicemos la herramienta de paquetes.

# upgradepkg a/pkgtools-*.tgz

Ok, ahora actualiza (e instala) el resto de las cosas.

# upgradepkg --install-new */*.tgz

Si quieres puedes usar este scriptcito, el cual viene (al igual que los demas en este articulo) en el cd/dvd de instalacion, para hacer el upgrade, porque el paso anterior te instala todos los paquetes de lenguaje de KDEI.

    #!/bin/sh
    for dir in a ap d e f k kde l n t tcl x xap y ; do
      ( cd $dir ; upgradepkg --install-new *.tgz )
    done

Ok, ahora ASEGURATE de ejecutar Lilo nuevamente para instalar Linux Loader.
Ahora te explico por que. Sucede que Lilo debe generar un archivo llamado ‘map’ , el cual le indica al Bios en que lugar fisico exacto se encuentra el Kernel en el disco duro, si olvidas ejecutar Lilo, lo mas seguro (99.99 %) que veras un precioso ‘Kernel Panic’.

Ahora, (esto es opcional, pero recomendado) remueve los paquetes obsoletos:


a/util-linux: Removido (reemplazado por util-linux-ng).
ap/espgs: Removido. Reemplazado por ghostscript.
ap/gimp-print: Removed. Reemplazado por gutenprint.
e/emacs-info: Removido (ahora esta incluido en monolithic emacs package).
e/emacs-leim: Removido (ahora esta incluido en monolithic emacs package).
e/emacs-lisp: Removido (ahora esta incluido en monolithic emacs package).
e/emacs-misc: Removido (ahora esta incluido en monolithic emacs package).
e/emacs-nox: Removido (ahora esta incluido en monolithic emacs package).
l/libmusicbrainz: Removido.
l/libtunepimp: Removido
l/mcs: Removed (renombrado a l/libmcs).
x/dejavu-ttf: Renombrado a x/dejavu-fonts-ttf.
x/xorg-server-xdmx: Removido.
extra/ham: Removido por falta de mantenimiento.
extra/intel-wlan-ipw3945/*: Removido, el soporte a este dispositivo ahora es incluido en el Kernel.
extra/linux-wlan-ng: removido, esto no compila con los kernels 2.6.24.x
extra/ntfsprogs: Actualizado, movido a los paquetes AP
extra/xf86-video-ati-6.6.3: Removido.
pasture/gcc-3.4.6/: Removido.

Por ultimo, tienes que arreglar los archivos de configuracion. Debes revisar los archivos .new, modificarlos y hacer los ajustes suficientes y renombrarlos (quitarles el .new ) para que sobreescriban los viejos.

Te sientes con valor :>> ? , aqui te dejo este script que renombrara los archivos de configuracion viejos con .bak y movera los .new a su lugar original. Luego puedes evaluar los .bak y hacer los ajustes a los nuevos archivos de configuracion ;) , eso si, OJO: vas a usarlo (si es que lo usas) bajo tu PROPIA responsabilidad!, ok? Ok.


#!/bin/sh
cd /etc
find . -name “*.new” | while read configfile ; do
if [ ! “$configfile” = “./rc.d/rc.inet1.conf.new” \
-a ! “$configfile” = “./group.new” \
-a ! “$configfile” = “./passwd.new” \
-a ! “$configfile” = “./shadow.new” ]; then
cp -a $(echo $configfile | rev | cut -f 2- -d . | rev) \
$(echo $configfile | rev | cut -f 2- -d . | rev).bak 2> /dev/null
mv $configfile $(echo $configfile | rev | cut -f 2- -d . | rev)
fi
done

Listo, ya puedes regresar a RunLevel 3 (si ese es el que usas, si no, vuelve a tu runlevel)

# telinit 3

Para este entonces ya deberias estar corriendo Slackware 12.1 :)

Buena suerte,

--
Jose P. Espinal
http://www.slackware-es.com

Apache HTTP Server, PHP, MySQL

10.05.08 | by José P. Espinal [mail] | Categories: Configuración, Administración

… bien, acabas de instalar Slackware y te gustaría probar localmente una aplicación que use Apache, PHP y MySQL, pero te das cuenta que no viene preconfigurado por defecto. ¿Qué hacer?.

Bueno, primero vamos con Apache.

Comencemos editando el archivo ‘/etc/httpd/httpd.conf’ , busquen la línea que tiene algo como esto y descoméntanla:

Include /etc/httpd/mod_php.conf

Con eso de ahi arriba ya PHP esta habilitado ;) , ahora es recomendable agregar la posibilidad de que un ‘index.php’ sea considerado indice de directorio, no solo los ‘index.html’, asi que en la sección que dice:

Code:

<IfModule dir_module>
    DirectoryIndex index.html index.php
</IfModule>

Nota: he agregado ‘index.php’ a esa sección.

Ya puedes reiniciar Apache:

# /etc/rc.d/rc.httpd restart

Ahora solo resta configurar MySQL (Tal vez habrás notado que en la instalación por default, si lo arrancas, se detiene al rato dando un error).

Primero vamos a instalar las bases de datos que usa en motor de MySQL.

# su mysql
# mysql_install_db

Notas:
a) No olvides la partecita ’su mysql’ para que los permisos sean correctamente asignados.
b) El usuario mysql ya existe por default en nuestro sistema con privilegios mínimos.

Luego de que hemos instalado las bases de datos iniciales, podemos iniciar MySQL de la siguiente manera:

chmod 755 /etc/rc.d/rc.mysqld
/etc/rc.d/rc.mysqld start

Cambiar los permisos de rc.mysql a 755 nos garantiza dos cosas:
a) Que si el script no estaba ejecutable, lo este antes de que lo usemos ;)
b) Que MySQL suba cuando iniciemos nuestro sistema.

Y listo, con esto ya tienes Apache HTTPD, PHP y MySQL corriendo :)

NOTAS ADICIONALES:

1.1 Por cuestion de seguridad, es muy importante cambiar el password del usuario root, el cual, por defaul es nulo (en blanco).

Para esto, luego de haber levantado MySQL ejecuta lo siguiente:

# mysqladmin -u root password 'tu_nuevo_password'
# mysqladmin -u root password 'tu_nuevo_password' -h localhost -p

OJO: Luego del segundo comando, te pedira password ya que con el primero le asignaste a root un nuevo password; el password que usaras, obviamente, es el que le acabas de asignar a root.

1.2 Por cuestiones de seguridad (tambien), por default el archivo /etc/rc.d/rc.mysqld trae una linea que dice algo como:

SKIP="--skip-networking"

Debes comentar esta linea si quieres aceptar conexiones desde otras maquinas hacia MySQL. Lo que este parametro hace es que, al levantar MySQL, este solo escuche por sockets (localmente) y no por TCP/IP :P

Bueno, hasta la proxima, cualquier duda ya saben, me mandan un mensaje. Ahi nos vemos.

--
Jose P. Espinal
http://www.slackware-es.com

Slackware Linux : VSFTPD

04.05.08 | by José P. Espinal [mail] | Categories: Configuración, Networking, Administración

Buenas noches!! B) (es de noche mientras escribo esto); Hoy tendremos la oportunidad de configurar un server FTP para nuestro sistema.

He elegido VSFTPD (Very Secure FTP Daemon) por varias razones muy personales (es decir, no tienen que tomarlas como punto de referencia para elegir un server FTP para su sistema):

a) Es MUY rapido. Como trabajo administrando servers de hosting he tenido la oportunidad de probar otros, y definitivamente, este es rapido!.

b) Seguro, muy seguro. Es tanto asi que es el server FTP que trae OpenBSD; que, creanlo o no, es el Sistema operativo mas seguro.

c) Facil de configurar!! (muy facil, en serio)

El archivo de configuracion trae por default (en Slackware, no en la instalacion desde el source) las siguientes opciones con las cuales se puede correr el server FTP luego de ser modificadas a tu gusto:

#
# Los settings compilados por default son casi paranoicos. Este
# ejemplo floja un poco las cosas para hacer el server de FTP un
# poco mas util.
#
# LEE ESTO!!!!!!!!: Este ejemplo no es exhaustivo en los detalles
# de configuracion. Favor de dirigirse a la documentacion en la
# pagina oficial y al man page.
#
# Permitir FTP anonimo? (Ten cuidado, porque estara habilitado por
# default si comentas esta opcion ).
anonymous_enable=NO

# Permitir a los usuarios locales loggearse?
local_enable=YES

# Permitir cualquier tipo de escritura via FTP
write_enable=YES

# El umask por default para los usuarios locales es 007.
# Tal vez desees cambiar esto a 002, si eso es lo que esperan
# tus usuarios. (002 es el default en la mayoria de ftpd's)
local_umask=022

# Activar mensajes de directorios - mesajes dados a los usuarios
# cuando se dirijan a cierto directorio.
dirmessage_enable=YES

# Activar el registro de transferencias
xferlog_enable=YES

# Asegurarnos de que el puerto de transferencia se origine 
# desde el puerto 20 (ftp-data)
connect_from_port_20=YES

# Si quieres, puedes cambiar los permisos a un usuario diferente
# del usuario utilizado para subir los archivos. Por favor no 
# uses 'root', te puedes arrepentir luego.
chown_uploads=YES
chown_username=ftp

# Puedes sobreescribir donde se tendra el archivo de logs.
# El default es el siguiente:
xferlog_file=/var/log/vsftpd.log

# Si quieres, puedes tener tu logfile en un formato standard de
# ftpd-xferlog
xferlog_std_format=YES

# Puedes cambiar el valor por default para desconectar una conexion
# resagada
idle_session_timeout=1300

# Puedes cambiar el valor por default para desconectar una conexion
# de data
data_connection_timeout=300

# Es recomendable que definas un usuario en tu sistema, unico, el
# cual pueda ser utilizado totalmente aislado y sin privilegios.
nopriv_user=ftp #slackware trae este creado ya ;)

# Habilita esto y tu server reconocera peticiones ABOR asincronicos.
# Se considera no recomendable por cuestiones de seguridad.
# Sin embargo no usarlo podria confundir viejos clientes FTP
async_abor_enable=YES

# Por default el server pretendera permitir ASCII mode pero en 
# realidad ignorara esas peticiones. Enciende la opcion mas abajo
# para que el server en realidad maneje peticiones ASCII.
# Ten MUY en cuenta que en algunos FTP servers, soportar ASCII
# puede permitir un ataque de denegacion de servicio (DoS) a travez
# del comando "SIZE /big/file/" en ASCII mode. vsftpd predijo este
# ataque y siempre ha sido seguro reportando el tama~no del archivo
# en crudo.
# 
ascii_upload_enable=YES
ascii_download_enable=YES

# Puedes customizar completamente la cadena de anuncio al
# iniciar sesion
ftpd_banner=Bienvenido a Slackware-ES FTP Server

# Si se activa esta opcion, puedes proporcionar una lista de 
# usuarios que seran colocados en su directorio home mediante 
# chroot() cuando inicien sesion.
# Ahora bien, el significado es un poco diferente si se usa la 
# opcion chroot_local_user en YES.
# En este caso, la lista se vuelve un listado de usuarios a los que 
# NO se le hara chroot() a su home.
chroot_list_enable=YES
chroot_local_user=YES
chroot_list_file=/etc/vsftpd.chroot_list

# Nota: Esto se vuelve medio confuso, si activas chroot_list_enable
# se supone que le daras al sistema una lista de usuarios para
# hacerles chroot() a su home. Si activas chroot_local_user, 
# entonces la lista indicara cuales usuarios NO quieres que se le 
# haga chroot() a su home.
# Yo personalmente activo chroot_list_enable y tambien activo
# chroot_local_user, sin embargo, dejo la lista vacia, asi le hago
# chroot() a TODOS ;)

#
# Puedes activar la opcion "-R" para el comando interno ls.
# Esto esta deshabilitado por predeterminado para evitar que los 
# usuarios remotos sean capaces de causar un excesivo I/O en sitios
# bastante grandes.
# De todas formas, algunos clientes FTP defectuosos asumen la 
# precedencia de "-R", asi que hay una razon de peso para
# habilitarla.
ls_recurse_enable=YES

# Para correr vsftpd en modo standalone (o sea, individual, no 
# por medio de inetd), descomenta la linea siguiente 
#listen=YES

Ahora bien, puedes copiar esa configuracion como ejemplo y guardarla como
/etc/vsftpd.conf y hacer lo siguiente:

Para iniciar tu servidor FTP en modo standalone (individual, no iniciado por inetd) ejecuta el comando ‘/usr/sbin/vsftpd &‘ (recuerda quitar el comentario a la linea liste=YES de vsftpd.conf para que no te de error)

Si quieres que cada vez que tu ordenador suba, el servicio FTP inicie automaticamente, simplemente edita el archivo ‘/etc/inetd.conf‘ y descomenta la linea que dicen lo siguiente:

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  vsftpd

Y listo, subira automaticamente siempre :) ,

No olvides crear el archivo /etc/vsftpd.chroot_list si utilizaste esta opcion ;)

Puedes crear uno vacio de la siguiente forma (como root, claro esta):

# touch /etc/vsftpd.chroot_list

Ya si, todo esta listo!.

Puedes probar conectandote por FTP (una vez que el server este ejecutandose), utilizando un usuario de tu sistema :) (el mismo que usas para loggearte tu, por ej.)

NOTAS:

a) La configuracionde vsftpd es (MUY!) amplia, si quieres ver mas opciones para ir configurando mas a fondo tu sistema, puedes ver la pagina del manual de vsftpd.conf

man vsftpd.conf

b) cuando hablo de hacer chroot() a un usuario a su /home , me refiero a que TODOS los comandos que ejecute cierto usuario por FTP estaran encapsulados (o enjaulados, como quieras) a su directorio /home a travez del comando chroot. Asumo que no te gustaria que ningun usuario de FTP este rondando por /var/lib o /etc/X11 , verdad?, lo mas prudente es que nadie salga de su /home asignado, cierto? Pues para eso es que se usa chroot() :P

Espero que esta info haya sido util!, cualquier cosa no dudes escribirme o enviarme un mensaje.

Cuidense!

--
Jose P. Espinal
http://www.slackware-es.com

Comando tar : Slackware Linux ( continuacion )

04.03.08 | by José P. Espinal [mail] | Categories: Administración, Comandos Linux

Hoy llegue a mi oficina un poco tarde, al revisar mi mail encuentro en mi inbox un mensaje de un colega linuxero (JCRP) que me planteo una peque~na pregunta (MUY apropiada) acerca de como hacer backups en dispositivos de cinta.

Pues bien; como sabran no soy un experto ni nada parecido, de modo que si me equivoco en algo por favor escribanme ;D

Lo primero que debemos hacer antes de crear un backup en una unidad de cinta es darse (leerse) un peque~no ‘man mt’ (si saben ingles. -Ahora que lo pienso, agregare una seccion en el blog para ir traduciendo las paginas de man-, si no es que ya alguien esta en eso por ahi :P )

La herramienta mt es la que nos permite controlar dispositivos de cinta mageneticos.

Manos a la obra:

Veamos el status de la cinta (opcional):

# mt -f /dev/sr0 status

Veamos en que bloque estamos (opcional):

# mt -f /dev/sr0 tell

Todo en orden? Continuemos. Primero, rebobinar la cinta:

# mt -f /dev/sr0 rewind

Luego de esto, digamos que quieres hacer un backup del directorio ORACLE , y que quieres comprimirlo ( ahorremos un poco de espacio :) ):

# tar -czf /dev/sr0 ORACLE/

Ahora, veamos un listado de los archivos que hemos respaldado (backup)

# tar -tzf /dev/sr0

(NOTA: recuerden ojearse las paginas de manual de ‘tar’, luego de que le coges el hilo a esta herramienta, te daras cuenta que es muy muy util)

IMPORTANTE:

Vamos ahora a restaurar el backup que hicimos en la unidad de cinta

# cd /
# mt -f /dev/sr0 rewind
# tar -xzf /dev/sr0 ORACLE

Ahora, descarguemos la cinta:

# mt -f /dev/sr0 offline

OPCIONAL:

Si quieres borrar datos de la cinta usa

# mt -f /dev/sr0 erase

Espero que este articulo haya sido de utilidad, ya que en realidad mi experiencia con dispositivos de cinta es casi nula :>> (la omnisciencia no es una de mis cualidades :P ). Cualquier cosa, me escriben ;)

--
Jose P. Espinal
http://www.slackware-es.com

Páginas: 1 2 >>

Buscar

Recomendados

[~] SQLninja
[~] XvidCap
[~] Free DNS
Marzo 2010
Lun Mar Mié Jue Vie Sáb Dom
 << <   > >>
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
¡el blog solicitada ya no existe más!
powered by b2evolution free blog software