“¿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

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 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 , 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

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

Luego de un buen tiempo sin postear (el tiempo es un factor relevante en esto), he decidido inaugurar en este a~no (ok, uso el teclado en Ingles, y no tengo ‘ñ’, en lo adelante cuando vean ‘~n’, ya saben a lo que me refiero) con algo nuevo.

Para orientacion de los lectores, y leccion a usuarios de M$ Winblows que creen en Linux estamos desamparados, cuando a tecnologia se refiere; he escrito este post

1. La magia de HAL (Hardware Abstraction Layer -Capa de Abstraccion de Hardware-)

Lo primero que debes saber es que es una ‘capa de abstraccion’.

Puesto en palabras simples, no es mas que una forma de esconder los detalles de implementacion de un conjunto dado de funcionalidades. Es decir, ocultar los detalles intimos acerca de como y por que funciona algo, y simplemente asegurarse de que funcione y darte acceso a dichas funcionalidades.

Entonces, HAL, es una capa de abstraccion entre el Hardware y el Software que corre en nuestro sistema. Este, se asegura de que las cosas funcionen, sin que tu tengas que saber por que, como y cuando (o intervenir en ello).

La funcion principal de HAL es proveer informacion al sistema operativo acerca del hardware conectado en nuestro sistema, independientemente del bus (ej. SATA, IDE, SCSI, PCI, PCIe, etc.) o el tipo de dispositivo (Camaras, Scanners, Printers, etc.)

Adicional a esto, HAL tambien mantiene metadata (meta, del griego μετά = mas alla, despues, , data = informacion) acerca de los dispositivos, la cual posibilita a los entornos graficos y otras aplicaciones, acceder a estos.

Nota: es demasiado lo que podriamos estudiar acerca de HAL, asi que por razones de brevedad, vamos a limitarnos (por ahora) a esto; en caso de que necesiten un estudio mas profundo acerca de HAL, saben donde encontrarme

2. UDEV , accediendo a los dispositivos.

Una vez que HAL ha provisto al Kernel de informacion acerca de un dispositivo conectado al sistema, entra en juego ‘UDEV’.

UDEV es el software encargado de proveer, en tiempo real, los accesos a dichos dispositivos en el directorio /dev. Este crea o remueve nodos a los dispositivos en el directorio /dev, y tambien es el encargado de renombrar las interfaces de red.

Por lo general udev corre como udevd, y recibe ‘uevents’ (notificaciones, eventos) directamente del Kernel si un dispositivo es agregado o quitado del sistema.

Conectarse a un Movil GSM

Habiamos visto que una vez que conectamos un dispositivo a nuestro sistema, HAL le da la informacion necesaria al Kernel, y este avisa a udev para que cree el nodo en /dev. Bien, esto tambien sucede al conectar nuestro telefono mobil a nuestro sistema.

En mi caso, estoy probando con un Sony Ericsson 550k, al conectarlo puedo ver que es reconocido como un ‘USB ACM device’ (Abtract Control Model).

Nota: En este articulo no voy, ni siquiera, a pasarle cerca a la explicacion acerca de que es ‘CDC ACM’ o ‘USB CDC’.

Para ver que informacion HAL le paso al Kernel, uso ‘demsg‘

# dmesg

Lo que me dice algo como esto:

usb 6-2: new full speed USB device using uhci_hcd and address 5
usb 6-2: configuration #3 chosen from 1 choice
cdc_acm 6-2:3.1: ttyACM0: USB ACM device
cdc_acm 6-2:3.3: ttyACM1: USB ACM device
usb0: register 'cdc_ether' at usb-0000:00:1d.0-2, CDC Ethernet Device, XX:80:XX:09:X3:XX

Veo que el dispositivo ha sido reconocido como una interfaz serial.

Ya que se con que nodo puedo conctarme al movil, (ttyACM0, ttyACM1) todo lo que tengo que hacer es utilizar el comando ‘cu‘ para conectarme, o utilizar la aplicacion ‘kandy’ que trae Slackware.

El comando ‘cu‘ se utiliza para llamar a otro sistema y actuar como un marcador de la terminal. También puede hacer transferencias de archivos simples, sin comprobación de errores.

Ya que el dispositivo movil se comporta como una interfaz de comunicaciones, por default udev creara el nodo en /dev como /dev/ttyACM0 o /dev/ttyACM1 con permisos de root:uucp (root , unix to unix copy). Para poder conectarte a el tienes que agregar el grupo ‘uucp’ como grupo adicional de tu usuario en el sistema:

# usermod -G uucp jespinal

Luego de hacer esto, tienes que salir del sistema y volver a entrar (para que tu usurio asuma los privilegios adicionales del grupo uucp, y puedas conectarte al movil utilizando ‘kandy’)

Una vez que hayas hecho esto, puedes configurar ‘kandy’ para que sue se conecte a tu movil, en mi caso utilizo el nodo /dev/ttyACM0. Con esto podras sincronizar tus contactos del movil con KDE Address Book, etc. (Cosas que realmente no utilizo para NADA, pero, es posible que alguno de mis lectores encuentre util )

Espero que esta informacion haya sido util a muchos usuarios de Linux que, posiblemente, se hayan encontrado con la duda en este sentido.

Hasta luego,

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

Este cuatrimestre en la universidad me encontré con la sorpresa de que, para programación, nos iban a impartir clases de C# (C sharp).

Un poco de historia al asunto:
C sharp es un lenguaje de programación creado por Microsoft pero abierto al público (esta parte me sorprendió, realmente) por medio de unas estandarizaciones, como por ejemplo ISO, y ECMA (Standard Computer Manufacturers Association). De modo que ya no es solo para productos Microsoft.

Problemática:
Sin importar la razón que fuese, no tenía (ni tengo) ninguna intención de blasfemar la integridad de mi disco duro instalando Microsh*t Winblows; de modo que anduve buscando opciones.

Alternativa:
Encontré a “Mono", un compilador de C# para Linux que es asombrosamente compatible con el framework .NET de M$ft. Entre las cosas que me motivaron a verlo con buen ojo, están:

1. Multi Plataforma:
Corre en Linux, OS X, BSD, y Microsoft Windows, incluyendo x86, x86-64, ARM, s390, PowerPC y varias más, de modo que si te decides a programar en C#, tus clientes potenciales son muchos.

2. Multi Lenguaje:
Puedes programar en C# 3.0 (incluyendo LINQ), VB 8, Java, Python, Ruby, Eiffel, F#, Oxygene, y varios más.

3. Está auspiciado por Novell (hay dinero de por medio invertido en esto).

4. Etc.

Para obtener la ultima versión estable de Mono, solo hay que ir a su área de descarga: http://ftp.novell.com/pub/mono/sources-stable/

Luego de bajarlo, puedes instalarlo sin ningún problema siguiendo unos pasos de instalación básica que trae.

$ ./configure
$ make
# make install

MonoDevelop , el gran reto:
Aunque el proceso de instalacion de Mono es muy sencillo, realmente no se puede decir lo mismo de la interfaz de desarrollo que se usa para esas cuestioncitas .NET (en Linux). Realmente no es ‘dificil’, pero es bien trabajoso y puede ser hasta frustrante si no se hace en un orden correcto (lo digo por experiencia).

Si eres usuario de Slackware, y tienes la version 12.1 o cercana, es probable que no tengas instalado Gnome (como me pasó a mi). Si lo tienes instalado, felicidades, no creo que te falte nada.

A los que no tenemos Gnome instalado, nos hace falta tener algunas dependencias; las cuales deben ser instaladas en cierto orden para evitar infartos. Luego de instalar todo, y haber tomado notas del orden de instalación, me gustaría compartirlo con el publico .

El orden de las dependencias es el siguiente:

1. Mono.Addins 0.3.1
   
   • gtk-sharp
     
     • pango
       
       • glib-2.18.2
2. Gtksourceview#-2.0 0.10
3. Monodoc 1.2.6
4. MonoDevelop Source
   
   • gtksourceview-sharp-2.0
     
     • gnome-sharp-2.0
       
       • libgnomecanvas
         
         • gail

       • libgnome

         • gnome-vfs-2.0
           
           • gconf-2.0
             
             • ORBit-2.0

       • libbonobo-2.0

         • libgnomeui
           
           • libbonoboui-2.0
           • gnome-keyring-1
             
             • LibtASN1

       • libgnomeprint

         • libgnomecups-1.0
       • libgnomeprintui

       • gnome-panel

         • gtk+-2.0 >= 2.13.1 (desinstalar las que trae Slackware)
           
           • cairo >= 1.6 (desinstalar el que trae Slackware)
             
             • pixman-1 >= 0.12.0
         • gnome-desktop-2.0
           
           • gnome-doc-utils >= 0.3.2
         • gnome-menus
         • libwnck-1.0 >= 2.19.5
         • gweather
           
           • libsoup-2.4
     • gtksourceview-1.0

as mas produndo en el orden previo este la libreria, debes darle prioridad en la instalacion; es decir, si te fijas en la lista anterior, te digo ahi que debes instalar gtksourceview-sharp-2.0. Pero para eso necesitas previamente algunas librerias, como por ejemplo gnome-sharp-2.0, quien a su vez depende de varias mas, como es el caso de libgnome ( pero necesitas instalar ORBit-2.0, luego gconf-2.0, luego gnome-vfs-2.0, y luego es que vas a instalar libgnome).

Todo el proceso te puede tomar de 30 minutos, a incluso varias horas. Si haces caso de la lista de dependencias que puse ahi arriba, puede ser rapido y sin complicaciones.

NOTA, cuando alguna dependencia dice nombre-xx-2.0 , no necesariamente buscaras la version 2.0, sino la version que en la rama 2.x este como estable.

Y por ultimo, los sources y librerias (requisitos, dependencias), puedes encontrarlos aqui: http://ftp.gnome.org/pub/GNOME/sources/ (casi todos).

A excepcion de uno o dos que no estan ahi porque no son desarrollados por Gnome. Pero son MUY facil de encontrar en google.

Finalmente:
El tomarse el tiempo de instalar o no Mono, MonoDevelop IDE, depende de que tanto te moleste o no la idea de tener que instalar Windows en tu PC. En mi caso preferiria comprar otro disco que luego pueda arrojar a la basura en caso de que le pase algo

Espero que esta lista les haya sido util, y que les ahorre tiempo.

Hasta luego,

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

… 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 , 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

Definitivamente, luego de haber entrado en el mundo de Slackware Linux, Los ‘man pages’ (páginas de manual) y Google serán tus mejores amigos; y más que eso, tu Shaman y tu Guía, respectivamente.

Relmente no tenía tiempo para escribir hoy, estoy algo atareado por cuestiones laborales, y me senté un rato en mi PC a descansar, hasta que de pronto… ‘tucutú’ , el horrible sonidito de aMSN indicando que alguien me ha hablado.

Sin mucho ánimo, muevo mi brazo hasta alcanzar el mouse, le doy click a la … ventanita esta!, pensando que es algo importante (puesto que mi estado esta en ‘away’) y de pronto: alguien preguntandome algo que estoy ultra seguro que Google en su inmensa sabiduría ha respondido ya de muchas maneras.

Mi respuesta fue simple:
RTFM! (Read The F—-ng Manual) , lo cual no me ayudo mucho, pero me desahogó…

En esta ocasion vamos a tratar de entender unos cuantos tips de nuestro gran amigo ‘man’ (manual).

Si escribimos en consola:

# man man

Estaremos llamando el manual del manual pages, el cual muestra algo como esto:

NOMBRE
       man - formatea y despliega las paginas online del manual

SINOPSIS
       man  [-acdfFhkKtwW]  [--path]  [-m  system]  [-p  texto] 
            [-C config_file] [-M pathlist] [-P pager] [-B navegador]
            [-H htmlpager] [-S section_list] [section] nombre ...

DESCRIPCIÓN
       man formatea y despliega las paginas online del manual.  si
       le especificas la sección, man unicamente buscará en esa
       sección del manual.
       nombre , normalmente es el nombre de la página
       del manual, la cual es típicamente el nombre del comando, 
       función, o archivo. Sin embargo, si el nombre contiene una
       barra (slash, '/'), entonces man lo interpretara como la 
       especificacion de un archivo,  
       de modo que puedes hacer:
       man ./foo.5 o incluso man /cd/foo/bar.1.gz.

Entre otras cosas…

1. Todos los parametros que esten incluidos en llaves, indican que son opcionales, y no es explicitamente necesario indicar uno o más de ellos. Ej.

[-acdfFhkKtwW]  [--path]  [-m  system]

me parece que esa sintaxis es un estandar de documentación, puesto que incluso la documentación de muchas otras cosas usan este formato. (ej. PHP, PERL, C, etc. etc.)

2. Los parametros que no aparezcan dentro de llaves, son obligatorios. Ej.
nombre

3. Una sinopsis es una definicion resumida y generalizada acerca de algo, los detalles de todos los parametros opcionales y obligatorios, son descritos mas abajo, de modo que tendras que desplazarte a travez de toda la pagina del manual para poder entender cierta documentacion.

4. Los manuales siempre hacen refencia a otras paginas de manual, diciendo algo como:

SEE ALSO
       apropos(1), whatis(1), less(1), groff(1), man.conf(5).

En este caso (y muy pertinentemente, hacen referencia a la pagina numero (1) del comando ‘apropos’, el cual es bastante util buscando en diferentes paginas de manual.

5. Cuando veas algo como man.conf(5), quiere decir que debes buscar en la pagina (5), del manual:

man 5 man.conf

6. Para saber cuales paginas de manual hablan acerca de cierto termino, usamos ‘apropos’, ej:

apropos ssh

nos desplegara (entre otras cosas) algo como esto:

hfssh                (1)  - Tcl interpreter with HFS extensions
ssh                  (1)  - OpenSSH SSH client (remote login program)
ssh-add              (1)  - adds RSA or DSA identities to the authentication agent
ssh-agent            (1)  - authentication agent
ssh-copy-id          (1)  - install your identity.pub in a remote machine's authorized_keys
ssh-keygen           (1)  - authentication key generation, management and conversion
ssh-keyscan          (1)  - gather ssh public keys
ssh-keysign          (8)  - ssh helper program for host-based authentication
ssh_config           (5)  - OpenSSH SSH client configuration files
sshd                 (8)  - OpenSSH SSH daemon
sshd_config          (5)  - OpenSSH SSH daemon configuration file

indicando el nombre y numero de la pagina de manual que hace referencia al termino que estuvimos buscando, para visualizar, hacemos igual que como hicimos anteriormente:

# man 5 ssh_config
# man 8 sshd
# man 1 ssh-keygen

7. Si no te gusta leer man pages en consola, puedes abrir konqueror y poner algo como esto en la barra de direcciones:

man:/cp
Para ver el manual del comando cp , por ejemplo, y asi sucesivamente.

8. Es cierto que no es lo mas sencillo del mundo entender man pages, pero tambien es cierto que no es lo mas dificil. Simplemente lee con detenimiento, sin desesperarte y trata de no pasar por alto nada, por mas elemental que parezca.

Entender y familiarizarte con ‘man’ te van a economizar tiempo, y sobre todo, podras evitar algunas de estas respuestas:
RTFM (Read the F—-ng Manual)
RTMFM (Read The Mother F—-ng Manual)
JFGI (Just F—-ng Google It)
STFW (Search the F—-ng Web)
Entre otros…

Espero que este articulo te haya ayudado a comprender e interesarte mas por ‘man’, a la vez que te ayude a invitar a otros a usar Google cuando piensan que eres una enciclopedia online en MSN.

NOTA:
Ayudar al otro implica que logre su propósito. Si ese otro no se interesa en aprender o investigar, es porque su principal propósito es permanecer en ignorancia, así que no le des la respuesta a sus preguntas, y estarás ayudandolo igualmente

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

Por primera vez (eso realmente no lo se, pero yo no había visto otro) se está realizando un concurso de Blogs en República Dominicana. No recuerdo bien como fue que me enteré de el concurso, pero decidí inscribir este blog , a ver si el destino se equivoca y por alguna remota razón (que no nos detendremos a imaginar cual sería), pues… ganamos.

Bueno, sin mas preambulos, si quieres votar haz click en esta imagen y busca mi blog en la seccion ‘TEMATICOS‘:

Luego les cuento como se dió este asunto

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

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